Suboptimal behavior from nsd

[Miek Gieben]

[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
> | :-(

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