must authority section be populated for a NOERROR response with the AA bit set?
Irwin Tillman
irwin at princeton.edu
Thu Nov 18 19:08:23 UTC 2004
Can someone point me to the relevant RFC that covers this:
When a nameserver authoritative for foo returns a (positive)
NOERROR response for foo with the authoritative bit set,
is the response required to include authority records?
While the response typically does have authority records in this case,
there's an application (lbnamed) that does not do so. Here's an example:
% dig @hermes.princeton.edu arizona.princeton.edu.
; <<>> DiG 9.3.0 <<>> @hermes.princeton.edu arizona.princeton.edu.
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;arizona.princeton.edu. IN A
;; ANSWER SECTION:
arizona.princeton.edu. 0 IN CNAME phoenix.Princeton.EDU.
phoenix.Princeton.EDU. 3600 IN A 128.112.128.42
;; Query time: 2 msec
;; SERVER: 128.112.129.18#53(hermes.princeton.edu)
;; WHEN: Thu Nov 18 13:59:32 2004
;; MSG SIZE rcvd: 111
A customer tells me that under some circumstances, a BIND 9.3.0 nameserver
attempting to resolve "arizona.princeton.edu" will produce the
"multiple RRs of singleton type" error when confronted with the
response above. (I've not been able to reproduce the failure
here, but it may require the BIND nameserver to be configured in some
particular way.)
I can't find a spot in the relevant RFCs that require the authority section
to be populated in the response above. Does anyone know if the RFCs
say so (and if so, where?).
If the response above violates the RFCs, then the problem is with lbnamed.
But if the response above is OK, then is sounds like it could be
an issue with BIND 9.3.0.
More information about the bind-users
mailing list