Hello, and Happy New year to nsd-users, I just detected a sub-optimal (but probably legal) behavior of nsd. (You are welcome to perform tests with ns2.nic.fr, which runs nsd 1.2.2.) When a nsd server is authoritative, it does not send in the Additional section every information it has. Here, ns2.nic.fr is not authoritative for enst.fr, the reply is as expected: 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 Here, ns2.nic.fr is authoritative for supelec.fr and one IP address is missing from the Additional section, because it is not in the queried domain (but it is known from the nsd server): 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 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 :-( 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. 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). Comments?
[Quoting Stephane Bortzmeyer, on Jan 8, 13:55, in "Suboptimal behavior ..."]> Hello, and Happy New year to nsd-users, > > I just detected a sub-optimal (but probably legal) behavior of > nsd. (You are welcome to perform tests with ns2.nic.fr, which runs nsd > 1.2.2.) > > When a nsd server is authoritative, it does not send in the Additional > section every information it has.An authoritative-only server should only produce the necessary glue: info about in-zone nameservers, and no other Additional data. The fact that older, broken resolvers used any supplied additional data, made the DNS system vulnarible. Let's look at your examples:> ;; 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.1Officially, no glue for phoenix.uneec.eurocontrol.fr is needed here. This is out-of-zone glue which should not be present. Anyway, "good" resolvers will discard this info, and requery for phoenix.uneec.eurocontrol.fr before going there.> ;; 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.109This is the correct additional section. -- ted
On Thu, 8 Jan 2004, Stephane Bortzmeyer wrote:> This behaviour is probably legal (you put as many things you want in > the Additional section, after all),NSD behaviour is legal, and the most optimal. A resolver must discard out-of-bailiwick, to be spoof-proof. A server must not send out-of-bailiwick.> but clearly sub-optimal (BIND 8 and BIND 9 do not exhibit this > behaviour).In effect, sending extra information in the additional section is suboptimal in 2 ways. A Bigger Packet. Less Secure. Roy
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/ | -----------------------------------------------------------------------------
[Quoting Stephane Bortzmeyer, on Jan 12, 14:55, in "Re: Suboptimal behav ..."]> On Thu, Jan 08, 2004 at 02:36:51PM +0100, > Ted Lindgreen <ted at tednet.nl> wrote > a message of 49 lines which said: > > > An authoritative-only server should only produce the necessary > > glue: info about in-zone nameservers, and no other Additional > > data. > > So, BIND is wrong?No, BIND is (per default) not an "authoritative-only server". BIND is (also) a caching forwarder, and caching forwarders can/may give back any RRsets it has properly looked up and successfully cached earlier, when it believes such RRsets may to be relevant to the requestor (like an A RR to which a CNAME or an MX points). What a caching forwarder server should NOT do, is to construct answers using RRsets received as glue on earlier queries. But I don't think modern BINDs (i.e. later than BIND4) are doing that anymore. -- ted
[Quoting Alexis Yushin, on Jan 12, 16:10, in "Re: Suboptimal behav ..."]> Once Ted Lindgreen wrote: > >[Quoting Stephane Bortzmeyer, on Jan 12, 14:55, in "Re: Suboptimal behav ..."] > >> On Thu, Jan 08, 2004 at 02:36:51PM +0100, > >> Ted Lindgreen <ted at tednet.nl> wrote > >> a message of 49 lines which said: > >> > >> > An authoritative-only server should only produce the necessary > >> > glue: info about in-zone nameservers, and no other Additional > >> > data. > >> > >> So, BIND is wrong? > > > >No, BIND is (per default) not an "authoritative-only server". > > > >BIND is (also) a caching forwarder, and caching forwarders can/may > >give back any RRsets it has properly looked up and successfully > >cached earlier, when it believes such RRsets may to be relevant to > >the requestor (like an A RR to which a CNAME or an MX points). > > As long as AA flag is not set on the answer.No, that is not true: The AA flag reflects the status of the info in the "ANSWER SECTION", and says nothing about status of the info in the "ADDITIONAL SECTION". -- ted
[Quoting Alexis Yushin, on Jan 12, 17:23, in "Re: Suboptimal behav ..."]> Well we were talking about BIND returning the A records in the answer > section, no?No, we were talking about various (in- and out-of zone) glue A RRs in the additional section, and whether this was "correct", but also perhaps "suboptimal" behaviour of an authoritative-only server. Regards, -- ted