auto-dnssec resign timers

2010-09-17 Thread Niobos
Hi,

I'm experimenting with the auto-dnssec feature of bind 9.7.0-P1. I know
it's outdated; I did skim over the changelog up until 9.7.2rc2, and
didn't find anything that seems like this issue.

This query demonstrates the issue:
;  DiG 9.6.0-APPLE-P2  +dnssec SOA dnssec.dest-unreach.be
@imset.org +norec
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 8632
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;dnssec.dest-unreach.be.IN  SOA

;; ANSWER SECTION:
dnssec.dest-unreach.be. 86400   IN  SOA serv02.imset.org.
hostmaster.dest-unreach.be. 55 3600 3600 172800 300
dnssec.dest-unreach.be. 86400   IN  RRSIG   SOA 7 3 86400 20100919163624
20100916153624 42614 dnssec.dest-unreach.be.
WBdpqpLCa/5cnMAThAcftrOysfdN8K594WAM+6AMyRPiEpXVF6JRqJWH
N46J3aN6BliM09bA9RxYOoClCcIsJA==

;; AUTHORITY SECTION:
dnssec.dest-unreach.be. 300 IN  NS  serv02.imset.org.
dnssec.dest-unreach.be. 300 IN  NS  sdns1.ovh.net.
dnssec.dest-unreach.be. 300 IN  RRSIG   NS 7 3 300 20100919161438
20100916153624 42614 dnssec.dest-unreach.be.
U6KZzFZecSZNEL0Wp8NxlmjgitQfXbHNt1+S85sZxm9Ti8oNiWMhESts
SmLTmos4VU2yqSo6KOq8mQ/xvoehhw==

;; ADDITIONAL SECTION:
serv02.imset.org.   86400   IN  A   94.23.24.89
serv02.imset.org.   86400   IN  
2001:41d0:2:1959:21c:c0ff:fe88:6f58

;; Query time: 7 msec
;; SERVER: 94.23.24.89#53(94.23.24.89)
;; WHEN: Fri Sep 17 11:29:14 2010
;; MSG SIZE  rcvd: 435

(the dnssec.dest-unreach.be zone is my test zone; publicly available,
but not publicly delegated)


In my opinion, BIND should have resigned this by now: The signature is
valid until a little over 2 days. This means that if the slave would
loose contact with the master right now, it will give out signatures
that will expire before their TTL does.
According to my calculations, RRSIGs should be regenerated zone-expire +
RR-ttl seconds before the RRSIG expires.

For reference, the configuration:
zone dnssec.dest-unreach.be {
type master;
file /var/lib/bind/dnssec.dest-unreach.be.zone;
update-policy local;
auto-dnssec maintain;
dnssec-secure-to-insecure yes;
key-directory /etc/bind/keys;
sig-validity-interval 3;
};

And to be completely honest: the configured slave NS record doesn't
really slave this zone; but BIND shouldn't know or care.

greets,
Niobos

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


Re: auto-dnssec resign timers

