Suboptimal behavior from nsd

NSD
1

Hello, and Happy New year to nsd-users,

I just detected a sub-optimal (but probably legal) behavior of
nsd. (You are welcome to perform tests with ns2.nic.fr, which runs nsd
1.2.2.)

When a nsd server is authoritative, it does not send in the Additional
section every information it has.

Here, ns2.nic.fr is not authoritative for enst.fr, the reply is as
expected:

eve:~ % dig @ns2.nic.fr NS enst.fr

;; AUTHORITY SECTION:
enst.fr. 345600 IN NS minos.enst.fr.
enst.fr. 345600 IN NS enst.enst.fr.
enst.fr. 345600 IN NS infres.enst.fr.
enst.fr. 345600 IN NS phoenix.uneec.eurocontrol.fr.

;; ADDITIONAL SECTION:
minos.enst.fr. 345600 IN A 137.194.2.34
enst.enst.fr. 345600 IN A 137.194.2.16
infres.enst.fr. 345600 IN A 137.194.160.3
phoenix.uneec.eurocontrol.fr. 345600 IN A 147.196.69.1

Here, ns2.nic.fr is authoritative for supelec.fr and one IP address is
missing from the Additional section, because it is not in the queried
domain (but it is known from the nsd server):

eve:~ % dig @ns2.nic.fr NS supelec.fr

;; ANSWER SECTION:
supelec.fr. 86400 IN NS supelec.supelec.fr.
supelec.fr. 86400 IN NS infogif.supelec.fr.
supelec.fr. 86400 IN NS hermes.supelec.fr.
supelec.fr. 86400 IN NS ns2.nic.fr.

;; ADDITIONAL SECTION:
supelec.supelec.fr. 86400 IN A 160.228.120.192
infogif.supelec.fr. 86400 IN A 160.228.120.190
hermes.supelec.fr. 86400 IN A 160.228.120.109

It means that most nameservers will not bother trying to get the
missing IP address so, in practice, the fourth server will not be used
:frowning:

Worse, if I ask a more reasonable question:

eve:~ % dig @ns2.nic.fr A www.afnic.fr

;; ANSWER SECTION:
www.afnic.fr. 172800 IN CNAME rigolo.nic.fr.

The CNAME is *not* followed, probably because it is out of the zone,
despite the fact that ns2.nic.fr is also authoritative for nic.fr.

Try now with www.nic.fr, it works better:

eve:~ % dig @ns2.nic.fr A www.nic.fr

;; ANSWER SECTION:
www.nic.fr. 172800 IN CNAME rigolo.nic.fr.
rigolo.nic.fr. 172800 IN A 192.134.4.20

This behaviour is probably legal (you put as many things you want in
the Additional section, after all), but clearly sub-optimal (BIND 8
and BIND 9 do not exhibit this behaviour).

Comments?

2

[Quoting Stephane Bortzmeyer, on Jan 8, 13:55, in "Suboptimal behavior ..."]

Hello, and Happy New year to nsd-users,

I just detected a sub-optimal (but probably legal) behavior of
nsd. (You are welcome to perform tests with ns2.nic.fr, which runs nsd
1.2.2.)

When a nsd server is authoritative, it does not send in the Additional
section every information it has.

An authoritative-only server should only produce the necessary
glue: info about in-zone nameservers, and no other Additional
data. The fact that older, broken resolvers used any supplied
additional data, made the DNS system vulnarible.

Let's look at your examples:

;; AUTHORITY SECTION:
enst.fr. 345600 IN NS minos.enst.fr.
enst.fr. 345600 IN NS enst.enst.fr.
enst.fr. 345600 IN NS infres.enst.fr.
enst.fr. 345600 IN NS phoenix.uneec.eurocontrol.fr.

;; ADDITIONAL SECTION:
minos.enst.fr. 345600 IN A 137.194.2.34
enst.enst.fr. 345600 IN A 137.194.2.16
infres.enst.fr. 345600 IN A 137.194.160.3
phoenix.uneec.eurocontrol.fr. 345600 IN A 147.196.69.1

