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

Wed Sep 7 20:56:33 UTC 2011

On 9/6/2011 8:40 PM, Mark Andrews wrote:
> In message<4E66B5B5.30200 at chrysler.com>, Kevin Darcy writes:
>> 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".
> Well really they are.  Address records on TLD labels will *never*
> work reliably unless you can get the world to agree to stop using
> search lists.
Seriously, if a TLD label *only* appears in the RDATA of NS records, and 
*never* as a "hostname" (in the RFC 952/1123 sense), why would we worry 
about searchlisting complications?

And even if a TLD label is presented at the user-to-program interface, 
as long as the prevailing convention for disabling searchlists 
(mandatory as per RFC 1123) is present (e.g. trailing dot), it too can 
be unambiguously resolved.

So there's really no *technical* reason for dig to malfunction when 
encountering a delegation to a TLD label. IMO, this smacks more of 
prioritizing a personal preference against the use of TLD labels, over 
fixing a _bona_fide_ bug in the dig +trace algorithm. You may not like 
TLD labels, but they should still work regardless.

                                                             - Kevin

P.S. Don't get me wrong, as a general rule I hate shortnames and 
searchlisting, and I've been trying to eradicate their use here for 
decades, but in the spirit of dig's "give me what I ask for, not what 
you think is best for me", and mere consistency, I think that if named 
itself can handle delegations to TLD labels, dig +trace should be able 
to handle them too. People do, after all, use dig +trace to mimic an 
iterative resolver, even if, as you pointed out, it "outsources" some of 
that functionality to the getaddrinfo() routine.

P.P.S. I think there might be a latent security vulnerability in letting 
getaddrinfo() apply searchlist logic to the dig +trace algorithm, 
inasmuch as dig +trace might give results which differ from what a 
"real" iterative resolver would end up with, when attempting to follow 
the same delegation chain. Thus an evildoer may be able to leverage this 
to obscure the actual authoritative source for a given DNS name, from 
dig +trace's view. Consider that if named itself applied searchlist 
logic to delegated names, it would *definitely* have security 
ramifications; the fact that dig +trace does so raises similar concerns, 
albeit on a much smaller scale (given that the audience for dig +trace 
is a tiny fraction of the size of the audience for named's resolver 
component).