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