Hi Ondrej,

Thanks for your reply (and sorry for the delay on this on my side).
Yes, I am aware of the new default for the `minimal-responses` option: we have 
set it to "no".

But anyway, if I am not wrong, the minimal-response option controls whether or 
not the NS records are returned, right ?

I have 2 similar DNS servers, one running BIND9.11 and one running BIND9.16 
with default minimal-response option.

On the second one, the "AUTHORITY SECTION" and "ADDITIONAL SECTION" are omitted 
(as expected because of the minimal-response).
But I can see on both servers that the CNAME and A records are returned in the 
"ANSWER SECTION".

So the "minimal-response" option is not the one controlling whether or not both 
CNAME and A are turned by dig, right ?
Thanks,
Veronique
________________________________
From: Ondřej Surý <ond...@isc.org>
Sent: Monday, October 31, 2022 5:30 PM
To: BIND users <bind-users@lists.isc.org>
Cc: Veronique Lefebure <veronique.lefeb...@cern.ch>
Subject: Re: dig +norecurse behaviour changed with 9.16.33

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

Reply via email to