Subject: [DNSOP] watching for signature expiration in zones you don't sign

From: Joe Abley <[email-masked]>
Date: Thu, 2 Jun 2011 13:02:27 +0300

Hi all,

I've been poking about a bit in other signed zones looking for impending signature expirations. I've been doing this mainly because we sign a lot of zones and have had at least one accident in the past, but this also seems like something that is worth knowing if you're the operator of a validator and you want to be able to prepare for impending signature expiration in zones that are otherwise going to cause you helpdesk problems.

See attached script for an example of what I have been doing.

I have realised, however, that I can't tell whether a signature that is (say) going to expire in under three days is a cause for concern, or whether it's normal operations and something I should expect to be replaced as part of normal operations.

This boils down to there being no way for a zone operator to publish their normal signature replacement policy in a way that I can obtain in a simple way. Sometimes that information is present in a DPS, but often there is no DPS to be found, sometimes there's a DPS but it doesn't contain that level of detail, and in any case this is all far too manual for an automated check script.

Is there perhaps value in finding a mechanism by which zone operators can publish information in their zones which gives guidance as to what the normal limits for signature expiration ought to be?

  $ORIGIN HOPCOUNT.CA.
  @ RRSIGPOLICY DNSKEY <min planned remaining signature validity> <max planned remaining signature validity>
  @ RRSIGPOLICY SOA ....

or something?

Joe

