Suboptimal behavior from nsd

[Roy Arends]

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

Non sequitur.

> From a purity standpoint that host should not have been added in the
> additional section.

s/purity/security/

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

Roy