Re: minimal-any on master

[Tony Finch]

Jim Popovitch  wrote:

>
> Hmmm, this is counter to what I've believed all along.  I
> thought it was
> prudent to have key overlap during rollovers.

There are two separate things which you can overlap semi-independently:

* is the key published in the zone?

* is the key active, i.e. being used to generate signatures?

If you want to minimize RRSIG overhead when rolling a ZSK, the process
is basically:

* publish new key, but inactive - old key continues to be published

* wait for changed DNSKEY RRset to propagate everywhere, so that
  validators become ready to trust the new key

* deactivate old key and activate new key - no change to DNSKEY RRset at
  this time, just change how RRSIGs are generated

* wait for zone to be re-signed and for old signatures to expire from
  caches; there will be a mix of old and new RRSIGs on different RRsets,
  but only one RRSIG on each

* unpublish old key

For a KSK the process is:

* add a DS record for the new key, keeping the DS for the old key; the
  new key is not published yet

* wait for the new bigger DS RRset to propagate, so validators are ready
  to trust the new key

* publish and activate the new KSK and unpublish and deactivate the old
  KSK at the same time; both old and new DNSKEY RRsets can be validated
  by the big DS RRset

* wait for the DNSKEY RRset to propagate, so nothing is using the old
  key any more

* remove the old DS record(s) for the old key

That is the process to minimize DNSKEY RRset size, but it involves two
delegation updates; you can alternatively use a bigger DNSKEY RRset and
make only one delegation update.

This is covered in much more detail in
https://tools.ietf.org/html/rfc7583 - the ZSK method above is in section
3.2.1 and the KSK method is in 3.3.2.

Tony.
--
f.anthony.n.finch    http://dotat.at/  -  I xn--
  zr8h punycode

___
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: minimal-any on master

[Jim Popovitch via bind-users]

On Mon, Sep 05, 2016 at 05:12:47PM +0100, Tony Finch wrote:
> Jim Popovitch via bind-users  wrote:
> >
> > Thanks.  Now I'm seeing something slighly different.  I have 3 NS
> > servers, ns{1-3}.domainmail.org.
> >
> > When I first asked 3 days ago I was seeing long ANY repsonses on the
> > master (ns1).  Today I am seeing long ANY responses on ns3 (but not
> > ns1).  O.o
> >
> > for ns in ns1 ns2 ns3; do dig ANY domainmail.org @$ns.domainmail.org|wc -c; 
> > done
> > 591
> > 610
> > 13280
> 
> OK, this is SUBTLE.
> 
> minimal-any is a bit stupid: it just hands out the first RRset it gets
> out of the guts of BIND without any attempt to choose the smallest or
> otherwise choose an RRset consistently. This means you will get different
> answers from different servers depending on how the zone has changed
> recently - especially if there is churn due to DNSSEC re-signing.
> 
> So it is expected that you will get answers of varying sizes. But why such
> a huge variation in this case?
> 
> Well, minimal-any doesn't apply to queries over TCP - you get the full
> unexpurgated ANY response over TCP. So, if you use `dig +tcp` you will get
> the huge answer from all your servers. If you use `dig +ignore` (i.e.
> ignore truncation) you will prevent dig from switching from UDP to TCP, so
> you should get a more reliable indication that minimal-any is actually
> working.
> 
> Now why are you getting a truncated response?
> 
> If I look at the RRsets at the apex of your zone, most of them are pretty
> small, but the DNSKEY RRset is huge. (See script below.) So if your server
> happens to choose the DNSKEY RRset as its response to ANY, that might lead
> to TC and retry over TCP.


Thank you for detailing that Tony, I now have a better understanding.

> 
> Your DNSKEY RRset is huge because you have four keys (two KSKs and two
> ZSKs) and four RRSIGs (one for each key).


I call that "full mesh"!  :-)
 
> You can reduce this a bit by setting dnssec-dnskey-kskonly in named.conf.
> This tells BIND to only use KSKs to sign the DNSKEY RRset, which would
> reduce you from 4 signatures to 2.


Done.  Thank you for suggesting that.

> You can also be careful when setting up your key rollovers so that only
> one key is active at a time, which would reduce you to 1 signature.
 

Hmmm, this is counter to what I've believed all along.  I thought it was 
prudent to have key overlap during rollovers. Or are saying only do ZSK 
rollovers well after the KSK rollover has settled?


> And you can avoid rolling ZSK and KSK at the same time, so you only have 2
> or 3 DNSKEY records.
> 