Officially, no glue for phoenix.uneec.eurocontrol.fr is needed here.
This is out-of-zone glue which should not be present.
Anyway, "good" resolvers will discard this info, and requery for
phoenix.uneec.eurocontrol.fr before going there.

;; ANSWER SECTION:
supelec.fr. 86400 IN NS supelec.supelec.fr.
supelec.fr. 86400 IN NS infogif.supelec.fr.
supelec.fr. 86400 IN NS hermes.supelec.fr.
supelec.fr. 86400 IN NS ns2.nic.fr.

;; ADDITIONAL SECTION:
supelec.supelec.fr. 86400 IN A 160.228.120.192
infogif.supelec.fr. 86400 IN A 160.228.120.190
hermes.supelec.fr. 86400 IN A 160.228.120.109

This is the correct additional section.

-- ted

3

This behaviour is probably legal (you put as many things you want in
the Additional section, after all),

NSD behaviour is legal, and the most optimal.

A resolver must discard out-of-bailiwick, to be spoof-proof.
A server must not send out-of-bailiwick.

but clearly sub-optimal (BIND 8 and BIND 9 do not exhibit this
behaviour).

In effect, sending extra information in the additional section is
suboptimal in 2 ways. A Bigger Packet. Less Secure.

Roy

4

a message of 17 lines which said:

A server must not send out-of-bailiwick.

Out of bailiwick? ns2.nic.fr is authoritative for these domaines
(supelec.fr, nic.fr, afnic.fr).

5

All RR's in the response must have owner names relative (in-bailiwick) to
QNAME. If the resolver wants to know other names, it can (must if I were
king) query for that. Authoritative has nothing to do with it and has
only bearing on the origin of the response, and then, only to the answer
and authority section, not the additional section.

Roy

6

eve:~ % dig @ns2.nic.fr NS enst.fr

;; AUTHORITY SECTION:
enst.fr. 345600 IN NS minos.enst.fr.
enst.fr. 345600 IN NS enst.enst.fr.
enst.fr. 345600 IN NS infres.enst.fr.
enst.fr. 345600 IN NS phoenix.uneec.eurocontrol.fr.

;; ADDITIONAL SECTION:
minos.enst.fr. 345600 IN A 137.194.2.34
enst.enst.fr. 345600 IN A 137.194.2.16
infres.enst.fr. 345600 IN A 137.194.160.3
phoenix.uneec.eurocontrol.fr. 345600 IN A 147.196.69.1

[...]

eve:~ % dig @ns2.nic.fr NS supelec.fr

;; ANSWER SECTION:
supelec.fr. 86400 IN NS supelec.supelec.fr.
supelec.fr. 86400 IN NS infogif.supelec.fr.
supelec.fr. 86400 IN NS hermes.supelec.fr.
supelec.fr. 86400 IN NS ns2.nic.fr.

;; ADDITIONAL SECTION:
supelec.supelec.fr. 86400 IN A 160.228.120.192
infogif.supelec.fr. 86400 IN A 160.228.120.190
hermes.supelec.fr. 86400 IN A 160.228.120.109

If I understand you correctly, you see that both "enst.fr" and
"supelec.fr" both have 3 name servers in their own zone, and 1 name
server out of zone, and that you would be expecting consistent
behaviour by either supplying the additional A record in both cases
or not supplying it in both cases.

It means that most nameservers will not bother trying to get the
missing IP address so, in practice, the fourth server will not be used
:frowning:

It seems to me that if they have already queried "ns2.nic.fr" to get
this data, then they already know its address (to have done so), and
thus supplying the A record is now redundant.

Perhaps this could be a problem if the resolver which has the A
record for "ns2.nic.fr" cached loses it due to expiration while
waiting for that answer. Is that allowed behaviour for a resolver?

Worse, if I ask a more reasonable question:

