Subject: Re: [DNSOP] Fwd: Comments on draft-ietf-dnsop-root-loopback

From: Tony Finch <[email-masked]>
Date: Mon, 5 Jan 2015 12:06:50 +0000

Brian Dickson <[email-masked]> wrote:
>
> - Given the lack of the "big red button", this would be a good time to
> introduce the ability to opt-in to a NOTIFY "registry", so that
> appropriately validated notifications could be sent by a root-zone operator
> (from whom the root-loopback operator does AXFRs)

I don't think this necessary. The refresh timer on the root zone is 30
minutes but the update frequency is twice a day (I think). NOTIFY would
not provide much benefit.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Dover, Wight, Portland, Plymouth: South 5 or 6, veering southwest 6 to gale 8,
becoming cyclonic 4 or 5 later. Moderate or rough, occasionally very rough in
Portland and Plymouth. Rain. Good, occasionally poor.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 10 Jan 2015 10:05:00 -0800

Wearing my co-author hat:

On Dec 29, 2014, at 2:23 PM, Brian Dickson <[email-masked]> wrote:
> - Given the unsigned nature of the glue in the zone, and the importance of root glue, it might be the right time to also introduce a "zone signature" RR, signed by the ZSK.

It might be, but that certainly would not go in this document. Having said that, it would be good to first hear evidence about how many resolvers take the unsigned root glue on faith versus how many chase down the names themselves. If there is only a small percentage who use the unsigned root glue, adding a new zone signature RR would seem awfully heavy-weight. (I say that as someone who has already done a design for the RR and presented it as a possibly-useful idea; I'm now not convinced it is worth the effort.)

> - Given the lack of the "big red button", this would be a good time to introduce the ability to opt-in to a NOTIFY "registry", so that appropriately validated notifications could be sent by a root-zone operator (from whom the root-loopback operator does AXFRs)

It might be, but that certainly would not go in this document. Still, I don't see the need for this if the root-loopback operator is checking for updates at a reasonable rate. The next draft will have a note about the history of root zone updates.

> - I'd also suggest adding something like a "sentinel" query for SOA Serial Number be made at REFRESH intervals to randomly-selected root servers. If the SOA Serial Number is stale for REFRESH + RETRY, it may be safer to go SERVFAIL at that point rather than waiting for EXPIRE. (The stale zone might still want to be used if all other root servers become unreachable, so don't delete the zone, just prefer not to use it.)

What does "safer" mean here? If the folks who create the root zone (or any zone, for that matter) want people to expire sooner, they should change the value of the EXPIRE field: they shouldn't rely on us second-guessing them.

--Paul Hoffman

---

From: Brian Dickson <[email-masked]>
Date: Sat, 10 Jan 2015 12:36:00 -0800

On Sat, Jan 10, 2015 at 10:05 AM, Paul Hoffman <[email-masked]>
wrote:

> > - Given the unsigned nature of the glue in the zone, and the importance
> of root glue, it might be the right time to also introduce a "zone
> signature" RR, signed by the ZSK.
>
> It might be, but that certainly would not go in this document. Having said
> that, it would be good to first hear evidence about how many resolvers take
> the unsigned root glue on faith versus how many chase down the names
> themselves. If there is only a small percentage who use the unsigned root
> glue, adding a new zone signature RR would seem awfully heavy-weight. (I
> say that as someone who has already done a design for the RR and presented
> it as a possibly-useful idea; I'm now not convinced it is worth the effort.)
>

The problem with chasing down the names is that the names are not in signed
zones (root-servers.net for example, but many TLD's name server names are
in unsigned zones.) I was surprised to learn this, and back when there were
only a few hundred TLDs, had trouble finding TLDs whose name server names
*were* in signed zones.

Maybe the issue is moot, if the AXFR sources are configured by IP address
rather than name, and don't factor into the attack surface. The downside
is, if there is a need to change the AXFR IP address, presuming a large
installed base, how would that happen?

On the other hand, if AXFR addresses are looked up in DNS, it becomes a
"capture" issue. If an attacker manages to poison the cache of the
operator, the attacker can capture the AXFR itself and provide a modified
root zone with good signed data but bad glue data. This becomes an
undetectable and unrecoverable situation.

The use of a zone signature would protect against this, for comparatively
low cost.

> It might be, but that certainly would not go in this document. Still, I
> don't see the need for this if the root-loopback operator is checking for
> updates at a reasonable rate. The next draft will have a note about the
> history of root zone updates.
>

Ah, rIght, there could be a big difference between RR TTLs and SOA REFRESH.
I was thinking of the former, not the latter.

>
> > - I'd also suggest adding something like a "sentinel" query for SOA
> Serial Number be made at REFRESH intervals to randomly-selected root
> servers. If the SOA Serial Number is stale for REFRESH + RETRY, it may be
> safer to go SERVFAIL at that point rather than waiting for EXPIRE. (The
> stale zone might still want to be used if all other root servers become
> unreachable, so don't delete the zone, just prefer not to use it.)
>
> What does "safer" mean here? If the folks who create the root zone (or any
> zone, for that matter) want people to expire sooner, they should change the
> value of the EXPIRE field: they shouldn't rely on us second-guessing them.
>
>
For most current situations, any zone which is being served by a
secondary/slave (including the root zone), normally is done with the
knowledge and intent of the zone owner/operator, and (at least for best
practices) is monitored by the zone operator. As such, it is generally a
rare event for EXPIRE to take effect, at least anecdotally speaking.

The root-loopback draft changes the operation of the root zone instances
from "all managed by one of the root operators" to "loosely managed by
resolver operators". The benefits of having local root zones may be
compelling, but IMHO the implementation of this may require more cautious
approaches to boundary conditions. Fail safe, to put it in simple terms.

"Safer" means, "This should never happen", and if it does, something
extremely odd has happened. If the SOA serial is consistently behind some
other reference SOA serial source, it means that either the zone updates
have been failing, or the upstream masters are themselves stale. Without an
additional master from whom to [AI]XFR, this is an "error" condition for
which there is no available solution via established mechanisms.

Ideally, the root-loopback host should be configured to AXFR from any/all
root servers, which I think makes the scenario impossible. If the host only
does AXFR from a subset of (or only one of) the root servers, the scenario
goes from impossible to possible (regardless of how likely, or via what
chain of events).

Basically, if the SOA serial has changed, but we aren't using the new copy
of the zone (i.e. our copy's serial is older), then by definition we are
using a stale copy of the zone. At that point, the only way to get
non-stale answers is to query something other than the local
(root-loopback) root servers.

I'm suggesting that how this error condition is handled, might better
reflect how a resolver operator would handle it (human intervention) than
how an authority server operator would handle it. Actually, I think
authority server operators would also take intervention steps if the
scenario existed (a persistently stale slave). I'm thinking that the logic
for this should be "What would Joe do?". :-)

Brian