Re: [DNSOP] New draft on delegation revalidation

[Gavin McCullagh <[e-mail]>]

Hi Shumon,

On Wed, Apr 22, 2020 at 12:32 PM Shumon Huque <[e-mail]> wrote:

But appreciating the subtleties of the DNS delegation mechanism involves a
> lot of arcane details that are not easy to understand for anyone. If the
> namespace is a tree, and zones are contiguous subtrees, how do you a
> visualize a zone cut in this data structure? It doesn't cleanly intersect
> any node or edge between nodes, but rather partitions the data sets located
> at a node in a weird, inconsistent fashion. Most apex RRsets live
> authoritatively at the node, but one has a copy in the parent zone, and one
> is authoritative in the parent. It's all very complicated.
>

I agree these things are complicated (and if I'm honest I may be missing
subtleties you aren't), but I don't think ordinary DNS users should need to
understand that level of detail to be able to work with delegations.  We
seem to have a choice here between the user needing to understand "the
parent must point at the child" versus understanding that "the parent must
point at the child which (usually) must point at itself".   Everyone I talk
to outside the DNS community seems to leap to the former conclusion.   I
doubt that will change.


> [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?


> You are right that the TTL control issue primarily comes up at the TLD/SLD
> level, but it is certainly not a corner case or that only affects a small
> minority, in my estimation.
>

I didn't mean to suggest the TLD/SLD is a corner case, it obviously
isn't.   I was trying to point out that the non-registrar case is also not
a corner case.   Both are common.  I suppose I am arguing that the case
where: [we have a TLD/SLD managed by an expert DNS operator who understands
how to (and is motivated to) manipulate child-centric resolvers to improve
redelegation safety] is really a corner case.  Perhaps not among the people
on this list, but over all delegations in the world, I'd say it is a very
tiny fraction.  And I'd prefer to optimize to simplify the rest.

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.

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?

Gavin