Re: [DNSOP] Making domains work even when connectivity fails (Was: the root is not special, everybody please stop obsessing over it

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 <paul@redbarn.org> wrote:

>
>
> Stephane Bortzmeyer wrote on 2019-02-15 06:34:
> > On Fri, Feb 15, 2019 at 09:29:29AM -0500,
> >   Bob Harold <rharolde@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
>