wifi-216-217:~]% ./sigexpire.sh
2011-06-01 15:30:41 UTC ---------- right now -----------------------------
2011-06-02 15:30:41 UTC ---------- 1 day from now ------------------------
2011-06-03 15:30:41 UTC ---------- 2 days from now -----------------------
2011-06-03 18:25:33 UTC signature over COM. DNSKEY expires
2011-06-04 15:30:41 UTC ---------- 3 days from now -----------------------
2011-06-04 18:02:19 UTC signature over VIP.ICANN.ORG. DNSKEY expires
2011-06-04 18:02:19 UTC signature over VIP.ICANN.ORG. DNSKEY expires
2011-06-05 15:30:41 UTC ---------- 4 days from now -----------------------
2011-06-05 16:00:23 UTC signature over GOV. DNSKEY expires
2011-06-06 04:00:23 UTC signature over GOV. SOA expires
2011-06-06 15:30:41 UTC ---------- 5 days from now -----------------------
2011-06-06 16:38:57 UTC signature over NET. DNSKEY expires
2011-06-06 19:28:05 UTC signature over EDU. DNSKEY expires
2011-06-07 06:21:17 UTC signature over DK. DNSKEY expires
2011-06-07 08:00:01 UTC signature over EU. DNSKEY expires
2011-06-07 08:00:01 UTC signature over EU. DNSKEY expires
2011-06-07 08:00:01 UTC signature over EU. DNSKEY expires
2011-06-07 09:09:09 UTC signature over CH. DNSKEY expires
2011-06-07 09:09:09 UTC signature over LI. DNSKEY expires
2011-06-07 15:30:41 UTC ---------- 6 days from now -----------------------
2011-06-08 00:00:00 UTC signature over . SOA expires
2011-06-08 00:00:00 UTC signature over ARPA. SOA expires
2011-06-08 06:00:00 UTC signature over DE. SOA expires
2011-06-08 09:00:00 UTC signature over BR. SOA expires
2011-06-08 09:02:13 UTC signature over EU. SOA expires
2011-06-08 09:02:13 UTC signature over EU. SOA expires
2011-06-08 09:16:26 UTC signature over VIP.ICANN.ORG. SOA expires
2011-06-08 11:23:03 UTC signature over BE. DNSKEY expires
2011-06-08 14:34:51 UTC signature over XN--DEBA0AD. DNSKEY expires
2011-06-08 14:38:20 UTC signature over XN--0ZWM56D. SOA expires
2011-06-08 14:38:54 UTC signature over IANA.ORG. SOA expires
2011-06-08 14:38:54 UTC signature over IP6-SERVERS.ARPA. DNSKEY expires
2011-06-08 14:38:54 UTC signature over XN--G6W251D. DNSKEY expires
2011-06-08 14:50:18 UTC signature over ICANN.ORG. SOA expires
2011-06-08 14:57:44 UTC signature over IP6.ARPA. DNSKEY expires
2011-06-08 14:59:29 UTC signature over XN--9T4B11YI5A. SOA expires
2011-06-08 15:12:05 UTC signature over URI.ARPA. SOA expires
2011-06-08 15:14:51 UTC signature over COM. SOA expires
2011-06-08 15:15:06 UTC signature over EDU. SOA expires
2011-06-08 15:18:24 UTC signature over NET. SOA expires
2011-06-08 15:23:13 UTC signature over XN--ZCKZAH. SOA expires
2011-06-08 15:30:41 UTC ---------- 7 days from now -----------------------
2011-06-08 15:40:41 UTC signature over IN-ADDR-SERVERS.ARPA. SOA expires
2011-06-08 16:02:53 UTC signature over IN-ADDR.ARPA. SOA expires
2011-06-08 16:02:53 UTC signature over XN--HLCJ6AYA9ESC7A. SOA expires
2011-06-08 16:22:55 UTC signature over XN--HGBK6AJ7F53BBA. DNSKEY expires
2011-06-08 17:12:02 UTC signature over URI.ARPA. DNSKEY expires
2011-06-08 17:47:06 UTC signature over URN.ARPA. SOA expires
2011-06-08 18:26:30 UTC signature over DK. SOA expires
2011-06-08 18:29:41 UTC signature over XN--JXALPDLP. DNSKEY expires
2011-06-08 18:46:03 UTC signature over IRIS.ARPA. SOA expires
2011-06-08 19:07:26 UTC signature over URN.ARPA. DNSKEY expires
2011-06-08 19:58:19 UTC signature over IANA.ORG. DNSKEY expires
2011-06-08 20:14:20 UTC signature over IN-ADDR-SERVERS.ARPA. DNSKEY expires
2011-06-08 20:19:01 UTC signature over XN--KGBECHTV. SOA expires
2011-06-08 20:23:40 UTC signature over XN--DEBA0AD. SOA expires
2011-06-08 21:00:28 UTC signature over XN--11B5BS3A9AJ6G. SOA expires
2011-06-08 21:23:22 UTC signature over XN--JXALPDLP. SOA expires
2011-06-08 21:28:57 UTC signature over IP6.ARPA. SOA expires
2011-06-08 21:52:46 UTC signature over XN--11B5BS3A9AJ6G. DNSKEY expires
2011-06-08 22:06:53 UTC signature over IRIS.ARPA. DNSKEY expires
2011-06-08 22:26:09 UTC signature over XN--ZCKZAH. DNSKEY expires
2011-06-08 23:54:38 UTC signature over ICANN.ORG. DNSKEY expires
2011-06-08 23:58:18 UTC signature over XN--KGBECHTV. DNSKEY expires
2011-06-08 23:59:30 UTC signature over XN--80AKHBYKNJ4F. SOA expires
2011-06-09 00:24:19 UTC signature over IN-ADDR.ARPA. DNSKEY expires
2011-06-09 00:24:19 UTC signature over XN--HLCJ6AYA9ESC7A. DNSKEY expires
2011-06-09 00:32:02 UTC signature over IP6-SERVERS.ARPA. SOA expires
2011-06-09 00:32:02 UTC signature over XN--G6W251D. SOA expires
2011-06-09 01:25:10 UTC signature over XN--80AKHBYKNJ4F. DNSKEY expires
2011-06-09 01:28:57 UTC signature over XN--0ZWM56D. DNSKEY expires
2011-06-09 01:44:31 UTC signature over XN--9T4B11YI5A. DNSKEY expires
2011-06-09 02:16:57 UTC signature over XN--HGBK6AJ7F53BBA. SOA expires
2011-06-09 04:47:12 UTC signature over MUSEUM. DNSKEY expires
2011-06-09 04:47:12 UTC signature over MUSEUM. DNSKEY expires
2011-06-09 05:53:12 UTC signature over CAT. DNSKEY expires
2011-06-09 15:30:42 UTC ---------- 8 days from now -----------------------
2011-06-10 09:00:00 UTC signature over BR. DNSKEY expires
2011-06-10 15:30:42 UTC ---------- 9 days from now -----------------------
2011-06-11 09:01:45 UTC signature over BE. SOA expires
2011-06-11 20:02:44 UTC signature over SE. DNSKEY expires
2011-06-12 17:32:10 UTC signature over CZ. DNSKEY expires
2011-06-13 04:02:44 UTC signature over SE. DNSKEY expires
2011-06-13 04:18:16 UTC signature over CZ. DNSKEY expires
2011-06-13 09:43:58 UTC signature over CZ. SOA expires
2011-06-14 04:35:53 UTC signature over LU. DNSKEY expires
2011-06-14 08:20:20 UTC signature over FI. DNSKEY expires
2011-06-14 10:39:30 UTC signature over SE. SOA expires
2011-06-14 17:10:30 UTC signature over LU. SOA expires
2011-06-14 23:18:40 UTC signature over NL. DNSKEY expires
2011-06-14 23:59:59 UTC signature over . DNSKEY expires
2011-06-14 23:59:59 UTC signature over ARPA. DNSKEY expires
2011-06-15 04:48:19 UTC signature over UK. SOA expires
2011-06-15 06:53:11 UTC signature over CAT. SOA expires
2011-06-15 10:48:19 UTC signature over UK. DNSKEY expires
2011-06-15 11:47:13 UTC signature over MUSEUM. SOA expires
2011-06-15 15:45:48 UTC signature over ASIA. DNSKEY expires
2011-06-15 15:45:48 UTC signature over ASIA. DNSKEY expires
2011-06-15 15:46:29 UTC signature over ME. DNSKEY expires
2011-06-15 15:46:29 UTC signature over ME. DNSKEY expires
2011-06-15 15:47:16 UTC signature over AG. DNSKEY expires
2011-06-15 15:47:16 UTC signature over AG. DNSKEY expires
2011-06-15 15:49:25 UTC signature over INFO. DNSKEY expires
2011-06-15 15:49:25 UTC signature over INFO. DNSKEY expires
2011-06-15 15:56:25 UTC signature over ORG. DNSKEY expires
2011-06-15 15:56:25 UTC signature over ORG. DNSKEY expires
2011-06-15 16:05:05 UTC signature over IN. DNSKEY expires
2011-06-15 16:05:05 UTC signature over IN. DNSKEY expires
2011-06-15 16:30:31 UTC signature over BZ. DNSKEY expires
2011-06-15 16:30:31 UTC signature over BZ. DNSKEY expires
2011-06-15 16:36:33 UTC signature over VC. DNSKEY expires
2011-06-15 16:36:33 UTC signature over VC. DNSKEY expires
2011-06-15 17:12:20 UTC signature over HN. DNSKEY expires
2011-06-15 17:12:20 UTC signature over HN. DNSKEY expires
2011-06-15 18:36:55 UTC signature over MN. DNSKEY expires
2011-06-15 18:36:55 UTC signature over MN. DNSKEY expires
2011-06-15 20:15:17 UTC signature over FI. SOA expires
2011-06-15 21:51:38 UTC signature over SC. DNSKEY expires
2011-06-15 21:51:38 UTC signature over SC. DNSKEY expires
2011-06-15 23:32:32 UTC signature over LC. DNSKEY expires
2011-06-15 23:32:32 UTC signature over LC. DNSKEY expires
2011-06-15 23:54:39 UTC signature over NL. SOA expires
2011-06-16 02:13:38 UTC signature over GI. DNSKEY expires
2011-06-16 02:13:38 UTC signature over GI. DNSKEY expires
2011-06-16 12:00:00 UTC signature over DE. DNSKEY expires
2011-06-18 03:44:21 UTC signature over AM. DNSKEY expires
2011-06-18 03:44:21 UTC signature over AM. DNSKEY expires
2011-06-21 20:13:06 UTC signature over LI. DNSKEY expires
2011-06-21 22:31:39 UTC signature over CH. DNSKEY expires
2011-06-22 08:34:51 UTC signature over LC. SOA expires
2011-06-22 11:27:43 UTC signature over SC. SOA expires
2011-06-22 11:56:35 UTC signature over VC. SOA expires
2011-06-22 14:06:18 UTC signature over MN. SOA expires
2011-06-22 14:28:51 UTC signature over HN. SOA expires
2011-06-22 14:55:24 UTC signature over BZ. SOA expires
2011-06-22 14:58:49 UTC signature over GI. SOA expires
2011-06-22 15:11:25 UTC signature over AG. SOA expires
2011-06-22 15:15:57 UTC signature over IN. SOA expires
2011-06-22 15:17:51 UTC signature over ASIA. SOA expires
2011-06-22 15:18:25 UTC signature over ME. SOA expires
2011-06-22 15:18:32 UTC signature over INFO. SOA expires
2011-06-22 15:21:45 UTC signature over ORG. SOA expires
2011-06-22 18:42:09 UTC signature over LA. SOA expires
2011-06-24 00:21:43 UTC signature over BIZ. DNSKEY expires
2011-06-24 00:21:43 UTC signature over BIZ. DNSKEY expires
2011-06-24 00:21:43 UTC signature over BIZ. DNSKEY expires
2011-06-24 02:08:36 UTC signature over US. DNSKEY expires
2011-06-24 02:08:36 UTC signature over US. DNSKEY expires
2011-06-24 13:00:00 UTC signature over CO. DNSKEY expires
2011-06-24 13:00:00 UTC signature over CO. DNSKEY expires
2011-06-24 13:00:00 UTC signature over CO. DNSKEY expires
2011-06-24 13:45:59 UTC signature over LA. DNSKEY expires
2011-06-25 10:17:03 UTC signature over XN--FZC2C9E2C. SOA expires
2011-06-25 10:17:38 UTC signature over XN--XKC2AL3HYE2A. SOA expires
2011-06-25 19:59:45 UTC signature over LA. DNSKEY expires
2011-06-26 18:41:02 UTC signature over TH. DNSKEY expires
2011-06-26 18:41:02 UTC signature over TH. DNSKEY expires
2011-06-26 18:41:02 UTC signature over TH. SOA expires
2011-06-27 17:45:03 UTC signature over JP. DNSKEY expires
2011-06-27 17:45:03 UTC signature over JP. SOA expires
2011-06-28 06:04:02 UTC signature over NA. DNSKEY expires
2011-06-28 06:04:02 UTC signature over NA. DNSKEY expires
2011-06-28 09:06:45 UTC signature over BE. DNSKEY expires
2011-06-28 09:06:45 UTC signature over BE. DNSKEY expires
2011-06-28 09:06:45 UTC signature over BE. DNSKEY expires
2011-06-29 05:46:24 UTC signature over AC. DNSKEY expires
2011-06-29 05:46:24 UTC signature over AC. DNSKEY expires
2011-06-29 05:46:24 UTC signature over AC. SOA expires
2011-06-29 05:46:24 UTC signature over IO. DNSKEY expires
2011-06-29 05:46:24 UTC signature over IO. DNSKEY expires
2011-06-29 05:46:24 UTC signature over IO. SOA expires
2011-06-29 05:46:24 UTC signature over SH. DNSKEY expires
2011-06-29 05:46:24 UTC signature over SH. DNSKEY expires
2011-06-29 05:46:24 UTC signature over SH. SOA expires
2011-06-29 05:46:24 UTC signature over TM. DNSKEY expires
2011-06-29 05:46:24 UTC signature over TM. DNSKEY expires
2011-06-29 05:46:24 UTC signature over TM. SOA expires
2011-06-30 10:29:51 UTC signature over LK. SOA expires
2011-07-01 03:01:01 UTC signature over PR. DNSKEY expires
2011-07-01 03:01:01 UTC signature over PR. DNSKEY expires
2011-07-01 03:17:05 UTC signature over NU. DNSKEY expires
2011-07-01 04:30:04 UTC signature over HOPCOUNT.CA. DNSKEY expires
2011-07-01 04:30:04 UTC signature over HOPCOUNT.CA. DNSKEY expires
2011-07-01 04:30:04 UTC signature over HOPCOUNT.CA. SOA expires
2011-07-01 06:01:01 UTC signature over PR. SOA expires
2011-07-01 06:04:01 UTC signature over NA. SOA expires
2011-07-01 06:17:05 UTC signature over NU. SOA expires
2011-07-01 07:00:07 UTC signature over PT. SOA expires
2011-07-01 07:53:19 UTC signature over AUTOMAGIC.ORG. DNSKEY expires
2011-07-01 07:53:19 UTC signature over AUTOMAGIC.ORG. DNSKEY expires
2011-07-01 07:53:19 UTC signature over AUTOMAGIC.ORG. SOA expires
2011-07-01 08:00:11 UTC signature over BG. SOA expires
2011-07-01 08:45:04 UTC signature over AM. SOA expires
2011-07-01 10:00:19 UTC signature over E164.ARPA. DNSKEY expires
2011-07-01 10:00:19 UTC signature over E164.ARPA. SOA expires
2011-07-01 12:00:05 UTC signature over PT. DNSKEY expires
2011-07-01 12:00:05 UTC signature over PT. DNSKEY expires
2011-07-01 12:12:12 UTC signature over GR. DNSKEY expires
2011-07-01 12:12:12 UTC signature over GR. DNSKEY expires
2011-07-01 12:12:12 UTC signature over GR. SOA expires
2011-07-01 13:00:13 UTC signature over BG. DNSKEY expires
2011-07-01 13:00:13 UTC signature over BG. DNSKEY expires
2011-07-01 13:34:40 UTC signature over CH. SOA expires
2011-07-01 13:59:07 UTC signature over LI. SOA expires
2011-07-01 15:14:32 UTC signature over BIZ. SOA expires
2011-07-01 15:14:50 UTC signature over CO. SOA expires
2011-07-01 15:19:33 UTC signature over US. SOA expires
2011-07-16 13:30:20 UTC signature over CL. SOA expires
2011-07-16 13:30:21 UTC signature over CL. DNSKEY expires
2011-07-29 12:16:31 UTC signature over FR. DNSKEY expires
2011-07-29 12:16:31 UTC signature over FR. DNSKEY expires
2011-07-29 12:17:36 UTC signature over PM. DNSKEY expires
2011-07-29 12:17:36 UTC signature over PM. DNSKEY expires
2011-07-29 12:17:36 UTC signature over PM. SOA expires
2011-07-29 12:17:37 UTC signature over RE. DNSKEY expires
2011-07-29 12:17:37 UTC signature over RE. DNSKEY expires
2011-07-29 12:17:37 UTC signature over TF. DNSKEY expires
2011-07-29 12:17:37 UTC signature over TF. DNSKEY expires
2011-07-29 12:17:37 UTC signature over TF. SOA expires
2011-07-29 12:17:39 UTC signature over WF. DNSKEY expires
2011-07-29 12:17:39 UTC signature over WF. DNSKEY expires
2011-07-29 12:17:39 UTC signature over WF. SOA expires
2011-07-29 12:17:39 UTC signature over YT. DNSKEY expires
2011-07-29 12:17:39 UTC signature over YT. DNSKEY expires
2011-07-29 12:17:39 UTC signature over YT. SOA expires
2011-07-30 06:29:31 UTC signature over JP. DNSKEY expires
2011-07-31 05:00:04 UTC signature over RE. SOA expires
2011-07-31 09:00:06 UTC signature over FR. SOA expires
2011-08-11 14:37:10 UTC signature over CL. DNSKEY expires
2011-08-15 00:00:00 UTC signature over LK. DNSKEY expires
2011-08-15 00:00:00 UTC signature over LK. DNSKEY expires
2011-08-15 00:00:00 UTC signature over XN--FZC2C9E2C. DNSKEY expires
2011-08-15 00:00:00 UTC signature over XN--FZC2C9E2C. DNSKEY expires
2011-08-15 00:00:00 UTC signature over XN--XKC2AL3HYE2A. DNSKEY expires
2011-08-15 00:00:00 UTC signature over XN--XKC2AL3HYE2A. DNSKEY expires
2011-08-28 13:06:23 UTC signature over MY. DNSKEY expires
2011-08-28 13:06:23 UTC signature over MY. DNSKEY expires
2011-08-30 05:06:22 UTC signature over MY. SOA expires
2011-12-31 23:59:59 UTC signature over KG. DNSKEY expires
2011-12-31 23:59:59 UTC signature over KG. DNSKEY expires
2011-12-31 23:59:59 UTC signature over KG. SOA expires
[wifi-216-217:~]%