2010-09-17 Thread Niobos
On 2010-09-17 12:15, Tony Finch wrote:
 On 17 Sep 2010, at 10:44, Niobos nio...@dest-unreach.be
 mailto:nio...@dest-unreach.be wrote:

 In my opinion, BIND should have resigned this by now: The signature is
 valid until a little over 2 days. This means that if the slave would
 loose contact with the master right now, it will give out signatures
 that will expire before their TTL does.
 According to my calculations, RRSIGs should be regenerated zone-expire +
 RR-ttl seconds before the RRSIG expires.
 
 You have to manually set the zone expiry time, TTLs, signature lifetime,
 and re-signing time consistently.
 
 The documentation for 9.7.1 says:
 
 *sig-validity-interval*
 *
 *
 *Specifies the number of days into the future when DNSSEC signatures
 automatically generated as a result of dynamic updates (the section
 called “Dynamic Update”
 http://dotat.at/tmp/arm97/Bv9ARM.ch04.html#dynamic_update) will
 expire. There is an optional second field which specifies how long
 before expiry that the signatures will be regenerated. If not specified,
 the signatures will be regenerated at 1/4 of base interval. The second
 field is specified in days if the base interval is greater than 7 days
 otherwise it is specified in hours. The default base interval
 is |30| days giving a re-signing interval of 7 1/2 days. The maximum
 values are 10 years (3660 days).***
Wonderful, exactly what I was looking for.

Unfortunately, this mail is the first place where I find a reference to
this second field. My Google-searches of bind arm
sig-validity-interval only return the single-field descriptions (eg
http://training.nlnetlabs.nl/Documentation/bind-arm/Bv9ARM.ch06.html#zone_statement_grammar
); even the man-page of my installation says:
sig-validity-interval integer;
note the absence of the second field.

Is the current version of the ARM available online somewhere?

Thx,
Niobos

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

tkey-gssapi-credential

2010-09-17 Thread Nicholas F Miller
I was wondering if it is possible to use the tkey-gssapi-credential and 
update-policy on a Windows install of bind. It strikes me that running bind on 
a Windows server, snapped into the AD it will serve DNS to, should be the 
easiest way of getting DDNS with update-policy control working.

Am I nuts? Should I just install it on a Linux box and be done?
_
Nicholas Miller, ITS, University of Colorado at Boulder



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


Re: auto-dnssec resign timers

2010-09-17 Thread Tony Finch
On 17 Sep 2010, at 14:10, Niobos nio...@dest-unreach.be wrote:
 
 Is the current version of the ARM available online somewhere?

http://dotat.at/tmp/arm97/

IIRC the specific version that comes from is 9.7.1p2.

Tony.
--
f.anthony.n.finch  d...@dotat.at  http://dotat.at/___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: auto-dnssec resign timers

2010-09-17 Thread Niobos
On 2010-09-17 19:50, Tony Finch wrote:
 On 17 Sep 2010, at 14:10, Niobos nio...@dest-unreach.be
 mailto:nio...@dest-unreach.be wrote:

 Is the current version of the ARM available online somewhere?
 
 http://dotat.at/tmp/arm97/
 
 IIRC the specific version that comes from is 9.7.1p2.

Thanks for the quick and accurate answer!

Niobos

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


NSEC3 salt lifetime (and some other DNSSEC params): sane value?

2010-09-17 Thread Niobos
Hi,

I'm playing around with the different timers of DNSSEC. Usually these
timers are a balance between a low overhead vs quick propagation:
* A high TTL gives more caching and thus less load on the authoritative
server; but it takes a long time for updates to propagate.
* A short RRSIG lifetime limits the amount of time old answers can be
replayed; but requires regular resigning

Or they are a balance between low overhead and security:
* A DNSKEY (ZSK or KSK) used for a long time risks being cracked;
changing it often requires maintenance.

But for the NSEC3 salt, I can't really figure out what the components
are... If someone is brute-forcing the NSEC3 hashes (cfr Daniel
Bernstein's presentation), changing the salt requires only a minuscule
change on their end. I see no reason to change the NSEC3 salt at all.

So the question is: what is a normal lifetime of an NSEC3 salt, and for
what reason?

And while I'm at it: what lifetimes, keylengths and algo's are popular
for ZSK's and KSK's? Are your keys stored online or offline?

I'm thinking of using ZSK's of 1280bits for a year (since I'm lazy) and
KSK's of 2048bits until I feel like changing it (i.e. pretty much
indefinitely). This would allow the KSK to be offline, and only needed
once a year.
I'd like to use NSEC3 with RSA/SHA-512, but that might be unreasonable
strong compared to my lazy lifetimes. On the other hand, RSA/SHA1 is
more compatible (eg with bind 9.6).
My signature lifetime will probably be 3 weeks, resigning every week.
With 1 week expire timers, it leaves 1 week of margin to correct errors.
Are these values/argo's sane?

Thx,
Niobos

PS: don't try talking me into using NSEC. I'm using NSEC3 because I
can, not that it would be any problem at all if they walked my zone.

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


bind 9.7.1-P2 startup: unable to set effective gid to 0

2010-09-17 Thread aldus jung
We recently upgraded from bind version 9.7.0 to 9.7.1-P2 and we noticed that
upon start of named, we are seeing the following warning message:

 [ID 123 daemon.warning] unable to set effective gid to 0: Not owner
 [ID 123 daemon.info] generating session key for dynamic DNS
 [ID 123 daemon.warning] unable to set effective gid to 0: Not owner

On our DNS server, root user is configured as uid=0(root) gid=1(other), but
we didn't encounter these warnings in version 9.7.0.
It would be easy to work around the warnings by adding root to root's group,
but I wanted to understand why we are getting these warning when we didn't
see this on 9.7.0.

Which file or directory is named trying to set gid to 0?

thanks for your help,
AJ
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: tkey-gssapi-credential

2010-09-17 Thread Rob Austein
At Fri, 17 Sep 2010 09:17:09 -0600, Nicholas F Miller wrote:
 
 I was wondering if it is possible to use the tkey-gssapi-credential
 and update-policy on a Windows install of bind. It strikes me that
 running bind on a Windows server, snapped into the AD it will serve
 DNS to, should be the easiest way of getting DDNS with update-policy
 control working.

It would be, except for one small problem: the Windows native Kerberos
doesn't support GSS-API (or didn't, when last I checked), instead it
supports some similar-but-different Microsoft proprietary API whose
name has temporarily escaped my memory.  So either we would have to
hack Windows-specific code here to use Microsoft's API, or we would
have to get a Unix-style Kerberos library working on Windows.

We spent an insane amount of time banging our head against the latter
approach, but never got it to work, for reasons that never made a lot
of sense (eg, linking against precompiled MIT Kerberos binaries
resulted in binaries that worked fine for everything but GSS-TSIG but
failed silently for that, attempting to build MIT Kerberos for Windows
from source resulted in Kerberos code that couldn't even kinit, and
nobody on the MIT Kerberos project could tell us why).  We eventually
gave up, because we had deadlines to meet and this configuration
(BIND9 running GSS-TSIG on Windows) wasn't on our critical feature
list.

 Am I nuts? Should I just install it on a Linux box and be done?

Yes, unless you (or some other brave soul) have the time and energy to
get this working on Windows, in which case please tell us what you did
(and i will stand you a beer if we ever meet...).
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: tkey-gssapi-credential

2010-09-17 Thread Nicholas F Miller
Thanks, that will save me a bunch of time. Of course I spent my morning testing 
it out to no avail.

Does anyone have instructions on how to setup a Linux bind server to use 
GSS-TSIG against an AD? I have found many articles from people having issues 
with it but none that had good instructions on how to get it working. Last year 
we played around with it but were having issues getting it to work. kinit would 
work against the AD on our RHEL bind server but our clients couldn't update 
their records.
_
Nicholas Miller, ITS, University of Colorado at Boulder



On Sep 17, 2010, at 12:54 PM, Rob Austein wrote:

 At Fri, 17 Sep 2010 09:17:09 -0600, Nicholas F Miller wrote:
 
 I was wondering if it is possible to use the tkey-gssapi-credential
 and update-policy on a Windows install of bind. It strikes me that
 running bind on a Windows server, snapped into the AD it will serve
 DNS to, should be the easiest way of getting DDNS with update-policy
 control working.
 
 It would be, except for one small problem: the Windows native Kerberos
 doesn't support GSS-API (or didn't, when last I checked), instead it
 supports some similar-but-different Microsoft proprietary API whose
 name has temporarily escaped my memory.  So either we would have to
 hack Windows-specific code here to use Microsoft's API, or we would
 have to get a Unix-style Kerberos library working on Windows.
 
 We spent an insane amount of time banging our head against the latter
 approach, but never got it to work, for reasons that never made a lot
 of sense (eg, linking against precompiled MIT Kerberos binaries
 resulted in binaries that worked fine for everything but GSS-TSIG but
 failed silently for that, attempting to build MIT Kerberos for Windows
 from source resulted in Kerberos code that couldn't even kinit, and
 nobody on the MIT Kerberos project could tell us why).  We eventually
 gave up, because we had deadlines to meet and this configuration
 (BIND9 running GSS-TSIG on Windows) wasn't on our critical feature
 list.
 
 Am I nuts? Should I just install it on a Linux box and be done?
 
 Yes, unless you (or some other brave soul) have the time and energy to
 get this working on Windows, in which case please tell us what you did
 (and i will stand you a beer if we ever meet...).
 ___
 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: bind 9.7.1-P2 startup: unable to set effective gid to 0

