Suboptimal behavior from nsd
miekg at atoom.net
Thu Jan 15 09:54:10 UTC 2004
[On 15 Jan, @05:31, Roy wrote in "Re: Suboptimal behavior from n ..."]
> > >>| enst.fr. 345600 IN NS phoenix.uneec.eurocontrol.fr.
> > >>|
> > >>| ;; ADDITIONAL SECTION:
> > >>| minos.enst.fr. 345600 IN A 184.108.40.206
> > >>| enst.enst.fr. 345600 IN A 220.127.116.11
> > >>| infres.enst.fr. 345600 IN A 18.104.22.168
> > >>| phoenix.uneec.eurocontrol.fr. 345600 IN A 22.214.171.124
> > >
> > >
> > > 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).
> Ah, are you going to change that design ? Since all records did _not_ came
I guess not. The inclusion of that 'phoenix' host is due to the fact that it is
glue in the .fr zone (for some other zone). From a purity standpoint that host
should not have been added in the additional section. I don't think fixing this
is trivial in the current NSD design (current: 1.2.X and 2.X.X).
> from a single zone. This design is not spoof-proof.
a well implemented cache should see that and not cache that information. It
sounds a bit strange in my ears to talk about spoof-proofing NSD while
NSD has no cache...
GPG fingerprint: miek.nl/about.html
More information about the nsd-users