Suboptimal behavior from nsd
miekg at atoom.net
Fri Jan 9 12:09:21 UTC 2004
[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 18.104.22.168
> | enst.enst.fr. 345600 IN A 22.214.171.124
> | infres.enst.fr. 345600 IN A 126.96.36.199
> | phoenix.uneec.eurocontrol.fr. 345600 IN A 188.8.131.52
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 184.108.40.206
> 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,
More information about the nsd-users