2010-09-17 Thread aldus jung
Just a follow up, I've added some debug statements to bin/named/unix/os.c to
see the files that named is trying to set the effective gid for, and I see:
[ID 873 daemon.warning] Trying to open: '/var/run/named.pid'.
[ID 873 daemon.warning] unable to set effective gid to 0: Not owner
[ID 873 daemon.info] generating session key for dynamic DNS
[ID 873 daemon.warning] Trying to open: '/var/run/named/session.key'.

We are running bind in a chrooted environment, running named as user 'named'
on a Solaris 10 server:
/bind/sbin/named -t /chroot/domain -u named

Only when we make root's primary id to be 0, we can get rid of the warning.
We tried adding root to the group 'root', and we still get the warning.

We've set /chroot/domain/var/run ownership to: drwxrwxr-x   4 root other

And named.pid gets created correctly:
-rw-r--r--   1 namednamed

It could be something simple that I am missing.. we'll well see.  Any
thoughts?   Thanks for your help,

AJ

On Fri, Sep 17, 2010 at 2:42 PM, aldus jung aldus...@gmail.com wrote:

 We recently upgraded from bind version 9.7.0 to 9.7.1-P2 and we noticed
 that upon start of named, we are seeing the following warning message:

  [ID 123 daemon.warning] unable to set effective gid to 0: Not owner
  [ID 123 daemon.info] generating session key for dynamic DNS
  [ID 123 daemon.warning] unable to set effective gid to 0: Not owner

 On our DNS server, root user is configured as uid=0(root) gid=1(other), but
 we didn't encounter these warnings in version 9.7.0.
 It would be easy to work around the warnings by adding root to root's
 group, but I wanted to understand why we are getting these warning when we
 didn't see this on 9.7.0.

 Which file or directory is named trying to set gid to 0?

 thanks for your help,
 AJ


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

