find the professional DNS hosting service
Hi list, We are a company running for gaming. Our website's rank is about 500 in Alexa. We didn't have our own nameservers, have been using the domain registry provider's nameservers for free. Due to some problems, we want to change the DNS hosting. The provider should have included the features: * Professional DNS hosting service with 24*7 tech supports. * Great stability and fast speed. * Anti-DDoS and other DNS attacks. * Having webadmin system which is ease to use for DNS records management. * Audit mechanisms for different management accounts. * It's better if there is DNS query statistics. We have been greatest expecting the solid and professional DNS hosting service, the price is no problem. If there is any commercial hosting provider here you could please contact with me. Thanks. Kind regrads, Jorg W. Young ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: "broken trust chain" for non-existing AAAA records
Zitat von Mark Andrews : In message <20101118131400.37717e5p5tard...@webmail.kwsoft.de>, lst_ho...@kwsof t.de writes: We are using Bind 9.7 at the border to resolve DNS queries for a small LAN. After moving forward in using IPv6 we discovered many "broken trust chain" errors in the bind log for non existing records. One example is Nov 18 01:18:21 firewall named[27580]: error (broken trust chain) resolving 'smtp.g.comcast.net//IN': 76.96.53.47#53 Nov 18 01:18:21 firewall named[27580]: error (broken trust chain) resolving 'smtp.g.comcast.net//IN': 68.87.66.201#53 Nov 18 01:18:29 firewall named[27580]: error (broken trust chain) resolving 'smtp.g.comcast.net//IN': 76.96.53.47#53 Nov 18 01:18:29 firewall named[27580]: error (broken trust chain) resolving 'smtp.g.comcast.net//IN': 76.96.53.47#53 From what i can see there is no DNSSEC for comcast.net so this should not happen and the A record just resolve fine. Any comment if this should worry me? A broken chain of trust can be *anywhere* in the trust chain. Remember named has to prove that a answer should be insecure (not signed) by looking for the absence of a DS RRset at a delegation point above the name in question. Sorry to come up with this again... As far as i understand if i get a secure answer from the root-NS that there is no DS for the domain in inquestion (de. net. etc) there should be no "broken trust chain" further on because there is (validated) none? If validation is working correctly you should be able to get a validated negative response for DS net. Note the "ad" in the flags below which indicates that named thinks the answer is secure. This is working, no problem but i still get "broken trust chain" for some non existing records like for example this one: ; <<>> DiG 9.7.0-P1 <<>> +dnssec mail.cdu-freiburg.de ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54325 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;mail.cdu-freiburg.de. IN Nov 29 14:37:01 firewall named[976]: error (broken trust chain) resolving 'mail.cdu-freiburg.de//IN': 62.116.129.129#53 ; <<>> DiG 9.7.0-P1 <<>> +dnssec de. DS ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9033 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;de.IN DS ;; AUTHORITY SECTION: . 3 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2010112801 1800 900 604800 86400 . 3 IN RRSIG SOA 8 0 86400 2010120500 2010112723 40288 . HxKeNrwFeDxJDKKbBcQJQQ8aXf1sEs93J1rcm647RI3Qw3bpm9Dbs+xj aYki5iRhk0HHjDHm1Kj2gGXFdKlzMAExszF7js1IaCs+EgePqwSqDoHT lSduCn/hqlrklOqrwQkjYJhJkEYLJuhKVHTkilbC/w94RxVK3Uh5qEdJ K44= de. 3 IN RRSIG NSEC 8 1 86400 2010120500 2010112723 40288 . DfHYLjIgdB3M+ib9Gn6anvtE27UTdZWX9nqvzf7ts4+X2TCVwlPmGtn7 4EXwrDTfYNe5YEWh67MO/7mcUeZ2LcqqyQifIu0hJZf5RBmys0ml39JZ VNcSaWr7N5J3OV2GCJl366w24Eeuuje+xAJAyIfzE68LkMlnypjbrAAT mtA= de. 3 IN NSECdj. NS RRSIG NSEC So it is validated that the TLD de. has no DS (-> NSEC) but Bind 9.7 report a broken trust chain for the IPv6 record of "mail.cdu-freiburg.de". I have not even find something looking like DNSKEY further down the road so why the error is reported? Many Thanks Andreas smime.p7s Description: S/MIME Cryptographic Signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about the zone file management
Or nsupdate Lyle Giese LCR Computer Services, Inc. philippe.simo...@swisscom.com wrote: > Hi > > if i good understand your question maybe the answer is : > rndc freeze / thaw > > Philippe > > > >> -Original Message- >> From: bind-users-bounces+philippe.simonet=swisscom@lists.isc.org >> [mailto:bind-users-bounces+philippe.simonet=swisscom@lists.isc.org] >> On Behalf Of Tech W. >> Sent: lundi 29 novembre 2010 06:38 >> To: bind-users@lists.isc.org >> Subject: about the zone file management >> >> Hello, >> >> I'm not sure, is it right for the management of zone files, with both dynamic >> update and editting by hand? >> >> Thanks. >> >> >> >> ___ >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users >> > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: "broken trust chain" for non-existing AAAA records
Is this still with BIND 9.7.0-P1 or something more recent? If it is still BIND 9.7.0-P1 then please upgrade. There really is no point debugging validation failures in BIND 9.7.0-P1 anymore as the validator has had really extensive changes since then. Please remember, that unlike most of the rest of named, the validator is still very much "new" code that hasn't had millions of users exercising it in the real world like the rest of the code base has. As a result it is still changing as we run into real world patterns that have not been seen in the lab or by those of us that have been running it in production for several years. If you are validating you really need to follow the releases we make. For the record I can validate the answer in question with current code. Mark ; <<>> DiG 9.6.0-APPLE-P2 <<>> mail.cdu-freiburg.de @127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56812 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;mail.cdu-freiburg.de. IN ;; Query time: 345 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Nov 30 08:55:51 2010 ;; MSG SIZE rcvd: 38 ; <<>> DiG 9.6.0-APPLE-P2 <<>> +dnssec de ds @127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45413 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;de.IN DS ;; AUTHORITY SECTION: . 7641IN SOA a.root-servers.net. nstld.verisign-grs.com. 2010112900 1800 900 604800 86400 . 7641IN RRSIG SOA 8 0 86400 2010120600 2010112823 40288 . VXdtlcNzXMvVy0QGYYNv8euCsGn9Cb+aM+jhdMM2aABpShc7d8J8vBWS XrnFwmr1AoqV8LhcWYwSP3+Xu2XOs7HW3OY9IXYVoYDW2JLgCef9fYe/ MkwNxTQFuw2EwZFZTkkrxPLhPucuwiCRlBO/w1dl8Qak6F72lFG39UFt h9Q= de. 7641IN RRSIG NSEC 8 1 86400 2010120600 2010112823 40288 . JB4Fz8EGFxg5sY/KY5EK0ebcmLr03LnQSVtddkHxljSydz1RA/OoriNe xwp6GmYz6DpjuoDcBMW/9PDwYTl17SqPFwFQBw/6yRf+oXtHx5u7Q7zx 4Kf/7zDxw8h2L/FeAa1WqLLbmhEBF2RcaV6Rv2OCj1VXIVffBgW/GDDw CD8= de. 7641IN NSECdj. NS RRSIG NSEC ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Nov 30 08:56:20 2010 ;; MSG SIZE rcvd: 447 In message <20101129144338.8595771dm36el...@webmail.kwsoft.de>, lst_ho...@kwsof t.de writes: > Zitat von Mark Andrews : > > > > > In message <20101118131400.37717e5p5tard...@webmail.kwsoft.de>, > > lst_ho...@kwsof > > t.de writes: > >> We are using Bind 9.7 at the border to resolve DNS queries for a small > >> LAN. After moving forward in using IPv6 we discovered many "broken > >> trust chain" errors in the bind log for non existing records. One > >> example is > >> > >> Nov 18 01:18:21 firewall named[27580]: error (broken trust chain) > >> resolving 'smtp.g.comcast.net//IN': 76.96.53.47#53 > >> Nov 18 01:18:21 firewall named[27580]: error (broken trust chain) > >> resolving 'smtp.g.comcast.net//IN': 68.87.66.201#53 > >> Nov 18 01:18:29 firewall named[27580]: error (broken trust chain) > >> resolving 'smtp.g.comcast.net//IN': 76.96.53.47#53 > >> Nov 18 01:18:29 firewall named[27580]: error (broken trust chain) > >> resolving 'smtp.g.comcast.net//IN': 76.96.53.47#53 > >> > >> From what i can see there is no DNSSEC for comcast.net so this should > >> not happen and the A record just resolve fine. Any comment if this > >> should worry me? > > > > A broken chain of trust can be *anywhere* in the trust chain. > > > > Remember named has to prove that a answer should be insecure (not > > signed) by looking for the absence of a DS RRset at a delegation > > point above the name in question. > > > Sorry to come up with this again... > As far as i understand if i get a secure answer from the root-NS that > there is no DS for the domain in inquestion (de. net. etc) there > should be no "broken trust chain" further on because there is > (validated) none? > > > > If validation is working correctly you should be able to get a > > validated negative response for DS net. Note the "ad" in the flags > > below which indicates that named thinks the answer is secure. > > > This is working, no problem but i still get "broken trust chain" for > some non existing records like for example this one: > > ; <<>> DiG 9.7.0-P1 <<>> +dnssec mail.cdu-freiburg.de > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54325 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ;; QUESTION SECTION: > ;mail.cdu-freiburg.de.IN > > > Nov 29 14:37:01 firewall named[976]: error (broken trust chain) > resolving 'mail
Re: zone management plus automatic "nsupdate"
On Nov 28, 2010, at 3:25 AM, Christian Ruppert wrote: > Hey guys, > > we have many zones and a few admins who are able to edit those. Now > we're looking for a good and free solution to a) track who changed what > and b) to update the zone afterwards. > > So we thought using git with a update hook could be a good one. > With git we can see who changed what and when and the hook could use > "git diff" with a simple diff parser to get the lines that shall be > updated by nsupdate. > > e.g. > -ns IN A > +ns IN A > > The first line would be used for "update delete" and the second one for > "update add". > > Of course it takes some time realize this properly so my question is: Is > there already something equivalent? > Or do you guys have a better idea? How do you manage your zones? Before rolling your own DNS management platform, take a look at the existing solutions. In addition to the commercial offerings, there is Carnegie Mellon's NetReg, which is apparently both credible and open source. http://www.net.cmu.edu/netreg/ Disclaimers: I've never used NetReg, and I work for a company that produces a commercial solution for DNS, DHCP, and IP address management (DDI). Chris Buxton BlueCat Networks ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: "broken trust chain" for non-existing AAAA records
Zitat von Mark Andrews : Is this still with BIND 9.7.0-P1 or something more recent? If it is still BIND 9.7.0-P1 then please upgrade. There really is no point debugging validation failures in BIND 9.7.0-P1 anymore as the validator has had really extensive changes since then. Please remember, that unlike most of the rest of named, the validator is still very much "new" code that hasn't had millions of users exercising it in the real world like the rest of the code base has. As a result it is still changing as we run into real world patterns that have not been seen in the lab or by those of us that have been running it in production for several years. If you are validating you really need to follow the releases we make. I was afraid of that. If using a pre-packed system you get only (backported) security fixes most of the time and managing a self compiled packaging is the thing one tries to avoid in using a pre-packed system :-( I have not suspected that the code changed that much with minor version numbers, but of course this may not apply to DNSSEC. I will try if i can get a "clean" update from source. Thanks for the help Andreas smime.p7s Description: S/MIME Cryptographic Signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
