Re: [dns-operations] anybody awake over at comcast.net?

2021-02-17 Thread Brett 
We use Validns for exactly that purpose:

http://www.validns.net

Brett

On Tue, 9 Feb 2021 at 18:56, Wessels, Duane via dns-operations
 wrote:
>
>
>
>
> -- Forwarded message --
> From: "Wessels, Duane" 
> To: Matthew Richardson 
> Cc: "dns-operati...@dns-oarc.net" 
> Bcc:
> Date: Tue, 9 Feb 2021 18:53:33 +0000
> Subject: Re:  [dns-operations] anybody awake over at comcast.net?
>
>
> > On Feb 9, 2021, at 9:58 AM, Matthew Richardson  
> > wrote:
> >
> > On Tue, 9 Feb 2021 16:43:20 +, Duane Wessels wrote:-
> >
> >> If you use Nagios or something compatible, there is this:
> >>
> >> http://secure-web.cisco.com/1ZWcEZ_A3D0HVUDh0W30HiqK06_fxVH7k6Y8MQ0xEkq1R7DisrP18NBN1e4yKETi4R0R3tKtYvbgbceXgcgJ9C21mjdIL9Y0Pi_Vi2A0Bec1tUqiBtCl2wuBuf4RT9Knwd995i-JtjkwjqGTjcDaMcEBN2Wd3J0kKflgMjk2Quq2zjxyDzHe1onv98qw0k-KwnjHmEXxC0KV139PzFEJNQuXFh0FvDW6UESHUbtewefOJN2wnn7lvU7iwPnTztW2X_FiaYT56yvFT9z4BFBcAwg/http%3A%2F%2Fdns.measurement-factory.com%2Ftools%2Fnagios-plugins%2Fcheck_zone_rrsig_expiration.html
> >>
> >> But it only checks one RR (default SOA) since it doesn't assume access to 
> >> the whole zone.
> >> That would be a good upgrade, though, to have it axfr the zone and check 
> >> everything.
> >
> > Are there any existing tools which would take a whole zonefile and check
> > the expirations?  In a similar way to (for example) dnssec-verify from
> > Bind.
>
>
> YAZVS: Yet Another Zone Validation Script
>
> https://github.com/verisign/yazvs
>
> It is designed to also show changes between a new and current zone, but you 
> can skip that part with the -x option.
>
> DW
>
>
>
>
>
> ------ Forwarded message --
> From: "Wessels, Duane via dns-operations" 
> To: Matthew Richardson 
> Cc: "dns-operati...@dns-oarc.net" 
> Bcc:
> Date: Tue, 9 Feb 2021 18:53:33 +
> Subject: Re: [dns-operations] anybody awake over at comcast.net?
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] anybody awake over at comcast.net?

2021-02-09 Thread Peterson (AWS), Alec via dns-operations 
--- Begin Message ---
OK fair point, will get with the team and we’ll figure out what skew we’re 
factoring in.  Thanks for that.

Alec