---

From: João Damas <[email-masked]>
Date: Thu, 2 Jun 2011 12:17:42 +0200

at first glance it might look useful, but this is the kind of info that tends to go stale and then what do you do when there is a mismatch?
Would you invalidate a still-valid signature if it doesn't conform to policy in case someone else is signing the zone other than the authorised party?
Would you send mail to the zone admin? (and knowing the people on this list, that would be a lot email on top of that admin) :)

Shouldn't this sort of admin work be done by the admin, either internally or by outsourcing to some other organisation?

Joao

On 2 Jun 2011, at 12:02, Joe Abley wrote:

> <sigexpire.sh>_______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Joe Abley <[email-masked]>
Date: Thu, 2 Jun 2011 13:22:16 +0300

> at first glance it might look useful, but this is the kind of info that tends to go stale and then what do you do when there is a mismatch?

I guess you flag it for manual investigation. The alternative is that you don't really know when a situation is actually bad until the signature expires, and it'd be nice to have some early warning.

I could maintain a manual table of what "bad" means for particular zones based on observation, but that seems even more likely to become stale.

> Would you invalidate a still-valid signature if it doesn't conform to policy in case someone else is signing the zone other than the authorised party?

Nope, but (especially in these early days of deployment) perhaps it might merit a note to an administrator, or a heads-up to a public list.

