Re: [DNSOP] New draft on delegation revalidation

Gavin McCullagh <> Mon, 20 April 2020 17:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CA2D33A0C09 for <>; Mon, 20 Apr 2020 10:30:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.186
X-Spam-Status: No, score=-0.186 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UqUxRxZFxwIM for <>; Mon, 20 Apr 2020 10:30:49 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 59AED3A0BED for <>; Mon, 20 Apr 2020 10:27:40 -0700 (PDT)
Received: by with SMTP id u189so6020358ilc.4 for <>; Mon, 20 Apr 2020 10:27:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cxQt8oz+w2XdOJXnCvMR+oQrGsPWGRKNsaMa6CAlARs=; b=n6PEBo10VPeXnQj+6eI/NXMq9BHCO21Pk/jCh0meor9cElImity8GjYYQRLcoOGR7E KOd9AvrFVoYkIM/hTGOrfrax4KI0+h9EY15Z7PLSr+iOwSReTzdrpK87N46F5oSEr81h fWHPPc7tfIpEADECimVTaySfnu6zuWPPDmH8HZruzV4CDVRVQcYrpvqg8N1yow/5jkW6 xKfbmxLcieIAT9VDyUvlkFmxyT7bjHX5Tu+36k9gkCyscjO9yqAf9r5NOiVA9JFWSK+B vBML6qSTYZatOaXZ8panOqpANTQoIiTQw+qEYw5MlZuC+kjiVZdAH5U1mGnI4jkHCS8V g/1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cxQt8oz+w2XdOJXnCvMR+oQrGsPWGRKNsaMa6CAlARs=; b=naFA3g48T45dUxKW9xe4h4k6KwHglmV+tuEKeWDaQgXRE0AndTECapSYoXgj5BsIsh xiNE4rqcXwsAjZfJOIEXVaOH/5lxHCvRwXMwMNu9rPWvokALvNzy5lv02Hb2+ysAYE7B f6h3O9GDZugb5EgLvxc/ceFuoYVtJHYeopUG+FOu6Er/aoKqldBPp7bCvVM4N1jzm/ei O2JdSymIed/L9dcfSMREbxlh8+hhW6zFsqq90CIKvxgGiEuvf2Ihm6xkOurL0I3RbQT/ xGeXZSgueEQwo4hOAGPt4xPNicTiGGlhY/S7Q/LMCACUmaG+ivpj1bhJ72Z8xuemqmfb LAcg==
X-Gm-Message-State: AGi0Puagjrg6UsIbN3CWmtVTv6SFlYIq82SH7jxO7reGdb+pm8JRgpga sGMHGWA2FF65XNpEzHcCBR6y79ilSN5pIszKDO4=
X-Google-Smtp-Source: APiQypI5q2SabYlKyF4QWO8eokMrg6VzJkYiCXIN+wk57/iii8P+T/zVPxkOEkXb76BMdahBZUzbVK0qRdN09tos9A0=
X-Received: by 2002:a92:5f17:: with SMTP id t23mr16959547ilb.2.1587403658910; Mon, 20 Apr 2020 10:27:38 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Gavin McCullagh <>
Date: Mon, 20 Apr 2020 10:27:27 -0700
Message-ID: <>
To: Bob Harold <>
Cc: Shumon Huque <>, Tim Wicinski <>, " WG" <>
Content-Type: multipart/alternative; boundary="000000000000345edd05a3bc37e8"
Archived-At: <>
Subject: Re: [DNSOP] New draft on delegation revalidation
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Apr 2020 17:30:56 -0000


I'm new to posting on this list, so please accept my advance apologies if I
make any novice errors or posted this in the wrong place.  Apologies also
for the long email. :-)

I can't claim to have the same detailed knowledge of the protocol as the
authors of this draft.  All the same, I've been mulling this
child/parent-centric resolver question for a while and watching its impact
on our customers and developers.  This draft seems to resolve this question
with the conclusion that child-centric (non-sticky?) is the correct

Shumon Huque:
> There is a range of different behaviors in resolver implementations
> in this respect today, and it would be good if we could agree on
> more commonality.

I agree.  Having a predictable standard behavior (at least for recent,
well-behaved resolvers) is very desirable.

The recent thread on the DNS OARC list seemed to frame this question as a
trade off mostly of these points:

