RE: Issue running "dig txt rs.dns-oarc.net" on 9.12
Thanks for the information Cathy. I've always run the Red Hat provided packages in the past, this is the first time I've ever tried running the newest release direct. Mostly I'm just feeling extra cautious since this is something I've never done before and admittedly I don't know as much about DNS as I should so I really appreciate you taking the time to break down what is happening. Based on your explanation it sounds like this isn't something I'll ever run into other than this one special case so I'll stop worrying about it. Thank you! -Nick -Original Message- From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Cathy Almond Sent: Tuesday, February 27, 2018 4:29 AM To: bind-users@lists.isc.org Subject: Re: Issue running "dig txt rs.dns-oarc.net" on 9.12 On 22/02/2018 16:44, NNEX Support wrote: > I'm sorry to keep replying to myself but I believe I've found the line of > code that is causing this issue. Looking at validator.c, in the > check_deadlock function, 9.12.0rc1 says: > > ... > > if (parent->event != NULL && > parent->event->type == type && > dns_name_equal(parent->event->name, name) && > > ... > > 9.12.0rc3 and above says: > > ... > > if (parent->event != NULL && > (parent->event->type == type || > parent->event->type == dns_rdatatype_cname) && > dns_name_equal(parent->event->name, name) && > > ... > > By removing "parent->event->type == dns_rdatatype_cname)" (and adjusting the > rest of the if statement appropriately) the query "dig ns rs.dns-oarc.net" > works. > > I see this commit related to this line of code: > https://gitlab.isc.org/isc-projects/bind9/commit/2b51d5874c49ac823890b > 88824290fbf1c18f2cc > > I'm sure this line of code is important, otherwise it wouldn't be there and I > don't know enough to be removing random bits of code, so of course I'd never > run this in production. Still I want to understand why this is happening and > if it’s a bug or me not understanding DNS properly. Good sleuthing - though apart from understanding why the query now fails, I don't think there's any code defect that needs to be addressed. This line of code belongs with these changes between RC1 and RC3. They are kinda important (note the CVE reference): 4859. [bug] A loop was possible when attempting to validate unsigned CNAME responses from secure zones; this caused a delay in returning SERVFAIL and also increased the chances of encountering CVE-2017-3145. [RT #46839] 4858. [security] Addresses could be referenced after being freed in resolver.c, causing an assertion failure. (CVE-2017-3145) [RT #46839] The debug log you pointed to was also specific about why the validation stopped: validating rs.dns-oarc.net/CNAME: checking existence of DS at 'rs.dns-oarc.net' validating rs.dns-oarc.net/CNAME: continuing validation would lead to deadlock: aborting validation validating rs.dns-oarc.net/CNAME: deadlock found (create_fetch) The rs.dns-oarc.net zone is broken because it returns a CNAME for queries at the apex. Observe the delegation (I'm querying one of the servers auth for dns-oarc.net): ; <<>> DiG 9.11.2 <<>> +norec +dnssec @64.191.0.65 rs.dns-oarc.net NS ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43571 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: 47d4eddbbbde6fd18616a25b5a952d35767788ad0b03038f (good) ;; QUESTION SECTION: ;rs.dns-oarc.net. IN NS ;; AUTHORITY SECTION: rs.dns-oarc.net.3600IN NS ns00.rs.dns-oarc.net. rs.dns-oarc.net.3600IN NSECrs4.dns-oarc.net. NS RRSIG NSEC rs.dns-oarc.net.3600IN RRSIG NSEC 8 3 3600 20180328101103 20180226091103 12093 dns-oarc.net. floDmByYaxmh+QQWou7PtICj4tnpW6/ea1WzatUfAEMvPOSmm54CJ467 KWpnf5XADFgFrcHOr0gYLlbFVJrwEB5n6R+SvXOTx9zwgva3SY37Vgq8 ZMwdNPdGxmVLOz1Ou5tByfZV2ZLpueF+hBB12wft+wNCysjMuwtx4U2D a64= ;; ADDITIONAL SECTION: ns00.rs.dns-oarc.net. 3600IN A 64.191.0.133 ns00.rs.dns-oarc.net. 3600IN 2620:ff:c000:0:2::133 Then look at the query response for a DS RRset that the BIND validator is receiving from ns00.rs.dns-oarc.net: ; <<>> DiG 9.11.2 <<>> +norec +dnssec @64.191.0.133 rs.dns-oarc.net DS ; (1 server found) ;; global options: +cmd ;; Got a
RE: Issue running "dig txt rs.dns-oarc.net" on 9.12
I'm sorry to keep replying to myself but I believe I've found the line of code that is causing this issue. Looking at validator.c, in the check_deadlock function, 9.12.0rc1 says: ... if (parent->event != NULL && parent->event->type == type && dns_name_equal(parent->event->name, name) && ... 9.12.0rc3 and above says: ... if (parent->event != NULL && (parent->event->type == type || parent->event->type == dns_rdatatype_cname) && dns_name_equal(parent->event->name, name) && ... By removing "parent->event->type == dns_rdatatype_cname)" (and adjusting the rest of the if statement appropriately) the query "dig ns rs.dns-oarc.net" works. I see this commit related to this line of code: https://gitlab.isc.org/isc-projects/bind9/commit/2b51d5874c49ac823890b88824290fbf1c18f2cc I'm sure this line of code is important, otherwise it wouldn't be there and I don't know enough to be removing random bits of code, so of course I'd never run this in production. Still I want to understand why this is happening and if it’s a bug or me not understanding DNS properly. As always thank you for your time! -Nick ___ 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: Issue running "dig txt rs.dns-oarc.net" on 9.12
I apologize, I sent the previous email in error. This is what I get for having so many revisions of named sitting around on one server, I was not running 9.12.1b1 when I tested this. I will be more careful in the future. I just tested this with 9.12.1b1 and it still fails, the same as 9.12. I do understand that the function of rs.dns-oarc.net is to test things that can no longer be tested in 9.12, but regardless I should still be able to resolve the nameservers for rs.dns-oarc.net, right? Is anyone on 9.12 able to do this? Is this just my problem? Thank you again, -Nick -Original Message- From: NNEX Support Sent: Thursday, February 22, 2018 8:21 AM To: 'bind-users@lists.isc.org' Subject: RE: Issue running "dig txt rs.dns-oarc.net" on 9.12 Just wanted to follow up 9.12.1b1 fixes this issue for me. Thanks, -Nick ___ 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: Issue running "dig txt rs.dns-oarc.net" on 9.12
Just wanted to follow up 9.12.1b1 fixes this issue for me. Thanks, -Nick ___ 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: Issue running "dig txt rs.dns-oarc.net" on 9.12
[…] If you want to understand why your resolver is failing, again I'd have a look at the 'resolver' log channel. It should have some detail about what's resulting in the SERVFAIL message. […] I took a look at the ‘resolver’ log channel. I didn’t find any useful information there, just: fetch: rs.dns-oarc.net/TXT fetch: sns-pb.isc.org/A fetch: ns.isc.afilias-nst.info/A fetch: net/DS fetch: dns-oarc.net/DS fetch: net/DNSKEY I started trying different releases and found this query works consistently for me all the way up to bind-9.12.0rc1. As soon as I try bind-9.12.0rc3 the queries start failing. I’m using the exact same config and server for both the working rc1 and not working rc3 (both complied from source). Any thoughts on any differences between RC1 and RC3 that might explain this or any other logs I should be checking? The ‘resolver’ log channel on rc1 (which works) shows: fetch: rs.dns-oarc.net/TXT fetch: sns-pb.isc.org/A fetch: ns.isc.afilias-nst.info/A fetch: net/DS fetch: dns-oarc.net/DS fetch: net/DNSKEY fetch: rs.dns-oarc.net/DS fetch: dns-oarc.net/DNSKEY fetch: rst.x487.rs.dns-oarc.net/TXT fetch: rst.x461.x487.rs.dns-oarc.net/TXT fetch: rst.x466.x461.x487.rs.dns-oarc.net/TXT Looking at the ‘dnssec’ log channel I see this on RC1: validating rs.dns-oarc.net/CNAME: starting validating rs.dns-oarc.net/CNAME: attempting insecurity proof validating rs.dns-oarc.net/CNAME: checking existence of DS at 'net' validating net/DS: starting validating net/DS: attempting positive response validation validating net/DS: keyset with trust secure validating net/DS: verify rdataset (keyid=41824): success validating net/DS: marking as secure, noqname proof not needed validating rs.dns-oarc.net/CNAME: in dsfetched2: success validating rs.dns-oarc.net/CNAME: resuming proveunsecure validating rs.dns-oarc.net/CNAME: checking existence of DS at 'dns-oarc.net' validating dns-oarc.net/DS: starting validating dns-oarc.net/DS: attempting positive response validation validating net/DNSKEY: starting validating net/DNSKEY: attempting positive response validation validating net/DNSKEY: verify rdataset (keyid=35886): success validating net/DNSKEY: marking as secure (DS) validating dns-oarc.net/DS: in fetch_callback_validator validating dns-oarc.net/DS: keyset with trust secure validating dns-oarc.net/DS: resuming validate validating dns-oarc.net/DS: verify rdataset (keyid=25733): success validating dns-oarc.net/DS: marking as secure, noqname proof not needed validating rs.dns-oarc.net/CNAME: in dsfetched2: success validating rs.dns-oarc.net/CNAME: resuming proveunsecure validating rs.dns-oarc.net/CNAME: checking existence of DS at 'rs.dns-oarc.net' validating rs.dns-oarc.net/DS: starting validating rs.dns-oarc.net/DS: attempting negative response validation validating dns-oarc.net/SOA: starting validating dns-oarc.net/SOA: attempting positive response validation validating dns-oarc.net/DNSKEY: starting validating dns-oarc.net/DNSKEY: attempting positive response validation validating dns-oarc.net/DNSKEY: verify rdataset (keyid=20899): success validating dns-oarc.net/DNSKEY: marking as secure (DS) validating dns-oarc.net/SOA: in fetch_callback_validator validating dns-oarc.net/SOA: keyset with trust secure validating dns-oarc.net/SOA: resuming validate validating dns-oarc.net/SOA: verify rdataset (keyid=12093): success validating dns-oarc.net/SOA: marking as secure, noqname proof not needed validating rs.dns-oarc.net/DS: in authvalidated validating rs.dns-oarc.net/DS: resuming nsecvalidate validating rs.dns-oarc.net/NSEC: starting validating rs.dns-oarc.net/NSEC: attempting positive response validation validating rs.dns-oarc.net/NSEC: keyset with trust secure validating rs.dns-oarc.net/NSEC: verify rdataset (keyid=12093): success validating rs.dns-oarc.net/NSEC: marking as secure, noqname proof not needed validating rs.dns-oarc.net/DS: in authvalidated validating rs.dns-oarc.net/DS: looking for relevant NSEC validating rs.dns-oarc.net/DS: nsec proves name exists (owner) data=0 validating rs.dns-oarc.net/DS: resuming nsecvalidate validating rs.dns-oarc.net/DS: nonexistence proof(s) found validating rs.dns-oarc.net/CNAME: in dsfetched2: ncache nxrrset validating rs.dns-oarc.net/CNAME: marking as answer (dsfetched2) validating rst.x476.rs.dns-oarc.net/CNAME: starting validating rst.x476.rs.dns-oarc.net/CNAME: attempting insecurity proof validating rst.x476.rs.dns-oarc.net/CNAME: checking existence of DS at 'net' validating rst.x476.rs.dns-oarc.net/CNAME: checking existence of DS at 'dns-oarc.net' validating rst.x476.rs.dns-oarc.net/CNAME: checking existence of DS at 'rs.dns-oarc.net' validating rst.x476.rs.dns-oarc.net/CNAME: marking as answer (proveunsecure (4)) validating rst.x461.x476.rs.dns-oarc.net/CNAME: starting validating rst.x461.x476.rs.dns-oarc.net/CNAME: attempting insecurity proof validating rst.x461.x476.rs.dns-oarc.net/CNAME: checking existence of DS at 'net' validating
RE: Issue running "dig txt rs.dns-oarc.net" on 9.12
Good thought but no luck, it doesn’t matter how many times I run “dig txt rs.dns-oarc.net” or how long I wait it continues to SERVFAIL until I run "dig txt rs.dns-oarc.net +trace" Interestingly I've found that running "dig txt dns-oarc.net +trace" isn't enough to fix it, I actually have to run "dig txt rs.dns-oarc.net +trace" before things start working. [...] There's an insecure delegation (NS set, and NSEC proving the nonexistence of a DS set) from dns-oarc.net to rs.dns-oarc.net. However, there's disagreement between the parent and child about what name servers actually serve rs.dns-oarc.net, and at least some of them are refusing to answer TCP. It's likely your recursive server is, for whatever reason, being drawn to the ones failing to respond, and not getting good data elsewhere fast enough to answer your query. [...] I agree, from my limited understanding this seems to describe what is happening well. The thing I'm wondering is why? I'm running older visions of named (9.9.4, yum provided RPM on CentOS 6) that seem immune to this issue. I've been digging through release notes and can't find any setting that has changed between the versions that might explain it (I know 9.9.4 to 9.12 is a big jump, so I'm sure I'm missing something) Thank you! -Nick ___ 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
Issue running "dig txt rs.dns-oarc.net" on 9.12
I'm sure I'm doing something wrong, but for the life of me I can't figure out
what. I'm running named 9.12 in a simple recursive setup (built from source on
CentOS 7).
In named.conf I've set:
dnssec-enable yes;
dnssec-validation auto;
When I try to run "dig txt rs.dns-oarc.net" I get SERVFAIL. The logs show:
validating rs.dns-oarc.net/CNAME: starting
validating rs.dns-oarc.net/CNAME: attempting insecurity proof
validating rs.dns-oarc.net/CNAME: checking existence of DS at 'net'
validating net/DS: starting
validating net/DS: attempting positive response validation
validating net/DS: keyset with trust secure
validating net/DS: verify rdataset (keyid=41824): success
validating net/DS: marking as secure, noqname proof not needed
validating rs.dns-oarc.net/CNAME: in dsfetched2: success
validating rs.dns-oarc.net/CNAME: resuming proveunsecure
validating rs.dns-oarc.net/CNAME: checking existence of DS at 'dns-oarc.net'
validating dns-oarc.net/DS: starting
validating dns-oarc.net/DS: attempting positive response validation
validating net/DNSKEY: starting
validating net/DNSKEY: attempting positive response validation
validating net/DNSKEY: verify rdataset (keyid=35886): success
validating net/DNSKEY: marking as secure (DS)
validating dns-oarc.net/DS: in fetch_callback_validator
validating dns-oarc.net/DS: keyset with trust secure
validating dns-oarc.net/DS: resuming validate
validating dns-oarc.net/DS: verify rdataset (keyid=25733): success
validating dns-oarc.net/DS: marking as secure, noqname proof not needed
validating rs.dns-oarc.net/CNAME: in dsfetched2: success
validating rs.dns-oarc.net/CNAME: resuming proveunsecure
validating rs.dns-oarc.net/CNAME: checking existence of DS at 'rs.dns-oarc.net'
validating rs.dns-oarc.net/CNAME: continuing validation would lead to deadlock:
aborting validation
validating rs.dns-oarc.net/CNAME: deadlock found (create_fetch)
Jan 26 15:06:59 red named[3036]: no valid RRSIG resolving
'rs.dns-oarc.net/TXT/IN': 64.191.0.133#53
However if I run "dig txt rs.dns-oarc.net +trace" and then "dig txt
rs.dns-oarc.net" the query completes as expected. It continues to complete as
expected until I restart named.
If I alter named.conf to say
dnssec-enable yes;
dnssec-validation yes;
The running "dig txt rs.dns-oarc.net" works immediately, but of course that
breaks verification of the root zone, so DNSSEC is worthless.
My named.conf is super simple:
key "rndc-key" {
algorithm hmac-sha256;
secret "$KEY";
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
acl "NNEX" {
127.0.0.1;
aaa.bbb.ccc.0/22;
};
options {
listen-on port 53 { 127.0.0.1; };
listen-on port 53 { aaa.bbb.ccc.d; };
directory "/var/named";
dnssec-enable yes;
dnssec-validation auto;
allow-recursion { nnex; };
allow-query { nnex; };
recursion yes;
};
logging {
channel dnssec_log {
file "/var/log/dnssec.log";
severity debug 3;
};
category dnssec { dnssec_log; };
};
Thank you,
-Nick
___
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: about NS server authorize
Hi, ns5.cloudwebdns.com ns6.cloudwebdns.com For these two nameservers (they are the native BIND 9), we can use them to resolve the other domains like .com/.net/.org/.info etc. But when we try to setup a .me domain to be resolved by them, from the registrar's control panel, it gets failed, saying name server not authorized. This is may be something wrong around EPP and host object. Can you help setup the host object with these two nameservers into .me's registry? Thanks. On 21.03.16 15:42, supp...@cloudwebdns.com wrote: We have two nameservers, ns5.cloudwebdns.com ns6.cloudwebdns.com the primary types of domains, like com/net/org/info can be setup to be resolved by them. But some other domsins, like .me one, can't be setup in registrar's admin panel, saying nameserver not authorized. contact your registrar about this issue. thisa is not a bind problem. ___ 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
about NS server authorize
Hello, We have two nameservers, ns5.cloudwebdns.com ns6.cloudwebdns.com the primary types of domains, like com/net/org/info can be setup to be resolved by them. But some other domsins, like .me one, can't be setup in registrar's admin panel, saying nameserver not authorized. Can you help with this issue? Thanks, Kevin ___ 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
R: Again question about edns (like swupdl.adobe.com)
Good morning,
I have those Bind versions installed:
BIND 9.10.1-x86 in a Windows Server 32 bit
BIND 9.10.1-x64 in a Windows Server 64 bit
Both versions have the SIT (Source Identity Token) EDNS option enabled by
default.
You have DiG 9.10-P1 (May 8 2014) and my problems start with 9.10.0-P2 (June
6 2014)
Regards
Staff IDS
Da: Chiesa Stefano [mailto:stefano.chi...@wki.it]
Inviato: mercoledì 22 ottobre 2014 14.44
A: IDS Submit; bind-us...@isc.org
Oggetto: R: Again question about edns (like swupdl.adobe.com)
Hello all.
Maybe I didnt understand the problem but in my installation of BIND 9.10
WINDOWS I cant replicate the error:
C:\dig swupdl.adobe.com @10.39.128.11
; DiG 9.10-P1 swupdl.adobe.com @10.39.128.11
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 43143
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 8, ADDITIONAL: 9
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;swupdl.adobe.com. IN A
;; ANSWER SECTION:
swupdl.adobe.com. 10761 IN CNAME swupdl.wip4.adobe.com.
swupdl.wip4.adobe.com. 561 IN CNAME
swupdl.adobe.com.edgesuite.net.
swupdl.adobe.com.edgesuite.net. 21561 IN CNAME a1577.d.akamai.net.
a1577.d.akamai.net. 20 IN A 95.101.34.43
a1577.d.akamai.net. 20 IN A 95.101.34.51
-
C:\dig www.acer.it @10.39.128.11
; DiG 9.10-P1 www.acer.it @10.39.128.11
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 49188
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 8, ADDITIONAL: 9
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.acer.it. IN A
;; ANSWER SECTION:
www.acer.it.275 IN CNAME public-akamai.gtm.acer.com.
public-akamai.gtm.acer.com. 6 IN CNAME www.acer.com.edgesuite.net.
www.acer.com.edgesuite.net. 21576 INCNAME a492.b.akamai.net.
a492.b.akamai.net. 20 IN A 2.228.46.113
a492.b.akamai.net. 20 IN A 2.228.46.122
Regards.
Stefano Chiesa
Da: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] Per conto di IDS Submit
Inviato: mercoledì 22 ottobre 2014 12:30
A: bind-us...@isc.org
Oggetto: Again question about edns (like swupdl.adobe.com)
Good morning,
with www.acer.it I have the same problem as swupdl.adobe.com
NXDOMAIN with bind 9.10 but NOERROR with Google DNS
I have read the Mark Andrews reply on july 4 2014:
--
It looks like nameserver vendors are not doing even rudimentry checks like
those above. DiG has thos options so that we could perform checks like
these.
Until Adobe fix their broken servers you can use a server clause to disable
sending SIT requests to them. Obviously this does not scale.
server address { request-sit no; };
Mark
--
But this doesnt solve the problem on others domains
should be possible enable request-sit no for all domains and not
manually add it?
Because I think there are lot of domains with this problem L
--
\Server\Bind\bin\dig.exe @81.174.15.142 www.acer.it
; DiG 9.10.1 @81.174.15.142 www.acer.it
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 42228
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.acer.it. IN A
;; ANSWER SECTION:
www.acer.it.300 IN CNAME public-akamai.gtm.acer.com.
;; AUTHORITY SECTION:
gtm.acer.com. 60 IN SOA gtm1.acer.com.
hostmaster.gtm1.acer.com. 482 10800 3600 604800 60
;; Query time: 572 msec
;; SERVER: 81.174.15.142#53(81.174.15.142)
;; WHEN: Wed Oct 22 12:13:12 ora legale Europa occidentale 2014
;; MSG SIZE rcvd: 132
--
--
\Server\Bind\bin\dig.exe @8.8.8.8 www.acer.it
; DiG 9.10.1 @8.8.8.8 www.acer.it
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 34510
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.acer.it. IN A
;; ANSWER SECTION:
www.acer.it.281 IN CNAME
R: Question about swupdl.adobe.com
Thanks Carl,
with your fix it works:
--
Server\Bind\bin\dig.exe @81.174.15.142 swupdl.adobe.com
; DiG 9.10.1 @81.174.15.142 swupdl.adobe.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 26321
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 8, ADDITIONAL: 9
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;swupdl.adobe.com. IN A
;; ANSWER SECTION:
swupdl.adobe.com. 10800 IN CNAME swupdl.wip4.adobe.com.
swupdl.wip4.adobe.com. 600 IN CNAME
swupdl.adobe.com.edgesuite.net.
swupdl.adobe.com.edgesuite.net. 21600 IN CNAME a1577.d.akamai.net.
a1577.d.akamai.net. 20 IN A 88.149.196.147
a1577.d.akamai.net. 20 IN A 88.149.196.144
;; AUTHORITY SECTION:
d.akamai.net. 4000IN NS n1d.akamai.net.
d.akamai.net. 4000IN NS n7d.akamai.net.
d.akamai.net. 4000IN NS n4d.akamai.net.
d.akamai.net. 4000IN NS n6d.akamai.net.
d.akamai.net. 4000IN NS n0d.akamai.net.
d.akamai.net. 4000IN NS n3d.akamai.net.
d.akamai.net. 4000IN NS n2d.akamai.net.
d.akamai.net. 4000IN NS n5d.akamai.net.
;; ADDITIONAL SECTION:
n0d.akamai.net. 4000IN A 88.221.81.194
n1d.akamai.net. 6000IN A 88.149.196.142
n2d.akamai.net. 8000IN A 88.221.212.76
n3d.akamai.net. 4000IN A 213.254.249.61
n4d.akamai.net. 6000IN A 88.149.196.143
n5d.akamai.net. 8000IN A 88.221.212.77
n6d.akamai.net. 4000IN A 88.149.196.141
n7d.akamai.net. 6000IN A 88.221.212.84
;; Query time: 2370 msec
;; SERVER: 81.174.15.142#53(81.174.15.142)
;; WHEN: Fri Oct 10 10:23:48 ora legale Europa occidentale 2014
;; MSG SIZE rcvd: 448
--
Thank you very much
Best regards
Michele
-Messaggio originale-
Da: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] Per conto di Carl Byington
Inviato: venerdì 10 ottobre 2014 0.54
A: bind-users@lists.isc.org
Oggetto: Re: Question about swupdl.adobe.com
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 2014-10-09 at 13:24 +0200, IDS Submit wrote:
I have BIND 9.10.1 x86 and I have error on query swupdl.adobe.com
See the archives around July 3rd for previous issues with adobe.
You might add this to /etc/named.conf
// adobe servers that don't understand edns options
server 192.150.16.247 { request-sit no; };
server 192.150.19.247 { request-sit no; };
server 193.104.215.247 { request-sit no; };
// eia.gov servers that don't understand edns options
server 205.254.135.9{ request-sit no; };
server 199.36.140.199 { request-sit no; };
The following two queries demonstrate that.
dig ardownload.wip4.adobe.com @da1gtm001.adobe.com +nsid
dig ardownload.wip4.adobe.com @da1gtm001.adobe.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
iEYEARECAAYFAlQ3EfQACgkQL6j7milTFsHTUgCfSSkvXuoJTWwzOighxBBtCmaR
AXkAnjjqaDiPL+1EpPssUb/ZNbGidgWz
=Z/tE
-END PGP SIGNATURE-
___
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
___
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: weird perfmonce BIND version 9.6
Hi Mathus one thing more. I´m little bit lost in bind9. Can you tell me which one those files where is defined the internal o external host? If is in mydomain.com.hosts.lan for internal and mydomain.com.hosts for external I already put them in each configuration file. But I´m still getting the IP Private address answer when i try to pinging for example ping mydomain.com -t I got the 192.168.1.3 answer. you said Check their match-* directives, post them here if possible. -which one is that configuration file? Thanks in advance On 26/09/2013 12:54 PM, Matus UHLAR - fantomas wrote: On 26.09.13 10:52, IT Support wrote: Hi Matus thanks for your answer, can you do me a favor? can you tell me how to looking for that configuration? only clients that are supposed to get internal private addresses should be in internal view. ...You mean, that I should to create a internal and external record in each view? if this is the case I already added those records. ¿Is there another thing that I´m forgetting to do?... check your view definition and which hosts fall into which view. Check their match-* directives, post them here if possible. No, you definitely should NOT mention both IPs in any view. hosts from internal view should get internal IP and hosts from external view should get external IP. ___ 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: weird perfmonce BIND version 9.6
Hi Chuck, sorry for the mistake. so i did the dig host2.mydomain.com and this is the result: host2.mydomain.com @xxx.xxx.xxx.xxx ; DiG 9.6-ESV-R4 host2.mydomain.com @xxx.xxx.xxx.xxx ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 33734 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0 ;; QUESTION SECTION: ;host2.mydomain.com. IN A ;; ANSWER SECTION: host2.mydomain.com. 3377IN A 192.168.1.133 ;; AUTHORITY SECTION: . 8579IN NS h.root-servers.net. . 8579IN NS k.root-servers.net. . 8579IN NS j.root-servers.net. . 8579IN NS m.root-servers.net. . 8579IN NS d.root-servers.net. . 8579IN NS g.root-servers.net. . 8579IN NS b.root-servers.net. . 8579IN NS l.root-servers.net. . 8579IN NS e.root-servers.net. . 8579IN NS i.root-servers.net. . 8579IN NS a.root-servers.net. . 8579IN NS c.root-servers.net. . 8579IN NS f.root-servers.net. ;; Query time: 2 msec ;; SERVER: xxx.xxx.xxx.xxx#53(xxx.xxx.xxx.xxx) ;; WHEN: Wed Sep 25 14:38:02 2013 ;; MSG SIZE rcvd: 266 too many times I´ve got advices about to dns testing using dig command, but I´m still using ping to check what ip address is answering to me. In this case i´m testing host2.mydomain.com and i´m getting the private ip address. I´m wondering how to fix this issue. thanks in advance. On 25/09/2013 2:33 PM, Charles Swiger wrote: dig host2.mydomain.com @external_IP ___ 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
Internernal view is answering to external ping
Hi brothers I have running bind9 on debian, with master zone for mydomain.com i created internal view for resolve names on my lan, and external zone for resolve my host on Internet, this is the working scenario Internal view LAN IP 192.168.0.67 Hostname sales.mydomain.com External view WAN IP 200.57.66.77 Hostname sales.mydomain.com When I make a ping from a other Internet access I get the answer from internal View Pinging sales.mydomain.com [192.168.0.67] with 32 bytes o Ping statistics for 192.168.0.67 Packets: Sent = 3, Received = 3, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 2ms, Average = 1ms Is it possible to change this issue? Thanks in advance. ___ 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: Internernal view is answering to external ping
Dear Carl
Thanks for your answer here the output:
acl allowed-users {
localhost;
200.57.66.77/28;
192.168.0.0/23;
189.0.0.0/8;
172.16.102.1;
172.28.76.0/24;
};
acl internal {
localhost;
200.57.66.77/28;
192.168.0.0/23
};
acl slaves {
200.57.66.78;
};
// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in
/etc/bind/named.conf.local
include /etc/bind/named.conf.options;
// prime the server with knowledge of the root servers
//zone . {
// type hint;
// file /etc/bind/db.root;
//};
// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
//zone localhost {
// type master;
// file /etc/bind/db.local;
//};
//zone 127.in-addr.arpa {
// type master;
// file /etc/bind/db.127;
//};
//zone 0.in-addr.arpa {
// type master;
// file /etc/bind/db.0;
//};
//zone 255.in-addr.arpa {
// type master;
// file /etc/bind/db.255;
//};
//zone 168.192.IN-ADDR.ARPA {
//type master;
//file /etc/bind/db.192;
//};
//zone 10.IN-ADDR.ARPA {
// type master;
// file /etc/empty;
//};
//zone 16.172.IN-ADDR.ARPA {
// type master;
// file /etc/empty;
//};
// zone com { type delegation-only; };
// zone net { type delegation-only; };
// From the release notes:
// Because many of our users are uncomfortable receiving undelegated
answers
// from root or top level domains, other than a few for whom that behaviour
// has been trusted and expected for quite some length of time, we have now
// introduced the root-delegations-only feature which applies
delegation-only
// logic to all top level domains, and to the root domain. An
exception list
// should be specified, including MUSEUM and DE, and any other top
level
// domains from whom undelegated responses are expected and trusted.
// root-delegation-only exclude { DE; MUSEUM; };
include /etc/bind/named.conf.local;
logging {
category lame-servers { null; };
category edns-disabled { null; };
};
key dhcpupdate {
algorithm hmac-md5;
secret ddjsdfruifhrfr88r8rr5544==;
};
Thanks in advance.
On 31/07/2013 5:46 PM, Carl Byington wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 2013-07-31 at 17:39 -0500, IT Support wrote:
I have running bind9 on debian, with master zone for mydomain.com i
created internal view for resolve names on my lan, and external zone
for resolve my host on Internet,
standard answer - post your bind config.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
iEYEARECAAYFAlH5k9MACgkQL6j7milTFsEtzgCeKCNBwf7sAtPQDXC+qU+vq6Go
8esAn2aWS7UaRcqWx8CDgG95+jZA1jXC
=knAS
-END PGP SIGNATURE-
___
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
___
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: Internernal view is answering to external ping
Thanks Mark for the advice, that output is my whole named.conf, please
let me know if I need to post another output file
This is what do i have on my bind folder:
named.conf
named.conf.dpkg-dist
named.conf.local
named.conf.local.bfRFC1918
named.conf.local.orig
named.conf.options
named.conf.options.dpkg-di
mydomain.com.hosts
mydomain.com.hosts.lan
db.0
db.127
db.192
192.168.0
db.192.168.0.internal
db.192.168.0.internal.jnl
db.192.168.external
db.192.168.internal
db.192.168.internal.jnl
db.192.internal
db.192.jnl
db.255
db.empty
db.local
db.root
root b
On 31/07/2013 7:09 PM, Mark Andrews wrote:
Post your *full* config not half of it. How the hell do you expect
people to identify problems unless you give them the neccessary
details.
Do you give you car mechanic only access to the boot when you have
a engine problem?
You said you created views yet you didn't send anything that described
how the views were configured.
Mark
In message 51f9a4dc.6040...@gmail.com, IT Support writes:
Dear Carl
Thanks for your answer here the output:
acl allowed-users {
localhost;
200.57.66.77/28;
192.168.0.0/23;
189.0.0.0/8;
172.16.102.1;
172.28.76.0/24;
};
acl internal {
localhost;
200.57.66.77/28;
192.168.0.0/23
};
acl slaves {
200.57.66.78;
};
// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in
/etc/bind/named.conf.local
include /etc/bind/named.conf.options;
// prime the server with knowledge of the root servers
//zone . {
// type hint;
// file /etc/bind/db.root;
//};
// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
//zone localhost {
// type master;
// file /etc/bind/db.local;
//};
//zone 127.in-addr.arpa {
// type master;
// file /etc/bind/db.127;
//};
//zone 0.in-addr.arpa {
// type master;
// file /etc/bind/db.0;
//};
//zone 255.in-addr.arpa {
// type master;
// file /etc/bind/db.255;
//};
//zone 168.192.IN-ADDR.ARPA {
//type master;
//file /etc/bind/db.192;
//};
//zone 10.IN-ADDR.ARPA {
// type master;
// file /etc/empty;
//};
//zone 16.172.IN-ADDR.ARPA {
// type master;
// file /etc/empty;
//};
// zone com { type delegation-only; };
// zone net { type delegation-only; };
// From the release notes:
// Because many of our users are uncomfortable receiving undelegated
answers
// from root or top level domains, other than a few for whom that behaviour
// has been trusted and expected for quite some length of time, we have now
// introduced the root-delegations-only feature which applies
delegation-only
// logic to all top level domains, and to the root domain. An
exception list
// should be specified, including MUSEUM and DE, and any other top
level
// domains from whom undelegated responses are expected and trusted.
// root-delegation-only exclude { DE; MUSEUM; };
include /etc/bind/named.conf.local;
logging {
category lame-servers { null; };
category edns-disabled { null; };
};
key dhcpupdate {
algorithm hmac-md5;
secret ddjsdfruifhrfr88r8rr5544==;
};
Thanks in advance.
On 31/07/2013 5:46 PM, Carl Byington wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 2013-07-31 at 17:39 -0500, IT Support wrote:
I have running bind9 on debian, with master zone for mydomain.com i
created internal view for resolve names on my lan, and external zone
for resolve my host on Internet,
standard answer - post your bind config.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
iEYEARECAAYFAlH5k9MACgkQL6j7milTFsEtzgCeKCNBwf7sAtPQDXC+qU+vq6Go
8esAn2aWS7UaRcqWx8CDgG95+jZA1jXC
=knAS
-END PGP SIGNATURE-
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscri
be from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--050203070403020006060804
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
html
head
meta content=text/html; charset=ISO-8859-1
http-equiv=Content-Type
/head
body bgcolor=#FF text=#00
div class=moz-cite-prefixDear Carlbr
br
Thanks for your answer here the output:br
br
acl allowed-users {br
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; localhost;br
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; font face=Bodoni MTfont
face=Bodoni MT200.57.66.77/font/font/28;br
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; 192.168.0.0/23;br
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; 189.0.0.0/8;br
Re: Internernal view is answering to external ping
Hi Steven Can you tell me what files do I have to post here? On 31/07/2013 7:04 PM, Steven Carr wrote: On 1 August 2013 00:59, IT Support it.compilat...@gmail.com wrote: Thanks in advance. Where is your view/zone configuration? (possibly in one of the included files) you will need to post that configuration as well. ___ 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 ___ 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
DNS and Remote Host over VPN
Hi brothers I have a question about dns Address record, I´m running Bind9 over d ebian, and I wonder if is posible to add address record for a remote host? this remote host i reach it by a site to site vpn, this is my scenario -dns server 192.168.10.100 -remote host 172.28.15.34 I already add a address record on my internal view for that remote host, if I ping this host by IP address i got answer, but if i ping the same host by name i got this message: ping: unknown host Thanks in advance. Cheers. Jah Love. ___ 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
ISC Security Advisory: CVE-2013-2266: A Maliciously Crafted Regular Expression Can Cause Memory Exhaustion in named
Note: This email advisory is provided for your information. The most up to date advisory information will always be at: https://kb.isc.org/article/AA-00871 please use this URL for the most up to date advisory information. --- A critical defect in BIND 9 allows an attacker to cause excessive memory consumption in named or other programs linked to libdns. CVE: CVE-2013-2266 Document Version: 2.0 Posting date: 26 March 2013 Program Impacted: BIND Versions affected:Unix versions of BIND 9.7.x, 9.8.0 - 9.8.5b1, 9.9.0 - 9.9.3b1. (Windows versions are not affected. Versions of BIND 9 prior to BIND 9.7.0 (including BIND 9.6-ESV) are not affected. BIND 10 is not affected.) Severity: Critical Exploitable: Remotely Description: A flaw in a library used by BIND 9.7, 9.8, and 9.9, when compiled on Unix and related operating systems, allows an attacker to deliberately cause excessive memory consumption by the named process, potentially resulting in exhaustion of memory resources on the affected server. This condition can crash BIND 9 and will likely severely affect operation of other programs running on the same machine. Please Note: Versions of BIND 9.7 are beyond their end of life (EOL) and no longer receive testing or security fixes from ISC. However, the re-compilation method described in the Workarounds section of this document will prevent exploitation in BIND 9.7 as well as in currently supported versions. For current information on which versions are actively supported, please seehttp://www.isc.org/software/bind/versions. Additional information is available in the CVE-2013-2266 FAQ and Supplemental Information article in the ISC Knowledge base, https://kb.isc.org/article/AA-00879. Impact: Intentional exploitation of this condition can cause denial of service in all authoritative and recursive nameservers running affected versions of BIND 9 [all versions of BIND 9.7, BIND 9.8.0 through 9.8.5b1 (inclusive) and BIND 9.9.0 through BIND 9.9.3b1 (inclusive)]. Additionally, other services which run on the same physical machine as an affected BIND server could be compromised as well through exhaustion of system memory. Programs using the libdns library from affected versions of BIND are also potentially vulnerable to exploitation of this bug if they can be forced to accept input which triggers the condition. Tools which are linked against libdns (e.g. dig) should also be rebuilt or upgraded, even if named is not being used. CVSS Score: 7.8 CVSS Equation: (AV:N/AC:L/Au:N/C:N/I:N/A:C) For more information on the Common Vulnerability Scoring System and to obtain your specific environmental score please visit: http://nvd.nist.gov/cvss.cfm?calculatoradvversion=2vector=(AV:N/AC:L/Au:N/C:N/I:N/A:C) Workarounds: Patched versions are available (see the Solutions: section below) or operators can prevent exploitation of this bug in any affected version of BIND 9 by compiling without regular expression support. Compilation without regular expression support: BIND 9.7 (all versions), BIND 9.8 (9.8.0 through 9.8.5b1), and BIND 9.9 (9.9.0 through 9.9.3b1) can be rendered completely safe from this bug by re-compiling the source with regular expression support disabled. In order to disable inclusion of regular expression support: - After configuring BIND features as desired using the configure script in the top level source directory, manually edit the config.h header file that was produced by the configure script. - Locate the line that reads #define HAVE_REGEX_H 1 and replace the contents of that line with #undef HAVE_REGEX_H. - Run make clean to remove any previously compiled object files from the BIND 9 source directory, then proceed to make and install BIND normally. Active exploits: No known active exploits. Solution: Compile BIND 9 without regular expression support as described in the Workarounds section of this advisory or upgrade to the patched release most closely related to your current version of BIND. These can be downloaded fromhttp://www.isc.org/downloads/all. BIND 9 version 9.8.4-P2 BIND 9 version 9.9.2-P2 Acknowledgements: ISC would like to thank Matthew Horsfall of Dyn, Inc. for discovering this bug and bringing it to our attention. Document Revision History: 1.0 Phase One - Advance Notification, 11 March 2013 1.1 Phase Two Three, 25 March 2013 2.0 Notification to Public (Phase Four), 26 March 2013 Related Documents: Japanese Translation:https://kb.isc.org
Re: ISC Security Advisory: CVE-2013-2266: A Maliciously Crafted Regular Expression Can Cause Memory Exhaustion in named
On 3/26/13 10:05 AM, Jack Tavares wrote: I have a request for clarification: The workaround states to rebuild BIND with regexp support disabled. And I see new versions of BIND have been released. Are those versions just a rebuild with regexp support disabled? Or are they a more comprehensive fix? This question is addressed in the CVE-2013-2266: FAQ and Supplemental Information Knowledge Base article, which I encourage everyone to read. https://kb.isc.org/article/AA-00879 Please see specifically the section which begins: What is the difference between deploying the patched versions of BIND versus implementing the documented workaround? Thanks, Michael McNally ISC Support ___ 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
CNAME used in Global Server Loadbalancing - is it RFC compliant ?
Hello, we are using Global Server Loadbalancing (GSLB) for site redundancy. GSLB is based on DNS technology and works as follows --- standard implementation case --- www.example.com.NS loadbalancer-1.example.com. # -- ( LB located at site-a) www.example.com.NS loadbalancer-2.example.com. # -- ( LB located at site-b) # the loadbalancer (LB) resolves the DNS query for www.example.com, based # on load balancing criteria with a site specific public IP address loadbalancer-1.example.com. A 1.y.z.w loadbalancer-2.example.com. A 2.y.z.w --- ?? 'CNAME approach' in question --- (-) Above setup works fine and for each service and we need 2 public IP addresses one at each site hosted on the loadbalancer device. (--) now considering that we host the same application with different names on the same server we need for each one another 2 public IP addresses - this leads to an unnecessary waste of addresses (x * 2) == NEW APPROACH Instead of using two new IP public addresses for the new service name I defined following: new-www.example.com CNAME www.example.com. == it works fine so far an the resolve process is as it should be, but Is it legitimate (RFC compliant) to use CNAME in this setup or is is just luck that it works and more compliant resolvers won't work properly ?? Thanks a lot Marcel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
