If you use DNS as you way of doing your investigation, you don’t really even need an account in the domain, or any of it’s trusted domains. DNS lookups generally don’t have permissions (although there are exceptions in a poorly configured DNS server).
However, the problem still remains:
[...] with an LDAP query. Ask for a standard user account for the other domain, use an LDAP query with a search and grab the DistinguishedName cut of the domain suffix, and you'll have your NETBIOS name.
This only works if the Distinguished domain name is the same as the NetBIOS domain (ie: If you assume AD.Mycorp.local has a DN of ‘AD’ however, this is not really a valid test because who ever created the domain may have given AD.Mycorp.local a NetBIOS name of ‘Root’). So while this may work, it’s relying on luck more then anything else. It also assume you allow anonymous look ups against the target domain (which is very often turned off as a security precaution).
If querying has been locked down for whatever reason so you can't use a standard account, ask for delegated rights to the OU with the computers in with list permissions (can't recall the exact property name required), and you will then be able to use your LDAP query.
First step, make sure your doing a BIND against the LDAP server WITH credentials. List permissions to the domain are almost always granted to authenticated users so that workstations can find their place before they are logged in, and so users can be located before authenticated so that the ID in question can be authenticated. If your workstation can’t find your ID, it has no way of knowing what policies need to be applied to that ID (as in what OU is your account a member of).