[dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode
paul at redbarn.org
Sat Apr 4 18:18:08 UTC 2020
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:
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.
More information about the dns-operations