[DNSOP] opportunistic semi-authoritative caching (Re: DNSOP Call for Adoption - draft-tale-dnsop-serve-stale)

[Paul Vixie <[e-mail]>]

note, there's a proposal contained here.

Jared Mauch wrote:
> On Thu, Sep 07, 2017 at 01:29:47PM -0700, Paul Vixie wrote:
>> if the draft being considered was clear on two points, i'd support adoption.
>>
>> ...
>
> 	Would you see the querying application informing you of intent via
> option code saying "If I'm unable to talk to you once TTL expires, I may serve
> your last known good answer"?

i don't think so. if it was "may i serve your last good answer?" then 
yes. but with it as "i may" and the ? outside the quotes as shown above, 
then no.

> 	What would a server then do if this intent were known?  serve some
> alternate data, or even return REFUSED?  I could see sending a secure notify
> to anyone who requested the QNAME after change, but holding this state may
> end up with complexity similar to what's some have seen with ECS.

this whole approach is incredibly unappealing. as i wrote to jinmei earlier:

> i think the actual problem statement is broader, and that by solving for this
> narrow version, we would lose the complexity/capability tradeoff -- we'd add
> more state and more signaling at a cost higher than what we would get for it.
>
> it's a general reachability problem not specifically ddos problem. reasons for
> not being able to refresh data in a cache include ddos, but also backhoes,
> wire cutters, squirrels, circuit breakers, and bad design/provisioning.
>
> i think the right answer will look like a miniature version of IXFR/AXFR and
> NOTIFY, such that a cache can register its intent to become a partial stealth
> secondary server, and by participating, an authority server can both indicate
> its willingness to have this done, and possibly remember what was transmitted
> so as to facilitate subsequent cache invalidation or zone change notification
> messaging. one could even imagine a dns cookie exchange at the outset, to help
> authenticate later messages. sort of a super-lightweight session protocol.
>
> when the DNS was first popularized, we were using a lot of computers with less
> than four megabytes of memory and fewer than a million instructions per
> second, and our links were thought fast if 56K DDS, or super-fast if 1.544M T1
> or even 2.0M E1. this drove choices of how to encode, how to compress, where
> to synthesize, and whether to authenticate. all of those choices should be up
> for reconsideration now.
>
> if our _vision_ as a technical community is to have little chunks of semi-
> authoritative data cached in stealth-like secondary-like places, and then kept
> up to date, then we should pursue that, because moore's law and the
> privatization and commercialization of the internet have made it now
> practical.

in other words i'd like to solve both partitioning/reachabilities not 
just one. not just "i can't reach a remote server due to a partition" 
but also "i can't learn the role and address of nearby servers due to a 
partition". i guess you could call it "opportunistic semi-authoritative 
caching".

the heuristic for deciding what to cache is probably popularity, but 
also, NS/A/AAAA chains, and also, the full contents of the root zone.

it would only be allowed if dns cookies were exchanged, since i don't 
think we should spam people with notifies after receiving a spoofed 
source stealth-service request.

the desire to stealth-serve would be encoded in an EDNS option bit, 
which if answered in the affirmative, would lead to a REQUEST-NOTIFY 
message that specified the RR-NAME of interest, and an enum saying 
whether it's all RR-SETs there, or just a couple of them, or whether 
it's the whole zone.

this would be in-band content monitoring. a "push" form of DNS. it would 
solve two disconnection problems (distant server unreachable, and also, 
nearby server unidentifiable). it would solve the "root servers might be 
ddos'd or otherwise unreachable" problem without any of the 
configuration hackery specified in RFC 7707. it would not lead to stale 
data. it would not require detailed DNS or server knowledge by an rdns 
operator. in fact it could be put into the middleboxes (wifi, cable, 
dsl) who insist on doing RDNS service now.

it could even be integrated with forwarding.

moore's law, and the internet economy, have been kind. let's use the 
resources we've been given, to come up with a DNS that actually does 
what we want, and doesn't add more static configuration state.

-- 
P Vixie