[Pdns-users] Wrongly sets the Authoritative Answer flag?

[Stephane Bortzmeyer]

On Wed, Mar 12, 2003 at 02:55:49PM +0100,
 bert hubert <ahu at ds9a.nl> wrote 
 a message of 49 lines which said:

> This is a bit tricky - I think you mean, that it is not authoritative for
> cfdt.fr, but only for .fr 

Yes, sorry for the typo.

> I'm wondering what is right. PowerDNS differs in this behaviour from other
> implementations. I'm still searching in the relevant RFCs where it says that
> it should drop the AA bit when answering a question for an NS record in the
> zone, for which it has authority.

I believe there is no doubt about the correct answer but it is not
written like that in the RFC. It is instead a consequence of various
definitions.

My analysis, made with Mohsen Souissi at the French NIC:

RFC 1034 defines the zones and the data they contain in
"4.2.1. Technical considerations". A part of the data (mostly the NS)
are (I quote RFC 1034) "Data that describes delegated subzones, i.e.,
cuts around the bottom of the zone.". It then defines "authoritative"
that way: "The authoritative data for a zone is simply all of the RRs
[Resource Records] attached to all of the nodes from the top node of
the zone down to leaf nodes or nodes above cuts around the bottom edge
of the zone." It is even more precise afterwards: "The RRs that
describe cuts around the bottom of the zone are NS RRs that name the
servers for the subzones.  Since the cuts are between nodes, these RRs
are NOT part of the authoritative data of the zone, and should be
exactly the same as the corresponding RRs in the top node of the
subzone."

So, it means that a compliant DNS server must analyze the data to find
the "cuts around the bottom edge of the zone" by treating NS records
as indicating these cuts. That way, the DNS server can know the bottom
limits of the zone it serves.

Also, this compliant DNS server must not set the Authoritative Answer
flag for these NS records.

It is also interesting to look at DNSSEC (RFC 2535). It specifies that
you must only sign (authenticate) the authoritative data, which makes
sense. And it explains in "2.3.4 Special Considerations at Delegation
Points": "But the DNS protocol views the leaf nodes in a zone, which
are also the apex nodes of a subzone (i.e., delegation points), as
"really" belonging to the subzone. [...] For all but one other RR type
the data from the subzone is more authoritative so only the subzone
KEY RR should be signed in the superzone if it appears there. The NS
and any glue address RRs SHOULD only be signed in the subzone."

The Internet-Draft "Delegation Signer Resource Record"
(http://www.ietf.org/internet-drafts/draft-ietf-dnsext-delegation-signer-13.txt)
which updates RFC 2535 is even more specific: "Delegations in the
parent MAY contain only the following RR types: NS, DS, NXT and SIG.
The NS RRset MUST NOT be signed." (Remember than you sign only
authoritative data.)

You can bring the matter to namedroppers, the IETF DNS Working Group,
but I'm quite certain of the reply.

> I'm willing to fix this if it turns out that RFCs demand or stipulate this
> behaviour but this would be behind a flag as it would probably hurt
> performance.

In that case, the default should not to set the AA flag, since it is
the proper behaviour.

I can add that the PowerDNS Bind backend exhibits the same problem and
that the same bug is seen when asking the A record for a nameserver in
a subzone (a glue record):

; <<>> DiG 9.2.1 <<>> @fr-powerdns-pgsql.dnsexp a thales.cnam.fr.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4029
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;thales.cnam.fr.                        IN      A

;; ANSWER SECTION:
thales.cnam.fr.         345600  IN      A       163.173.128.60

;; Query time: 1 msec
;; SERVER: 192.134.7.253#53(fr-powerdns-pgsql.dnsexp)
;; WHEN: Wed Mar 12 16:34:50 2003
;; MSG SIZE  rcvd: 48