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 <p...@redbarn.org> 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.
>
> 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_______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
