Subject: Should a non-authoritative server put the NS records into Answer or into Authority?

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 19 Mar 2003 15:10:06 +0100

Sorry to use an IETF WG for my training but this question puzzles me for a 
long time and, since we switched one of the nameservers of '.fr' to BIND9, it 
puzzles several of our registrars as well.

When you query a server on data it is not authoritative about (typically a TLD 
server about a subzone, for which it only knows the NS records and some glue), 
where the NS should be when replying? In the Authority section or in the 
Answer one?

Atlas, BIND9 and nsd put the NS records into the Authority section. The Answer 
section is empty (the Perl script of one of our registrars started to crash 
there: "Illegal division by zero" because of the empty section).

BIND8 and PowerDNS put the NS records into the Answer section.

You can check this on ns1.nic.fr (BIND8) vs. ns3.nic.fr (BIND9) or on 
a.root-servers.net (Atlas) vs. k.root-servers.net (nsd).

What is legal? What is best practice?

I'm still confused about what RFC 1034 says:

If recursive service is not requested or is not available, the non-
recursive response will be one of the following:

[...]

   - Some combination of:

     RRs that answer the question, together with an indication
     whether the data comes from a zone or is cached.

     A referral to name servers which have zones which are closer
     ancestors to the name than the server sending the reply.

IMHO, "some combination" without any details mean that all the programs quoted 
above are legally right, although different.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Doug Barton <[email-masked]>
Date: Wed, 19 Mar 2003 13:07:03 -0800 (PST)

On Wed, 19 Mar 2003, Stephane Bortzmeyer wrote:

> Sorry to use an IETF WG for my training

Don't be sorry, just don't do it. :) This question belongs on
[email-masked].

The short answer to your question is that BIND 9 is right. I'll send you a
longer answer in private mail.

Doug

> but this question puzzles me for a long time and, since we switched one
> of the nameservers of '.fr' to BIND9, it puzzles several of our
> registrars as well.
>

-- 

    If it's moving, encrypt it. If it's not moving, encrypt
        it till it moves, then encrypt it some more.

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 19 Mar 2003 23:00:01 +0100

Bonjour Stephane,

  (...)
 * where the NS should be when replying? In the Authority section or in the 
 * Answer one?

This behaviour stems from RFC1034 section 4.3.2. "Algorithm"

In step 3b of the algorithm it is specifically state that at a
delegation point the NS RRs are copied in the authority section.

         b. If a match would take us out of the authoritative data,
            we have a referral.  This happens when we encounter a
            node with NS RRs marking cuts along the bottom of a
            zone.

            Copy the NS RRs for the subzone into the authority
            section of the reply.  Put whatever addresses are
            available into the additional section, using glue RRs
            if the addresses are not available from authoritative
            data or the cache.  Go to step

---

From: "D. J. Bernstein" <[email-masked]>
Date: 19 Mar 2003 22:03:05 -0000

Stephane Bortzmeyer writes:
> When you query a server on data it is not authoritative about
> (typically a TLD server about a subzone, for which it only knows the
> NS records and some glue), where the NS should be when replying? In
> the Authority section or in the Answer one?

Both locations are possible. A referral has NS records in the authority
section. An NS answer has NS records in the answer section.

Of course, an NS answer isn't possible if the query type wasn't NS or *.
Furthermore, many servers (the most popular being tinydns and BIND 9)
choose to give referrals instead of answers when both are possible.

> it puzzles several of our registrars

People who don't understand DNS (such as the .fr registrars) shouldn't
be writing DNS software (such as the broken .fr zone checkers).

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: bert hubert <[email-masked]>
Date: Wed, 19 Mar 2003 23:32:36 +0100

On Wed, Mar 19, 2003 at 03:10:06PM +0100, Stephane Bortzmeyer wrote:

> When you query a server on data it is not authoritative about (typically a
> TLD server about a subzone, for which it only knows the NS records and
> some glue), where the NS should be when replying? In the Authority section
> or in the Answer one?

So when you query FR for the A record of www.yourdomain.fr? I don't really
get your question.

> BIND8 and PowerDNS put the NS records into the Answer section.

PowerDNS answers with records in the Authority record when it hands out a
referral.

Check out: dig www.lame.ds9a.nl @213.244.168.210

But if you do dig NS lame.ds9a.nl @213.244.168.210 you get answers in the
Answer section. Is this what you mean?

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 20 Mar 2003 13:56:34 +0100

On Wed, Mar 19, 2003 at 11:32:36PM +0100,
 bert hubert <[email-masked]> wrote 
 a message of 28 lines which said:

> So when you query FR for the A record of www.yourdomain.fr? 

Non, when you query '.fr' nameservers for the NS records of
yourdomain.fr.