> Shouldn't this sort of admin work be done by the admin, either internally or by outsourcing to some other organisation?

I guess my point is that unless you're the person involved in signing a particular zone, telling when there's a signature expiration problem looming is not easy.

Joe

---

From: Tony Finch <[email-masked]>
Date: Thu, 2 Jun 2011 12:47:03 +0100

Joe Abley <[email-masked]> wrote:
>
> Is there perhaps value in finding a mechanism by which zone operators
> can publish information in their zones which gives guidance as to what
> the normal limits for signature expiration ought to be?

Sounds like a good idea. I agree with João that you need to take care not
to confuse the current rrsig expiration semantics. So I think the right
thing to publish is the next planned signature refresh time. (Which
amounts to the same thing but the terminology is clearer.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in
Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5
or 6 later. Rough or very rough. Occasional rain. Moderate or good,
occasionally poor.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 2 Jun 2011 09:36:30 -0400

At 13:02 +0300 6/2/11, Joe Abley wrote:

>I have realised, however, that I can't tell whether a signature that is
>(say) going to expire in under three days is a cause for concern, or
>whether it's normal operations and something I should expect to be
>replaced as part of normal operations.

Once upon a time a DNS set up had two NS records and the two IP 
addresses were neighbors.  I was sitting next to the admin of the 
zone and mentioned this to him.  He said "but you don't know..." how 
he had set up the zone to avoid the problem I thought I detected.  It 
turns out, what I "didn't know" didn't really solve the problem but 
the moral is that with all the tricks available to admins these days, 
it's nearly impossible to poke at port 53 and make an accurate 
diagnosis and recommendation.  (You can detect symptoms, but not a 
reason.)

I also repeated this lesson writing lame server detection software 
years ago.  Again, you can find symptoms but can't really diagnose or 
prescribe fixes.

So, I would bet that about all you can do is list when signatures are 
to expire (in the future) and list signatures that expire and notify 
the admins.  Except for the expired ones, there's not much you can 
say definitively to the admin.  More remote monitoring and reporting 
symptoms is good, trying to diagnose and offer fixes is likely to 
drive you crazy (unless you like false positives).

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Now, don't say I'm always complaining.
Wait, that's a complaint, isn't it?

---

From: Tony Finch <[email-masked]>
Date: Thu, 2 Jun 2011 14:53:18 +0100

Edward Lewis <[email-masked]> wrote:
> So, I would bet that about all you can do is list when signatures are to
> expire (in the future) and list signatures that expire and notify the admins.
> Except for the expired ones, there's not much you can say definitively to the
> admin.  More remote monitoring and reporting symptoms is good, trying to
> diagnose and offer fixes is likely to drive you crazy (unless you like false
> positives).

It's possibly useful to know the ratio of the intervals between the
inception time and now, and now and the expiry time. Also the relation
between the now/expiry interval and the relevant TTLs and zone refresh and
expiry intervals.

Tony.

---

From: Jim Reid <[email-masked]>
Date: Thu, 2 Jun 2011 15:02:23 +0100

> between the now/expiry interval and the relevant TTLs and zone  

How does this differ from the metadata that's in the zone's RRSIG and  
SOA records?

---

From: Tony Finch <[email-masked]>
Date: Thu, 2 Jun 2011 15:24:05 +0100

Jim Reid <[email-masked]> wrote:
> How does this differ from the metadata that's in the zone's RRSIG and SOA
> records?

Joe's script doesn't display that metadata. It might help you decide if
you should worry about signatures that are due to expire soon, more than
just the interval between now and the expiry time.

Tony.

---

From: Jim Reid <[email-masked]>
Date: Thu, 2 Jun 2011 16:11:37 +0100

> just the interval between now and the expiry time.

Ah. I thought you were talking about Joe's idea rather than the script  
he used to illustrat that.

---

From: Richard Lamb <[email-masked]>
Date: Thu, 2 Jun 2011 08:23:38 -0700

I still think, stale or not, having some idea of what the zone's policy is regarding signature updates would be useful.  I've been running signature expiry monitoring scripts for a few years and having some idea of what is "ok" for a zone would be very helpful - particularly those zones that have a policy of not refreshing signatures a day or two before expiry (e.g. red ones on http://www.dnssek.info/ )- which I would normally consider a concern and start firing off warning emails.

-Rick

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Joe Abley
> Sent: Thursday, June 02, 2011 3:22 AM
> To: João Damas
> Cc: IETF DNSOP WG
> Subject: Re: [DNSOP] watching for signature expiration in zones you don't sign
> 
> 
> I guess you flag it for manual investigation. The alternative is that you don't really know when a
> situation is actually bad until the signature expires, and it'd be nice to have some early warning.
> 
> I could maintain a manual table of what "bad" means for particular zones based on observation, but
> that seems even more likely to become stale.
> 
> > Would you invalidate a still-valid signature if it doesn't conform to policy in case someone else is
> signing the zone other than the authorised party?
> 
> Nope, but (especially in these early days of deployment) perhaps it might merit a note to an
> administrator, or a heads-up to a public list.
> 
> I guess my point is that unless you're the person involved in signing a particular zone, telling when
> there's a signature expiration problem looming is not easy.
> 
> 
> Joe
> _______________________________________________
> DNSOP mailing list
> [email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 2 Jun 2011 08:43:28 -0700

Another thought is to simply keep a detailed history and watch the replacements. For each zone, you should be able to determine what their normal renewal buffer is. You would only need to be concerned about those that get too close to the edge from their normal operations.

--Paul Hoffman

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 02 Jun 2011 11:43:52 -0400

> I still think, stale or not, having some idea of what the zone's policy is regarding signature updates would be useful.  I've been running signature expiry monitoring scripts for a few years and ha…

Strictly speaking from a protocol point of view any signature that 
expires before (zone expiry + RR TTL) is a potential validation failure.
Any Signature that expires before corresponding TTL is a likely 
validation failure if there is a non DNSSEC validating cache in the path.

Any Signature that has expired is bad.

The issue is that many zone owners do not
a) Do not know how long it takes to distribute their modified zone to 
all the servers in the NS set. (frequent assumption is 0 seconds)
b) Forget about the possible impact of zone expiry when secondary server 
can not reach distribution server.
c) Forget about maximum TTL in zone

	Olafur

