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