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

[Evan Hunt <[e-mail]>]

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.

> 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.

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 -- [e-mail]
Internet Systems Consortium, Inc.