Re: dig +norecurse behaviour changed with 9.16.33
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: 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.
Re: dig +norecurse behaviour changed with 9.16.33
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: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9899 ;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; E
DoT forwarding from BIND9
Hello, I tried to find a way how to configure queries forwarding over encrypted channel. But unlike zone transfer and notifications, I have not found a way to configure query forwarding over DNS over TLS even in latest 9.18.9 version. Have I looked wrong? Is there some important limit why this is not straightforward to configure? Is there some architectural change needed to be able to handle high enough count of forwarded queries? I think acting as a cache for local network and forwarding queries over encrypted channel might be quite common configuration. But I have not found a way how to specify tls paramters for forwarders clause. Is there some reason for it? Is there missing some important implementation detail? I think unbound can forward queries over encrypted channel just fine. Is bind able to configure the same thing? Version 9.18 already has solid support for queries served over XoT. Is it still missing ability to forward queries? Regards, Petr -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- 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: DoT forwarding from BIND9
> On Dec 14, 2022, at 10:12 AM, Petr Menšík wrote: > > Hello, > > I tried to find a way how to configure queries forwarding over encrypted > channel. But unlike zone transfer and notifications, I have not found a way > to configure query forwarding over DNS over TLS even in latest 9.18.9 version. > Petr, You didn’t miss it, we don’t have it yet. https://gitlab.isc.org/isc-projects/bind9/-/issues/3726 Vicky-- 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: DoT forwarding from BIND9
Hi Vicky. Excellent, thank you for the issue link. Is backport to 9.18 decided already? Would it appear on minor updates in 9.18.x line? I see comment it needs some missing feature. Is that temporary issue or already decided? It seems to be important prerequisite for Zero Trust initiative implementation. On 12/14/22 16:16, Victoria Risk wrote: Petr, You didn’t miss it, we don’t have it yet. https://gitlab.isc.org/isc-projects/bind9/-/issues/3726 Vicky -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- 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
Domain no longer fully secure after move
Hi, I'm trying to understand what exactly is wrong with DNSSEC for my domain, penguinpee.nl, before contacting involved parties. I recently (last weekend) moved the domain to a new registrar. The keys are now managed by the registrar directly. At least I don't see an option providing my own or additional keys in their web interface. Moreover, I'm no longer running my own DNS server. :( Previously, I could set my own BIND server as a primary server for my domain and have the registrar use AXFR to update the secondaries. The DNSViz analysis for the current situation: https://dnsviz.net/d/penguinpee.nl/Y5oJSw/dnssec/ And from before the move: https://dnsviz.net/d/penguinpee.nl/Yq3P8w/dnssec/ Verisign has one single complaint: No DS records found for penguinpee.nl in the nl zone. IIUC, the details for the DS record have to be provided by my new registrar, so SIDN can add them. -- Sandro -- 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
