[dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode

[Paul Vixie]

On Saturday, 4 April 2020 17:45:49 UTC Doug Barton wrote:
> On 4/3/20 9:28 PM, Paul Vixie wrote:
> > the economy requires faster, easier takedown of domains. when a delegation
> > is revoked due to bad behaviour by a registrant, it has to die
> > _everywhere_ almost immediately. not sporadically depending on which
> > (above vs. below) NS RRset was cached, or on what TTL it had.
> > 
> > the overwhelming majority of newly created domains are used maliciously,
> > and die quickly after short, brutal lives. we have to make them as easy
> > to kill as to birth.
> 
> I agree with you, Paul, on most domains being bad; and that takedowns
> are often effective. However this is actually one reason not to prefer
> the child TTL, since the bad actors will simply crank up the TTL on
> their NS set to the max.
> 
> That said, I still want to prefer the child TTL. The parent delegation
> is not authoritative, it's just a referral. ...

somehow we're off track entirely, and using terms like parent-centric and 
child-centric. anyone using those terms hasn't read <https://www.ietf.org/
archive/id/draft-vixie-dnsext-resimprove-00.txt> so let me quote it for you:

> INTERNET-DRAFT                 2010-06-22                 DNS-RESIMPROVE
> 
> 2. Delegation Revalidation Upon NS RRSet Expiry
> 
>    2.1. Because the delegating NS RRset at the bottom of the parent zone
>    and the apex NS RRset in the child zone are unsynchronized, the TTL
>    of the parent's delegating NS RRset is meaningless. A child zone's
>    apex NS RRset is authoritative and thus has a higher cache
>    credibility than the parent's delegating NS RRset, so, the NS RRset
>    "below the cut" immediately replaces the parent's delegating NS RRset
>    in cache when an iterative caching DNS resolver crosses a zone cut.
>    
>    2.2. The lowest TTL found in a parent zone's delegating NS RRset
>    should be stored in the cache and used to trigger delegation
>    revalidation as follows.  Whenever a cached RRset is being considered
>    for use in a response, the cache should be walked upward toward the
>    root, looking for expired delegations. At the first expired
>    delegation encountered while walking upward toward the root,
>    revalidation should be triggered, putting the processing of dependent
>    queries on hold until validation is complete.
>    
>    2.3. To revalidate a delegation, the iterative caching DNS resolver
>    will forward the query that triggered revalidation to the nameservers
>    at the closest enclosing zone cut above the revalidation point. While
>    searching for these nameservers, additional revalidations may occur,
>    perhaps placing an entire chain of dependent queries on hold,
>    unwinding in downward order as revalidations closer to the root must
>    be complete before revalidations further from the root can begin.
>    
>    2.4. If a delegation can be revalidated at the same node, then the
>    old apex NS RRset should be deleted from cache and then the new
>    delegating NS RRset should be stored in cache. The minimum TTL from
>    the new delegating NS RRset should also be stored in cache to
>    facilitate future revalidations. This order of operations ensures
>    that the RRset credibility rules do not prevent the new delegating NS
>    RRset from entering the cache. It is expected that the child's apex
>    NS RRset will rapidly replace the parent's delegating NS RRset as
>    soon as iteration restarts after the revalidation event.
>    
>    2.5. If the new delegating NS RRset cannot be found (RCODE=NXDOMAIN)
>    or if there is a new zone cut at some different level of the
>    hierarchy (insertion or deletion of a delegation point above the
>    revalidation point) or if the new RRset shares no nameserver names in
>    common with the old one (indicating some kind of redelegation, which
>    is rare) then the cache should be purged of all names and RRsets at
>    or below the revalidation point. This facilitates redelegation or
>    revocation of a zone by a parent zone administrator, and also
>    conserves cache storage by deleting unreachable data.
>    
>    2.6. To make the timing of a revalidation event unpredictable from
>    the point of view of a potential cache-spoof attacker, the parent's
>    delegating NS RRset TTL should be reduced by a random fraction of its
>    value before being stored for use in revalidation activities.
> 
> Expires 2010-12-22                                              [Page 2]

normally i would ask, please tell me how that could be made more clear. 
however, that ship has sailed, and the result is a new draft:

https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01

as a named co-author of both drafts, i think it's itinerant upon you to avoid 
making any statement that presumes a "child-centric" or "parent-centric" view 
on my part. i see a role for both delegating and apex NS RRsets, and i think 
any recursion logic that ignores one in favour of the other is incomplete at 
best, but probably also wrong.

> The child should have the right to determine its own fate. This is
> especially true when it comes to preparing for a redelegation, but there
> are other reasons of course.

that right is preserved in both this year's revalidation draft and the 
original from 2010. so i don't know who you are arguing with but it is not me 
and in such case i'd thank you not to make such a statement while replying to 
text i wrote, as in the case of your message here.

> Regarding resolver operators who don't want to obey TTLs that they think
> are too short, they already have options to set minimums that work for
> them. That combined with the resolver otherwise obeying the child TTL
> makes everyone happy (and follows the protocol).

if you're going to argue against an internet-draft, please read it first.

-- 
Paul