> PowerDNS answers with records in the Authority record when it hands out a

No. Here is an example. According the analysis of Olaf Kolkman,
PowerDNS is wrong in that respect (hence the Reply-To the PowerDNS
mailing list).

~ % dig @fr-powerdns-pgsql.dnsexp.eureg.org ns  elysee.fr 

; <<>> DiG 9.2.1 <<>> @fr-powerdns-pgsql.dnsexp.eureg.org ns elysee.fr
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25933
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;elysee.fr.                     IN      NS

;; ANSWER SECTION:
elysee.fr.              345600  IN      NS      ns1.oleane.net.
elysee.fr.              345600  IN      NS      ns0.oleane.net.
elysee.fr.              345600  IN      NS      berlioz.elysee.fr.

;; ADDITIONAL SECTION:
berlioz.elysee.fr.      345600  IN      A       62.160.71.251

;; Query time: 43 msec
;; SERVER: 192.134.7.253#53(fr-powerdns-pgsql.dnsexp.eureg.org)
;; WHEN: Thu Mar 20 13:55:56 2003
;; MSG SIZE  rcvd: 111

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 20 Mar 2003 14:07:59 +0100

On Wed, Mar 19, 2003 at 03:10:06PM +0100,
 Stephane Bortzmeyer <[email-masked]> wrote 

> puzzles several of our registrars as well.

Someone told me that a known troll sent a message to the namedroppers
mailing list mentioning "the broken .fr zone checkers". Since I filter
this bozo because of the ad nominem attacks against people accused of
being paid by the ISC, I missed this interesting logorrhea.

I just wanted to say that, if someone has actual remarks (not name
calling) or bug reports to do about ZoneCheck, he/she should direct
them to [email-masked], which is currently completing the v2
(entirely rewritten from scratch) of the ZoneCheck tool. Advices,
comments and other inputs from the community are welcome.

Do note that, unlike v1, v2 separates coding from policy. The list of
tests to perform, as well as their severity (warning, fatal, etc) is
now in an external configuration file and can be tuned by each
registry.

The tool will be formally introduced by its author, Stephane d'Alu, at
the next RIPE meeting in Barcelona.

Version 1 is still the official one and is usable from
<URL:http://www.nic.fr/zonecheck/english.html>. See by yourself.

Version 2 can be tested here <URL:http://zonecheck.nic.fr/v2/>

---

From: bert hubert <[email-masked]>
Date: Thu, 20 Mar 2003 14:38:17 +0100

> PowerDNS is wrong in that respect (hence the Reply-To the PowerDNS

Ok, this is fixed in CVS. PowerDNS 2.9.7 was just released which
incorporated the following based on your input:

# PowerDNS set the 'aa' bit on serving NS records in a zone for which it was
  authoritative. Most implementations drop the 'aa' bit in this case and
  Stephane Bortzmeyer informed us of this. PowerDNS now also drops the 'aa'
  bit in this case.

# PowerDNS can now perform AAAA additional processing optionally, turned on
  by setting do-ipv6-additional-processing. Thanks to Stephane Bortzmeyer
  for pointing out the need.

In 2.9.8, PowerDNS gives this answer:

$ dig NS lame.ds9a.nl @127.0.0.1 -p 5301

; <<>> DiG 9.2.1 <<>> NS lame.ds9a.nl @127.0.0.1 -p 5301
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25373
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;lame.ds9a.nl.			IN	NS

;; AUTHORITY SECTION:
lame.ds9a.nl.		3600	IN	NS	ns1.xs4all.nl.
lame.ds9a.nl.		3600	IN	NS	ns2.xs4all.nl.

;; Query time: 2 msec
;; SERVER: 127.0.0.1#5301(127.0.0.1)
;; WHEN: Thu Mar 20 14:37:21 2003
;; MSG SIZE  rcvd: 73

Thanks.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 20 Mar 2003 13:58:27 +0100

On Wed, Mar 19, 2003 at 01:07:03PM -0800,
 Doug Barton <[email-masked]> wrote 

> Don't be sorry, just don't do it. :) This question belongs on

Why? It has nothing to do with a given implementation. It is question
of what is legal. 
 
> longer answer in private mail.

Well, thanks for the sample code (which I've forwarded to our
registrars). I believe that Olaf's reply was the most precise, legally
speaking. I have an opinion I can defend now :-)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 20 Mar 2003 14:01:29 +0100

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

On Wed, Mar 19, 2003 at 11:00:01PM +0100,
 Olaf Kolkman <[email-masked]> wrote 

> This behaviour stems from RFC1034 section 4.3.2. "Algorithm"

Thanks, I believe it is reasonably clear and that settles the
question. I now have a legal reference to show to my registrars.