Subject: [DNSOP] some 2015-era thoughts about RFC 7706 -bis

From: Paul Vixie <[email-masked]>
Date: Tue, 23 Jul 2019 22:18:20 +0000

at the one-hour DNSOP meeting in montreal on monday evening, the authors of 
RFC 7706 described some of the use case questions they were hoping to answer 
in their -bis document, and one of them hit squarely on a topic i spoke about 
frequently between 2005 and 2015. i've attached a copy of the 2015 proposal, 
which was reviewed by warren kumari and then presented in a non-IETF meeting 
on these topics, organized by warren and i, in hong kong.

i was opposed to RFC 7706 as written, but there is no permanent record of my 
reasoning since RFC documents don't include a "dissenting views" section, so 
let me briefly recapitulate here.

first, all complexity comes at a cost. the new code and configuration needed 
to support "mirror zones" will be a life long source of bugs and 
vulnerabilities, because that's true of every new feature. the desired benefit 
should be weighed against this cost. "by running one on the loopback" fails 
this important test, mostly because it only applies to the root zone.

second, RDNS name servers who wanted to support this feature, which all must, 
due to the competitive nature of the open source infrastructure community, 
have to add features very much like authority DNS. we have been moving away 
from the so-called "hybrid server" model for three decades now, and this was a 
move in precisely the wrong direction.

third, access patterns of root zone data are an important input to internet 
governance, and the 7706 proposal included no recommendations by which access 
patterns could still be globally shared in any way -- and for reasons of 
scale, they will not be participating in Day In The Life exercises.

in summary, RFC 7706 solves the wrong problem, in the wrong way, with an 
inverted cost:benefit model compared to similar conceptions with similar 
implementation costs.

