Grant Taylor wrote on 2019-02-14 18:27:
Please explain how "warm storage" relates to priming issues. Does
warm mean that it's something you have queried? Or does it also
include pertinent (meta)data for interesting things (but not
everything) that you've not yet queried?
i don't expect anyone to store anything they have not queried, though
it's natural for an implementation to permit an operator to statically
define other targets as well, much as mark andrews did with "stub" zones
starting in 1990 or so in BIND4.
Does "still reach all internet resources on my side of the break"
include things that you've not yet queried for?
no. while there may be some kind of persistent storage of long term
popularity information so that things that were ever warm can be kept
warm even if not queried since the last reboot cycle, i do not expect
any tree-walking exercises. my long term study of RDNS tells me that
there is a high correlation between past and future queries. if some
query tries to occur during a connectivity break, it might fail, and in
that sense it's a DNS problem we've always had, that i'm not solving.
...
How close would something like this be to what you're wanting to
see?
i think leasing behaviour is expensive on a network-wide basis, and
should be limited to high-value data, by which i mean metadata needed to
reach and trust name servers. so, DS/NS, DNSKEY/RRSIG, and related
AAAA/A. i do not foresee remembering non-metadata information, no matter
how popular, since it's in a content operator's power to put a copy of
their DNS infrastructure inside any region that also has a copy of its
services. it's only third party metadata, like the delegation and trust
chain, that is an unmanageable risk today.
also note, i would not propose invalidation on its own merits, because
the cost of the data-state and trust-state is too high. however, if we
have to maintain that state anyway, for leasing, then invalidation is
approximately free, depending on the priorities of the authority server
operator. therefore, it becomes a package deal, one stone, two birds.
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