eve:~ % dig @ns2.nic.fr A www.afnic.fr

;; ANSWER SECTION:
www.afnic.fr. 172800 IN CNAME rigolo.nic.fr.

The CNAME is *not* followed, probably because it is out of the zone,
despite the fact that ns2.nic.fr is also authoritative for nic.fr.

You mean not followed in the authoritative sever? The resolver most
certainly needs to follow it. But I guess you are asking why it is
not supplied as additional data. My take is that the data being given
is under a single zone of authority, despite the coincidence of the
two zones being served from the same place. As an implementation,
I believe NSD is doing it's work with the one zone it has accessed in
the database, and just does not go chase another zone by design.

Try now with www.nic.fr, it works better:

eve:~ % dig @ns2.nic.fr A www.nic.fr

;; ANSWER SECTION:
www.nic.fr. 172800 IN CNAME rigolo.nic.fr.
rigolo.nic.fr. 172800 IN A 192.134.4.20

This behaviour is probably legal (you put as many things you want in
the Additional section, after all), but clearly sub-optimal (BIND 8
and BIND 9 do not exhibit this behaviour).

And both pieces of data were right there in that zone; no additional work
needed.

I guess the argument is, isn't it faster to just have the authoritative
name server look up the referenced zone, and if it believes itself to be
authoritative for that other zone, and there is data that is certainly
going to be asked for next, to go ahead and provide it, at least if it
won't truncate the answer.

Personally, if it were me, for a name in the _same_ zone, where the name
being queried is the CNAME, and the query type is not CNAME, then I would
"flatten" the answer and just give:

www.nic.fr. 172800 IN A 192.134.4.20

But I'm sure that breaks something I can't think of at the moment.

7

[On 09 Jan, @02:43, Phil wrote in "Re: Suboptimal behavior from n ..."]

> ;; AUTHORITY SECTION:
> enst.fr. 345600 IN NS minos.enst.fr.
> enst.fr. 345600 IN NS enst.enst.fr.
> enst.fr. 345600 IN NS infres.enst.fr.
> enst.fr. 345600 IN NS phoenix.uneec.eurocontrol.fr.
>
> ;; ADDITIONAL SECTION:
> minos.enst.fr. 345600 IN A 137.194.2.34
> enst.enst.fr. 345600 IN A 137.194.2.16
> infres.enst.fr. 345600 IN A 137.194.160.3
> phoenix.uneec.eurocontrol.fr. 345600 IN A 147.196.69.1

I'm slightly puzzled on why this last A record is added, it should
be considered out of zone, but somehow NSD will add it.

> It means that most nameservers will not bother trying to get the
> missing IP address so, in practice, the fourth server will not be used
> :frowning:

This all depends on the resolver, maybe there implementation out there
to only use the first nameserver... in that case the first NS listed
will be hit the hardest.

> Worse, if I ask a more reasonable question:
>
> eve:~ % dig @ns2.nic.fr A www.afnic.fr
>
> ;; ANSWER SECTION:
> www.afnic.fr. 172800 IN CNAME rigolo.nic.fr.
>
> The CNAME is *not* followed, probably because it is out of the zone,
> despite the fact that ns2.nic.fr is also authoritative for nic.fr.

You mean not followed in the authoritative sever? The resolver most
certainly needs to follow it. But I guess you are asking why it is
not supplied as additional data. My take is that the data being given
is under a single zone of authority, despite the coincidence of the
two zones being served from the same place. As an implementation,
I believe NSD is doing it's work with the one zone it has accessed in
the database, and just does not go chase another zone by design.

This is indeed how NSD works.

I guess the argument is, isn't it faster to just have the authoritative
name server look up the referenced zone, and if it believes itself to be
authoritative for that other zone, and there is data that is certainly
going to be asked for next, to go ahead and provide it, at least if it
won't truncate the answer.

Personally, if it were me, for a name in the _same_ zone, where the name
being queried is the CNAME, and the query type is not CNAME, then I would
"flatten" the answer and just give:

