auto-dnssec resign timers

[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

[Tony Finch]

On 17 Sep 2010, at 10:44, Niobos  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”) 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).

The signature inception time is unconditionally set to one hour before the 
current time to allow for a limited amount of clock skew.

The sig-validity-interval should be, at least, several multiples of the SOA 
expire interval to allow for reasonable interaction between the various timer 
and expiry dates.

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

Re: auto-dnssec resign timers

[Niobos]

On 2010-09-17 12:15, Tony Finch wrote:
> On 17 Sep 2010, at 10:44, Niobos  > 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”
> ) 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

[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

[David Forrest]

On Fri, 17 Sep 2010, Niobos wrote:



Is the current version of the ARM available online somewhere?

Thx,
Niobos


It is in the doc directory of the source for the subject binary, in html 
and pdf formats.


Dave
--
St. Louis, Missouri
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: auto-dnssec resign timers

[Tony Finch]

On 17 Sep 2010, at 14:10, Niobos  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.finchhttp://dotat.at/___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: auto-dnssec resign timers

[Niobos]

On 2010-09-17 19:50, Tony Finch wrote:
> On 17 Sep 2010, at 14:10, Niobos  > 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?

[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

[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

[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

[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

[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  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

[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