> On Feb 9, 2021, at 7:57 PM, Matt Nordhoff  wrote:
> 
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you can confirm the sender and know the 
> content is safe.
> 
> 
> 
> On Wed, Feb 10, 2021 at 3:47 AM Peterson (AWS), Alec
>  wrote:
>> Hey Matt, sorry we missed your forum post, we do need to stay on top of 
>> those.
>> 
>> There are actually 2 hours of overlap, not 1.  For the zone I just provided, 
>> here is the previous and current RRSIG:
>> 
>> DNSKEY 13 2 3600 2021020901 2021020815 38680 hilander.com. 
>> J5WR2nU1Gl3xI5ehHBsnI7OXiThuYZKc1XpV6brYf85BgurOcZkb5+6eLbsvV+ykODaPrEnEIDu/HRYcaIRrNg==
>> DNSKEY 13 2 3600 2021020909 2021020823 38680 hilander.com. 
>> 735uL43A++phhPv/edwq02zANvAfEsas1j9HM+ghe+t7b6FLCAF6RZfXA9L+TBukYmhIkPiF87GbHDWXmETBNQ==
>> 
>> So when we roll the signature over, the one that we were previously using 
>> still has 2 hours of validity, not 1 hour.  So using your example, we would 
>> roll it over at 2300, not , giving us room for 1 hour of clock skew.  
>> Think that’s reasonable.
>> 
>> Alec
> 
> I haven't looked recently, but when I checked some poor customer's
> domain at 2020-12-31 23:59:59, that wasn't the case. It returned the
> 2020-12-31 15:00:00 - 2021-01-01 01:00:00 records:
> 
> 
> 
> If the record rollover has been moved back one hour, the inception
> should correspondingly be moved back to 06:00:00 / 14:00:00 /
> 22:00:00, though. :-D
> 
>> On Feb 9, 2021, at 7:37 PM, Matt Nordhoff  wrote:
>> 
>> CAUTION: This email originated from outside of the organization. Do not 
>> click links or open attachments unless you can confirm the sender and know 
>> the content is safe.
>> 
>> 
>> 
>> On Wed, Feb 10, 2021 at 1:44 AM Peterson (AWS), Alec via
>> dns-operations  wrote:
>> 
>> +1 for short RRSIG times and the discipline it enforces.  We went down this 
>> path when building DNSSEC for Route 53, ZSK signatures are on the order of 
>> 10 hours:
>> 
>> hilander.com. 3599 IN RRSIG DNSKEY 13 2 3600 2021021009 (
>> 2021020923 38680 hilander.com.
>> 3H3QZt3qC2XbqkbumqsvRVeVrtgJVVRVGC/TZkc7vMuN
>> IdlL/wZrw+qBfYaSOex7dOp2PUP7pwW+NUgCXc2F7Q== )
>> 
>> A bunch of risks with this approach that needs to be mitigated, especially 
>> around static stability in the face of an issue with the ZSK signing 
>> process.  But all solvable.  As part of this we also automated ZSK rotation 
>> (which happens less often, but still on the order of once a week).
>> 
>> 
>> Speaking of which, the DNSKEY RRSIG lifetime should be 11 hours, not
>> 10 hours. The current expiration doesn't allow for client caching plus
>> clock skew. E.g.:
>> 
>> 23:59:59: Recursive resolver queries authoritative servers for
>> hilander.com DNSKEY, gets back record set with TTL 3600, RRSIG
>> inception 15:00:00, expiration 01:00:00.
>> (00:00:00: Authoritative servers switch to new DNSKEY record set, TTL
>> 3600, inception 23:00:00, expiration 09:00:00.)
>> 00:59:58: Validating stub resolver queries recursive resolver for
>> hilander.com DNSKEY. gets back cached record set with TTL 1, RRSIG
>> inception 15:00:00, RRSIG expiration 01:00:00.
>> 
>> If the stub resolver's clock is 3 seconds fast -- 01:00:01 -- and it
>> doesn't make an extra allowance for expired records or clock skew, it
>> will treat the record set as bogus.
>> 
>> (All other records except for DNSKEY are live signed, with the RRSIG
>> expiration set 1 hour after the TTL.)
>> 
>> 
>> 
>> On Feb 8, 2021, at 9:27 PM, Paul Vixie  wrote:
>> 
>> CAUTION: This email originated from outside of the organization. Do not 
>> click links or open attachments unless you can confirm the sender and know 
>> the content is safe.
>> 
>> 
>> 
>> On Mon, Feb 08, 2021 at 01:45:06AM -0500, Viktor Dukhovni wrote:
>> 
>> ...
>> I do not recommend either X.509 certificate or RRSIG lifetimes quite
>> this long.  Shorter lifetimes IMHO promote better discipline.
>> 
>> 
>> for my own zones i think i'm using one year signatures and regenerating them
>> from "cron" once per week -- just to be safe. so, not better discipline 
>> unless
>> you deliberately _live_ on the edge, which i think is an unwise practice.
>> 
>> i expect i'll crib together some bourne shellack to check my whole signature
>> chains and warn me when there's less than 72 hours remaining in any validity
>> period. going into SERVFAIL like this is an operational risk i shouldn't 
>> take.
> --
> Matt Nordhoff


--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] anybody awake over at comcast.net?

2021-02-09 Thread Matt Nordhoff 
On Wed, Feb 10, 2021 at 3:47 AM Peterson (AWS), Alec
 wrote:
> Hey Matt, sorry we missed your forum post, we do need to stay on top of those.
>
> There are actually 2 hours of overlap, not 1.  For the zone I just provided, 
> here is the previous and current RRSIG:
>
> DNSKEY 13 2 3600 2021020901 2021020815 38680 hilander.com. 
> J5WR2nU1Gl3xI5ehHBsnI7OXiThuYZKc1XpV6brYf85BgurOcZkb5+6eLbsvV+ykODaPrEnEIDu/HRYcaIRrNg==
> DNSKEY 13 2 3600 2021020909 2021020823 38680 hilander.com. 
> 735uL43A++phhPv/edwq02zANvAfEsas1j9HM+ghe+t7b6FLCAF6RZfXA9L+TBukYmhIkPiF87GbHDWXmETBNQ==
>
> So when we roll the signature over, the one that we were previously using 
> still has 2 hours of validity, not 1 hour.  So using your example, we would 
> roll it over at 2300, not , giving us room for 1 hour of clock skew.  
> Think that’s reasonable.
>
> Alec

