Since we have already established that this is not a **dig** issue, you might want to look at the `minimal-responses` option. The default has changed from `no` to `no-auth-recursive` in 9.12.0
Anyway, the 9.16.0 is doing the right thing because there's a zone cut between the two names, any resolver still has to revalidate the answer, and there's no point in appending records that would be thrown away anyway. Cheers, Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 28. 10. 2022, at 22:39, Nick Tait via bind-users > <bind-users@lists.isc.org> wrote: > > Hi Veronique. > > I'm not an expert, but to me the 9.16 behaviour is what I would expect to > happen, based on: > > When you issue the non-recursive query for "spectrum.cern.ch", it is answered > from the "cern.ch" zone, which only knows the CNAME (returned in the ANSWER > section) and the NS records for the zone that the CNAME points to (presumably > returned in the ADDITIONAL section?). > A [hypothetical] subsequent non-recursive query for "spectrum-lb.cern.ch" > would be answered from the "spectrum-lb.cern.ch" zone which contains the A > records (which should be returned in the ANSWER section of that query). > (A recursive resolver would be expected to make both of the queries above to > give a complete answer to the query for "spectrum.cern.ch".) > > But aside from the observation that the responses from 9.11 and 9.16 aren't > the same, what is the actual problem you are trying to solve? i.e. Why does > it matter if the A record is or isn't returned in a non-recursive query for > "spectrum.cern.ch"? > > Nick. > > > On 28/10/22 01:28, Veronique Lefebure wrote: >> 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> >>> <mailto: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
-- 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
