On 9/6/2011 8:40 PM, Mark Andrews wrote:
In message<4e66b5b5.30...@chrysler.com>, Kevin Darcy writes:
On 9/1/2011 7:57 PM, Mark Andrews wrote:
In message<4e5fb1ab.4040...@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).
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