Yes, the current situation is due to unfortunate timing.

-Jim P.



signature.asc
Description: Digital 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: minimal-any on master

[Tony Finch]

Jim Popovitch via bind-users  wrote:
>
> Thanks.  Now I'm seeing something slighly different.  I have 3 NS
> servers, ns{1-3}.domainmail.org.
>
> When I first asked 3 days ago I was seeing long ANY repsonses on the
> master (ns1).  Today I am seeing long ANY responses on ns3 (but not
> ns1).  O.o
>
> for ns in ns1 ns2 ns3; do dig ANY domainmail.org @$ns.domainmail.org|wc -c; 
> done
> 591
> 610
> 13280

OK, this is SUBTLE.

minimal-any is a bit stupid: it just hands out the first RRset it gets
out of the guts of BIND without any attempt to choose the smallest or
otherwise choose an RRset consistently. This means you will get different
answers from different servers depending on how the zone has changed
recently - especially if there is churn due to DNSSEC re-signing.

So it is expected that you will get answers of varying sizes. But why such
a huge variation in this case?

Well, minimal-any doesn't apply to queries over TCP - you get the full
unexpurgated ANY response over TCP. So, if you use `dig +tcp` you will get
the huge answer from all your servers. If you use `dig +ignore` (i.e.
ignore truncation) you will prevent dig from switching from UDP to TCP, so
you should get a more reliable indication that minimal-any is actually
working.

Now why are you getting a truncated response?

If I look at the RRsets at the apex of your zone, most of them are pretty
small, but the DNSKEY RRset is huge. (See script below.) So if your server
happens to choose the DNSKEY RRset as its response to ANY, that might lead
to TC and retry over TCP.

Your DNSKEY RRset is huge because you have four keys (two KSKs and two
ZSKs) and four RRSIGs (one for each key).

You can reduce this a bit by setting dnssec-dnskey-kskonly in named.conf.
This tells BIND to only use KSKs to sign the DNSKEY RRset, which would
reduce you from 4 signatures to 2.

You can also be careful when setting up your key rollovers so that only
one key is active at a time, which would reduce you to 1 signature.

And you can avoid rolling ZSK and KSK at the same time, so you only have 2
or 3 DNSKEY records.

$ dig +dnssec +tcp domainmail.org any @ns1.domainmail.org |
  awk '!/^;|^$/ { print $4 }' | sort -u |
  while read t; do echo $t;
dig +norec +ignore +dnssec domainmail.org $t @ns1.domainmail.org | grep 
SIZE;
  done
A
;; MSG SIZE  rcvd: 691

;; MSG SIZE  rcvd: 703
DNSKEY
;; MSG SIZE  rcvd: 3407
MX
;; MSG SIZE  rcvd: 696
NS
;; MSG SIZE  rcvd: 729
NSEC
;; MSG SIZE  rcvd: 725
RRSIG
;; MSG SIZE  rcvd: 675
SOA
;; MSG SIZE  rcvd: 722
SPF
;; MSG SIZE  rcvd: 727
TXT
;; MSG SIZE  rcvd: 808

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Northwest Hebrides, Bailey: Cyclonic 5 to 7, becoming southwesterly 7 to
severe gale 9. Rough becoming high or very high. Occasional rain. Moderate or
poor, occasionally good.
___
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: minimal-any on master

[Jim Popovitch via bind-users]

On Mon, Sep 05, 2016 at 09:51:25AM +0100, Tony Finch wrote:
> Jim Popovitch via bind-users  wrote:
> >
> > Should minimal-all (v9.11.0-rc1) work on a master?  My testing shows
> > that it only works on the slave DNS servers.
> 
> Works for me :-) minimal-any is implemented at the point the records are
> being assembled into an answer - it still does all the usual ANY
> processing, but just omits all but the first RRset. So it isn't even aware
> of whether the records are from the cache or authoritative, let alone what
> type of authoritative zone they might be from.
> 

Hmmm.

Thanks.  Now I'm seeing something slighly different.  I have 3 NS servers, 
ns{1-3}.domainmail.org.

When I first asked 3 days ago I was seeing long ANY repsonses on the master 
(ns1).  Today I am seeing long ANY responses on ns3 (but not ns1).  O.o


for ns in ns1 ns2 ns3; do dig ANY domainmail.org @$ns.domainmail.org|wc -c; done
591
610
13280


-Jim P.





signature.asc
Description: Digital 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