DIG question

Jonathan de Boyne Pollard J.deBoynePollard at Tesco.NET
Tue Apr 6 11:07:04 UTC 2004


S> Why in one case does BIND respond with its own data and in 
S> the other case goes to the Internet and fails?

Your question is a leading question based upon a false premise and is thus 
unanswerable.  It was _not_ "named" that "went to Internet and failed".  It 
was "dig".

In a "split horizon" DNS service scenario such as yours, DNS diagnosis 
utilities for tracing query resolution will only provide the same results as 
your resolving proxy DNS server does if they are configured with the same 
overrides of the delegation information in the public DNS database as your
resolving proxy DNS server is.  In this particular case, your DNS diagnosis 
tool would have had to have been told to override the contents of the public 
DNS database for "fakedomain.gr." and its subdomains.  (Of course, there's 
no actual way to do that with "dig".)  Since it wasn't, it didn't perform 
query resolution in the same way that your resolving proxy DNS server, that 
_did_ have the override, did.

Not following the same query resolution path as resolving proxy DNS servers 
actually follow is a fault that is endemic in DNS diagnosis tools that
attempt to trace query resolution.  In this case, it's simply a lack of
a feature in the tool to mirror the override feature in the resolving
proxy DNS server.  In other cases, the tool is severely broken.

<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/dnstracer-incorrect-algorithm.html>

For tracing the operation of query resolution, the best tool (and in the
case of "split horizon" DNS service the only tool) is usually the log 
output of the resolving proxy DNS server itself (provided in the normal 
course of operation by some DNS server softwares; provided when a special 
diagnostic option is enabled, by others).


More information about the bind-users mailing list