Multicast NOTIFY? You mean like RFC 6804, or RFC 7558. Use of a subscription model or lease still depends on reachability and when you don't have that, you have two choices, use a stale lease or abandon it. Take your pick.
/Wm On Fri, Feb 15, 2019 at 8:44 AM Paul Vixie <p...@redbarn.org> wrote: > > > Stephane Bortzmeyer wrote on 2019-02-15 06:34: > > On Fri, Feb 15, 2019 at 09:29:29AM -0500, > > Bob Harold <rharo...@umich.edu> wrote > > a message of 73 lines which said: > > > >> I think in most solutions, if the name servers for " > >> malware-c-and-c-as-a-service.com" and "com" are both unreachable, > >> the domain should continue to resolve. But if "com" is reachable, > >> and says " malware-c-and-c-as-a-service.com" no longer exists, it > >> should go away. > > this is why serve-stale is most wrong. permission, and an agreement to > hear a trusted NOTIFY later if the authority wants to do the work of > keeping track of who it told things to, and the work of telling them > when something has importantly changed (like a glue address change, a > name server change, a key change, a signature invalidated, or malware > removed). this is a subscription (leasing) problem, not a caching one. > > > Any volunteer to write a problem statement for the "VIX.SU issue"? > > Short version: "when I'm on the same network that at least one > > authoritative name server of VIX.SU, I want this domain to work, even > if there > > is zero Internet connectivity to the outside world" Longer version: > > "TODO (think of: is it automatic or not, does it require prior access > > or not, phantom domains, etc)" > > just as root-level is the wrong focus, so is local-level. the reason we > don't solve this problem with multicast NOTIFY is that the information > you may need a subscription to (due to potential network partitioning) > could be in another campus, or another region, or another isp, or > another country. > > -- > P Vixie > > _______________________________________________ > 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
