Re: BIND 9.9.0 Inline-Signing Out of Control
We thought of two other differences between this zone and the others: 1. this zone has NS records with servers that are in the zone itself, and 2. our global "also-notify" option contain IP addresses that resolve to host names in this zone. Could the problem be the result of the servers notifying each other? On 2 Mar 2012, at 5:13 PM, David Kreindler wrote: > When BIND 9.9.0 was released, we started converting our DNSSEC-signed zones > to inline signing. > > Everything went smoothly with all but one of our zones ("pesky.zone", below). > With that zone, after named signed it and completed an AXFR-style IXFR to > each of four slaves, it proceeded to start repeatedly incrementing the SOA > serial and retransferring. By the time we stopped it, named had incremented > the serial almost 200 times, with corresponding IXFRs. > > There is nothing different about this zone from any of our others, except > that it contains somewhat more RRs. (There are no dynamic updates permitted, > no DS records for delegated subdomains, nothing else that we could think of > to explain the behavior.) > > Why would named go crazy when we configure inline signing for this one zone, > when all of our other zones are working fine with inline signing? > > Mar 2 14:33:14 ns0 named[806928]: received control channel command > 'reconfig' > Mar 2 14:33:14 ns0 named[806928]: loading configuration from > '/etc/named.conf' > Mar 2 14:33:14 ns0 named[806928]: reading built-in trusted keys from > file '/etc/bind.keys' > Mar 2 14:33:14 ns0 named[806928]: using default UDP/IPv4 port range: > [1024, 65535] > Mar 2 14:33:14 ns0 named[806928]: using default UDP/IPv6 port range: > [1024, 65535] > Mar 2 14:33:14 ns0 named[806928]: prefix length for ::1 is unknown > (assume 128) > Mar 2 14:33:14 ns0 named[806928]: sizing zone task pool based on 207 > zones > Mar 2 14:33:15 ns0 named[806928]: zone pesky.zone/IN: (master) removed > Mar 2 14:33:15 ns0 named[806928]: prefix length for ::1 is unknown > (assume 128) > Mar 2 14:33:15 ns0 named[806928]: reloading configuration succeeded > Mar 2 14:33:15 ns0 named[806928]: zone pesky.zone/IN (unsigned): > loaded serial 2012030200 > Mar 2 14:33:15 ns0 named[806928]: any newly configured zones are now > loaded > ... > Mar 2 14:33:15 ns0 named[806928]: zone pesky.zone/IN (signed): loaded > serial 2012030200 > Mar 2 14:33:15 ns0 daemon:err|error named[806928]: zone pesky.zone/IN > (signed): receive_secure_serial: unchanged > Mar 2 14:33:15 ns0 named[806928]: zone pesky.zone/IN (signed): > reconfiguring zone keys > Mar 2 14:33:16 ns0 named[806928]: zone pesky.zone/IN (signed): next > key event: 02-Mar-2012 15:33:15.740 > Mar 2 14:33:16 ns0 named[806928]: client [ns3]#42941/key ns0-ns3 > (pesky.zone): transfer of 'pesky.zone/IN': AXFR-style IXFR started: TSIG > ns0-ns3 > Mar 2 14:33:17 ns0 named[806928]: client [ns4]#48695/key ns0-ns4 > (pesky.zone): transfer of 'pesky.zone/IN': AXFR-style IXFR started: TSIG > ns0-ns4 > Mar 2 14:33:17 ns0 named[806928]: client [ns2]#52228/key ns0-ns2 > (pesky.zone): transfer of 'pesky.zone/IN': AXFR-style IXFR started: TSIG > ns0-ns2 > Mar 2 14:33:17 ns0 named[806928]: client [ns3]#42941/key ns0-ns3 > (pesky.zone): transfer of 'pesky.zone/IN': AXFR-style IXFR ended > Mar 2 14:33:17 ns0 named[806928]: client [ns1]#51606/key ns0-ns1 > (pesky.zone): transfer of 'pesky.zone/IN': AXFR-style IXFR started: TSIG > ns0-ns1 > Mar 2 14:33:18 ns0 named[806928]: client [ns4]#48695/key ns0-ns4 > (pesky.zone): transfer of 'pesky.zone/IN': AXFR-style IXFR ended > Mar 2 14:33:18 ns0 named[806928]: client [ns2]#52228/key ns0-ns2 > (pesky.zone): transfer of 'pesky.zone/IN': AXFR-style IXFR ended > Mar 2 14:33:18 ns0 named[806928]: client [ns1]#51606/key ns0-ns1 > (pesky.zone): transfer of 'pesky.zone/IN': AXFR-style IXFR ended > Mar 2 14:33:21 ns0 named[806928]: client [ns3]#42944/key ns0-ns3 > (pesky.zone): transfer of 'pesky.zone/IN': IXFR started: TSIG ns0-ns3 > Mar 2 14:33:21 ns0 named[806928]: client [ns3]#42944/key ns0-ns3 > (pesky.zone): transfer of 'pesky.zone/IN': IXFR ended > Mar 2 14:33:21 ns0 named[806928]: client [ns2]#52229/key ns0-ns2 > (pesky.zone): transfer of 'pesky.zone/IN': IXFR started: TSIG ns0-ns2 > Mar 2 14:33:21 ns0 named[806928]: client [ns4]#48700/key ns0-ns4 > (pesky.zone): transfer of 'pesky.zone/IN': IXFR started: TSIG ns0-ns4 > Mar 2 14:33:21 ns0 named[806928]: client [ns1]#51607/key ns0-ns1 > (pesky.zone): transfer of 'pesky.zone/IN': IXFR started: TSIG ns0-ns1 > Mar 2 14:33:22 ns0 named[806928]: client [ns2]#52229/key ns0-ns2 > (pesky.zone): transfer of 'pesky.zone/IN': IXFR ended > Mar 2 14:33:22 ns0 named[806928]: client [ns4]#48700/key ns0-ns4 > (pesky.zone): transfer of 'pesky.zone/IN': IXFR ended >
RE: BIND 9.9.0 Inline-Signing Out of Control
> We thought of two other differences between this zone and the others: > 1. this zone has NS records with servers that are in the zone itself, and 2. > our global "also-notify" option contain IP addresses that resolve to host > names in this zone. I don't have a handle on the underlying problem, but you can tamp down the notification process. For your master zones: acl peskySlaves { ; ; ... }; zone "pesky.zone" { type master; ... notify explicit; also-notify { peskySlaves; }; allow-transfer { peskySlaves; }; ... }; And for your slave zones: options { notify no; (or notify master-only;) ... }; See ftp://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.pdf, pages 15 and 62. Jeffry A. Spain Network Administrator Cincinnati Country Day School ___ 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: BIND 9.9.0 Inline-Signing Out of Control
On 05.03.12 07:46, David Kreindler wrote: We thought of two other differences between this zone and the others: 1. this zone has NS records with servers that are in the zone itself, and 2. our global "also-notify" option contain IP addresses that resolve to host names in this zone. Could the problem be the result of the servers notifying each other? This should not cause a problem, unless they would change the SOA each time. As far as I understand your loks and Mark's reply, it's the same version of a zone, but the server is incrementally signing the zone, and after signong a bunch of names, it gets IXFRed to slaves. On 2 Mar 2012, at 5:13 PM, David Kreindler wrote: Mar 2 14:33:15 ns0 named[806928]: zone pesky.zone/IN (signed): loaded serial 2012030200 Mar 2 14:33:15 ns0 daemon:err|error named[806928]: zone pesky.zone/IN (signed): receive_secure_serial: unchanged Mar 2 14:33:15 ns0 named[806928]: zone pesky.zone/IN (signed): reconfiguring zone keys Mar 2 14:33:16 ns0 named[806928]: zone pesky.zone/IN (signed): next key event: 02-Mar-2012 15:33:15.740 Mar 2 14:33:16 ns0 named[806928]: client [ns3]#42941/key ns0-ns3 (pesky.zone): transfer of 'pesky.zone/IN': AXFR-style IXFR started: TSIG ns0-ns3 Mar 2 14:33:17 ns0 named[806928]: client [ns4]#48695/key ns0-ns4 (pesky.zone): transfer of 'pesky.zone/IN': AXFR-style IXFR started: TSIG ns0-ns4 Mar 2 14:33:17 ns0 named[806928]: client [ns2]#52228/key ns0-ns2 (pesky.zone): transfer of 'pesky.zone/IN': AXFR-style IXFR started: TSIG ns0-ns2 Mar 2 14:33:17 ns0 named[806928]: client [ns3]#42941/key ns0-ns3 (pesky.zone): transfer of 'pesky.zone/IN': AXFR-style IXFR ended Mar 2 14:33:17 ns0 named[806928]: client [ns1]#51606/key ns0-ns1 (pesky.zone): transfer of 'pesky.zone/IN': AXFR-style IXFR started: TSIG ns0-ns1 Mar 2 14:33:18 ns0 named[806928]: client [ns4]#48695/key ns0-ns4 (pesky.zone): transfer of 'pesky.zone/IN': AXFR-style IXFR ended Mar 2 14:33:18 ns0 named[806928]: client [ns2]#52228/key ns0-ns2 (pesky.zone): transfer of 'pesky.zone/IN': AXFR-style IXFR ended Mar 2 14:33:18 ns0 named[806928]: client [ns1]#51606/key ns0-ns1 (pesky.zone): transfer of 'pesky.zone/IN': AXFR-style IXFR ended Mar 2 14:33:21 ns0 named[806928]: client [ns3]#42944/key ns0-ns3 (pesky.zone): transfer of 'pesky.zone/IN': IXFR started: TSIG ns0-ns3 Mar 2 14:33:21 ns0 named[806928]: client [ns3]#42944/key ns0-ns3 (pesky.zone): transfer of 'pesky.zone/IN': IXFR ended Mar 2 14:33:21 ns0 named[806928]: client [ns2]#52229/key ns0-ns2 (pesky.zone): transfer of 'pesky.zone/IN': IXFR started: TSIG ns0-ns2 Mar 2 14:33:21 ns0 named[806928]: client [ns4]#48700/key ns0-ns4 (pesky.zone): transfer of 'pesky.zone/IN': IXFR started: TSIG ns0-ns4 Mar 2 14:33:21 ns0 named[806928]: client [ns1]#51607/key ns0-ns1 (pesky.zone): transfer of 'pesky.zone/IN': IXFR started: TSIG ns0-ns1 Mar 2 14:33:22 ns0 named[806928]: client [ns2]#52229/key ns0-ns2 (pesky.zone): transfer of 'pesky.zone/IN': IXFR ended Mar 2 14:33:22 ns0 named[806928]: client [ns4]#48700/key ns0-ns4 (pesky.zone): transfer of 'pesky.zone/IN': IXFR ended Mar 2 14:33:22 ns0 named[806928]: client [ns1]#51607/key ns0-ns1 (pesky.zone): transfer of 'pesky.zone/IN': IXFR ended -- 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. M$ Win's are shit, do not use it ! ___ 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: how to reduce unnecessary lots of AAAA queries?
On 03/04/2012 01:20 PM, Chuck Anderson wrote: > You can't, clients can decide to query whatever they want, and they > may have other IPv6 connectivity to use responses with. can > be queried over IPv4 just fine, just as A can be queried over IPv6. Most clients, however, are smart enough not to do queries if they don't have an IPv6 address. Firefox on Linux is a glaring exception to this; you need to set network.dns.disableIPv6 in about:config to stop it from doing pointless queries. -- Ian Pilcher arequip...@gmail.com "If you're going to shift my paradigm ... at least buy me dinner first." ___ 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: BIND 9.9.0 Inline-Signing Out of Control
Thanks for the suggestion. After 48 sets of IXFRs and more than 1200 SOA serial increments, the system finished signing the zone. Manually incrementing the (unsigned) SOA serial now results in just one more set of IXFRs. It would have been helpful if somewhere in the documentation we were warned to expect a large number if IXFRs following the initial AXFR-style IXFR. Are there guidelines or suggestions for setting the values of sig-signing-nodes and sig-signing-signatures? On 2 Mar 2012, at 6:23 PM, Mark Andrews wrote: > > Just let it complete signing the zone. This is done incrementally. > >sig-signing-nodes ; >sig-signing-signatures ; > > These control the number nodes processed and signatures generated per > increment. > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: BIND 9.9.0 Inline-Signing Out of Control
On 05/03/12 17:46, David Kreindler wrote: Are there guidelines or suggestions for setting the values of sig-signing-nodes and sig-signing-signatures? For what it's worth, we do "auto-dnssec maintain" with dynamic zones, and have left them at their default. It's a big zone, and the constant trickle of signing doesn't seem to be so bad. Is there some reason the defaults don't suit you? ___ 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
reverse dns for IPV6 ranges
Dear all, Can anyone help me with its experience on reverse dns for IPV6? Presently, when we reverse an IPV4 subnet for clients, we configure all the reverse for the whole subnet. It is a lot of PTR's but perfectly manageable. With IPV6, the number of IP's that we will receive is amazing So...it seems impossible for every single IPV6 inthe range to configure a PTR. So...what to do? What is the common practice? What is possible with BIND? Thanks in advance for your answer. ___ 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: reverse dns for IPV6 ranges
> Can anyone help me with its experience on reverse dns for IPV6? > Presently, when we reverse an IPV4 subnet for clients, we configure all the > reverse for the whole subnet. > It is a lot of PTR's but perfectly manageable. > With IPV6, the number of IP's that we will receive is amazing > So...it seems impossible for every single IPV6 inthe range to configure a PTR. > So...what to do? > What is the common practice? > What is possible with BIND? For our IPv6 address space 2001:4870:20ca::/48, I created a reverse lookup zone a.c.0.2.0.7.8.4.1.0.0.2.ip6.arpa and arranged for delegation from our ISP. I included PTR records only for those hosts accessible from the outside. Internal DNS is Windows Active Directory integrated. Here's a sample from the zone file, which contains about 25 PTR records in all: $ORIGIN . $TTL 3600 ; 1 hour a.c.0.2.0.7.8.4.1.0.0.2.ip6.arpa IN SOA ns1.countryday.net. hostmaster.countryday.net. ( 2012030101 ; serial 86400 ; refresh (1 day) 3600 ; retry (1 hour) 1209600; expire (2 weeks) 3600 ; minimum (1 hour) ) NS ns1.countryday.net. NS ns2.countryday.net. $ORIGIN 9.0.0.0.a.c.0.2.0.7.8.4.1.0.0.2.ip6.arpa. a.5.6.9.f.9.e.4.3.4.3.e.f.a.0.8 PTR ns2.countryday.net. $ORIGIN 8.5.1.0.a.c.0.2.0.7.8.4.1.0.0.2.ip6.arpa. 2.9.1.f.1.d.2.1.b.f.7.5.7.f.8.0 PTR ns1.countryday.net. I would also be interested in hearing about the practices of others. Jeff. Jeffry A. Spain Network Administrator Cincinnati Country Day School ___ 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: reverse dns for IPV6 ranges
In message , hugo hugoo writes: > > Dear all, > > Can anyone help me with its experience on reverse dns for IPV6? > Presently, when we reverse an IPV4 subnet for clients, we configure all= > the reverse for the whole subnet. > It is a lot of PTR's but perfectly manageable. > > With IPV6, the number of IP's that we will receive is amazing > So...it seems impossible for every single IPV6 inthe range to configure a P= > TR. > > So...what to do? > What is the common practice? > What is possible with BIND? > > Thanks in advance for your answer. Let the machines register their own PTR record using TCP as the authenticator. update-poliy { grant . tcp-self * PTR; }; Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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
bind9.9.0 named-checkzone usage message
root@ns0s:~ # named-checkzone usage: named-checkzone [-djqvD] [-c class] [-f inputformat] [-F outputformat] [-t directory] [-w directory] [-k (ignore|warn|fail)] [-n (ignore|warn|fail)] [-m (ignore|warn|fail)] [-r (ignore|warn|fail)] [-i (full|full-sibling|local|local-sibling|none)] [-M (ignore|warn|fail)] [-S (ignore|warn|fail)] [-W (ignore|warn)] [-o filename] zonename filename FWIW, the options [-h] [-L serial] [-s style], as described in Bv9ARM.pdf, page 158, are missing from the usage message. Same with named-compilezone. Jeffry A. Spain Network Administrator Cincinnati Country Day School ___ 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: reverse dns for IPV6 ranges
thanks for your comment. But if only some IP have e reverse..what about the other server who have received an IP in the range? Ip that can be changed every x hours. IF no reverse, it can be blacklisted for some reasons or having some problems with services asking a reverse dns resolution. > From: spa...@countryday.net > To: hugo...@hotmail.com > CC: bind-users@lists.isc.org > Subject: RE: reverse dns for IPV6 ranges > Date: Mon, 5 Mar 2012 21:15:53 + > > > Can anyone help me with its experience on reverse dns for IPV6? > > Presently, when we reverse an IPV4 subnet for clients, we configure all the > > reverse for the whole subnet. > > It is a lot of PTR's but perfectly manageable. > > With IPV6, the number of IP's that we will receive is amazing > > So...it seems impossible for every single IPV6 inthe range to configure a > > PTR. > > So...what to do? > > What is the common practice? > > What is possible with BIND? > > For our IPv6 address space 2001:4870:20ca::/48, I created a reverse lookup > zone a.c.0.2.0.7.8.4.1.0.0.2.ip6.arpa and arranged for delegation from our > ISP. I included PTR records only for those hosts accessible from the > outside. Internal DNS is Windows Active Directory integrated. Here's a sample > from the zone file, which contains about 25 PTR records in all: > > $ORIGIN . > $TTL 3600 ; 1 hour > a.c.0.2.0.7.8.4.1.0.0.2.ip6.arpa IN SOA ns1.countryday.net. > hostmaster.countryday.net. ( > 2012030101 ; serial > 86400 ; refresh (1 day) > 3600 ; retry (1 hour) > 1209600; expire (2 weeks) > 3600 ; minimum (1 hour) > ) > NS ns1.countryday.net. > NS ns2.countryday.net. > $ORIGIN 9.0.0.0.a.c.0.2.0.7.8.4.1.0.0.2.ip6.arpa. > a.5.6.9.f.9.e.4.3.4.3.e.f.a.0.8 PTR ns2.countryday.net. > $ORIGIN 8.5.1.0.a.c.0.2.0.7.8.4.1.0.0.2.ip6.arpa. > 2.9.1.f.1.d.2.1.b.f.7.5.7.f.8.0 PTR ns1.countryday.net. > > I would also be interested in hearing about the practices of others. Jeff. > > Jeffry A. Spain > Network Administrator > Cincinnati Country Day School > ___ 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: reverse dns for IPV6 ranges
On Tue, 2012-03-06 at 08:23 +1100, Mark Andrews wrote: > In message , hugo hugoo writes: > > > > Dear all, > > > > Can anyone help me with its experience on reverse dns for IPV6? > > Presently, when we reverse an IPV4 subnet for clients, we configure all= > > the reverse for the whole subnet. > > It is a lot of PTR's but perfectly manageable. > > > > With IPV6, the number of IP's that we will receive is amazing > > So...it seems impossible for every single IPV6 inthe range to configure a P= > > TR. > > > > So...what to do? > > What is the common practice? > > What is possible with BIND? > > > > Thanks in advance for your answer. > > Let the machines register their own PTR record using TCP as the authenticator. > > update-poliy { > grant . tcp-self * PTR; > }; > Thats dangerous 14m1337.u.suck.hax0r.org -yeah, it would be highly abused and why most ISP's don't do/allow it :) But for a small company that has trustworthy staff, maybe, but then mail servers will start rejecting some of them trying to send directly because theres likely no matching A record. > Mark <> signature.asc Description: This is a digitally signed message part ___ 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: reverse dns for IPV6 ranges
In message <1330991057.3861.10.camel@tardis>, Noel Butler writes: > > > In message , hugo hugoo writ > es: > > > > > > Dear all, > > > > > > Can anyone help me with its experience on reverse dns for IPV6? > > > Presently, when we reverse an IPV4 subnet for clients, we configure all > = > > > the reverse for the whole subnet. > > > It is a lot of PTR's but perfectly manageable. > > > > > > With IPV6, the number of IP's that we will receive is amazing > > > So...it seems impossible for every single IPV6 inthe range to configure > > > a PTR. > > > > > > So...what to do? > > > What is the common practice? > > > What is possible with BIND? > > > > > > Thanks in advance for your answer. > > > > Let the machines register their own PTR record using TCP as the authentic > ator. > > > > update-poliy { > > grant . tcp-self * PTR; > > }; > > Thats dangerous 14m1337.u.suck.hax0r.org -yeah, it would be > highly abused and why most ISP's don't do/allow it :) And is a baseless fear as it can be tracked back to the customer involved or does the ISP permit customers to spoof each other or permit the public to spoof its customers? This isn't wide open UPDATE. Its 1.2.3.4 can update 4.3.2.1.IN-ADDR.ARPA/PTR and only 4.3.2.1.IN-ADDR.ARPA/PTR if the update request comes over TCP. > But for a small company that has trustworthy staff, maybe, but then mail > servers will start rejecting some of them trying to send directly > because theres likely no matching A record. The machine adds its own A / records using TSIG. These can then be updated as it moves around the world. > > Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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
A question for the reference
Hello, Please see this case: $ dig funnygamesite.com @k.gtld-servers.net ; <<>> DiG 9.7.3 <<>> funnygamesite.com @k.gtld-servers.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35540 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;funnygamesite.com. IN A ;; AUTHORITY SECTION: funnygamesite.com. 172800 IN NS ns1.dnsbed.com. funnygamesite.com. 172800 IN NS ns2.dnsbed.com. ;; ADDITIONAL SECTION: ns1.dnsbed.com. 172800 IN A 174.140.172.238 ns2.dnsbed.com. 172800 IN A 50.31.252.20 ;; Query time: 188 msec ;; SERVER: 192.52.178.30#53(192.52.178.30) ;; WHEN: Tue Mar 6 09:30:42 2012 ;; MSG SIZE rcvd: 110 When a resolver query funnygamesite.com from one of the gtld name servers, will the resolver use the reference (AUTHORITY SECTION and ADDITIONAL SECTION) directly? or it make another query for ns1.dnsbed.com and ns2.dnsbed.com and get the authorative answers for them? Thanks. ___ 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
lame-servers and network unreachable errors
Hi, I have a fedora15 box with bind-9.8.2 running as master for one zone, and having some problems with lame-servers and "network unreachable" messages. I believe I understand what a lame-server is, but don't understand why there would also be a "network unreachable" message attached to it: 05-Mar-2012 21:10:54.733 lame-servers: info: error (network unreachable) resolving '82.8.193.122.zen.spamhaus.org/A/IN': 2001:7b8:3:1f:0:2:53:2#53 05-Mar-2012 21:11:58.640 lame-servers: info: error (network unreachable) resolving 'dns1.iplanisp.com.ar/A/IN': 2001:67c:e0::59#53 05-Mar-2012 21:11:58.640 lame-servers: info: error (network unreachable) resolving 'dns2.iplanisp.com.ar/A/IN': 2001:67c:e0::59#53 05-Mar-2012 21:11:58.640 lame-servers: info: error (network unreachable) resolving 'dns1.iplanisp.com.ar//IN': 2001:67c:e0::59#53 05-Mar-2012 21:11:58.640 lame-servers: info: error (network unreachable) resolving 'dns2.iplanisp.com.ar//IN': 2001:67c:e0::59#53 05-Mar-2012 21:11:59.446 lame-servers: info: error (network unreachable) resolving '73.113.26.69.zen.spamhaus.org/A/IN': 2001:7b8:3:1f:0:2:53:1#53 05-Mar-2012 21:11:59.446 lame-servers: info: error (network unreachable) resolving 'ns1.mirohost.net/A/IN': 2a02:2278:70eb:199::196:43#53 05-Mar-2012 21:11:59.447 lame-servers: info: error (network unreachable) resolving 'ns1.mirohost.net/A/IN': 2a01:758:fffc:6::2#53 05-Mar-2012 21:11:59.447 lame-servers: info: error (network unreachable) resolving 'ns1.mirohost.net/A/IN': 2a01:4f8:100:22a6:188:40:253:34#53 05-Mar-2012 21:11:59.625 lame-servers: info: error (network unreachable) resolving '112.193.69.200.zen.spamhaus.org/A/IN': 2001:7b8:3:1f:0:2:53:2#53 I'm sorry if that isn't very legible. How can I troubleshoot this? It isn't every query, but quite a few queries are resulting in this unreachable error. I've included my named.conf below in hopes someone can point out a configuration issue. It contains one master zone; a local spam blacklist. controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; 68.XXX.YYY.45; } keys { "rndc-key"; }; }; acl "trusted" { { 127/8; }; { 67.XXX.YYY.224/28; }; { 67.XXX.YYY.0/26; }; { 192.168.1.0/24; }; }; options { listen-on port 53 { 127.0.0.1; 68.XXX.YYY.45; }; listen-on-v6 { none; }; // listen-on-v6 port 53 { ::1; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named.stats"; memstatistics-file "/var/named/data/named_mem_stats.txt"; allow-query { localhost; 68.XXX.YYY.45/32; }; recursion yes; zone-statistics yes; dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; /* Path to ISC DLV key */ bindkeys-file "/etc/named.iscdlv.key"; managed-keys-directory "/var/named/dynamic"; }; logging { channel default_debug { file "data/named.run"; severity dynamic; }; // Record all queries to the box for now channel query_info { severity info; file "/var/log/named.query.log" versions 3 size 10m; print-time yes; print-category yes; }; // added for fail2ban support channel security_file { severity dynamic; file "/var/log/named.security.log" versions 3 size 30m; print-time yes; print-category yes; }; channel b_debug { file "/var/log/named.debug.log" versions 2 size 10m; print-time yes; print-category yes; print-severity yes; severity dynamic; }; category queries { query_info; }; category default { b_debug; }; category config { b_debug; }; category security { security_file; }; }; zone "." IN { type hint; file "named.ca"; }; zone "sbl.example.com" { type slave; file "slaves/db.sbl.example.com"; masters { 64.XXX.YYY.5; }; allow-transfer { none; }; allow-query { trusted; }; }; include "/etc/named.rfc1912.zones"; include "/etc/named.root.key"; include "/etc/rndc.key"; Thanks, Alex ___ 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: A question for the reference
I tested this by capturing network traffic on a bind 9.9.0 recursive resolver. The commands 'rndc flush' followed by 'dig @localhost funnygamesite.com' resulted in the following: 1. A query to m.gtld-servers.net. 2. The same referral response that you got below. 3. A follow-up query 500 microseconds after the response to ns1.dnsbed.com. 4. Ns1.dnsbed.com then provided the answer (127.0.0.1). Thus it appears that bind 9.9.0 is relying on the data in the Authority and Additional sections of the first query for the addresses of funnygamesite.com's authoritative name servers. It is not making any additional queries for the addresses of those name servers. Jeff. -Original Message- Please see this case: $ dig funnygamesite.com @k.gtld-servers.net ; <<>> DiG 9.7.3 <<>> funnygamesite.com @k.gtld-servers.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35540 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;funnygamesite.com. IN A ;; AUTHORITY SECTION: funnygamesite.com. 172800 IN NS ns1.dnsbed.com. funnygamesite.com. 172800 IN NS ns2.dnsbed.com. ;; ADDITIONAL SECTION: ns1.dnsbed.com. 172800 IN A 174.140.172.238 ns2.dnsbed.com. 172800 IN A 50.31.252.20 ;; Query time: 188 msec ;; SERVER: 192.52.178.30#53(192.52.178.30) ;; WHEN: Tue Mar 6 09:30:42 2012 ;; MSG SIZE rcvd: 110 When a resolver query funnygamesite.com from one of the gtld name servers, will the resolver use the reference (AUTHORITY SECTION and ADDITIONAL SECTION) directly? or it make another query for ns1.dnsbed.com and ns2.dnsbed.com and get the authorative answers for them? ___ 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: A question for the reference
于 2012-3-6 10:23, Spain, Dr. Jeffry A. 写道: I tested this by capturing network traffic on a bind 9.9.0 recursive resolver. The commands 'rndc flush' followed by 'dig @localhost funnygamesite.com' resulted in the following: 1. A query to m.gtld-servers.net. 2. The same referral response that you got below. 3. A follow-up query 500 microseconds after the response to ns1.dnsbed.com. 4. Ns1.dnsbed.com then provided the answer (127.0.0.1). Thus it appears that bind 9.9.0 is relying on the data in the Authority and Additional sections of the first query for the addresses of funnygamesite.com's authoritative name servers. It is not making any additional queries for the addresses of those name servers. Jeff. Thank you Spain for the helpful info. That make the question clear. Regards. ___ 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: lame-servers and network unreachable errors
On Mon, 5 Mar 2012, Alex wrote: Hi, I have a fedora15 box with bind-9.8.2 running as master for one zone, and having some problems with lame-servers and "network unreachable" messages. I believe I understand what a lame-server is, but don't understand why there would also be a "network unreachable" message attached to it: 05-Mar-2012 21:10:54.733 lame-servers: info: error (network unreachable) resolving '82.8.193.122.zen.spamhaus.org/A/IN': 2001:7b8:3:1f:0:2:53:2#53 05-Mar-2012 21:11:58.640 lame-servers: info: error (network unreachable) resolving 'dns1.iplanisp.com.ar/A/IN': 2001:67c:e0::59#53 }; category queries { query_info; }; category default { b_debug; }; category config { b_debug; }; category security { security_file; }; Those are all lame-servers: info logs and can be eliminated by adding a category lame-servers { null; }; statement. -- David Forrest St. Louis, Missouri ___ 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: reverse dns for IPV6 ranges
> But if only some IP have e reverse..what about the other server who have > received an IP in the range? Ip that can be changed every x hours. > IF no reverse, it can be blacklisted for some reasons or having some problems > with services asking a reverse dns resolution. In my ip6.arpa zone, all of the entries are for servers whose IPv6 addresses never change. If you are going to register PTR records for clients with changeable IPv6 addresses, then you need a dynamic update mechanism. Mark Andrews made a recommendation earlier in this regard. I don't think there is any reason to have PTR records that have no corresponding records in the forward lookup zone. That would be computationally infeasible anyway. Jeff. ___ 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: lame-servers and network unreachable errors
The remote zones have IPv6 servers and named believes your machine has IPv6 connectivity. It then attempts to connect to the remote servers and gets back a network error saying that it can't reach the remote machines. The long term fix is to request IPv6 connectivity from your ISP. Short term fixes include: * configuring a IPv6 tunnel * globally disabling IPv6 as a transport (named -4) * using server clauses to selectively disable IPv6 as a transport. server ::/0 { bogus yes; }; server fdxx::::/48 { bogus no; }; In message , Alex writes: > Hi, > > I have a fedora15 box with bind-9.8.2 running as master for one zone, > and having some problems with lame-servers and "network unreachable" > messages. I believe I understand what a lame-server is, but don't > understand why there would also be a "network unreachable" message > attached to it: > > 05-Mar-2012 21:10:54.733 lame-servers: info: error (network > unreachable) resolving '82.8.193.122.zen.spamhaus.org/A/IN': > 2001:7b8:3:1f:0:2:53:2#53 > 05-Mar-2012 21:11:58.640 lame-servers: info: error (network > unreachable) resolving 'dns1.iplanisp.com.ar/A/IN': 2001:67c:e0::59#53 > 05-Mar-2012 21:11:58.640 lame-servers: info: error (network > unreachable) resolving 'dns2.iplanisp.com.ar/A/IN': 2001:67c:e0::59#53 > 05-Mar-2012 21:11:58.640 lame-servers: info: error (network > unreachable) resolving 'dns1.iplanisp.com.ar//IN': > 2001:67c:e0::59#53 > 05-Mar-2012 21:11:58.640 lame-servers: info: error (network > unreachable) resolving 'dns2.iplanisp.com.ar//IN': > 2001:67c:e0::59#53 > 05-Mar-2012 21:11:59.446 lame-servers: info: error (network > unreachable) resolving '73.113.26.69.zen.spamhaus.org/A/IN': > 2001:7b8:3:1f:0:2:53:1#53 > 05-Mar-2012 21:11:59.446 lame-servers: info: error (network > unreachable) resolving 'ns1.mirohost.net/A/IN': > 2a02:2278:70eb:199::196:43#53 > 05-Mar-2012 21:11:59.447 lame-servers: info: error (network > unreachable) resolving 'ns1.mirohost.net/A/IN': 2a01:758:fffc:6::2#53 > 05-Mar-2012 21:11:59.447 lame-servers: info: error (network > unreachable) resolving 'ns1.mirohost.net/A/IN': > 2a01:4f8:100:22a6:188:40:253:34#53 > 05-Mar-2012 21:11:59.625 lame-servers: info: error (network > unreachable) resolving '112.193.69.200.zen.spamhaus.org/A/IN': > 2001:7b8:3:1f:0:2:53:2#53 > > I'm sorry if that isn't very legible. How can I troubleshoot this? It > isn't every query, but quite a few queries are resulting in this > unreachable error. > > I've included my named.conf below in hopes someone can point out a > configuration issue. It contains one master zone; a local spam > blacklist. > > controls { >inet 127.0.0.1 port 953 >allow { 127.0.0.1; 68.XXX.YYY.45; } keys { "rndc-key"; }; > }; > > acl "trusted" { > { 127/8; }; > { 67.XXX.YYY.224/28; }; > { 67.XXX.YYY.0/26; }; > { 192.168.1.0/24; }; > }; > > options { > listen-on port 53 { 127.0.0.1; 68.XXX.YYY.45; }; > listen-on-v6 { none; }; > // listen-on-v6 port 53 { ::1; }; > directory "/var/named"; > dump-file "/var/named/data/cache_dump.db"; > statistics-file "/var/named/data/named.stats"; > memstatistics-file "/var/named/data/named_mem_stats.txt"; > allow-query { localhost; 68.XXX.YYY.45/32; }; > recursion yes; > zone-statistics yes; > > dnssec-enable yes; > dnssec-validation yes; > dnssec-lookaside auto; > > /* Path to ISC DLV key */ > bindkeys-file "/etc/named.iscdlv.key"; > > managed-keys-directory "/var/named/dynamic"; > > }; > > logging { > channel default_debug { > file "data/named.run"; > severity dynamic; > }; > > // Record all queries to the box for now > channel query_info { >severity info; >file "/var/log/named.query.log" versions 3 size 10m; >print-time yes; >print-category yes; > }; > > // added for fail2ban support > channel security_file { > severity dynamic; > file "/var/log/named.security.log" versions 3 size 30m; > print-time yes; > print-category yes; > }; > > channel b_debug { > file "/var/log/named.debug.log" versions 2 size 10m; > print-time yes; > print-category yes; > print-severity yes; > severity dynamic; > }; > > category queries { query_info; }; > category default { b_debug; }; > category config { b_debug; }; > category security { security_file; }; > > }; > > zone "." IN { > type hint; > file "named.ca"; > }; > > zone "sbl.example.com" { > type slave; > file "slaves/db.sbl.example.com"; > masters { 64.XXX.YYY.5; }; > allow-transfer { none; }; > allow-query { trusted; };
NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
Hi, > "auto-dnssec" zones can now have NSEC3 parameters set prior > to signing. [RT #23684] According to the docs it should be possible to set NSEC3PARAM on the unsigned version when using inline-signer mode. The signing BIND 9.9 should then decide to use NSEC3, which salt, opt-out, etc. based on this. I have tried this and could not get it to work. The only way to use NSEC3 with the inline signer atm is to run 'rndc -nsec3param' once the zone has been configured. Any hints? Thanks, -- Wolfgang Nagele Senior Systems and Network Administrator AusRegistry Pty Ltd Level 8, 10 Queens Road Melbourne, Victoria, Australia, 3004 Phone +61 3 9090 1756 Email: wolfgang.nag...@ausregistry.com.au Web: www.ausregistry.com.au The information contained in this communication is intended for the named recipients only. It is subject to copyright and may contain legally privileged and confidential information and if you are not an intended recipient you must not use, copy, distribute or take any action in reliance on it. If you have received this communication in error, please delete all copies from your system and notify us immediately. ___ 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: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
> According to the docs it should be possible to set NSEC3PARAM on the > unsigned version when using inline-signer mode. The signing BIND 9.9 > should then decide to use NSEC3, which salt, opt-out, etc. based on this. > I have tried this and could not get it to work. The only way to use NSEC3 > with the inline signer atm is to run 'rndc -nsec3param' once the zone has > been configured. Any hints? You should be able to use 'rndc signing -nsec3param' before the zone is signed. It's working for me: zone "example.nil" { type master; inline-signing yes; auto-dnssec maintain; file "example1.db"; }; $ rndc signing -nsec3param 1 0 10 BEEF example.nil $ rndc signing -list example.nil Pending NSEC3 chain 1 0 10 BEEF $ dnssec-keygen -3 example.nil Generating key pair.++ ..++ Kexample.nil.+007+28952 $ dnssec-keygen -3fk example.nil Generating key pair...+++ ..+++ Kexample.nil.+007+04053 $ rndc loadkeys example.nil $ sbin/rndc signing -list example.nil Done signing with key 4053/NSEC3RSASHA1 Done signing with key 28952/NSEC3RSASHA1 $ dig @localhost +short nsec3param example.nil 1 0 10 BEEF -- Evan Hunt -- each@isc.orggg Internet Systema 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