In message <d124b0ce.9a2e%edward.le...@icann.org>, Edward Lewis writes: > Content-transfer-encoding: 7bit > > ...to prevent another DS<-->DNSKEY mishap from happening again? > > I'm presenting the message to the DNS Operations list of DNS-OARC. (Being > subscribed to so many DNS lists I keep forgetting if I'm acting as an IETF > participant or talking as a past operator of DNS or as ....) > > In short, think about when a name server loads a zone with a DNSKEY set in > it. If, at the parent zone, there is a DS set and none of it's contents > refer to a record in the DNSKEY set, all DNSSEC validating queries will > declare everything in the zone broken. > > So, why can't the name server find the DS set, run a check and barf if > there's a problem? Barf - either refusing to load the zone or refusing to > change the zone that is already running.
Why don't we just implement TSIG signed updates to the parent and send a UPDATE message to the parent? What is so hard about a username/password pair which is all that TSIG is. > Here are some impediments: > > 1) The entity responsible for the set up is not likely to be a programmer. Doesn't matter. People do username/password pairs all the time. > 2) Authoritative servers don't launch queries. Has NEVER been true. SOA/IXFR queries are done regularly by authoritative servers. For over the last decade queries for nameserver addresses have been done for NOTIFY. > 3) Authoritative servers don't know anything about the parent zone. Discoverable. > 4) The owners of the zone and the operator of the DNS are not always the > same entity (person, company). Doesn't matter. > #1 - The implications of this is - tools/components are needed. One option > are management/diagnostic tools. Another option is an embedded in the name > server component. More tools is great when you are the jockey, more > embedded components is great when you are the customer. > > #2 - Software can do what it wants - but sometimes hidden masters are > shielded with the public Internet. (I'll assume the case is that the parent > and child zones are on separate sets of machines - when this is't true, we > don't have the problem.) I bet though, that it wouldn't be hard to convince > the operators of hidden masters to allow them access port 53 outside the > firewall. > > #3 - There's a brute force way to overcome this, come down the root to find > the cut point. Or this can be configured somehow (but I hate pinning). Or > maybe just doing a straight forward use of a validating recursive server > (but that's more tools, see #1). > > #4 - This is a critical aspect of the problem. Even if the customer tells > the DNS hosting company to roll keys, the customer has to be the one who > finds the registrar to ensure the DS set is correct in the registry. That's > four participants with the most important (customer) the least capable (or > they probably wouldn't be a customer). Failing to automate away the > customer's problem will kill the effort, certainly stall scaling. > > The first step is for the operations community to cobble together a solution > to this problem. Perhaps a proposal goes to the IETF for the proper review > and legal protection. And if there's a need to change other policies, an > IETF document might be the greatest asset. > > This is one way to make DNSSEC less clumsy. > > Please - if there are more impediments, suggest them. I may have missed > something. If you disagree with an impediment, speak out. I've already submitted a draft that would make this all possible. Sending signed UPDATE messages is relatively trivial. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs