When a trust is established between a domain in a forest and a domain
outside of that forest, security principals from the external domain
can access resources in the internal domain. Active Directory creates
a foreign security principal object in the internal domain to
represent each security principal from the trusted external domain.
These foreign security principals can become members of domain local
groups in the internal domain. Directory objects for foreign security
principals are created by Active Directory and should not be manually
modified. You can view foreign security principal objects from Active
Directory Users and Computers by enabling advanced features.
So your "Unknown Contact" is what's known as a foreign security principal in Domain2. There is a container in the default naming context of your directory at
CN=ForeignSecurityPrincipals,DC=domain2,DC=com. Inside that container should be pointers that Active Directory will use to resolve all the people from Domain1 that are known to Domain2. Domain2 knows the SIDs, but it has to ask Domain1 to kindly translate that SID into a SamAccountName.
Because your trust is one-way, Domain2 can't do that because Domain1 doesn't trust it.
You could enable anonymous SID translation in Domain1, but that's a security risk. Or you could make your trust 2-way.
What you have now, "Unknown Contact" isn't preventing anything from working as you have noticed, as the SID is sufficient to check forest trust. It's just kind of an aesthetic problem right now.
More MS documentation:
LookupAccountSid will call into LsaLookupSids with a single SID to
resolve. So LsaLookupSids is covered in this section.
LSA on the computer that the call is sent to (using the LSA RPC
interface) will resolve the SIDs it can map and send on the remaining
unresolved SIDs to a domain controller in the primary domain. The
domain controller will resolve additional SIDs to account names from
the local database, including SIDs found in SidHistory on a global
If SIDs cannot be resolved there, the domain controller will send
remaining SIDs to domain controllers in a trusted domain where the
domain part of the SID matches the trust information.
And finally, this bit from the Microsoft AskDS blog (which is a great blog btw):
Assuming the ports are open, there is some other piece blocking the
translation. Most commonly, we will see this when there is a one way
trust involved and anonymous translations are blocked. You can easily
allow anonymous SID/Name translation in Group Policy. This policy is
only applied to Domain controllers since they are the servers that
will actually process the translation request.
Edit: As a workaround, you could consider creating a security group in Domain2 called "People who can access Apps on Server2" and add the user principals from Domain1 to that group.