On 2012-11-23 2:34 PM, Mark Andrews wrote:
...
There is nothing wrong with using the SOA record from the -ve
response. Named has been doing it for about 15 years in nslookup.
If it is not there it falls back to stripping a label at a time
until it gets the SOA record.
indeed not. i think mark means nsupdate here. the history of this is, i
wrote for late model bind8 a function called res_findzonecut(), which
was part of integrating a contributed implementation of RFC 2136, which
i'd been the editor and main author of. the comments at the top of
lib/res/res_findzonecut.c are shown below. there's nothing untoward, or
spec-violating, or even spec-bending going on here.
/*
* int
* res_findzonecut(res, dname, class, zname, zsize, addrs, naddrs)
* find enclosing zone for a dname,class, and some server addresses
* parameters:
* res - resolver context to work within (is modified)
* dname - domain name whose enclosing zone is desired
* class - class of dname (and its enclosing zone)
* zname - found zone name
* zsize - allocated size of zname
* addrs - found server addresses
* naddrs - max number of addrs
* return values:
* 0 - an error occurred (check errno)
* = 0 - zname is now valid, but addrs[] wasn't changed
* 0 - zname is now valid, and return value is number of addrs[]
found
* notes:
* this function calls res_nsend() which means it depends on correctly
* functioning recursive nameservers (usually defined in
/etc/resolv.conf
* or its local equivilent).
*
* we start by asking for an SOAdname,class. if we get one as an
* answer, that just means dname,class is a zone top, which is fine.
* more than likely we'll be told to go pound sand, in the form of a
* negative answer.
*
* note that we are not prepared to deal with referrals since that
would
* only come from authority servers and our correctly functioning local
* recursive server would have followed the referral and got us
something
* more definite.
*
* if the authority section contains an SOA, this SOA should also
be the
* closest enclosing zone, since any intermediary zone cuts
would've been
* returned as referrals and dealt with by our correctly
functioning local
* recursive name server. but an SOA in the authority section
should NOT
* match our dname (since that would have been returned in the answer
* section). an authority section SOA has to be above our dname.
*
* however, since authority section SOA's were once optional, it's
* possible that we'll have to go hunting for the enclosing SOA by
* ripping labels off the front of our dname -- this is known as doing
* it the hard way.
*
* ultimately we want some server addresses, which are ideally the ones
* pertaining to the SOA.MNAME, but only if there is a matching NS RR.
* so the second phase (after we find an SOA) is to go looking for the
* NS RRset for that SOA's zone.
*
* no answer section processed by this code is allowed to contain CNAME
* or DNAME RR's. for the SOA query this means we strip a label and
* keep going. for the NS and A queries this means we just give up.
*/
paul
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
