What is the correct behavior with A and AAAA records in different domains?

[Kevin Darcy]

On 3/12/2010 5:37 PM, Mark Andrews wrote:
> In message<BA2C5191E8735241877D437C55FD143105040AAA at CORPUSMX20A.corp.emc.com>,
>   smith_roy at 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