Re: BIND 9.9.0 Inline-Signing Out of Control

2012-03-05 Thread David Kreindler
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

2012-03-05 Thread Spain, Dr. Jeffry A.
> 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

2012-03-05 Thread Matus UHLAR - fantomas

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?

2012-03-05 Thread Ian Pilcher
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

2012-03-05 Thread David Kreindler
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

2012-03-05 Thread Phil Mayers

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

2012-03-05 Thread hugo hugoo

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

2012-03-05 Thread Spain, Dr. Jeffry A.
> 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

2012-03-05 Thread Mark Andrews

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

2012-03-05 Thread Spain, Dr. Jeffry A.
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

2012-03-05 Thread hugo hugoo

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

2012-03-05 Thread Noel Butler
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

2012-03-05 Thread Mark Andrews

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

2012-03-05 Thread Jeff Peng

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

2012-03-05 Thread Alex
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

2012-03-05 Thread 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.

-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-03-05 Thread Jeff Peng

于 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

2012-03-05 Thread David Forrest

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

2012-03-05 Thread Spain, Dr. Jeffry A.
> 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

2012-03-05 Thread Mark Andrews

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)

2012-03-05 Thread Wolfgang Nagele
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)

2012-03-05 Thread Evan Hunt
> 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