per zone dnssec setting

[Shawn Zhou via bind-users]

Hi,
Does BIND9 allow per zone dnssec setting? I wanted to forward requests for 
certain zone to remote resolvers which doesn't support DNSSEC and also disable 
dnssec validation for that particular zone because forward-only resolver will 
return SERVFAIL to the client when the remote resolves don't support DNSSEC.
I was hoping I could configure dnssec on the zone level but that didn't appear 
to be supported (snippet from my test config):
zone "isc.org" {  type forward;  dnssec-validation no;  forward only;  
forwarders {       208.67.220.220;  };}

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec-validation auto vs yes

[Shawn Zhou via bind-users]

 Thanks Even. Sounds like "dnssec-validation auto" is a more future-proof 
option for what want it. I will use that instead.


On Wednesday, June 12, 2019, 5:25:51 PM PDT, Evan Hunt  
wrote:  
 
 On Wed, Jun 12, 2019 at 11:40:27PM +0000, Shawn Zhou via bind-users wrote:
> The default BIND9 installation for CentOS7 has dnssec-validation set to
> "yes" and it also includes managed-keys as well. Do those managed-keys
> get updated automatically?

Yes, if the "managed-keys" statement is in named.conf (or included in
it via an "include" statement) then the keys will be updated automatically.
Based on what you copy-pasted, that appears to be the case.

"dnssec-validation auto" causes named to use its built-in key for the root
zone, so you don't have to put your own "managed-keys" statement into
named.conf, but otherwise it's the same as "dnssec-validation yes".

(BTW, a note in passing: we're changing the command from "managed-keys" to
"dnssec-keys" over the next few years. The new syntax will be available in
BIND 9.15.1, which should be out next week; the old syntax will be
phased out later.)

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
  ___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

dnssec-validation auto vs yes

[Shawn Zhou via bind-users]

Hi,
The default BIND9 installation for CentOS7 has dnssec-validation set to "yes" 
and it also includes managed-keys as well. Do those managed-keys get updated 
automatically? It is not clear from reading 
https://ftp.isc.org/isc/dnssec-guide/html/dnssec-guide.html#dnssec-validation-explained
 that these managed-keys will get updated automatically if dnssec-validation is 
not set to "auto".
[root@centos-linux ~]# named -vBIND 9.9.4-RedHat-9.9.4-73.el7_6 (Extended 
Support Version)[root@centos-linux ~]# grep named.root.key 
/etc/named.confinclude "/etc/named.root.key";[root@centos-linux ~]# cat 
/etc/named.root.keymanaged-keys {        # ROOT KEYS: See 
https://data.iana.org/root-anchors/root-anchors.xml        # for current trust 
anchor information.        #        # This key (19036) is to be phased out 
starting in 2017. It will        # remain in the root zone for some time after 
its successor key        # has been added. It will remain this file until it is 
removed from        # the root zone.        . initial-key 257 3 8 
"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF 
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX 
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD 
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz 
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS 
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=";
        # This key (20326) is to be published in the root zone in 2017.        
# Servers which were already using the old key should roll to the        # new 
# one seamlessly.  Servers being set up for the first time        # can use 
either of the keys in this file to verify the root keys        # for the first 
time; thereafter the keys in the zone will be        # trusted and maintained 
automatically.        . initial-key 257 3 8 
"AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 
+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv 
ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 
0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e 
oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd 
RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN R1AkUTV74bU=";};

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

how does BIND resolvers pick the authoritative servers to query

[Shawn Zhou via bind-users]

I am seeing occasional SERVFAILs when I flush BIND cache then run test queries 
with dig.
Can someone let me know how BIND picks the authoritative server to query?

>From what I know, BIND picks an authoritative server by assign random RTT to 
>authoritative servers then queries the one with smallest RTT. If BIND picks an 
>ipv6 authoritative server, and it can't reach it due to iptables/networking 
>route and etc. Will it try the next authoritative which maybe an ipv4 
>authoritative server?


The particular record that I have problems is s.afl.com.au which has two auths 
(dns1.cscdns.net. and dns2.cscdns.net). Both of these auths have ipv4 and ipv6 
address. This is how to run my tests:
for i in {1..10}; do rndc flush; dig @localhost s.afl.com.au; sleep 3; done 
|grep -i status
I wonder the SERVFAILs I see is due BIND picks the ipv6 auth which is not 
reachable and causes SERVFAILs.

After I updated BIND (9.11.2) to only do ipv4, my test queries went fine 
without issues.






___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

bugs with BIND 9.11.0-P3 edns client subnet

[Shawn Zhou via bind-users]

Hello all,
Does anyone use BIND 9.11.0-P3 in recursive setup with edns client subnet 
support?When I dig against a local recursive resolver (BIND 9.11.0-P3) with 
'+subnet=' option, it doesn't send 'Client subnet' option to the authoritative 
server which also runs the same version of BIND; however, if I dig directly 
against the authorize server with '+subnet=' option and it works fine. Is this 
a known bug with client subnet implementation in BIND?

Thanks,Shawn___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: [dns-operations] bind edns-client-subnet

[Shawn Zhou via bind-users]

 Hi Mukund,I filed a bug ISC-Bugs #45846. I wonder if what I saw was due to 
config issues or not. Does anyone also have similar problems?
On Thursday, August 17, 2017, 7:09:07 PM PDT, Mukund Sivaraman 
 wrote:  
 
 On Fri, Aug 18, 2017 at 01:14:50AM +, Shawn Zhou wrote:
> Hello, I am running BIND 9.11.0 with edns-client-subnet support. I
> have geo rules to return a different IP for a test record only for
> Germany. BIND give responses with client-subnet scope is set to '/0'
> for queries for countries  (say, 127.0.0.1) other than Germany. Why
> would BIND return client-subnet scope 0 when there is no geo rule
> match the IP provided in client-subnet? Do I miss settings in my
> configs?

Also, the right place to ask for help with BIND issues is the bind-users
list. dns-operations list is meant for discussions on operational
issues.

https://lists.isc.org/mailman/listinfo/bind-users

        Mukund
  ___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users