I haven't looked recently, but when I checked some poor customer's
domain at 2020-12-31 23:59:59, that wasn't the case. It returned the
2020-12-31 15:00:00 - 2021-01-01 01:00:00 records:



If the record rollover has been moved back one hour, the inception
should correspondingly be moved back to 06:00:00 / 14:00:00 /
22:00:00, though. :-D

> On Feb 9, 2021, at 7:37 PM, Matt Nordhoff  wrote:
>
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you can confirm the sender and know the 
> content is safe.
>
>
>
> On Wed, Feb 10, 2021 at 1:44 AM Peterson (AWS), Alec via
> dns-operations  wrote:
>
> +1 for short RRSIG times and the discipline it enforces.  We went down this 
> path when building DNSSEC for Route 53, ZSK signatures are on the order of 10 
> hours:
>
> hilander.com. 3599 IN RRSIG DNSKEY 13 2 3600 2021021009 (
> 2021020923 38680 hilander.com.
> 3H3QZt3qC2XbqkbumqsvRVeVrtgJVVRVGC/TZkc7vMuN
> IdlL/wZrw+qBfYaSOex7dOp2PUP7pwW+NUgCXc2F7Q== )
>
> A bunch of risks with this approach that needs to be mitigated, especially 
> around static stability in the face of an issue with the ZSK signing process. 
>  But all solvable.  As part of this we also automated ZSK rotation (which 
> happens less often, but still on the order of once a week).
>
>
> Speaking of which, the DNSKEY RRSIG lifetime should be 11 hours, not
> 10 hours. The current expiration doesn't allow for client caching plus
> clock skew. E.g.:
>
> 23:59:59: Recursive resolver queries authoritative servers for
> hilander.com DNSKEY, gets back record set with TTL 3600, RRSIG
> inception 15:00:00, expiration 01:00:00.
> (00:00:00: Authoritative servers switch to new DNSKEY record set, TTL
> 3600, inception 23:00:00, expiration 09:00:00.)
> 00:59:58: Validating stub resolver queries recursive resolver for
> hilander.com DNSKEY. gets back cached record set with TTL 1, RRSIG
> inception 15:00:00, RRSIG expiration 01:00:00.
>
> If the stub resolver's clock is 3 seconds fast -- 01:00:01 -- and it
> doesn't make an extra allowance for expired records or clock skew, it
> will treat the record set as bogus.
>
> (All other records except for DNSKEY are live signed, with the RRSIG
> expiration set 1 hour after the TTL.)
>
> 
>
> On Feb 8, 2021, at 9:27 PM, Paul Vixie  wrote:
>
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you can confirm the sender and know the 
> content is safe.
>
>
>
> On Mon, Feb 08, 2021 at 01:45:06AM -0500, Viktor Dukhovni wrote:
>
> ...
> I do not recommend either X.509 certificate or RRSIG lifetimes quite
> this long.  Shorter lifetimes IMHO promote better discipline.
>
>
> for my own zones i think i'm using one year signatures and regenerating them
> from "cron" once per week -- just to be safe. so, not better discipline unless
> you deliberately _live_ on the edge, which i think is an unwise practice.
>
> i expect i'll crib together some bourne shellack to check my whole signature
> chains and warn me when there's less than 72 hours remaining in any validity
> period. going into SERVFAIL like this is an operational risk i shouldn't take.
-- 
Matt Nordhoff

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] anybody awake over at comcast.net?

2021-02-09 Thread Peterson (AWS), Alec via dns-operations 
--- Begin Message ---
Hey Matt, sorry we missed your forum post, we do need to stay on top of those.

There are actually 2 hours of overlap, not 1.  For the zone I just provided, 
here is the previous and current RRSIG:

DNSKEY 13 2 3600 2021020901 2021020815 38680 
hilander.com. 
J5WR2nU1Gl3xI5ehHBsnI7OXiThuYZKc1XpV6brYf85BgurOcZkb5+6eLbsvV+ykODaPrEnEIDu/HRYcaIRrNg==
DNSKEY 13 2 3600 2021020909 2021020823 38680 
hilander.com. 
735uL43A++phhPv/edwq02zANvAfEsas1j9HM+ghe+t7b6FLCAF6RZfXA9L+TBukYmhIkPiF87GbHDWXmETBNQ==

So when we roll the signature over, the one that we were previously using still 
has 2 hours of validity, not 1 hour.  So using your example, we would roll it 
over at 2300, not , giving us room for 1 hour of clock skew.  Think that’s 
reasonable.

Alec

On Feb 9, 2021, at 7:37 PM, Matt Nordhoff 
mailto:mnordh...@gmail.com>> wrote:

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.



