In message <[email protected]>, Tim Wicinski writes: > > On 11/7/13 5:32 AM, Edward Lewis wrote: > > > > I'm confused by Mark's sentence beyond that comment. A registrant per > > se has no reason to do a DNS lookup so I don't get why "Registrant > > does a DNS lookup" is meaningful. The registrant's relying parties > > that do lookups. Using different terminology - customers of > > enterprises do the lookups, not the enterprises. Where the enterprise > > (registrant) has employed a DNS service provider and separately a > > registrar, the enterprise may be completely hands-off the DNS. And > > then there's the place the name is registered... > > > > One gap in such a scenario is bridging between the DNS service > > operator and the domain name registrar. Today there is absolutely no > > standard protocol (I mean "rules of engagement" not "XML/JSON-based > > language") there. > > > > ...I'm mindful of the wide range of use cases. I'm just focusing on > > one here that is still not addressed in any of the proposals I've seen > > to date. > > I believe that all these examples went out of their way to specifically > not address the DNS Service operator <-> domain name registrar bridge, > lest they be accused of trying to enforce a process upon those folks, > which would not take kindly to such things.
No my example covered service operator or anyone other M2M update which is what we are trying to achieve. The service operator has one or more TSIG which authenticates the updates he/she is permitted to make. Today with nameservers you can say this TSIG can update this <name,type> tuple and a second TSIG can update everything at <name> and a third TSIG can update the same name and a list other types a fourth TSIG can update name and all subdomains. Now when updating a parent zone you don't necessarially need all that flexability but you do need some of it. The Registrant establishes the update policy though the web interface and configures the software that will be doing the updates with the appropriate keys. This may be done directly or indirectly through the use of a agent. All that is required to do this is for the nameserver (or other piece of software with the ability to update the registry and hence the zone) performing the update have access to the private key and a description/table of what that key is permitted to do. Mark > > (FWIW, this is a necessary piece of work but I'm doubtful the answer > > lies within the port 53 protocol.) > > > > This may be the bigger discussion, and it may be the ultimate answer. > But (my opinion) is that we should do our due diligence. > > tim > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