---

From: Edward Lewis <[email-masked]>
Date: Thu, 2 Jun 2011 12:22:42 -0400

Time is a pain in the neck.  Conversations over the meaning of timers 
and time fields have gone on for a long time.

Keep in mind the difference between absolute (or wall clock) time and 
relative time.  The latter is even stickier because the time may be 
relative to an event that is local and not even zone-wide.

What timers are used to do is to govern different, often orthogonal 
operations and events in the DNS system.  The TTL is there to govern 
freshness of cached records in a server.  The SOA timers are there to 
govern the freshness of a copy of a zone in a slave server. 
Authority (only) servers have no notion of time and we've made 
strides to keep it that way.  (At least in the protocol.)

DNSSEC came along with absolute time.  That is a novelty of the 
extensions.  The time was used to do two things - protect the 
cryptographic relevance of the signature and to limit the impact of 
replay attempts.

Along the way many have confused the meaning of the timers.  TTL 
trimming to the signature expiration is one abuse, arguably one that 
makes sense.  In the purity of the protocol it doesn't but given 
operational realities that there may be a forced downstream validator 
that needs this trimming to be done.

At 11:43 -0400 6/2/11, Olafur Gudmundsson wrote:

>Strictly speaking from a protocol point of view any signature that expires
>before (zone expiry + RR TTL) is a potential validation failure.

