On 3/12/2010 5:37 PM, Mark Andrews wrote:
In message<ba2c5191e8735241877d437c55fd143105040...@corpusmx20a.corp.emc.com>,
smith_...@emc.com writes:
I've got an "interesting" network setup I'm trying to work with. There
are hosts with IPv4 and IPv6 interfaces. For reasons beyond my control
and comprehension, the IT department decided to put the A and AAAA
records in different domains. Thus, we have a machine foo, which has:
foo.d1.com IN A 10.1.8.200
foo.d2.com IN AAAA 3ffe:80c0:22c:60:203:baff:fe2c:b672
Now, let's say I've got the following in resolv.conf:
search d1.com d2.com
and I issue the query, "nslookup -type=aaaa foo". What should the
resolver do? My reading of RFC 1034, section 5.3.3, says it should
query foo.d1.com, get back a response of "no errors, no answers", and
iterate to foo.d2.com, where it will get back the AAAA record. My
esteemed colleague says when it gets back the "no errors, no answers"
response, it should stop iterating at that point.
Experimentally, the solaris boxes exhibit the first behavior, and the
linux boxes the second. Which is correct?
Firstly RFC 1034, section 5.3.3 does not cover this senario. It is
dealing with fully qualified queries.
My personal opinion is that the search should stop on noerror nodata.
foo should *always* refer to the same machine with a given search
list regardless of the query type.
I believe the current behaviour of skipping noerror nodata responses
is a workaround for how search lists were originally implemented
where they didn't names with periods in them first but rather last
and if you had a wildcard record in one of the zones in the search
list stopping on noerror nodata would prevent you reaching the site
you wanted to.
Noerror nodata *is* a valid answer.
I agree with Mark. Stop on noerror/nodata. It's bad enough that the old,
hoary kludge of shortname resolution (aka the "search" directive in
resolv.conf) still exists at all, but it was clearly never intended to
provide "parallel" resolution of the same name and different record
types, and using it in this way for "parallel" IPv4/IPv6 name-to-address
resolution just prolongs its demise.
Personally I would have gone further and purposely disabled shortname
resolution within the resolver routines whenever the query type is AAAA.
Let's leave all that shortname baggage behind as we enter the IPv6 era;
a fresh start, as it were...
- Kevin
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