On Wed, Feb 10, 2021 at 1:44 AM Peterson (AWS), Alec via
dns-operations 
mailto:dns-operati...@dns-oarc.net>> wrote:
+1 for short RRSIG times and the discipline it enforces.  We went down this 
path when building DNSSEC for Route 53, ZSK signatures are on the order of 10 
hours:

hilander.com. 3599 IN RRSIG DNSKEY 13 2 3600 
2021021009 (
2021020923 38680 hilander.com.
3H3QZt3qC2XbqkbumqsvRVeVrtgJVVRVGC/TZkc7vMuN
IdlL/wZrw+qBfYaSOex7dOp2PUP7pwW+NUgCXc2F7Q== )

A bunch of risks with this approach that needs to be mitigated, especially 
around static stability in the face of an issue with the ZSK signing process.  
But all solvable.  As part of this we also automated ZSK rotation (which 
happens less often, but still on the order of once a week).

Speaking of which, the DNSKEY RRSIG lifetime should be 11 hours, not
10 hours. The current expiration doesn't allow for client caching plus
clock skew. E.g.:

23:59:59: Recursive resolver queries authoritative servers for
hilander.com DNSKEY, gets back record set with TTL 3600, 
RRSIG
inception 15:00:00, expiration 01:00:00.
(00:00:00: Authoritative servers switch to new DNSKEY record set, TTL
3600, inception 23:00:00, expiration 09:00:00.)
00:59:58: Validating stub resolver queries recursive resolver for
hilander.com DNSKEY. gets back cached record set with TTL 
1, RRSIG
inception 15:00:00, RRSIG expiration 01:00:00.

If the stub resolver's clock is 3 seconds fast -- 01:00:01 -- and it
doesn't make an extra allowance for expired records or clock skew, it
will treat the record set as bogus.

(All other records except for DNSKEY are live signed, with the RRSIG
expiration set 1 hour after the TTL.)



On Feb 8, 2021, at 9:27 PM, Paul Vixie 
mailto:p...@redbarn.org>> wrote:

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.



On Mon, Feb 08, 2021 at 01:45:06AM -0500, Viktor Dukhovni wrote:

...
I do not recommend either X.509 certificate or RRSIG lifetimes quite
this long.  Shorter lifetimes IMHO promote better discipline.


for my own zones i think i'm using one year signatures and regenerating them
from "cron" once per week -- just to be safe. so, not better discipline unless
you deliberately _live_ on the edge, which i think is an unwise practice.

i expect i'll crib together some bourne shellack to check my whole signature
chains and warn me when there's less than 72 hours remaining in any validity
period. going into SERVFAIL like this is an operational risk i shouldn't take.
--
Matt Nordhoff

--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] anybody awake over at comcast.net?

2021-02-09 Thread Matt Nordhoff 
On Wed, Feb 10, 2021 at 1:44 AM Peterson (AWS), Alec via
dns-operations  wrote:
> +1 for short RRSIG times and the discipline it enforces.  We went down this 
> path when building DNSSEC for Route 53, ZSK signatures are on the order of 10 
> hours:
>
> hilander.com. 3599 IN RRSIG DNSKEY 13 2 3600 2021021009 (
> 2021020923 38680 hilander.com.
> 3H3QZt3qC2XbqkbumqsvRVeVrtgJVVRVGC/TZkc7vMuN
> IdlL/wZrw+qBfYaSOex7dOp2PUP7pwW+NUgCXc2F7Q== )
>
> A bunch of risks with this approach that needs to be mitigated, especially 
> around static stability in the face of an issue with the ZSK signing process. 
>  But all solvable.  As part of this we also automated ZSK rotation (which 
> happens less often, but still on the order of once a week).

Speaking of which, the DNSKEY RRSIG lifetime should be 11 hours, not
10 hours. The current expiration doesn't allow for client caching plus
clock skew. E.g.:

23:59:59: Recursive resolver queries authoritative servers for
hilander.com DNSKEY, gets back record set with TTL 3600, RRSIG
inception 15:00:00, expiration 01:00:00.
(00:00:00: Authoritative servers switch to new DNSKEY record set, TTL
3600, inception 23:00:00, expiration 09:00:00.)
00:59:58: Validating stub resolver queries recursive resolver for
hilander.com DNSKEY. gets back cached record set with TTL 1, RRSIG
inception 15:00:00, RRSIG expiration 01:00:00.

If the stub resolver's clock is 3 seconds fast -- 01:00:01 -- and it
doesn't make an extra allowance for expired records or clock skew, it
will treat the record set as bogus.

(All other records except for DNSKEY are live signed, with the RRSIG
expiration set 1 hour after the TTL.)



