mDNSResponder won't flush DNS Server scope entries without reboot

I am having a problem with my mid 2012 13" MacBook Air - Lion 10.7.5 where when moving from my home network to office environment, I have to reboot before it will allow me to connect back to resources in my home network. The setup is:

home.net

Local DNS Server (Mountain Lion Server) which overloads the DNS resolution of *.home.net hosts to local network addresses. So there is a scope on the locally defined network (192.168.200.0/24) for .home.net where the the authoritative DNS response is delegated to the lcoal server and it returns local addresses. Then, outside of the network a public internet DNS service is authoratative and the same host(s) resolve to a routable IP address (let's call it 50.1.1.N).

So the result is on home.net - mail.home.net = 192.168.200.100, anywhere else mail.home.net = 50.1.1.5.

The problem is that when I suspend this computer and reanimate it on my office network, for some reason the .home.net hosts will no longer resolve. It gets a bit trickier because using some DNS tools like host/dig/nslookup, the local name server here on my network will return the correct response (mail.home.net = 50.1.1.5). However, using anything that actually uses the mDNSResponder mechanism (ping, traceroute, applications, VPN, etc.) it cannot resolve mail.home.net to an IP. The function tries, waits and eventually times out.

I have traced this back to mDNSResponder as the culprit. I have tried killing the proc (sudo killall mDNSResponder), I have tried the new (Lion/ML) way of flushing the cache (sudo killall -HUP mDNSResponder), I have tried unloading and loading via launchd, just for good measure I have even tried the Leopard/Snow Leopard method (sudo dscacheutil -flushcache). All to no avail. The only solution I have found to effect this condition is to reboot the system.

In the spirit of trying to understand the mDNSResponder cache state, I have followed the man page documentation and killed the proc, sending it's state to the System Log (sudo killall -INFO mDNSResponder) and this is an excerpt of what I found that is interesting:

1/17/13 2:58:29.065 PM mDNSResponder: --------- DNS Servers ----------

1/17/13 2:58:29.065 PM mDNSResponder: DNS Server . 172.22.186.6:53 0 30

1/17/13 2:58:29.065 PM mDNSResponder: DNS Server . 172.22.186.12:53 0 0

1/17/13 2:58:29.065 PM mDNSResponder: DNS Server home.net. 192.168.100.200:53 0 30

1/17/13 2:58:29.065 PM mDNSResponder: DNS Server home.net. 192.168.100.1:53 0 0

1/17/13 2:58:29.065 PM mDNSResponder: DNS Server . en0 4.2.2.1:53 0 Scoped 30

1/17/13 2:58:29.065 PM mDNSResponder: DNS Server . en0 4.2.2.2:53 0 Scoped 0

I am quite certain that these two lines are the root of my problem:

1/17/13 2:58:29.065 PM mDNSResponder: DNS Server home.net. 192.168.100.200:53 0 30

1/17/13 2:58:29.065 PM mDNSResponder: DNS Server home.net. 192.168.100.1:53 0 0

These are the dynamic DNS Server entries set by my home DHCP server and because they state that 192.168.200.100 is authoritative for home.net., mDNSResolver is trying to contact the DNS server at 192.168.200.100:53. But of course it doesn't exist in this network context and mDNSResolver will not fall back to any of the others listed in the global scope to resolve.

My question is why are the entries for home.net. still there? mDNSResponder has been flushed and recycled. The ip address has been dropped and renewed. My Wifi adapter has even been disabled and re-enabled. Is there nothing short of a kernel reboot that can flush these entries from the resolver?

BTW - I don't have this problem with Mountain Lion or either of my iOS devices so it appears to be something Lion specific.

Regards,

C