www.nic.fr. 172800 IN A 192.134.4.20

But I'm sure that breaks something I can't think of at the moment.

this in effect, makes the CNAME disappear. Is that bad? Dunno,

grtz Miek

8

Miek Gieben wrote:

[On 09 Jan, @02:43, Phil wrote in "Re: Suboptimal behavior from n ..."]

;; AUTHORITY SECTION:
enst.fr. 345600 IN NS minos.enst.fr.
enst.fr. 345600 IN NS enst.enst.fr.
enst.fr. 345600 IN NS infres.enst.fr.
enst.fr. 345600 IN NS phoenix.uneec.eurocontrol.fr.

;; ADDITIONAL SECTION:
minos.enst.fr. 345600 IN A 137.194.2.34
enst.enst.fr. 345600 IN A 137.194.2.16
infres.enst.fr. 345600 IN A 137.194.160.3
phoenix.uneec.eurocontrol.fr. 345600 IN A 147.196.69.1

I'm slightly puzzled on why this last A record is added, it should
be considered out of zone, but somehow NSD will add it.

Because all these A records appear as glue in the .fr zone. So the answer is constructed using data from a single zone, as are all answers from NSD (by design).

Erik

9

[On 09 Jan, @13:29, Erik wrote in "Re: Suboptimal behavior from n ..."]

>be considered out of zone, but somehow NSD will add it.

Because all these A records appear as glue in the .fr zone. So the
answer is constructed using data from a single zone, as are all answers
from NSD (by design).

ah, ok, the quarter has dropped. We are diggen for NS enst.fr,
for which we get a referral FROM THE .fr zone. So the glue we
see is in zone. Beautifull :slight_smile:

yep, thanks,

grtz Miek

10

a message of 108 lines which said:

You mean not followed in the authoritative sever? The resolver most
certainly needs to follow it.

It takes more time for the resolver, if it has to issue a new
request. It is not a matter of correctness (nsd is correct), but of
performance.

But I guess you are asking why it is not supplied as additional
data.

BIND supplies it in the ANSWER section (test on ns3.nic.fr). Do you
think a bug report should be sent to BIND's authors?

Personally, if it were me, for a name in the _same_ zone, where the name
being queried is the CNAME, and the query type is not CNAME, then I would
"flatten" the answer and just give:

www.nic.fr. 172800 IN A 192.134.4.20

It seems a gross violation of the protocol.

But I'm sure that breaks something I can't think of at the moment.

Testing tools like Zonecheck <URL:http://www.zonecheck.fr/&gt; could no
longer tell if it is a CNAME (forbidden in RHS of some records) or an
A.

11

a message of 29 lines which said:

Because all these A records appear as glue in the .fr zone. So the
answer is constructed using data from a single zone, as are all
answers from NSD (by design).

And do you regard this design as proper?

12

a message of 49 lines which said:

An authoritative-only server should only produce the necessary
glue: info about in-zone nameservers, and no other Additional
data.

So, BIND is wrong?

13

[Quoting Stephane Bortzmeyer, on Jan 12, 14:55, in "Re: Suboptimal behav ..."]

a message of 49 lines which said:

> An authoritative-only server should only produce the necessary
> glue: info about in-zone nameservers, and no other Additional
> data.

So, BIND is wrong?

No, BIND is (per default) not an "authoritative-only server".

BIND is (also) a caching forwarder, and caching forwarders can/may
give back any RRsets it has properly looked up and successfully
cached earlier, when it believes such RRsets may to be relevant to
the requestor (like an A RR to which a CNAME or an MX points).

What a caching forwarder server should NOT do, is to construct
answers using RRsets received as glue on earlier queries. But I
don't think modern BINDs (i.e. later than BIND4) are doing that
anymore.

-- ted

14

