Suboptimal behavior from nsd
roy at logmess.com
Thu Jan 15 11:01:57 UTC 2004
On Thu, 15 Jan 2004, Miek Gieben wrote:
> [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).
But is it going to be fixed ?
> > 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...
Relying on a well implemented cache is a wee bit naive. It think both the
spoofer and the spoofee carry some responsibility for spoof-proofness.
More information about the nsd-users