> On Feb 8, 2021, at 9:27 PM, Paul Vixie  wrote:
>
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you can confirm the sender and know the 
> content is safe.
>
>
>
> On Mon, Feb 08, 2021 at 01:45:06AM -0500, Viktor Dukhovni wrote:
>
> ...
> I do not recommend either X.509 certificate or RRSIG lifetimes quite
> this long.  Shorter lifetimes IMHO promote better discipline.
>
>
> for my own zones i think i'm using one year signatures and regenerating them
> from "cron" once per week -- just to be safe. so, not better discipline unless
> you deliberately _live_ on the edge, which i think is an unwise practice.
>
> i expect i'll crib together some bourne shellack to check my whole signature
> chains and warn me when there's less than 72 hours remaining in any validity
> period. going into SERVFAIL like this is an operational risk i shouldn't take.
-- 
Matt Nordhoff

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] anybody awake over at comcast.net?

2021-02-09 Thread Peterson (AWS), Alec via dns-operations 
--- Begin Message ---
+1 for short RRSIG times and the discipline it enforces.  We went down this 
path when building DNSSEC for Route 53, ZSK signatures are on the order of 10 
hours:

hilander.com. 3599 IN RRSIG DNSKEY 13 2 3600 
2021021009 (
2021020923 38680 hilander.com.
3H3QZt3qC2XbqkbumqsvRVeVrtgJVVRVGC/TZkc7vMuN
IdlL/wZrw+qBfYaSOex7dOp2PUP7pwW+NUgCXc2F7Q== )

A bunch of risks with this approach that needs to be mitigated, especially 
around static stability in the face of an issue with the ZSK signing process.  
But all solvable.  As part of this we also automated ZSK rotation (which 
happens less often, but still on the order of once a week).

On Feb 8, 2021, at 9:27 PM, Paul Vixie 
mailto:p...@redbarn.org>> wrote:

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.



On Mon, Feb 08, 2021 at 01:45:06AM -0500, Viktor Dukhovni wrote:
...
I do not recommend either X.509 certificate or RRSIG lifetimes quite
this long.  Shorter lifetimes IMHO promote better discipline.

for my own zones i think i'm using one year signatures and regenerating them
from "cron" once per week -- just to be safe. so, not better discipline unless
you deliberately _live_ on the edge, which i think is an unwise practice.

i expect i'll crib together some bourne shellack to check my whole signature
chains and warn me when there's less than 72 hours remaining in any validity
period. going into SERVFAIL like this is an operational risk i shouldn't take.

--
Paul Vixie
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] anybody awake over at comcast.net?

2021-02-09 Thread Peterson (AWS), Alec via dns-operations 
--- Begin Message ---
+1 for short RRSIG times and the discipline it enforces.  We went down this 
path when building DNSSEC for Route 53, ZSK signatures are on the order of 10 
hours:

hilander.com. 3599 IN RRSIG DNSKEY 13 2 3600 
2021021009 (
2021020923 38680 hilander.com.
3H3QZt3qC2XbqkbumqsvRVeVrtgJVVRVGC/TZkc7vMuN
IdlL/wZrw+qBfYaSOex7dOp2PUP7pwW+NUgCXc2F7Q== )

A bunch of risks with this approach that needs to be mitigated, especially 
around static stability in the face of an issue with the ZSK signing process.  
But all solvable.  As part of this we also automated ZSK rotation (which 
happens less often, but still on the order of once a week).

On Feb 8, 2021, at 9:27 PM, Paul Vixie 
mailto:p...@redbarn.org>> wrote:

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.



On Mon, Feb 08, 2021 at 01:45:06AM -0500, Viktor Dukhovni wrote:
...
I do not recommend either X.509 certificate or RRSIG lifetimes quite
this long.  Shorter lifetimes IMHO promote better discipline.

for my own zones i think i'm using one year signatures and regenerating them
from "cron" once per week -- just to be safe. so, not better discipline unless
you deliberately _live_ on the edge, which i think is an unwise practice.

i expect i'll crib together some bourne shellack to check my whole signature
chains and warn me when there's less than 72 hours remaining in any validity
period. going into SERVFAIL like this is an operational risk i shouldn't take.

--
Paul Vixie
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] anybody awake over at comcast.net?

2021-02-09 Thread Viktor Dukhovni 
On Tue, Feb 09, 2021 at 06:57:21PM +, Matthew Richardson wrote:

> >My Perl script (below) just checks that none of the RRSIGs are expiring
> >too soon.  If some RRset is not signed at all, that's not detected
> >presently, but should be easy to add.
> 
> That is most useful - thank you!
> 
> My existing monitoring does feature a daily "dnssec-verify" of each
> zonefile accessed via AXFR.  I hope this would detect any unsigned RRset.
> If so, would simply parsing the zonefile to get each RRSIG with its expiry
> (ie not bothering with other record types) check everything was in order?

