9.8 controls stmt ignores second key?

2012-06-07 Thread Phil Pennock 
I upgraded bind today from 9.6 to 9.8.3-P1.

One of my automated reloads is now failing.  I've tracked this down to
the second key in the controls configuration being ignored.  If I swap
the order of the keys, the second (now first) key is honoured, the other
is not, so I know that both keys still work and it's just the order that
matters.

controls {
  inet 127.0.0.1 port 954 allow { localhost; } keys { rndc-key-nsauth; 
rndc-key-dnssync; };
  inet ::1 port 954 allow { localhost; } keys { rndc-key-nsauth; 
rndc-key-dnssync; };
};

(The non-standard port has a historical reason)

Both keys are hmac-md5.  As I say, both work, but only if they're first
in the list.  Whichever key is second gets this as client:
8< cut here >8--
rndc: connection to remote host closed
This may indicate that
* the remote server is using an older version of the command protocol,
* this host is not authorized to connect,
* the clocks are not synchronized, or
* the key is invalid.
8< cut here >8--

and as server:
8< cut here >8--
 general: info: received control channel command 'reload sks.pool.globnix.net'
 general: error: invalid command from 127.0.0.1#61018: bad auth
8< cut here >8--


As far as I can tell from:
  
http://ftp.isc.org/isc/bind9/cur/9.8/doc/arm/Bv9ARM.ch06.html#controls_statement_definition_and_usage
the syntax is unchanged and the above *should* work.

Have I missed something that has changed, or is this a regression?

Nothing obvious in "CHANGES" that I can see.

Thanks,
-Phil
___
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: 9.8 controls stmt ignores second key?

2012-06-08 Thread Phil Pennock 
On 2012-06-08 at 15:36 +1000, Mark Andrews wrote:
> Apply the following.  It should work
> 
> diff --git a/bin/named/controlconf.c b/bin/named/controlconf.c
[...]

Confirmed, works for me, thank you!

-Phil
___
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

KSK signing all records; NSEC3 algorithm status?

2014-05-27 Thread Phil Pennock 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The registrar for my zone "xn--qck5b9a5eml3bze.jp" required a DNSSEC
KSK update; good practice on their part.  My first rollover, though.
I've ended up with all records being signed by the new KSK, apparently
through an algorithm mismatch, and I'm not seeing how to handle this --
I'm wondering if I've run into a current Bind limitation?

I'm using Bind 9.10, and the zone statement includes:

auto-dnssec maintain;
inline-signing yes;

I had originally set up the signing for the zone with:

rndc signing -nsec3param 1 0 100 $(openssl rand -hex 8) $zone

For this rollover, I generated a new key, and perhaps stupidly took the
opportunity to bump the hash algorithm:

dnssec-keygen -3 -a RSASHA256 -b 2048 -f KSK xn--qck5b9a5eml3bze.jp

and deployed to the host; while checking man-pages to figure out how to
tell Bind to start using the new key, I noticed that it had in fact
picked it up.  ZSK being signed with both old and new KSK -- fantastic!
Alas: 
Which shows the id=53065 SEP-flagged KSK being used to sign non-DNSKEY
records within the zone.

List archives led me to Kyle Brantley's post:
  Subject: Re: auto-dnssec maintain: KSK being used as a ZSK as well?
  Date: Fri, 21 Dec 2012 19:50:43 -0700
  Message-ID: <50d52003.4010...@averageurl.com>
which clued me in with:
} Aye. Thanks, Alan, for the help. The problem was that I was generating a
} RSASHA512 for my KSK, but I was using NSEC3RSASHA1 for my ZSKs. I generated a
} temporary ZSK that was also RSASHA512 to match my KSK and it is working great
} now.

