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

[Mark Andrews]

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.

One could tweak dig to disable searching when resolving these
addresses, as the answers from the dns are absolute, but it is good
practice to never expect them to work in the first place.

"ssh tld" or "mail user at tld" or "browser http://tld/" will never
work reliably as long as search lists exist.

This is as much about expectation setting as anything else.

Mark

>                                                                  - Kevin
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>  from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org