Suboptimal behavior from nsd

[Phil Howard]

On Thu, Jan 08, 2004 at 01:52:24PM +0100, Stephane Bortzmeyer wrote:

| eve:~ % dig @ns2.nic.fr NS enst.fr 
| 
| ;; AUTHORITY SECTION:
| enst.fr.                345600  IN      NS      minos.enst.fr.
| enst.fr.                345600  IN      NS      enst.enst.fr.
| enst.fr.                345600  IN      NS      infres.enst.fr.
| 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

[...]

| eve:~ % dig @ns2.nic.fr NS supelec.fr
| 
| ;; ANSWER SECTION:
| supelec.fr.             86400   IN      NS      supelec.supelec.fr.
| supelec.fr.             86400   IN      NS      infogif.supelec.fr.
| supelec.fr.             86400   IN      NS      hermes.supelec.fr.
| supelec.fr.             86400   IN      NS      ns2.nic.fr.
| 
| ;; ADDITIONAL SECTION:
| supelec.supelec.fr.     86400   IN      A       160.228.120.192
| infogif.supelec.fr.     86400   IN      A       160.228.120.190
| hermes.supelec.fr.      86400   IN      A       160.228.120.109

If I understand you correctly, you see that both "enst.fr" and
"supelec.fr" both have 3 name servers in their own zone, and 1 name
server out of zone, and that you would be expecting consistent
behaviour by either supplying the additional A record in both cases
or not supplying it in both cases.


| 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
| :-(

It seems to me that if they have already queried "ns2.nic.fr" to get
this data, then they already know its address (to have done so), and
thus supplying the A record is now redundant.

Perhaps this could be a problem if the resolver which has the A
record for "ns2.nic.fr" cached loses it due to expiration while
waiting for that answer.  Is that allowed behaviour for a resolver?


| Worse, if I ask a more reasonable question:
| 
| eve:~ % dig @ns2.nic.fr A www.afnic.fr
| 
| ;; ANSWER SECTION:
| www.afnic.fr.           172800  IN      CNAME   rigolo.nic.fr.
| 
| The CNAME is *not* followed, probably because it is out of the zone,
| despite the fact that ns2.nic.fr is also authoritative for nic.fr.

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.


| Try now with www.nic.fr, it works better:
| 
| eve:~ % dig @ns2.nic.fr A www.nic.fr      
| 
| ;; ANSWER SECTION:
| www.nic.fr.             172800  IN      CNAME   rigolo.nic.fr.
| rigolo.nic.fr.          172800  IN      A       192.134.4.20
| 
| This behaviour is probably legal (you put as many things you want in
| the Additional section, after all), but clearly sub-optimal (BIND 8
| and BIND 9 do not exhibit this behaviour).

And both pieces of data were right there in that zone; no additional work
needed.

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:

www.nic.fr.             172800  IN      A       192.134.4.20

But I'm sure that breaks something I can't think of at the moment.

-- 
-----------------------------------------------------------------------------
| Phil Howard KA9WGN       | http://linuxhomepage.com/      http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/   http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------