Yes, just parsing the presentation form of the RRSIGs should do it.

> >That said, if "dnssec-verify" had a parameter to set a minimum remaining
> >signature time, I wouldn't need the Perl script.
> 
> A most splendid suggestion!  :-)

Perhaps some of the ISC folks are reading this thread, and would
consider this a feature request.  Otherwise, I might need to find the
website for opening feature request tickets.

-- 
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] anybody awake over at comcast.net?

2021-02-09 Thread Matthew Richardson 
On Tue, 9 Feb 2021 13:19:02 -0500, Viktor Dukhovni wrote:-

>My Perl script (below) just checks that none of the RRSIGs are expiring
>too soon.  If some RRset is not signed at all, that's not detected
>presently, but should be easy to add.

That is most useful - thank you!

My existing monitoring does feature a daily "dnssec-verify" of each
zonefile accessed via AXFR.  I hope this would detect any unsigned RRset.
If so, would simply parsing the zonefile to get each RRSIG with its expiry
(ie not bothering with other record types) check everything was in order?

>That said, if "dnssec-verify" had a parameter to set a minimum remaining
>signature time, I wouldn't need the Perl script.

A most splendid suggestion!  :-)

Best wishes,
Matthew
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] anybody awake over at comcast.net?

2021-02-09 Thread Wessels, Duane via dns-operations 
--- Begin Message ---


> On Feb 9, 2021, at 9:58 AM, Matthew Richardson  
> wrote:
> 
> On Tue, 9 Feb 2021 16:43:20 +, Duane Wessels wrote:-
> 
>> If you use Nagios or something compatible, there is this:
>> 
>> http://secure-web.cisco.com/1ZWcEZ_A3D0HVUDh0W30HiqK06_fxVH7k6Y8MQ0xEkq1R7DisrP18NBN1e4yKETi4R0R3tKtYvbgbceXgcgJ9C21mjdIL9Y0Pi_Vi2A0Bec1tUqiBtCl2wuBuf4RT9Knwd995i-JtjkwjqGTjcDaMcEBN2Wd3J0kKflgMjk2Quq2zjxyDzHe1onv98qw0k-KwnjHmEXxC0KV139PzFEJNQuXFh0FvDW6UESHUbtewefOJN2wnn7lvU7iwPnTztW2X_FiaYT56yvFT9z4BFBcAwg/http%3A%2F%2Fdns.measurement-factory.com%2Ftools%2Fnagios-plugins%2Fcheck_zone_rrsig_expiration.html
>> 
>> But it only checks one RR (default SOA) since it doesn't assume access to 
>> the whole zone.
>> That would be a good upgrade, though, to have it axfr the zone and check 
>> everything.
> 
> Are there any existing tools which would take a whole zonefile and check
> the expirations?  In a similar way to (for example) dnssec-verify from
> Bind.


YAZVS: Yet Another Zone Validation Script

https://github.com/verisign/yazvs

It is designed to also show changes between a new and current zone, but you can 
skip that part with the -x option.

DW




smime.p7s
Description: S/MIME cryptographic signature
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] anybody awake over at comcast.net?

2021-02-09 Thread Viktor Dukhovni 
On Tue, Feb 09, 2021 at 05:58:08PM +, Matthew Richardson wrote:

> >But it only checks one RR (default SOA) since it doesn't assume access to 
> >the whole zone.
> >That would be a good upgrade, though, to have it axfr the zone and check 
> >everything.
> 
> Are there any existing tools which would take a whole zonefile and check
> the expirations?  In a similar way to (for example) dnssec-verify from
> Bind.

My Perl script (below) just checks that none of the RRSIGs are expiring
too soon.  If some RRset is not signed at all, that's not detected
presently, but should be easy to add.

