subject:"Re\: dig \+norecurse behaviour changed with 9.16.33"

Re: dig +norecurse behaviour changed with 9.16.33

2022-12-14 Thread Ondřej Surý

I think it would be useful if you read the documentation on the feature before we continue this thread. Guessing what the feature is or isn’t does not help helpful discussion.8. Configuration Reference — BIND 9 9.18.9 documentationbind9.readthedocs.ioThanks,--Ondřej Surý — ISC (He/Him)My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.On 14. 12. 2022, at 11:21, Veronique Lefebure  wrote:






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ý 
Sent: Monday, October 31, 2022 5:30 PM
To: BIND users 
Cc: Veronique Lefebure 
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  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) 
360 ; 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: 
;; ->>HE

Re: dig +norecurse behaviour changed with 9.16.33

2022-12-14 Thread Veronique Lefebure

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ý 
Sent: Monday, October 31, 2022 5:30 PM
To: BIND users 
Cc: Veronique Lefebure 
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  
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)
360 ; 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: 8786b980a1a80a790100635a7898a512a21aa6138faf (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:

Re: dig +norecurse behaviour changed with 9.16.33

2022-11-01 Thread Petr Menšík


It seems to me this is a very similar question to previous thread named:

Classless reverse zones CNAME and PTR resolution issue

When your query does not request recursion then CNAME is not followed to 
other zones by authoritative server. For iterative recursive servers, be 
it bind9, unbound or similar, this is not a problem. The answer points 
where to follow. Another non-recursive query to spectrum-lb subdomain is 
required.


That is change done on 9.16.x and later. Any standards following 
implementation should handle it well.


May I ask why is this change considered a problem? If it did break 
anything then I assume the fix should be done elsewhere, not on bind9 
side. Is there any recursive resolver which is not able to follow such 
answers and to deliver final result to asking clients? Were you solving 
this difference just for curiosity or did it break something not yet 
mentioned?


Regards,
Petr

On 27. 10. 22 14: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)
360 ; 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: 8786b980a1a80a790100635a7898a512a21aa6138faf (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 
 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 " 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 @ 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 @ not @. 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 
 wrote:


Hi all,

yes, here is a concrete example:

Re: dig +norecurse behaviour changed with 9.16.33

2022-10-31 Thread Ondřej Surý

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 
>  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) 
>> 360 ; 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: 8786b980a1a80a790100635a7898a512a21aa6138faf (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  
>>>  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

Re: dig +norecurse behaviour changed with 9.16.33

2022-10-28 Thread Nick Tait via bind-users


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)
360 ; 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: 8786b980a1a80a790100635a7898a512a21aa6138faf (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 
 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 " 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 @ 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 @ not @. 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,

Re: dig +norecurse behaviour changed with 9.16.33

2022-10-27 Thread Greg Choules via bind-users

Hi Veronique.
As Petr said, please don't send a pcap. This is getting beyond the scope of
the list and into proper support territory. For which I would recommend
that CERN pay ISC for professional support services.

Regarding your external example, I get this:
%dig @192.65.187.5 foundservices.cern.ch | grep flags | grep ANSWER
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

ip-dns-0.cern.ch. 900 IN A 137.138.28.176
; <<>> DiG 9.18.5 <<>> @137.138.28.176 foundservices.cern.ch
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Both queries and responses are different from the ones in your mails and
the response I receive for "foundservices.cern.ch" from ext-dns-1 contains
only 1 answer, regardless of whether recursion (which the server doesn't
accept) is requested or not.

In short, this example does not help to explain what you are seeing.
Greg

On Thu, 27 Oct 2022 at 13: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)
> 360 ; 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: 8786b980a1a80a790100635a7898a512a21aa6138faf (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 
> 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" 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 @ 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 @ not @. 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

Re: dig +norecurse behaviour changed with 9.16.33

2022-10-27 Thread Bob McDonald

Are the zones cern.ch and spectrum-lb.cern.ch on the same authoritative
sDNS server?
-- 
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

Re: dig +norecurse behaviour changed with 9.16.33

2022-10-27 Thread Petr Špaček


Hello,

please see answer in-line:

On 27. 10. 22 14:28, Veronique Lefebure wrote:

(*) 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


Please note that your output above contains "ra" flag - Recursion 
Available. That one should be set only when talking to a resolver which 
can chase down indirection as needed.


I'm getting different answer when I ask from my machine:

$ dig @192.65.187.5 foundservices.cern.ch | grep flags | grep ANSWER
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

Most importantly, no "ra" flag is listed here.

This can be either a configuration thing (an ACL which allows recursion 
for your source address but not mine), or something messing with packets 
on network level.


It's hard to say what is going on when we can't see configs and can't 
access the servers.


In case sharing real configs & zones on this mailing list is not an 
option then there are two possible ways forward:


1. Reproduce the problem by recreating minimal working configuration & 
zone data to demonstrate the exact behavior using only the data which 
can be shared.


2. Get commercial support with NDA in place. With that in place we could 
hopefully be allowed to see everything we need. Please see 
https://www.isc.org/support/ for more details.



Greg, can I send you a pcap file in a private email ?

I'm not Greg, but please don't e-mail us privately.

https://blog.powerdns.com/2016/01/18/open-source-support-out-in-the-open/ 
applies here as well.


--
Petr Špaček

--
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

Re: dig +norecurse behaviour changed with 9.16.33

2022-10-27 Thread Veronique Lefebure


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)
360 ; 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: 8786b980a1a80a790100635a7898a512a21aa6138faf (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 
 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 " 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 @ 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 @ not @. 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  > wrote:
> > 
> > Hi all,
> > 
> > 
> > yes, here is a concrete example:
> > 
> > 
> > # ip-dns-1 runs BIND 9.16.33:
> > 
> > 
> > dig @ip-dns-1 spectrum.cern.ch  +short +norecurse
> > spectrum-lb.cern.ch . <- Here 
> > we get only the CNAME
> > 
> > 
> > 
> > # ip-dns-0 runs BIND 9.11:
> > 
> > 
> > dig @ip-dns-0 spectrum.cern.ch  +short +norecurse
> > spectrum-lb.cern.ch .
> > xxx.xxx.xx.140 < Here we get in addition the IP of 
> > 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 
> >

Re: dig +norecurse behaviour changed with 9.16.33

2022-10-27 Thread Matus UHLAR - fantomas


On 27.10.22 09:08, Veronique Lefebure wrote:

yes, here is a concrete example:

# ip-dns-1 runs BIND 9.16.33:

dig @ip-dns-1 spectrum.cern.ch +short +norecurse
spectrum-lb.cern.ch. <- Here we get only the CNAME



# ip-dns-0 runs BIND 9.11:

dig @ip-dns-0 spectrum.cern.ch +short +norecurse
spectrum-lb.cern.ch.
xxx.xxx.xx.140 < Here we get in addition the IP of 
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 ?


I could not reproduce as the query currently returns NXDOMAIN

AFAIK different servers may return different results depending if they have 
the requested record in cache or not.


+norecurse only asks server not to send query out, it doesn't prevent 
returning cached record.




--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Nothing is fool-proof to a talented fool.
--
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

Re: dig +norecurse behaviour changed with 9.16.33

2022-10-27 Thread Greg Choules via bind-users

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" 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 @ 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 @ not @. 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 
wrote:

> Hi all,
>
> yes, here is a concrete example:
>
> # ip-dns-1 runs BIND 9.16.33:
>
> dig @ip-dns-1 spectrum.cern.ch +short +norecurse
> spectrum-lb.cern.ch. <- Here we get only the CNAME
>
> # ip-dns-0 runs BIND 9.11:
>
> dig @ip-dns-0 spectrum.cern.ch +short +norecurse
> spectrum-lb.cern.ch.
> xxx.xxx.xx.140 < Here we get in addition the IP of
> 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 
> 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 @. 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> 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
> 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

Re: dig +norecurse behaviour changed with 9.16.33

2022-10-27 Thread Veronique Lefebure


Hi all,


yes, here is a concrete example:


# ip-dns-1 runs BIND 9.16.33:


dig @ip-dns-1 spectrum.cern.ch +short +norecurse
spectrum-lb.cern.ch. <- Here we get only the CNAME



# ip-dns-0 runs BIND 9.11:


dig @ip-dns-0 spectrum.cern.ch +short +norecurse
spectrum-lb.cern.ch.
xxx.xxx.xx.140 < Here we get in addition the IP of 
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  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 @. 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  > 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 
> > 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

Re: dig +norecurse behaviour changed with 9.16.33

2022-10-26 Thread Ondřej Surý

Or cache snooping behaves differently between two (or multiple) queries.

That’s why questions like this should not imply where the problem is but rather 
describe what can be seen (possibly also on the wire).

Ondrej
--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.

> On 26. 10. 2022, at 21:25, Jan-Piet Mens via bind-users 
>  wrote:
> 
> 
>> 
>> 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.
> 
> as others have said, this needs more details, but I wonder whether you might
> now be querying a server which has `minimal-responses yes' configured which it
> didn't previously.
> 
>-JP
> 
> -- 
> 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

Re: dig +norecurse behaviour changed with 9.16.33

2022-10-26 Thread Jan-Piet Mens via bind-users


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.


as others have said, this needs more details, but I wonder whether you might
now be querying a server which has `minimal-responses yes' configured which it
didn't previously.

-JP

--
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

Re: dig +norecurse behaviour changed with 9.16.33

2022-10-26 Thread Greg Choules via bind-users

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 @. 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 
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
> 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

RE: dig +norecurse behaviour changed with 9.16.33

2022-10-26 Thread Bob McDonald

For both versions of bind, please submit the actual dig command and the
complete results received. That will make diagnosing this issue MUCH easier.

Regards,

Bob
-- 
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

Re: dig +norecurse behaviour changed with 9.16.33

2022-10-26 Thread Andrew Latham

I am unable to reproduce this. Please share some examples like this:


dig +norecurse @216.239.34.110 www.lathama.org

```
; <<>> DiG 9.11.5-P4-5.1+deb10u8-Debian <<>> +norecurse @216.239.34.110
www.lathama.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28525
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.lathama.org.   IN  A

;; ANSWER SECTION:
www.lathama.org.3600IN  CNAME   lathama.net.

;; Query time: 58 msec
;; SERVER: 216.239.34.110#53(216.239.34.110)
;; WHEN: Wed Oct 26 18:02:45 UTC 2022
;; MSG SIZE  rcvd: 69
```

```
dig +norecurse @216.239.36.110 www.lathama.org

; <<>> DiG 9.16.33-Debian <<>> +norecurse @216.239.34.110 www.lathama.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25859
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.lathama.org.   IN  A

;; ANSWER SECTION:
www.lathama.org.3600IN  CNAME   lathama.net.

;; Query time: 48 msec
;; SERVER: 216.239.36.110#53(216.239.36.110)
;; WHEN: Wed Oct 26 12:03:51 MDT 2022
;; MSG SIZE  rcvd: 69
```

On Wed, Oct 26, 2022 at 10:07 AM Ondřej Surý  wrote:

> You need to be more specific with real examples.
>
> Ondrej
> --
> Ondřej Surý — ISC (He/Him)
>
> My working hours and your working hours may be different. Please do not
> feel obligated to reply outside your normal working hours.
>
> > On 26. 10. 2022, at 17:41, Veronique Lefebure <
> 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
> > 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
>


-- 
- Andrew "lathama" Latham -
-- 
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

Re: dig +norecurse behaviour changed with 9.16.33

2022-10-26 Thread Ondřej Surý

You need to be more specific with real examples.

Ondrej 
--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.

> On 26. 10. 2022, at 17:41, Veronique Lefebure  
> 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
> 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

Re: dig +norecurse behaviour changed with 9.16.33

Re: dig +norecurse behaviour changed with 9.16.33

Re: dig +norecurse behaviour changed with 9.16.33

Re: dig +norecurse behaviour changed with 9.16.33

Re: dig +norecurse behaviour changed with 9.16.33

Re: dig +norecurse behaviour changed with 9.16.33

Re: dig +norecurse behaviour changed with 9.16.33

Re: dig +norecurse behaviour changed with 9.16.33

Re: dig +norecurse behaviour changed with 9.16.33

Re: dig +norecurse behaviour changed with 9.16.33

Re: dig +norecurse behaviour changed with 9.16.33

Re: dig +norecurse behaviour changed with 9.16.33

Re: dig +norecurse behaviour changed with 9.16.33

Re: dig +norecurse behaviour changed with 9.16.33

Re: dig +norecurse behaviour changed with 9.16.33

RE: dig +norecurse behaviour changed with 9.16.33

Re: dig +norecurse behaviour changed with 9.16.33

Re: dig +norecurse behaviour changed with 9.16.33

18 matches

Site Navigation

Mail list logo

Footer information