[UNsolved] was: what does dig +trace do?

Kevin Darcy kcd at chrysler.com
Wed Sep 7 00:07:17 UTC 2011


On 9/1/2011 7:57 PM, Mark Andrews wrote:
> In message<4E5FB1AB.4040005 at data.pl>, Torinthiel writes:
>> On 09/01/11 17:56, Tom Schmitt wrote:
>>> =20
>>> I found the cause of my problem (and a solution):
>>> =20
>>> dig +trace actually has another behaviour than doing the trace manually=
>>   step by step with dig.
>>> =20
>>> =20
>>> For a trace, dig is asking for the NS-records, then for the IP-address =
>> of the nameserver found and then go on asking this nameserver. Till the d=
>> estination is reached.
>>> =20
>>> In my case, dig is asking for the nameservers of the root-zone and is g=
>> etting the answer:
>>> . IN NS root1
>>> . IN NS root2=20
>>> etc
>>> =20
>>> Next dig is asking for the A-record of root1. And here is the differren=
>> ce:
>>> =20
>>> If I do "dig root1" dig is asking exactly this, it is asking for the A-=
>> record of root1. And of course I get the correct answer from named.
>>> =20
>>> The +trace option does not do this!
>>> Instead, the +trace-option is using the searchsuffix in the resolv.conf=
>>   and is asking for root1.my.search.suffix. and NOT for root1.
>>> This is why the +trace option fails every time.
>>> =20
>>> After deleting the searchsuffix in resolv.conf, dig +trace is working f=
>> ine without any error.
>>> =20
>>> In my oppinion it's a bug that dig +trace behave in a differrent way th=
>> an doing the queries with dig one by one.
>>
>> No, IMHO, it's a bug in your root zone.
>> Names without dot at end are relative. Change your root zone to say
>> =2E IN NS root1.
>> =2E IN NS root2.
>>
>> (with dots appended) and you should be home.
> "dig +trace" calls getaddrinfo() and that needs to be able to resolve
> the hostname (without dots at the end).  getaddrinfo() is called
> so that we don't have to have a full blown iterative resolver in
> dig.
>
> The Internet moved from being a flat namespace (names without dots)
> for hostnames to a heirachical namespace (names with *internal*
> dots) a 1/4 century ago.  http://tools.ietf.org/html/rfc921
>
> Hostnames without dots are now local (e.g. localhost) or need to
> be qualified (resolv.conf: search).

Actually, RFC 1123 requires a way to suppress domain suffixing, and 
mentions the "trailing dot" convention:

6.1.4.3 Interface Abbreviation Facilities

User interfaces MAY provide a method for users to enter abbreviations 
for commonly-used names. Although the definition of such methods is 
outside of the scope of the DNS specification, certain rules are 
necessary to insure that these methods allow access to the entire DNS 
name space and to prevent excessive use of Internet resources. If an 
abbreviation method is provided, then:

(a) There MUST be some convention for denoting that a name is already 
complete, so that the abbreviation method(s) are suppressed. A trailing 
dot is the usual method.

But it appears that getaddrinfo() doesn't, apparently (according to a 
quick wrapper program I tested with) support the "trailing dot" 
convention for suppressing domain suffixing, or, AFAIK, any other way to 
suppress domain suffixing, therefore "dig +trace" is stuck either -- as 
you said -- implementing a full iterative resolver itself, or calling 
getaddrinfo() and confusing the user with unwanted domain suffixing, in 
the special case of a delegation to a root name.

Let's be clear, though: dig +trace *should* be able to deal with a 
delegation to a root name, as twisted and obscure as that is. It only 
fails to do so because of some design decisions/tradeoffs made with 
getaddrinfo() and/or dig itself. Not because the user is doing something 
"wrong".


                                                                         
                                                                 - Kevin




More information about the bind-users mailing list