named-compilezone -i local -jD -f raw -o - $zone $db 2>/dev/null |
perl -MPOSIX -lane '
BEGIN {
@nsec = () # NSEC signed zones, rest assumed NSEC3
($domain, $maxdays) = splice(@ARGV, 0, 2);
$now = time();
# Expect at least DNSKEY and NS RRsets
for (qw(DNSKEY NS)) { $want->{"IN"}->{$_}->{$domain} = 1; }
if (!grep { $domain eq "$_" } @nsec) {
# Expect NSEC3PARAM in non-NSEC zones
for (qw(MX NSEC3PARAM)) { $want->{"IN"}->{$_}->{$domain} = 
1; }
}
}
($owner, $ttl, $class, $rrtype, @rdata) = @F;
next if $rrtype ne "RRSIG";
($sigtype, $alg, $labels, $maxtll, $expiration, $inception) = 
@rdata;
$expiration =~ m{^(\d\d\d\d)(\d\d)(\d\d)(\d\d)(\d\d)(\d\d)$}
or die "Malformed expiration $owner $sigtype: $expiration\n";
$s = POSIX::mktime($6, $5, $4, $3, $2 - 1, $1 - 1900);
$d = ($s - $now) / 86400;
if ($d < $maxdays) {
warn sprintf("Signature of $owner $class $sigtype expires in 
%.2f days\n", $d);
}
$owner =~ s/.\K\.$//;
delete $want->{$class}->{$sigtype}->{lc($owner)};
END {
while (($class, $vc) = each %$want) {
while (($rrtype, $vr) = each %$vc) {
while (($domain, $dummy) = each %$vr) {
warn "No signature found for $domain $class 
$rrtype\n"
}
}
}
}
' "$zone" "$maxdays"

That said, if "dnssec-verify" had a parameter to set a minimum remaining
signature time, I wouldn't need the Perl script.

-- 
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] anybody awake over at comcast.net?

2021-02-09 Thread Matthew Richardson 
On Tue, 9 Feb 2021 16:43:20 +, Duane Wessels wrote:-

>If you use Nagios or something compatible, there is this:
>
>http://dns.measurement-factory.com/tools/nagios-plugins/check_zone_rrsig_expiration.html
>
>But it only checks one RR (default SOA) since it doesn't assume access to the 
>whole zone.
>That would be a good upgrade, though, to have it axfr the zone and check 
>everything.

Are there any existing tools which would take a whole zonefile and check
the expirations?  In a similar way to (for example) dnssec-verify from
Bind.

Best wishes,
Matthew
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] anybody awake over at comcast.net?

2021-02-09 Thread Wessels, Duane via dns-operations 
--- Begin Message ---


> On Feb 8, 2021, at 9:27 PM, Paul Vixie  wrote:
> 
> i expect i'll crib together some bourne shellack to check my whole signature
> chains and warn me when there's less than 72 hours remaining in any validity
> period. going into SERVFAIL like this is an operational risk i shouldn't take.

If you use Nagios or something compatible, there is this:

http://dns.measurement-factory.com/tools/nagios-plugins/check_zone_rrsig_expiration.html

But it only checks one RR (default SOA) since it doesn't assume access to the 
whole zone.
That would be a good upgrade, though, to have it axfr the zone and check 
everything.

DW



smime.p7s
Description: S/MIME cryptographic signature
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] anybody awake over at comcast.net?

2021-02-09 Thread Wessels, Duane via dns-operations 
--- Begin Message ---


> On Feb 8, 2021, at 9:27 PM, Paul Vixie  wrote:
> 
> i expect i'll crib together some bourne shellack to check my whole signature
> chains and warn me when there's less than 72 hours remaining in any validity
> period. going into SERVFAIL like this is an operational risk i shouldn't take.

If you use Nagios or something compatible, there is this:

http://dns.measurement-factory.com/tools/nagios-plugins/check_zone_rrsig_expiration.html

But it only checks one RR (default SOA) since it doesn't assume access to the 
whole zone.
That would be a good upgrade, though, to have it axfr the zone and check 
everything.

DW



smime.p7s
Description: S/MIME cryptographic signature
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] anybody awake over at comcast.net?

2021-02-09 Thread Casey Deccio 

> On Feb 9, 2021, at 12:33 AM, Viktor Dukhovni  wrote:
> 
> checks that every signature in every signed zone
> is at least 3.14 days away from expiration

3.14 sounds a little too irrational to me... :)

Casey___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] anybody awake over at comcast.net?

2021-02-08 Thread Viktor Dukhovni 
On Tue, Feb 09, 2021 at 05:27:01AM +, Paul Vixie wrote:

> On Mon, Feb 08, 2021 at 01:45:06AM -0500, Viktor Dukhovni wrote:
> > ...
> > I do not recommend either X.509 certificate or RRSIG lifetimes quite
> > this long.  Shorter lifetimes IMHO promote better discipline.
> 
> for my own zones i think i'm using one year signatures and regenerating them
> from "cron" once per week -- just to be safe. so, not better discipline unless
> you deliberately _live_ on the edge, which i think is an unwise practice.
> 
> i expect i'll crib together some bourne shellack to check my whole signature
> chains and warn me when there's less than 72 hours remaining in any validity
> period. going into SERVFAIL like this is an operational risk i shouldn't take.

I have BIND 9 doing automatic signing, with 14-day validity, and a
nightly cron job that checks that every signature in every signed zone
is at least 3.14 days away from expiration, that all NS records match
glue records (as appropriate).