The signature expiration is in absolute time.  Zone expiry (and 
refresh/retry) is a relative time.  TTL is also a relative time.

Whether the signature expiration time will arrive before the 
expiration of the zone or the cache entry is a question relative to 
the time you ask.

The base time for, say zone expiry, is relative to the slave server 
and is not revealed via the protocol.  And it is server specific, not 
zone specific!

So - there's no way to determine if "any signature ... expires 
before" zone expiry or RR TTL.

>Any Signature that expires before corresponding TTL is a likely validation
>failure if there is a non DNSSEC validating cache in the path.

What do you mean by "in the path"?

There's no protocol error in shipping an expired signature.  It's up 
to the receiver to decide if that matters.  We stopped requiring zone 
loading to check signatures like 10 years ago.

>Any Signature that has expired is bad.

http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-02 
says differently.

>a) Do not know how long it takes to distribute their modified zone to all
>the servers in the NS set. (frequent assumption is 0 seconds)

>c) Forget about maximum TTL in zone

I'm not sure where you are going here - but C isn't a problem in 
caches that do TTL trimming.   A & B aren't limited to being DNSSEC 
issues.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Richard Lamb <[email-masked]>
Date: Thu, 2 Jun 2011 10:41:25 -0700

Good point. Make it adaptive.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: Thursday, June 02, 2011 8:43 AM
> To: Joe Abley
> Cc: IETF DNSOP WG
> Another thought is to simply keep a detailed history and watch the replacements. For each zone, you
> should be able to determine what their normal renewal buffer is. You would only need to be concerned
> about those that get too close to the edge from their normal operations.
> 
> --Paul Hoffman

