Wrongly sets the Authoritative Answer flag?

classic Classic list List threaded Threaded
4 messages Options
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Wrongly sets the Authoritative Answer flag?

Stephane Bortzmeyer
I'm starting to experiment with PowerDNS on the '.fr' zone. I see that
PowerDNS sets the Authoritative Answer flag for queries about NS
records which are not in '.fr' but in a child zone:

; <<>> DiG 9.2.1 <<>> @fr-powerdns.dnsexp ns cfdt.fr.
...
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
cfdt.fr.                345600  IN      NS      proof.rain.fr.
cfdt.fr.                345600  IN      NS      relay.globalintranet.net.

I believe that PowerDNS is wrong. The server is authoritative for
'.fr', not for '.enst.fr'. nsd and BIND9 do not set the AA flag.

PowerDNS 2.9.6
PostgreSQL backend
Zone file loaded with 'zone2sql --gpgsql --zone-name=fr
--zone=/etc/bind/db.fr | psql powerdns'



Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wrongly sets the Authoritative Answer flag?

bert hubert
On Wed, Mar 12, 2003 at 02:24:39PM +0100, Stephane Bortzmeyer wrote:
> I'm starting to experiment with PowerDNS on the '.fr' zone. I see that
> PowerDNS sets the Authoritative Answer flag for queries about NS
> records which are not in '.fr' but in a child zone:

Hmm.

> ; <<>> DiG 9.2.1 <<>> @fr-powerdns.dnsexp ns cfdt.fr.
> ...
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
> ...
> ;; ANSWER SECTION:
> cfdt.fr.                345600  IN      NS      proof.rain.fr.
> cfdt.fr.                345600  IN      NS      relay.globalintranet.net.
>
> I believe that PowerDNS is wrong. The server is authoritative for
> '.fr', not for '.enst.fr'. nsd and BIND9 do not set the AA flag.

This is a bit tricky - I think you mean, that it is not authoritative for
cfdt.fr, but only for .fr - but that doesn't change anything.

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.

PowerDNS drops the AA bit when it hands out a referral, but in this case
PowerDNS figures that it has the right answer, and it feels authoritative. A
question for an A record for cfdt.fr would get a non-AA answer, as powerdns
has no clue.

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.

Stephane, I'm investigating this further, will report what I find. Should
you know which RFC mentions this behaviour and where, that will speed things
up.

Thanks!

Regards,

bert

--
http://www.PowerDNS.com      Open source, database driven DNS Software
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO
http://netherlabs.nl                         Consulting
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wrongly sets the Authoritative Answer flag?

Stephane Bortzmeyer
On Wed, Mar 12, 2003 at 02:55:49PM +0100,
 bert hubert <[hidden email]> 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
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wrongly sets the Authoritative Answer flag?

bert hubert
On Wed, Mar 12, 2003 at 04:36:04PM +0100, Stephane Bortzmeyer wrote:

> 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.

Indeed. I've since fixed this issue in PowerDNS, the aa bit is now dropped
in case an NS query is made for a record that does not have a SOA type too.
This will be in 2.9.7 by default. The performance impact will be slight as
explicit queries for NS records are very rare.

Thanks for bringing this to our attention and elucidating the reasons.

> 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):

This logic is 'higher up' in PowerDNS - the backends are quite simple in
fact and don't do any thinking. This bug is now solved for all backends.

I was already working on the glue issue, which is somewhat more subtle to
solve well while maintaining the ability to serve from SQL. 'Zone cuts' are
pretty hard to discover from SQL without trawling all records for each
query.

Will let you know how we proceed.

Regards,

bert

--
http://www.PowerDNS.com      Open source, database driven DNS Software
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO
http://netherlabs.nl                         Consulting
Loading...