Re: tkey-gssapi-credential

2010-09-17 Thread Rob Austein
At Fri, 17 Sep 2010 13:18:42 -0600, Nicholas F Miller wrote:
 
 Does anyone have instructions on how to setup a Linux bind server to
 use GSS-TSIG against an AD? I have found many articles from people
 having issues with it but none that had good instructions on how to
 get it working. Last year we played around with it but were having
 issues getting it to work. kinit would work against the AD on our
 RHEL bind server but our clients couldn't update their records.

Beyond what's already been posted here?  Not really.  I can perhaps
tell you two things that might be useful.

1) The code really does work, honest.  I have personally seen it work
   (in the lab -- my last stint as an operator supporting anything on
   Windows predated AD) with Windows 2000, Windows 2003 Server, and
   Windows XP.  I have not (yet) personally tested it with anything
   more recent than that, but unless Microsoft has done something
   weird (nah) it still should.

2) If you run into problems, the best debugging tools I can recommend
   are:

   a) Running named with full debugging (named -g and capture the
  stderr output somewhere, or do the equivalent with logging
  options in named.conf); and

   b) A good packet sniffer watching both DNS and Kerberos traffic.

   For (b) I recommend Wireshark (or tshark, same difference).  You
   can use some other tool (eg, tcpdump) to capture the dump, but
   understanding what happened requires an analyzer that do deep
   insepction of both DNS and Kerberos.  Make sure you capture full
   packets for both Kerberos and DNS, ie, UDP ports 88 and 53 as well
   as TCP port 53 (Yes, Windows uses all three).
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users