---

From: David Conrad <[email-masked]>
Date: Thu, 2 Jun 2011 09:28:45 -1000

On Jun 2, 2011, at 5:23 AM, Richard Lamb wrote:
> I still think, stale or not, having some idea of what the zone's policy is regarding signature updates would be useful.  

I'll admit a vague, unsubstantiated feeling of ill-ease about this.  Would publishing this policy provide information of benefit to potential attackers?

On the other hand, pragmatically speaking, I suspect signature expiration will be causing more damage to the DNS than potential attackers...

Regards,
-drc

---

From: "Marc Lampo" <[email-masked]>
Date: Fri, 3 Jun 2011 09:05:05 +0200 (CEST)

Which is basically what we, EURid for .eu, do.
Example : DNSKEY "operations" and usage during the month of may

domain "eu." on 2011-05-01
 serial : 1003539565
 ksks   : 61179 DS
 zsks   : 19700, 57368 RRSIG
domain "eu." on 2011-05-03
 signing with keyid 19700
 serial : 1003545434
 ksks   : 61179 DS
 zsks   : 19700 RRSIG, 57368 RRSIG
domain "eu." on 2011-05-12
 no longer signing with keyid 57368
 serial : 1003578276
 ksks   : 61179 DS
 zsks   : 19700 RRSIG, 57368
