Domained laptop - slow logon when connected to non-domain network

Question

Hi,
I'm looking for ideas on how to solve or workaround this issue, so any help would be appreciated.  Please note that this doesn't appear to be the usual type of "slow login" problem - in fact I'm pretty certain the issue is caused by public DNS
servers which return placeholder IP addresses for unknown domains, rather than correctly reporting them as being unknown, which is making XP "hang up" looking for servers which don't really exist.  Either way, it's causing a lot of problems for our remote
users.
The scenario is this.  When domain-member laptops are not on the domain network, they can take anywhere between 5-30 minutes to login.  This issue only occurs when the network they're connected to presents DNS servers which resolve unknown DNS
hosts/domains to "placeholder" sites.  Whilst Windows 7 laptops do also seem to suffer from this, login delays on those are at worst a couple of minutes, whereas the Windows XP machines are affected for much longer.
Maybe a bit more info will make it clearer :)
The AD namespace shares the external domain, and there are public DNS records for the external domain, but obviously not for internal hosts (like DCs).  So internally, the FQDNs of the domain controllers are "DC1.company.com", "DC2.company.com" etc.
When the laptop is connected to users home network, users can logon quickly (<30 seconds), as long as the DNS server offered by DHCP on that network doesn't return an IP for hosts/domains which don't exist publicly.  If they do, login takes 5-30 minutes.
I've confirmed this by doing a lookup of the domain on the affected networks to ascertain which DNS servers return placeholder IPs rather than reporting that name resolution isn't possible.  For example, OpenDNS's servers (208.67.222.222, 208.67.220.220)
return placeholders, Google's (8.8.8.8, 8.8.4.4) don't.  Using OpenDNS to lookup "dc1.company.com" returns their placeholder IP of 67.215.65.132, using Google's returns "can't find dc1.company.com: Non-existent domain".  OpenDNS is being used
as an example, increasingly ISP's seem to be using redirection, we're getting this issue with BT and Virgin Media networks, plus a couple of others.
So, if I manually set DNS on a laptop to use Google's servers, then connect it to one of the affected networks, login is virtually instantaneous.  I remove the manually configured DNS servers and allow DHCP to present the ISP's own servers, login is
seriously delayed.
From this I can only assume that the fact that the names are resolving at all is causing the delay.  I've removed possibly contributory factors from the equation, such as roaming profiles, redirected folders, mapped drives, group policy etc which the
workstation might be trying to access and causing a delay, as well as checking that fast logon optimization is active.
At the moment we're having to tell users to not connect to the network until after they've logged in, which you'd think wouldn't be that big a deal but you know what users are like :) 
I appreciate this issue really seems due to bad practice by ISPs rather than with Windows itself, but we really need a fix we can apply ourselves.  Reconfiguring users' home networks really isn't an option, there's too many of them, plus that wouldn't
solve the problem when they're using other networks (hotels etc).  I don't think setting "good" DNS servers manually is an option, certainly I can't think of a way that would still work when they're connected to our internal LAN. 
I'm thinking there must be some way we can set a timeout or something on the workstations so they don't spend so long trying to communicate with what they think are domain servers, but dispite much searching, I've been unable to find anything that works.
So, any help would be gratefully recieved.
Thanks

Answer 1

Thanks for the reply Martin, unfortunately it didn't help matters, but after pondering for a while (and eventually kicking myself for missing something so obvious) I did come up with a solution.
Basically, just set up public DNS A records for the internal servers and point them to 127.0.0.1 (setting up a wildcard DNS entry for the domain also pointing to 127.0.0.1 would do the same thing).
Sure enough logon now takes about 5 seconds, even on the Windows 7 machines (which were only taking a minute or so anyway).
Loopback is the best place to point these to,  Pointing them to a public server didn't work, and pointing them at a non routeable private IP didn't work either. 
To help anyone else confirming this is also the cause of their slow logon issue - when all three conditions are met it's time to mess with your public DNS!
The FQDN of the domain is public (company.co.uk) and not local (company.local).
The DNS servers in use on the network (or the ISP's DNS servers to which DNS requests are forwarded) return placeholder IPs for unknown host addresses, rather than a "non-existent domain or host" error.  This can be confirmed by pinging (or doing an
nslookup) on the affected machine, for a host for which no public DNS record exists (ie ping wibble.microsoft.com) - if an IP address is returned then the DNS servers in use are resolving unknown hosts/domains to a placeholder IP.
If you allow the machine to login on the external network, then run a
ipconfig /displaydns you'll see entries for attempts to resolve internal servers themselves, plus lookups relating to the AD domain such as
_msdcs.gc._tcp._ldap.internaldomain.co.uk and such - these shouldn't be there off-domain, and I believe they indicate the machine thinks it's on the domain, even though it isn't.
Hope this helps someone else out.
Ray Von