dig +norecurse behaviour changed with 9.16.33
Nick Tait
nick at tait.net.nz
Fri Oct 28 21:39:19 UTC 2022
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+bindusers at 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.lefebure at 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+bindusers at googlemail.com
>>> <mailto:gregchoules%2Bbindusers at 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.lefebure at 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 at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20221029/2404c447/attachment-0001.htm>
More information about the bind-users
mailing list