domain "eu." on 2011-05-20
 zsk 57368 - removed DNSKEY from zone
 serial : 1003606818
 ksks   : 61179 DS
 zsks   : 19700 RRSIG
domain "eu." on 2011-05-24
 zsk 34553 - added DNSKEY to zone
 serial : 1003620223
 ksks   : 61179 DS
 zsks   : 19700 RRSIG, 34553
domain "eu." on 2011-05-31
 signing with keyid 34553
 serial : 1003644472
 ksks   : 61179 DS
 zsks   : 19700 RRSIG, 34553 RRSIG

In addition :
On the network management server, scripts were added that do check
validity of published signatures.
Getting "too close" to end-of-validity is one of the triggers to send
alerts.

Kind regards,

Marc Lampo
Security Officer
EURid

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: 02 June 2011 05:43 PM
To: Joe Abley
Cc: IETF DNSOP WG
Subject: Re: [DNSOP] watching for signature expiration in zones you don't
sign

Another thought is to simply keep a detailed history and watch the
replacements. For each zone, you should be able to determine what their
normal renewal buffer is. You would only need to be concerned about those
that get too close to the edge from their normal operations.

--Paul Hoffman

---

From: "Marc Lampo" <[email-masked]>
Date: Fri, 3 Jun 2011 09:19:34 +0200 (CEST)

Hello,

And thanks for the reference to this website.

While I do agree that having signatures "close to end-of-validity time"
might be a reason for concern
 - in most cases I observed with our own registrars,
   getting "too close" usually leads to "no longer valid" signatures -
there is however absolutely no problem if the signatures are regenerated
before actually reaching that end-of-validity time.

(and though .eu shows "red" in this website,
 I can assure the community we got the re-signing well under control
 and also monitored by network management scripts).

On the other hand, I would be concerned with signatures that remain valid
"very" long !
They show up "green", but actually have a very long period of time
during which "replay attacks" are potentially possible !
Some malicious person might grab present data,
with presently valid signatures,
and - as long as that signature remains valid -
that capture data might be reused !
(the associated DNSKEY must/should remain in the zone
 to allow for validation of that signature)

This begin said :
(at least) one of the tld's that are green in the website,
sends signatures that remain valid till the last second of the present
year,
(and did not even, as far as I can see, any ZSK roll-over at all).
Now *that* would be a reason to flag them "red", in my opinion.

(and yes, I did send the colleague admins emails about this;
 and no, no response ...)

Kind regards,

Marc Lampo
Security Officer
EURid

-----Original Message-----
From: Richard Lamb [mailto:[email-masked]]
Sent: 02 June 2011 05:24 PM
To: Joe Abley; João Damas
Cc: IETF DNSOP WG
Subject: Re: [DNSOP] watching for signature expiration in zones you don't
sign

I still think, stale or not, having some idea of what the zone's policy is
regarding signature updates would be useful.  I've been running signature
expiry monitoring scripts for a few years and having some idea of what is
"ok" for a zone would be very helpful - particularly those zones that have
a policy of not refreshing signatures a day or two before expiry (e.g. red
ones on http://www.dnssek.info/ )- which I would normally consider a
concern and start firing off warning emails.

-Rick

> > at first glance it might look useful, but this is the kind of info
that tends to go stale and then
> what do you do when there is a mismatch?
>
> > Would you send mail to the zone admin? (and knowing the people on this
list, that would be a lot
> email on top of that admin) :)
> >
> > Shouldn't this sort of admin work be done by the admin, either
internally or by outsourcing to some
> other organisation?

---

From: João Damas <[email-masked]>
Date: Fri, 3 Jun 2011 11:03:29 +0200

So far, experience tells us exactly that. I am afraid it will continue to do so

Joao