I understand this to mean that answer RRs can become answer RRs or can
become additional RRs on future queries, and additional RRs can become
additional RRs on future queries, but cannot become answer RRs on future
queries. Servers like BIND might glue in RRs it is not authoritative
for, but if it can be determined that the server some additional RR
came from is the one that is authoritative for that data, why not allow
it? Or is it unreliable to determine that?

Just curious. Obviously this (caching behaviour) doesn't apply to NSD.
I happen to run NSD for authority purposes and BIND for caching purposes,
(though I am considering dnscache from DJBDNS) as well as an extra set of
BIND for slaving other domains.

15

Once Ted Lindgreen wrote:

[Quoting Stephane Bortzmeyer, on Jan 12, 14:55, in "Re: Suboptimal behav ..."]

a message of 49 lines which said:

> An authoritative-only server should only produce the necessary
> glue: info about in-zone nameservers, and no other Additional
> data.

So, BIND is wrong?

No, BIND is (per default) not an "authoritative-only server".

BIND is (also) a caching forwarder, and caching forwarders can/may
give back any RRsets it has properly looked up and successfully
cached earlier, when it believes such RRsets may to be relevant to
the requestor (like an A RR to which a CNAME or an MX points).

As long as AA flag is not set on the answer.

Alexis

16

[Quoting Alexis Yushin, on Jan 12, 16:10, in "Re: Suboptimal behav ..."]

Once Ted Lindgreen wrote:
>[Quoting Stephane Bortzmeyer, on Jan 12, 14:55, in "Re: Suboptimal behav ..."]
>> a message of 49 lines which said:
>>
>> > An authoritative-only server should only produce the necessary
>> > glue: info about in-zone nameservers, and no other Additional
>> > data.
>>
>> So, BIND is wrong?
>
>No, BIND is (per default) not an "authoritative-only server".
>
>BIND is (also) a caching forwarder, and caching forwarders can/may
>give back any RRsets it has properly looked up and successfully
>cached earlier, when it believes such RRsets may to be relevant to
>the requestor (like an A RR to which a CNAME or an MX points).

As long as AA flag is not set on the answer.

No, that is not true:

  The AA flag reflects the status of the info in the "ANSWER SECTION",
  and says nothing about status of the info in the "ADDITIONAL SECTION".

-- ted

17

Once Ted Lindgreen wrote:

[Quoting Alexis Yushin, on Jan 12, 16:10, in "Re: Suboptimal behav ..."]

Once Ted Lindgreen wrote:
>[Quoting Stephane Bortzmeyer, on Jan 12, 14:55, in "Re: Suboptimal behav ..."]
>> a message of 49 lines which said:
>>
>> > An authoritative-only server should only produce the necessary
>> > glue: info about in-zone nameservers, and no other Additional
>> > data.
>>
>> So, BIND is wrong?
>
>No, BIND is (per default) not an "authoritative-only server".
>
>BIND is (also) a caching forwarder, and caching forwarders can/may
>give back any RRsets it has properly looked up and successfully
>cached earlier, when it believes such RRsets may to be relevant to
>the requestor (like an A RR to which a CNAME or an MX points).

As long as AA flag is not set on the answer.

No, that is not true:

The AA flag reflects the status of the info in the "ANSWER SECTION",
and says nothing about status of the info in the "ADDITIONAL SECTION".

Well we were talking about BIND returning the A records in the answer
section, no?

Alexis

18

[Quoting Alexis Yushin, on Jan 12, 17:23, in "Re: Suboptimal behav ..."]

Well we were talking about BIND returning the A records in the answer
section, no?

No, we were talking about various (in- and out-of zone) glue A RRs
in the additional section, and whether this was "correct", but
also perhaps "suboptimal" behaviour of an authoritative-only server.

Regards,
-- ted

19

a message of 24 lines which said:

> So, BIND is wrong?

No, BIND is (per default) not an "authoritative-only server".

The BIND I talked about (ns3.nic.fr) obviously has "recursion no;" in
its configuration.

20

Ah, are you going to change that design ? Since all records did _not_ came
from a single zone. This design is not spoof-proof.

Roy