The rndc manual page states:
- 8< cut here >8--
   rndc signing -nsec3param sets the NSEC3 parameters for a zone. This
   is the only supported mechanism for using NSEC3 with inline-signing
   zones. Parameters are specified in the same format as an NSEC3PARAM
   resource record: hash algorithm, flags, iterations, and salt, in
   that order.

   Currently, the only defined value for hash algorithm is 1,
   representing SHA-1. The flags may be set to 0 or 1, depending on
   whether you wish to set the opt-out bit in the NSEC3 chain.
   iterations defines the number of additional times to apply the
   algorithm when generating an NSEC3 hash. The salt is a string of
   data expressed in hexadecimal, a hyphen (`-') if no salt is to be
   used, or the keyword auto, which causes named to generate a random
   64-bit salt.
- 8< cut here >8--

I do not really want to move away from inline-signing/maintain -- it's a
great feature which automates something which should be automated.  I
know that in theory, there's nothing requiring the KSK/ZSK split but I'd
still like to get back to a more traditional setup.

 (1) Have I put myself into a bad situation where my only way out is to
 generate a new DNSKEY KSK, this time back with the default SHA1,
 add it to the zone, then get the registrar to update the DS
 records?

 (2) Is it the case that the problem is that given a hash algorithm X
 and a second algorithm Y, with X used for the KSK and Y used for
 the ZSK, if inline-signing sees such a situation with no ZSK using
 algorithm X, then it will sign the entire zone with the KSK, as
 suggested by Kyle's debugging in 2012?  Is this intentional?  I can
 see a rationale -- keep one consistent set of signing algorithms,
 reduce potential for interop tangles.  However, since IANA appears
 to only have SHA-1 registered for NSEC3:
   

 this seems to be an unfortunate interplay.

 (3) Anyone have any constructive suggestions or advice to guide me out?
 Even if it's just "go route 1, at this time don't bother touching
 other hash algorithms while using NSEC3"?

Guidance appreciated, thanks,
- -Phil
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJThTt4AAoJEKBsj+IM0duFFq4IAJ+dn1+0Vkm7XnN+r70QDWmD
fgEN0G9D72TRJ0lYqkd19W/qwctfKDkCUaTt3BIjRwBDV3bQXxqLQkXxH7jWFNXK
czZEEm6mOKCQWcBEKAMtfWM5cGKGAjSjfvbA2ZOAvuUIkDfYN0s4kcWYFTre7Zyk
SSnZi909xs1ZPiuz447dmUBr3gg5wNJAuUNiNJJP9DHriu6542DdRzUtbu3zmABG
rBAjS/budz/nr3INHYvTCyR1PJ7RtzxtVT5PcnQ0GnP1H92Zspk3rDrqc8CWDSUA
5UUV0D8qSE8xvzwcW6qiaJO7OkYoaUgxjgsS0rsceOoLWLriIZuVsV8NgT8SNMw=
=hRKl
-END PGP SIGNATURE-
___
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: KSK signing all records; NSEC3 algorithm status?

2014-05-28 Thread Phil Pennock 
On 2014-05-28 at 13:02 +1000, Mark Andrews wrote:
> In message <20140528012734.ga55...@redoubt.spodhuis.org>, Phil Pennock writes:
> > The registrar for my zone "xn--qck5b9a5eml3bze.jp" required a DNSSEC
> > KSK update; good practice on their part.
> 
> For most zones you never need to roll DNSSEC keys.  Even for high
> value zones where someone would be willing to spend the resources
> to break the public keys once a decade would be fine.
> 
> The only reason higher frequency rollovers to occur is to practice them.

That was my understanding; however, "TLD registrar establishing a
mandate" is another good reason.

> This is not a KSK key rollover in the usual sence of the expression.
> This is rolling to a new DNSKEY algorithm and you should have
> generated both a KSK and ZSK for this algorithm.
> 
> If you want to finish transitioning to RSASHA256 just generate a
> zone signing key RSASHA256.  Named will sort things out.  You may
> end up with 3 sets of signatures for a while.  Don't worry about
> it.
> 
> Once that is done you need to add a DS record for the KSK.  You can also
> remove the old DS if twelve hours have elasped since you started the process.

The DS record is already in place for the KSK.

> After the maxmium of (12 hours (DS ttl), the maximum TTL in the
> zone (at least 12 hours)) after the DS change to remove the old DS
> you can tell mark the old keys as inactive and not to be published
> using dnssec-settime.  All the keys for the algorithm need to stop
> being used and published at the same time.

Perfect, thanks for that!

>   Yes.  Named enforces the signing rules that every record is
>   signed with every algorithm.  When you add a new DNSKEY algorithm
>   it will ensure that every RRset gets signed with it.  It does
>   this incrementally then updates the private type records to
>   say that it has completed the operation so you can then add the
>   DS records.  If there isn't a ZSK for that algorithm it will
>   use a KSK.

Ah, I hadn't considered how the KSK/ZSK being an operational distinction
rather than an algorithm distinction would play into the requirements
around key consistency -- as far as verifiers are concerned, the
validation of KSK is not a distinct step and does not introduce a "cut"
for record signing algorithm requirements.  Thanks.

> >  I can
> >  see a rationale -- keep one consistent set of signing algorithms,
> >  reduce potential for interop tangles.  However, since IANA appears
> >  to only have SHA-1 registered for NSEC3:
> >
> > <http://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-
> > parameters.xhtml>
> >  this seems to be an unfortunate interplay.
> 
>   That is the NSEC3 HASH algorithm, not the DNSKEY algorithm.

*blush*  Thank you.

>   DNSKEY algorithms 6, 7, 8 10, 12, 13, and 14 are all NSEC3
>   capable.  All future algorithms are supposed to be NSEC3
>   capable.

And of course, this is why I'd chosen to use the "-3" option to
dnssec-keygen, to ensure I remained NSEC3 capable, but by the end of
chasing the information paths I was on, I'd forgotten this.

Okay, I think that I'm on track to recovery.  Thanks.
-Phil
___
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: KSK signing all records; NSEC3 algorithm status?

2014-05-28 Thread Phil Pennock 
On 2014-05-28 at 13:02 +1000, Mark Andrews wrote:
> If you want to finish transitioning to RSASHA256 just generate a
> zone signing key RSASHA256.  Named will sort things out.  You may
> end up with 3 sets of signatures for a while.  Don't worry about
> it.

The new DNSKEY had id=33768 and when I deployed it, Bind signed the SOA
with it but nothing else.

$ rndc -s 127.0.0.5 signing -list xn--qck5b9a5eml3bze.jp
Done signing with key 53065/RSASHA256

$ host -lva xn--qck5b9a5eml3bze.jp nsauth | fgrep 33768
xn--qck5b9a5eml3bze.jp. 43200   IN  RRSIG   DNSKEY 8 2 43200 
20140627144436 20140528134436 33768 xn--qck5b9a5eml3bze.jp. 
BnKhdfy6/nGSEBnOo8EUJvHkzi+5NASKEHRTXE4R1abZprxSuuf2LFUhxzMsrZuvhsj/v7+8p0t5hQJx98Zvph+ddmFy5NfMBo/68OHtvuYPsquKuAQWLJtlykzj8C1MmMlute7tmxcZRaCMO7f26AqI/Pa4aa1JmmIyRtUo+Dg=
xn--qck5b9a5eml3bze.jp. 43200   IN  RRSIG   SOA 8 2 43200 
20140627144436 20140528134436 33768 xn--qck5b9a5eml3bze.jp. 
R7tyfea3OvFxnwgqL4xseUIAMfbIJsJywYn8hP8zYmTQqD6/31/ysNxVSJ8bnyGA1AwfcBrdjlD8NlDbzZRqMiM6avNF0PWIA8HMfvaB7AJ1aUjeGPLp3lR2zxTGdUpcpfY+Ge2fD2L7jB5hJYvCLEqCK8zDXC6EFYyZJFm0F+A=

It's been almost 14 hours, so anything that was going to slow roll,
should have completed.

Ran:

$ rndc -s 127.0.0.5 signing -nsec3param 1 0 100 $(openssl rand -hex 8) 
xn--qck5b9a5eml3bze.jp

(If I'd thought, I could have used the same seed as before by looking up
 NSEC3PARAM type in DNS; ah well, the change should be harmless, right?)

I'm seeing a very incomplete set of records signed with id=33768.

To make it easier for others to see, and because I didn't want to
reconfig or further perturb bind9.10 on the authoritative master, I just
set one of the secondaries to open zone transfer for this zone.  The
`us0ns.globnix.net` server, which gets NOTIFY updates, has
`allow-transfer { any; };` enabled for `xn--qck5b9a5eml3bze.jp`.

$ host -lva xn--qck5b9a5eml3bze.jp us0ns.globnix.net

There's various bits going into the logfile from default channel.  In
`logging {}` I do have `category "dnssec" { "dnssec_log"; };` but the
file taking that channel is, and always has been, empty.

It's hard to see anything about progress or decisions in signing in the
stuff which is going to the default log stream; there's:

8< cut here >8--
28-May-2014 09:44:36.735 general: info: zone xn--qck5b9a5eml3bze.jp/IN 
(signed): reconfiguring zone keys
28-May-2014 09:44:36.739 general: info: zone xn--qck5b9a5eml3bze.jp/IN 
(signed): next key event: 28-May-2014 10:44:36.735
28-May-2014 10:34:20.108 general: info: received control channel command 
'reload xn--qck5b9a5eml3bze.jp'
28-May-2014 10:34:20.110 general: info: zone xn--qck5b9a5eml3bze.jp/IN 
(unsigned): ixfr-from-differences: unchanged
28-May-2014 10:44:36.737 general: info: zone xn--qck5b9a5eml3bze.jp/IN 
(signed): reconfiguring zone keys
28-May-2014 10:44:36.902 general: info: zone xn--qck5b9a5eml3bze.jp/IN 
(signed): next key event: 28-May-2014 11:44:36.737
28-May-2014 10:44:36.903 notify: info: zone xn--qck5b9a5eml3bze.jp/IN (signed): 
sending notifies (serial 2014011540)
28-May-2014 10:59:28.035 general: info: zone xn--qck5b9a5eml3bze.jp/IN 
(signed): reconfiguring zone keys
28-May-2014 10:59:28.040 general: info: zone xn--qck5b9a5eml3bze.jp/IN 
(signed): next key event: 28-May-2014 11:59:28.035
[...]
28-May-2014 23:59:28.446 general: info: zone xn--qck5b9a5eml3bze.jp/IN 
(signed): reconfiguring zone keys
28-May-2014 23:59:28.451 general: info: zone xn--qck5b9a5eml3bze.jp/IN 
(signed): next key event: 29-May-2014 00:59:28.446
29-May-2014 00:14:03.818 general: info: received control channel command 
'signing -list xn--qck5b9a5eml3bze.jp'
29-May-2014 00:20:51.947 general: info: received control channel command 
'signing -list xn--qck5b9a5eml3bze.jp'
29-May-2014 00:28:51.777 general: info: received control channel command 
'signing -list xn--qck5b9a5eml3bze.jp'
29-May-2014 00:31:43.724 general: info: received control channel command 
'signing -nsec3param 1 0 100 018150bbcb496fae xn--qck5b9a5eml3bze.jp'
29-May-2014 00:31:43.815 general: info: zone xn--qck5b9a5eml3bze.jp/IN 
(signed): zone_addnsec3chain(1,REMOVE,100,AFAC2F795254DCC2)
29-May-2014 00:31:43.815 general: info: zone xn--qck5b9a5eml3bze.jp/IN 
(signed): zone_addnsec3chain(1,CREATE,100,018150BBCB496FAE)
29-May-2014 00:31:43.860 notify: info: zone xn--qck5b9a5eml3bze.jp/IN (signed): 
sending notifies (serial 2014011542)
29-May-2014 00:31:48.871 notify: info: zone xn--qck5b9a5eml3bze.jp/IN (signed): 
sending notifies (serial 2014011544)
8< cut here >8--

The TZ is America/New_York -- it's a mistake, I know why it has
happened, I'm not changing it back to UTC until this issue has been
resolved.

Any thoughts as to what I've messed up, and how, please?
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-use

Re: KSK signing all records; NSEC3 algorithm status?

2014-05-28 Thread Phil Pennock 
On 2014-05-29 at 00:59 -0400, Phil Pennock wrote:
> The new DNSKEY had id=33768 and when I deployed it, Bind signed the SOA
> with it but nothing else.

Bind 9.10 ARM (PDF-only??):
 "However, if the new key is replacing an existing key of the same
  algorithm, then the zone will be re-signed incrementally, with
  signatures from the old key being replaced with signatures from the new
  key as their signature validity periods expire. By default, this
  rollover completes in 30 days, after which it will be safe to remove the
  old key from the DNSKEY RRset."

This is the cause, isn't it?  The KSK/ZSK distinction again is
irrelevant here.  I'm not seeing any way to fix this, while keeping the
current id=53065 KSK.

Is there a way to transition in a timely manner while keeping current
keys?

If not, if I were to use dnssec-settime to set the 53065 key to be
retired in two days and generate a new KSK of same algorithm, what would
the timing be on switching to the new key and getting all the records
updated?  I have a two hour TTL on the DS records in the parent, which
are currently for 53065.

Thanks,
-Phil
___
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

recover missing journal files from running server

2014-07-10 Thread Phil Pennock 
Folks, in a moment of gross stupidity I added "--delete-delay" to an
rsync invocation in a deploy script, to remove master zonefiles from
the server which are no longer needed.  I forgot that the DNSSEC
auto-maintain journal files are in that directory too.

Seeing little things like this:

deleting db.spodhuis.org.signed.jnl
deleting db.spodhuis.org.signed
deleting db.spodhuis.org.jnl
deleting db.spodhuis.org.jbk

worry me.  So, I still have all of the DNSSEC keyfiles (different
directory, and in private git pushed to backup storage anyway).  I still
have a running server instance.

Is there any way to get back the on-disk state files for the
auto-maintained zones, so that I can recover from my mistake cleanly?
(There's about 20 domains).

Using `rndc sync` or `rndc sync spodhuis.org` does not recreate the
journal file.  Log file lines and `rndc zonestatus` below.

What are my options to recover?

Thanks,
-Phil


8< cut here >8--
10-Jul-2014 16:18:49.194 general: info: zone spodhuis.org/IN (signed): next key 
event: 10-Jul-2014 17:18:49.192
[...]
10-Jul-2014 16:27:47.724 general: info: received control channel command 'sync 
spodhuis.org'
10-Jul-2014 16:27:47.724 general: info: sync: dumping zone 'spodhuis.org/IN': 
success
8< cut here >8--

8< cut here >8--
% rndc zonestatus spodhuis.org
name: spodhuis.org
type: master
files: master/db.spodhuis.org
serial: 2014070501
signed serial: 2014070525
nodes: 211
last loaded: Wed, 09 Jul 2014 00:18:47 GMT
secure: yes
inline signing: yes
key maintenance: automatic
next key event: Thu, 10 Jul 2014 17:18:49 GMT
next resign node: _443._tcp.security.spodhuis.org/CNAME
next resign time: Thu, 10 Jul 2014 18:08:35 GMT
dynamic: no
8< cut here >8--


pgpa8H2AGewRy.pgp
Description: PGP signature
___
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: recover missing journal files from running server

2014-07-10 Thread Phil Pennock 
On 2014-07-10 at 12:33 -0400, Phil Pennock wrote:
> Folks, in a moment of gross stupidity I added "--delete-delay" to an
> rsync invocation in a deploy script, to remove master zonefiles from
> the server which are no longer needed.  I forgot that the DNSSEC
> auto-maintain journal files are in that directory too.
> 
> Seeing little things like this:
> 
> deleting db.spodhuis.org.signed.jnl
> deleting db.spodhuis.org.signed
> deleting db.spodhuis.org.jnl
> deleting db.spodhuis.org.jbk
> 
> worry me.  So, I still have all of the DNSSEC keyfiles (different
> directory, and in private git pushed to backup storage anyway).  I still
> have a running server instance.
> 
> Is there any way to get back the on-disk state files for the
> auto-maintained zones, so that I can recover from my mistake cleanly?
> (There's about 20 domains).
> 
> Using `rndc sync` or `rndc sync spodhuis.org` does not recreate the
> journal file.  Log file lines and `rndc zonestatus` below.
> 
> What are my options to recover?

For the archives: I did later solve this problem.

Using `rndc sign $zone` recreated the journal file on disk, with the
correct SOA serial number: the in-memory copy was used to create the SOA
for the new journal.

The important bit was to override the "next key event" by just forcing
an immediate re-signing.  I have since been able to `rndc reconfig` and
then also perform a full restart, and the zones are still serving
correctly.

So even though `named-journalprint $zonefile.signed.jnl` only shows
"del" records for SOAs with serial numbers higher than recorded in the
master zonefile as stored in git, on startup bind reconciles the
zonefile and the journal and works anyway.

(And yes, the fully dynamic zone I had is in a different directory and
is frozen/thaw'd around backup time anyway, so I could still have
recovered that aspect, had the failure occurred there).

Regards,
-Phil


pgp0RP4e70HyI.pgp
Description: PGP signature
___
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