Hi Shumon, On Wed, Apr 22, 2020 at 12:32 PM Shumon Huque <shu...@gmail.com> 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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop