Well,
So here a bit more details. Sorry, I cannot take an example with a DNS server accessible to you (*) because they have all been upgraded to 9.16. The .cern.ch contains: spectrum-lb IN NS ip-dns-1.cern.ch. spectrum-lb IN NS ip-dns-2.cern.ch. spectrum IN CNAME spectrum-lb.cern.ch. and spectrum-lb.cern.ch contains: $ORIGIN . $TTL 60 ; 1 minute spectrum-lb.cern.ch IN SOA ip-dns-1.cern.ch. internal-dns.cern.ch. ( 273 ; serial 3600 ; refresh (1 hour) 300 ; retry (5 minutes) 3600000 ; expire (5 weeks 6 days 16 hours) 60 ; minimum (1 minute) ) NS ip-dns-1.cern.ch. NS ip-dns-2.cern.ch. A xxx.xxx.xx.140 named configuration file is identical between 9.11 and 9.16 except for the following options that we have added for 9.16: #BIND916 options qname-minimization disabled; stale-answer-enable no; stale-refresh-time 0; #default is 30 max-stale-ttl 1w; dnssec-policy none; synth-from-dnssec no; min-cache-ttl 0; min-ncache-ttl 0; minimal-responses no; (*) On an external DNS server you can try with the following similar case: Running DiG 9.11.21 on a linux client ext-dns-1 (192.65.187.5) runs BIND9.16: dig @ext-dns-1 foundservices.cern.ch | grep flags | grep ANSWER ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 dig @ext-dns-1 foundservices.cern.ch +norecurse | grep flags | grep ANSWER ;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 Full output: dig @192.65.187.5 foundservices.cern.ch +norecurse ; <<>> DiG 9.11.21 <<>> @192.65.187.5 foundservices.cern.ch +norecurse ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9899 ;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 8786b980a1a80a7901000000635a7898a512a21aa6138faf (good) ;; QUESTION SECTION: ;foundservices.cern.ch. IN A ;; ANSWER SECTION: foundservices.cern.ch. 900 IN CNAME db-lb-1234.cern.ch. ;; Query time: 2 msec ;; SERVER: 192.65.187.5#53(192.65.187.5) ;; WHEN: Thu Oct 27 14:24:56 CEST 2022 ;; MSG SIZE rcvd: 103 ip-dns-0 runs BIND9.11: dig @ip-dns-0 foundservices.cern.ch | grep flags | grep ANSWER ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 4 dig @ip-dns-0 foundservices.cern.ch +norecurse | grep flags | grep ANSWER ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 4 Does that help ? Greg, can I send you a pcap file in a private email ? Thanks, Veronique > On 27/10/2022 10:09 Greg Choules <gregchoules+bindus...@googlemail.com> wrote: > > > > > Hi Veronique. > No, we cannot easily reproduce this behaviour because we have no knowledge of > the configs of either of those servers, the details of the zones you have > configured, the contents of those zones or of the system on which you are > running the dig command. > > > > As I said, we need to see everything please: > - Full digs, not +short > - you have specified @ip-dns0 and @ip-dns1 - the full configs of both of > those servers please, including zone definitions and contents for where > "spectrum.cern.ch <http://spectrum.cern.ch/>" lives as it is not a name that > can be resolved from the public Internet > - a binary pcap file, using the -w option of tcpdump, capturing all port 53 > traffic (UDP and TCP) between this machine and both DNS servers. > > > By the way, when using the @<server> option of dig please use explicit IP > addresses, not names. If you use a name, then dig first has to resolve that > name and the place it will go to do that is resolv.conf. So it is now > dependent on your system DNS setup to get an IP address to send the dig to. > Also, you have specified @<simple_host_name> not @<FQDN>. This suggests to me > that in resolv.conf you have a 'search' list. Personally I don't like search > lists because they potentially increase the workload of the DNS system > generally, lengthen query times and mean that you can't be sure exactly where > an answer came from. > > > Thanks, Greg > > > > > On Thu, 27 Oct 2022 at 08:08, Veronique Lefebure <veronique.lefeb...@cern.ch > <mailto:veronique.lefeb...@cern.ch>> wrote: > > > > Hi all, > > > > > > yes, here is a concrete example: > > > > > > # ip-dns-1 runs BIND 9.16.33: > > > > > > dig @ip-dns-1 spectrum.cern.ch <http://spectrum.cern.ch> +short +norecurse > > spectrum-lb.cern.ch <http://spectrum-lb.cern.ch>. <------------- Here > > we get only the CNAME > > > > > > > > # ip-dns-0 runs BIND 9.11: > > > > > > dig @ip-dns-0 spectrum.cern.ch <http://spectrum.cern.ch> +short +norecurse > > spectrum-lb.cern.ch <http://spectrum-lb.cern.ch>. > > xxx.xxx.xx.140 <-------- Here we get in addition the IP of > > spectrum-lb.cern.ch <http://spectrum-lb.cern.ch>. > > > > > > > > > > > > And yes, a capture shows confirms indeed that dig returns less information > > when the BIND 9.16.33 DNS server is used. > > > > > > I guess you can easily reproduce that behaviour, unless it is due to a > > mis-configuration bit on our DNS server ? > > > > > > Thanks, > > Véronique > > > > > On 26/10/2022 21:04 Greg Choules <gregchoules+bindus...@googlemail.com > > > <mailto:gregchoules%2bbindus...@googlemail.com>> wrote: > > > > > > > > > > > > > > > Hi Veronique. > > > As other people have said, more details please. > > > > > > > > > To have a complete picture of what is going on, not only would we need to > > > know what your dig tests look like, but also where dig is sending its > > > queries and how that DNS server is configured. > > > > > > > > > You can tell dig to send queries anywhere, using @<server>. However, if > > > you don't use that it will default to using the nameservers in > > > /etc/resolv.conf. So it may be useful to see the contents of that. > > > > > > > > > Wherever dig is sending its queries, we would need to know what that > > > server will do with them. So its configuration would also be useful. > > > > > > > > > Lastly, the best way to see queries and responses, right down to the nuts > > > and bolts, is with a packet capture. > > > > > > > > > > > > > > > You thought this was an easy question, huh ;) > > > > > > Can you provide at least some of these things, to get started? > > > > > > > > > Cheers, Greg > > > > > > > > > On Wed, 26 Oct 2022 at 16:41, Veronique Lefebure > > > <veronique.lefeb...@cern.ch <mailto:veronique.lefeb...@cern.ch>> wrote: > > > > > > > > Hi, > > > > > > > > > > > > dig answer is different between BIND 9.11 and BIND 9.16(.33) when > > > > +norecurse option is used. > > > > Is this documented somewhere ? > > > > > > > > > > > > Is there an option that needs to be set so that the behaviour of 9.16 > > > > is the same as the one in 9.11. > > > > > > > > > > > > The change is that with 9.16, if the requested name is a CNAME, only > > > > the CNAME value is returned by dig, while with 9.11 dig would return > > > > both the CNAME value and the IP of the CNAME. > > > > > > > > > > > > Thanks, > > > > Veronique -- > > > > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > > > > from this list > > > > > > > > ISC funds the development of this software with paid support > > > > subscriptions. Contact us at https://www.isc.org/contact/ for more > > > > information. > > > > > > > > > > > > bind-users mailing list > > > > bind-users@lists.isc.org <mailto:bind-users@lists.isc.org> > > > > https://lists.isc.org/mailman/listinfo/bind-users > > >
-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
