Suboptimal behavior from nsd

[Miek Gieben]

[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       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).
> 
> 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...

grtz
      Miek
--
Seabiscuit Rules!  
GPG fingerprint: miek.nl/about.html