Suboptimal behavior from nsd

Miek Gieben miekg at
Fri Jan 9 12:09:21 UTC 2004

[On 09 Jan, @02:43, Phil wrote in "Re: Suboptimal behavior from n ..."]
> |                345600  IN      NS
> |                345600  IN      NS
> |                345600  IN      NS
> |                345600  IN      NS
> | 
> |          345600  IN      A
> |           345600  IN      A
> |         345600  IN      A
> | 345600 IN A

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 A
> | 
> |           172800  IN      CNAME
> | 
> | The CNAME is *not* followed, probably because it is out of the zone,
> | despite the fact that is also authoritative for
> 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:
>             172800  IN      A
> 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,

grtz Miek

More information about the nsd-users mailing list