those who hang around where i do have heard me explain that what DNS needs is 
a lease model for all metadata, with secure revocation. any delegation data 
including NS, glue, and DNSSEC chains, must be held by an RDNS until it 
changes, and every authority must be able to signal such changes. you can 
think of this as like a micro-secondary server at the RRset level, plus 
NOTIFY. no network partition should keep an RDNS from returning all 
information which is still available ("on this side of the partition") needed 
to reach services and assets which are still available ("on this side of the 
partition"), and DNS got that wrong by externalizing dependencies.

however, that is not the subject of the attached 2015-era "hong kong" 
proposal. at DNSOP monday night, a use case that was mentioned for 7706-bis is 
where the local copy of the root zone not be necessarily co-served by an RDNS. 
that is a much smaller problem than "leasing for all metadata in case of a 
network partition", and is squarely addressed by the modest proposal below.

one world, one internet, one namespace.

-- 
Paul

---

From: Brian Dickson <[email-masked]>
Date: Tue, 23 Jul 2019 20:54:49 -0400

Small couple of comments in a top-reply...

I think the concept of having the root zone integrated into the RDNS is
something that Paul correctly indicates as something RDNS practices have
moved away from.
I happen to agree that doing so is a mistake, with particular reasoning:
- When integrated into the RDNS servers' db/cache and loaded at start time,
the {potential,likely,known} effect is to short-circuit DNSSEC validation,
as well as TTLs.
- OTOH, having a root zone served on one or more of the original anycast IP
(v4 and/or v6) addresses, which is on the same host (reachable by a
loopback address) or very close by, avoids those issues (and avoids needing
to change RDNS implementations)

With a small amount of operator work, it should be feasible to have on-host
or very-close-by root anycast instance(s) available and preferred (by e.g.
routing, such as BGP) IFF the "local" instance is conditionally announced
by the host/server using suitable software (e.g. quagga). The advantage of
such a set-up is that if it is done right, an unavailable local instance
will result in fall-back to a "real" anycast instance. It is important, of
course, to not export the announcement beyond the "local" scope, at least
not without the permission and cooperation of the operator of the specific
anycast address.

In addition, I think it would be helpful/advisable to augment the current
7706 with some export of statistics in a way that is compatible with the
operator of the particular root operator's own statistics gathering, so
this information is not lost, but merely gathered differently than would be
the case without the local instance. (Anonymizing the data etc. if
required/desired.)
By feeding the data to the root operators, it would potentially be feasible
for said operator to include it in DITL data sets.

Brian

On Tue, Jul 23, 2019 at 6:19 PM Paul Vixie <[email-masked]> wrote:

> Paul_______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Tony Finch <[email-masked]>
Date: Wed, 24 Jul 2019 15:33:43 +0100

> this important test, mostly because it only applies to the root zone.

Yes. I also agree with Geoff Huston's article from April that hyperlocal
roots are not a compelling imrovement when we have DNSSEC negative answer
synthesis, which applies to any NSEC zone, not just the root.

https://www.potaroo.net/ispcol/2019-04/root.html

> have to add features very much like authority DNS.

Ironically, unbound has been growing more and more features for serving
authoritative data. There are fairly compelling operational pressures
that drive recursive servers to become more and more complicated, because
they are a very powerful point of control.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Great Orme Head to the Mull of Galloway: South 3 to 5. Smooth or slight.
Mainly fair. Moderate or good.

---

From: Evan Hunt <[email-masked]>
Date: Thu, 25 Jul 2019 05:44:50 +0000

On Tue, Jul 23, 2019 at 10:18:20PM +0000, Paul Vixie wrote:
> at the one-hour DNSOP meeting in montreal on monday evening, the authors
> of RFC 7706 described some of the use case questions they were hoping to
> answer in their -bis document, and one of them hit squarely on a topic i
> spoke about frequently between 2005 and 2015. i've attached a copy of the
> 2015 proposal, which was reviewed by warren kumari and then presented in
> a non-IETF meeting on these topics, organized by warren and i, in hong
> kong.
> 
> i was opposed to RFC 7706 as written, but there is no permanent record of
> my reasoning since RFC documents don't include a "dissenting views"
> section, so let me briefly recapitulate here.

Thanks. I've never understood your objection to 7706, as it wasn't a new
protocol, it just informed people of a way to use what already existed.

> first, all complexity comes at a cost. the new code and configuration
> needed to support "mirror zones" will be a life long source of bugs and
> vulnerabilities, because that's true of every new feature. the desired
> benefit should be weighed against this cost. "by running one on the
> loopback" fails this important test, mostly because it only applies to
> the root zone.

A couple of points here: first, mirror zones were developed as a way to
make it simpler to configure a 7706-style local root mirror, and to
mitigate certain failure cases that could occur in the wake of a failed
transfer, but mirror zones are not RFC 7706.  You can set up 7706 on *any*
name server; the examples in that document were written without mirror
zones.

Second, this is mostly just nitpicking, but the statement about mirror
zones isn't really correct. In BIND, at least, "type mirror" can be used
for any zone that allows transfers. However, admittedly, one probably
wouldn't want to do it for large zones, and I don't know of any TLD's that
allow transfer in the first place, so for the purposes of the current
discussion, you're right enough.

Third, and more pertinently, this work may have spin-off benefits.  I've
thought for a long time that a mechanism to use DNSSEC to validate zone
transfers would be a useful addition to BIND.  While that feature, per se,
still doesn't exist, the mirror zone developemnt invovled writing a lot the
code that's needed for it, and I expect it to exist fairly soon. So I don't
think 7706 will have been a waste of time even if it turns out not to have
been particularly effective at its original use case.

> second, RDNS name servers who wanted to support this feature, which all
> must, due to the competitive nature of the open source infrastructure
> community, have to add features very much like authority DNS. we have
> been moving away from the so-called "hybrid server" model for three
> decades now, and this was a move in precisely the wrong direction.

This confuses me. There's nothing in particular for RDNS implementations to
support. Set up your root hints to point at a local address, run an auth
server at that address, configure that server as a secondary for the root
zone - presto, 7706 is supported. What server can't do that?

Some implementations may wish to support 7706 internally as BIND has done,
but it isn't mandatory.  In any case, it would't be the first time it's
been useful to mix RDNS and auth (consider empty RFC 1918 reverse zones,
for example).  I've never agreed that mixing auth and RDNS functions was a
bad idea, actually, but that's another conversation.

> third, access patterns of root zone data are an important input to
> internet governance, and the 7706 proposal included no recommendations by
> which access patterns could still be globally shared in any way -- and
> for reasons of scale, they will not be participating in Day In The Life
> exercises.

This bit's legit.

> inverted cost:benefit model compared to similar conceptions with similar

As far as I know, 7706 hasn't had much benefit with respect to latency in
most environments, and I'm skeptical about its utility with random-query
attacks.  (Unfortunately, I hear negative answer synthesis isn't working as
well at that as we'd hoped, either.)

But, it's Mostly Harmless.  The implementation cost can be zero if you want
it to be; it's just a server configuration.  At worst, it's a waste of the
time that's been spent talking about it (with the zone transfer code that
fell out of it turning the effort to a net positive, I hope).

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 25 Jul 2019 06:34:57 +0000

On Thursday, 25 July 2019 05:44:50 UTC Evan Hunt wrote:
> ...

the presence of the logic; the capability itself, has a complexity cost, imposed by hooks in 
the surrounding code. if used, the cost rises.

bert has argued pretty cogently about the dns camel. i won't repeat any of that here, 
except, you can correctly treat complexity as mass we all carry.

see also:

https://daverupert.com/2018/09/if-statements-should-cost-10000/[1] 

-- 
Paul

--------
[1] https://daverupert.com/2018/09/if-statements-should-cost-10000/

---

From: Vladimír Čunát <[email-masked]>
Date: Thu, 25 Jul 2019 11:36:08 +0200

On 7/25/19 7:44 AM, Evan Hunt wrote:
> [... TLD XFR] However, admittedly, one probably

I know about .se (and .nu) providing AXFR, but I suspect it might not be
worth mirroring continually in this way, even for large Swedish ISPs.  A
related thing in .cz (where to zone is not public by a rule) is that
register-managed instances are running inside ISP networks and routing
ensures they are "separate" from public instances (against attacks), but
I'm digressing...

[.se] https://zonedata.iis.se/

--Vladimir

---

From: Shumon Huque <[email-masked]>
Date: Thu, 25 Jul 2019 11:15:22 -0400

(I'll ignore the question of the cost/benefits of running a local root copy
for now and just focus on the technical topic below).

> been particularly effective at its original use case.

Evan,

Can you elaborate on how you plan to do this?

One of the things that has always annoyed me about RFC7706 (and its
successor I-D) is that it offers no suggestions on how to validate that you
got a correct copy of the entire root zone. The example configurations
given in the appendix are all insecure - they rely on unauthenticated zone
transfer. The one example that is likely secure is the one given for the
Knot resolver, but that's because it is decidedly not using 7706, and
instead uses cache prefill from a root zone copy located at a well known
HTTPS authenticated destination. If an operator using 7706 is targeted by a
glue spoofing attack, then it will likely require manual intervention of
the resolver operator to recover. Whereas without 7706, I assume robust
resolvers may be able to recover by themselves by retrying other root
servers, if they can determine that they were directed to bogus servers in
the case of signed child zones.

If you plan to use DNSSEC to validate the zone, I assume you might be
thinking of either (1) signed ZONEMD, although that does not exist yet for
the root zone, or (2) proposing to re-design child NS and glue records so
that they can be signed. But perhaps there are other ways that I haven't
thought of.

Recall that there have been extensive discussions on this topic during the
initial debate on ZONEMD, which I won't rehash here. But I want to note
that there is now a draft on XFR over TLS, which may offer a new channel
protection possibility to address this issue (assuming it makes progress,
and there is implementation interest on the part of root zone operators).

Shumon Huque

---

From: Evan Hunt <[email-masked]>
Date: Thu, 25 Jul 2019 16:52:33 +0000

On Thu, Jul 25, 2019 at 11:15:22AM -0400, Shumon Huque wrote:
> transfer.

I wouldn't say "insecure", exactly, but you're partly right - in the
examples in RFC 7706, the zone transfer itself would be insecure, but once
the zone was transfered, answers would still be validated. That's why the
local mirror is set up in a separate auth server or view - it prevents
answers from being returned as authoritative data, without validation.  So
clients do still have some protection; the problem is, there's no automatic
recovery if the transfer is bad. Clients would start to SERVFAIL and the
local root wouldn't know it had a problem.

BIND 9 mirror zones address this in two ways: first, the zone is validated
when transferred; the transfer is rejected if any bogus RRsets are found or
if the NSEC chain is incompete. Second, if the zone is unusable, either
because it failed to transfer in the first place or because it expired
without a successful refresh, named automatically fails over to normal
recursion to the root.

This doesn't address the problem of glue and delegation NS records, but
those aren't subject to DNSSEC validation during normal recursion anyway,
so clients aren't substantially worse off. The transfer does represent an
attack surface that wasn't there before, but it would be an extremely
difficult one to exploit. That said, ZONEMD or XoT would improve things
further, and I hope the root zone will adopt one or both.

In the more general case for validating zone transfers, the idea is to have
a sanity check that signatures are good before a secondary starts serving a
zone.  This is mostly about preventing self-foot-shooting incidents; ZONEMD
isn't strictly necessary for it.