In older BIND releases I'd occasionally find that automatic signing
stopped, when the signatures were getting to close to expiring,  and
I'd get it going again (reload or resign the zone).  Haven't seen
that happen in some time now.  The underlying issues appear to have
been resolved.

Though my zone hardly changes, I don't sign commitments to accept one
year old data as valid.  And with "danebot" now in use, I'll be rolling
the TLSA RRs more frequently, with old keys not hanging around signed
for more than 14 days.

-- 
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] anybody awake over at comcast.net?

2021-02-08 Thread Paul Vixie 
On Mon, Feb 08, 2021 at 01:45:06AM -0500, Viktor Dukhovni wrote:
> ...
> I do not recommend either X.509 certificate or RRSIG lifetimes quite
> this long.  Shorter lifetimes IMHO promote better discipline.

for my own zones i think i'm using one year signatures and regenerating them
from "cron" once per week -- just to be safe. so, not better discipline unless
you deliberately _live_ on the edge, which i think is an unwise practice.

i expect i'll crib together some bourne shellack to check my whole signature
chains and warn me when there's less than 72 hours remaining in any validity
period. going into SERVFAIL like this is an operational risk i shouldn't take.

-- 
Paul Vixie
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] anybody awake over at comcast.net?

2021-02-08 Thread Viktor Dukhovni 
On Mon, Feb 08, 2021 at 01:45:06AM -0500, Viktor Dukhovni wrote:

> The inception was 124 days in the past, so this is a 6 month RRSIG
> validity, which I think is long enough to increase the odds of
> complacency.  If the RRSIG lifetime were only 30 days or less,
> this would more likely have been subject to well-oiled automation.

Well, 4 months actually, but still too long IMHO...

> I do not recommend either X.509 certificate or RRSIG lifetimes quite
> this long.  Shorter lifetimes IMHO promote better discipline.

-- 
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] anybody awake over at comcast.net?

2021-02-07 Thread Viktor Dukhovni 
On Sun, Feb 07, 2021 at 10:22:49PM -0800, Paul Vixie wrote:

> my IPv6 PTRs are failing, and like last time, it's a signature
> expiration upstream of my zone:
> 
> > https://dnsviz.net/d/3.5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.9.5.5.0.1.0.0.2.ip6.arpa/dnssec/

Just one crucial expired RRSIG, the KSK "self-signagure" of the DNSKEY
RRset of "9.5.5.0.1.0.0.2.ip6.arpa".  Deprecation of algorithm 5 aside,
everything else looks OK.

But this does suggest lack of monitoring of this particular reverse
zone.  With the RRSIG 4 days in the past, this appears to have been
overlooked.

The inception was 124 days in the past, so this is a 6 month RRSIG
validity, which I think is long enough to increase the odds of
complacency.  If the RRSIG lifetime were only 30 days or less,
this would more likely have been subject to well-oiled automation.

I do not recommend either X.509 certificate or RRSIG lifetimes quite
this long.  Shorter lifetimes IMHO promote better discipline.

-- 
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] anybody awake over at comcast.net?

2021-02-07 Thread Paul Vixie 
my IPv6 PTRs are failing, and like last time, it's a signature
expiration upstream of my zone:

> 5.0.1.0.0.2.ip6.arpa to 9.5.5.0.1.0.0.2.ip6.arpa: No valid RRSIGs made by a 
> key corresponding to a DS RR were found covering the DNSKEY RRset, resulting 
> in no secure entry point (SEP) into the zone. (68.87.68.244, 68.87.72.244, 
> 68.87.76.228, 68.87.85.132, 69.252.250.103, 2001:558:1004:7:68:87:85:132, 
> 2001:558:100a:5:68:87:68:244, 2001:558:100e:5:68:87:72:244, 
> 2001:558:1014:c:68:87:76:228, 2001:558:fe23:8:69:252:250:103, 
> UDP_-_EDNS0_4096_D_KN)
> RRSIG 9.5.5.0.1.0.0.2.ip6.arpa/DNSKEY alg 5, id 47242: The Signature 
> Expiration field of the RRSIG RR (2021-02-03 13:23:52+00:00) is 4 days in the 
> past.
> RRSIG 9.5.5.0.1.0.0.2.ip6.arpa/DNSKEY alg 5, id 47242: The Signature 
> Expiration field of the RRSIG RR (2021-02-03 13:23:52+00:00) is 4 days in the 
> past.

see also a lot of warnings about signing alg 5 and digest alg 1:

> https://dnsviz.net/d/3.5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.9.5.5.0.1.0.0.2.ip6.arpa/dnssec/
uptime needed.

vixie

-- 
Are you in?   https://labs.fsi.io/
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations