Re: [DNSOP] New draft on delegation revalidation

[Shumon Huque <[e-mail]>]

On Fri, Apr 24, 2020 at 6:21 PM Gavin McCullagh <[e-mail]>
wrote:

>
>
>> [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".  [...]
>>>
>>
>> Changing (a) properly requires re-designing the DNS delegation mechanism,
>> and sounds like a much more ambitious undertaking to me. I am actually
>> interested in looking at that myself, because there are certainly
>> deficiencies that could be addressed. Since delegation records and glue
>> address records are unsigned, they can be spoofed, and DNSSEC should really
>> allow us to detect such spoofing once a resolver sees referral data. And
>> not (as it now is), after being sent on a wild goose chase to a set of
>> rogue servers, and subsequently determining that those servers cannot
>> present a DNSKEY RRset that matches the parent DS. Fixing this, requires
>> creating a new delegation record type that can be signed in the parent. And
>> the TTL issue and delegation revalidation would then have to be assessed by
>> looking at both the child NS set and this new delegation record (although
>> for secure delegations, the DS set could likely be used in place of the
>> latter). And then figuring out the large work of how to deploy it Internet
>> wide.
>>
>
> I may be missing some subtlety here, but parent-centric resolvers seem to
> use the NS records and DS records from the parent zone today just fine.
> The DS is signed by the parent and provided in the same response as the
> referring NS record.  If the response was spoofed the DS rrsig wouldn't
> validate.   If the referring NS record needs to be signed, surely that
> should be designed into DNSSEC.  Are you saying you believe that
> parent-centric resolvers are insecure?
>

Hi Gavin,

I probably wasn't clear enough, but what I was saying is that changing the
definition of what side of the zone cut is authoritative is a rather
significant change to the protocol. And any proposal for such a change
would need to carry a high bar for acceptance. This would be a breaking
change for validators. Deployed code today already understands the
semantics and authoritative-or-not nature of the NS/DS sets and would need
to change. Lots of NS records on either side of zone cuts would need to
signed/unsigned. For large delegation centric zones that use opt-out, this
would also impose quite a significant cost. The non-disruptive, incremental
way to introduce such a change would be introduce a new delegation record.

There are two categories of unfortunate "surprises" we commonly see due to
>>> child centric resolvers.  [...]
>>>
>>
>> I would hope that making resolver behavior consistent would address most
>> of this. If all resolvers locked on to the authoritative NS set, then most
>> of the surprises would disappear (hopefully).
>>
>
> Things will break more reliably, for sure.   And I agree that consistency
> is better.   But it likely won't make it any easier for non-DNS geeks to
> understand why.
>

Thanks for sharing your experience. I suspect that if we asked a wide range
of folks, we would get differing experiences too. My own experience is
quite different than yours. At my employer, we do lots of DNS changes all
the time. We have ~ 3000 registered domains, and there are constant changes
related to moving between DNS providers (acquisitions, DNSSEC signing
requirements, and other reasons). I often find checklists that have steps
like: lower the zone NS TTL, make the changes, update the TLD via the
registrar interface/API, wait, raise the TTL. This is almost like DNS 101
to them, and I have had to step in explain that lowering the TTL may not
have the effect they expect. These are quite smart people, just not DNS
experts. They understand that there are parent and child NS records, that
they should take care to make sure they match. They are only vaguely aware
of glue records and when they are needed. They see how to set the TTL in
their zones, and expect that to be used. The registrar/registry interface
presents no TTL configuration knobs, so they are not even aware there is an
issue.

To give you another example, on several occasions in the past few years,
I've had to step in to repair an outage caused by teams deploying parent
and child zones on the same server, who didn't realize that the parent has
to have NS records at the child delegation points - a configuration which
accidentally worked, until a later time at which the parent zone was
migrated to another server and things broke.

So, I suspect your experience is not universal.


> 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 complexity.
>>>
>>
>> Based on history to date, it seems to be rather intractable, but I would
>> love to be proven wrong. The interfaces that registrars use to update
>> delegation records in the registries don't even offer any TTL configuration
>> option that I've seen (even if the registries were willing to support it).
>> Does the EPP DNS mapping even support setting TTL?
>>
>
> That's one way to approach it.   What I was thinking was, if the
> registries want to dictate the TTL, that seems understandable.  But in so
> doing, they could have a process where they dictate a lowered TTL (of their
> choice) for a period after each change, then raise it back up to normal in
> order to reduce the impact of mistakes/problems.   A "bake period"
> essentially.  The timers would be argued about of course, like all magic
> numbers, but something conservative like an hour would seem like a major
> improvement on today.  Hypothetically, would you consider that would
> improve your use case?
>

Based on my experience, I doubt that registries would do this. I could be
wrong though, and perhaps we should ask and get them to respond to your
suggestion. But to answer your last question, the draft that has been
proposed is not about improving my own personal use case(s).

Shumon.