[a] saying the in-zone NS
is authoritative and more trustworthy.  (pro: child-centric)
[b] flexibility for DNS operators to lower the effective TTL on a
delegation during changes despite registries fixing their TTL.   (pro:
     Paragraph 4 in
[c] the additional complexity resolvers will have to bear  (pro:
[d] making resolution deterministic  (pro: parent-centric)

I'd like to draw attention to a fifth item which I haven't see addressed.

[e] obeying the principle of least astonishment for mortal DNS operators
who do not understand this subtlety (and who I assume are the overwhelming
majority).  (pro: parent-centric)

The child-centric resolver behaviour applied by many resolvers today is
probably clear to most who reads this list and DNS OARC.   But it's very
counter-intuitive to everyone else.  In my experience the overwhelming
majority of people operating DNS do not understand this very subtle point.
They all tend to assume the parent-centric behaviour.  Perhaps that's
because many of them have a software developer background and are familiar
with tree data structures and linked lists.  Put another way, child-centric
resolvers effectively insist on there being two sources of truth for a
delegation, which is very surprising.

My organization tends to operate with every team being enabled (and
expected) to own their own service, including its DNS, so we have a lot of
software developers and others who don't have time or inclination to read
DNS RFCs and books dealing with DNS but still need to do it.  We delegate
domains at multiple levels to give people that autonomy.  We're also a DNS
vendor for many public customers.  I've seen lots of outages and security
issues either caused by or prolonged by people surprised by child-centric
resolver behaviour.   So much so, that I am inclined to prefer

[a] seems like a definition which could be changed if it was so decided.
DS records are totally parent centric for example.  It seems like NS could
be too if we declared the in-zone NS to be "informational only".  I
understand the desire for [b], but it seems to propose to dictate a
specific behavior at every level of delegation in order to work around a
problem that only exists with second level delegations (those managed by
registries).  In so doing, it optimizes for an arcane but admittedly useful
flexibility that only a tiny minority of DNS operators will ever understand
how to use.  At the same time, we'd be standardizing on behavior that
surprises the majority of operators and at times causes them (or at least
leads them into) outages, even when they are working at a 3rd or 4th level
delegation (ie not a registry).

There are two categories of unfortunate "surprises" we commonly see due to
child centric resolvers.  The first surprise is that when redelegating a
third level domain, it's obvious to moderately experienced operators that
they must lower the parent NS TTL in order to get a fast rollback, but as
they don't realise the in-zone NS takes over, they don't lower that TTL.
Now their fast rollback plan is ineffective on child-centric resolvers.
It's great to see in this draft that the "delegation revalidation" section
of the draft seems to solve that sharp edge by choosing the minimum TTL at
the delegation.  If we conclude we must have child-centric behaviour, this
at least makes it safer than today.   But still the misunderstanding points
to the surprising behaviour of child-centric resolvers.   The second
surprise category are a variety of subtle misconfigurations which we have
seen at the in-zone NS which operators don't understand (copying the NS
from the previous zone, altering the NS in an effort to get a full sideways
delegation, just plain errors, etc).  When we explain these problems, our
customers say "but the child NS isn't used for delegation, what are you
talking about?".   "dig +trace" also ignores the in-zone NSes (that could
be fixed of course, but it reinforces how people think about delegations).

It probably shouldn't drive the decision, but choosing parent-centric will
also remove the problems outlined in the draft around non-compliant dns
implementations which don't answer NS or do so incorrectly.  That's not
critical, but it will make life easier.  The original reason those
implementations exist is very likely due to the odd "two sources of truth"
situation we're in.  If the in-zone NS becoms "informational only", that
non-compliance will probably continue, but it will become less of an issue.

So, to summarize, compared with today, I think the draft as written would
be an improvement as it will bring consistency.  Delegation revalidation
will also remove a sharp edge which causes problems for less experienced
DNS operators in a world of child-centric resolvers.  However, on balance,
I would suggest it would be better to optimize for DNS delegations which
are "intuitive for the majority of dns operators" instead of "flexible for
a (tiny?) minority".  I think parent-centric is a better choice for DNS and
I don't think registries should force the DNS standard into making a
Sophie's Choice like this.

I hope this helps,

PS How truly intractible is the registry argument?  It seems something like
"When an NS change is made, TTL=3600 for the first N hours, then 2 days
thereafter." would be a major step forward without drastically increasing

On Tue, Apr 14, 2020 at 8:24 AM Bob Harold <> wrote:

> On Mon, Apr 13, 2020 at 4:59 PM Shumon Huque <> wrote:
>> On Fri, Apr 10, 2020 at 12:51 PM Bob Harold <
>> <>> wrote:
>>> Having read through the draft, and twice through the emails, I think the
>>> draft has the right balance in using the parent and child NS RRsets
>>> properly.
>>> I think the "extra" query for the child NS, sent once per parent TTL, is
>>> a savings over the older method of sending the NS records as "additional
>>> data" in every response.
>> Thank you Bob. I just want to qualify your last observation a bit - the
>> extra query would be once per minimum of parent and child TTL, roughly.
>> Shumon.
> Ah, yes, thanks for the correction.
> --
> Bob Harold
> _______________________________________________
> DNSOP mailing list