Dear Paul,
On Wed, 17 Jun 2020 at 00:03, Paul Vixie <p...@redbarn.org> wrote:
>
> i've described this to you (when you were at BII) several times as a kind
> of
> microtransfer or lease, where cooperating initiators (RDNS in this case)
> and
> responders (ADNS in this case) can agree on a NOTIFY TSIG key to be used
> later, so that an RRset if changed or removed in the authority, a few
> million
> leaseholder RDNS can be told about this.
Yes. I remember we discussed the distribution of shared TSIG key instead
of address-based ACL when we talked about the zone distribution.
> if you start an effort on it, i'll contribute.
OK. Thank you for your support.
> as you know, synchronizing the root zone (RFC 7706)
> solves almost none of the problem of occasional connectivity, since so
> many
> other NS, DS, glue, key, and signature data are needed in-cache to
> continue
> retrieving other answers during times of disconnectivity. we (you) should
> do
> this.
>
I guess you mean providing an alternative resolution path for occasional
disconnectivity on the path between the authority server and the resolver
, #2 is one approach, right?
> > > 2. A resolver can forward queries to another resolver if the load is
> high
> > > to reduce the recursion.
>
> if by this you mean the potential for a DNS Ring, where a cooperating set
> of
> RDNS servers agrees to randomly forward queries through other RDNS servers
> in
> order to obscure the real source of a query, then i'm in favour of it.
The original idea is to reduce the load of resolver for recursion. The
privacy feature you proposed is a good point we can include in the
requirement draft.
> it's long been known that ECS is a privacy nightmare; we must obsolete it
> and also
> erase set-associativity currently available by non-anycasted RDNS servers.
What do you mean by set-associativity of non-anycasted RDNS servers?
> i'd like to see a world where every house, every VM cluster (including
> laptops
> like mine) can run their own recursive validating iterating caching DNS
> server
> and have almost none of those queries reach an ADNS server with any sort
> of
> topology or other identifying characteristics. we (you) should do this
> also. i
> think it would be _very_ popular in these anti- pervasive monitoring times.
>
The concentration of Resolver seems like a tread nowadays. Privacy is one
concern, the other concern is the HA of resolver even if all resolvers are
run by one operator.
> > > 3. A resolver/authoritative server mode serving Apps via DoH or other
> > > Application-level DNS. Operators of apps can edit each response on
> demand
> > > and propagate the changes of DNS RR in seconds. It also provides a
> private
> > > zone and names for each Apps.
>
> i think a correct and complete microtransfer / lease method as described
> for
> #1 above would answer this App level requirement, and that working on this
> requirement discretely would qualify as unnecessary systemic complexity.
>
>
It's fine
> > > 4. A Hybrid DNS which is used as a name server but cache and pull the
> > > authoritative data from another authoritative server. It provides an
> > > approach to easily scale the system without any change of existing
> > > authoritative DNS.
>
> i think ralf's observation (below) applies here. existing RDNS
> implementations
> already do this. i think it's justified for NS/DS, glue, key and signature
> chains needed to re-fetch and re-validate high-usage cache content, and
> that
> it may also be justified for high-usage content itself. but if it's to
> become
> a standard, it should be part of #1 above ("if the ADNS doesn't agree to
> share
> a NOTIFY TSIG key") rather than pursued independently.
>
> OK
i think DNSOP is the wrong working group, and that the IRTF would be better
> at
> this early stage. however, if you begin the work, several of us will
> contribute
>
OK. We can draft a document with requirements and gap analysis first.
Again, thank you for your comments and support.
Davey
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
