Commenting on deployment... On May 20, 2014, at 11:11 PM, Mark Andrews <ma...@isc.org<mailto:ma...@isc.org>> wrote:
In message <537c15b4.2000...@necom830.hpcl.titech.ac.jp<http://hpcl.titech.ac.jp>>, Masataka Ohta writes: Mark Andrews wrote: The reason why CNAME is prohibited at a zone apex is described in RFC 1034: If we must change something, isn't it easier to allow CNAME at a zone apex than introducing ENAME? No. They are roughly equally difficult and allowing CNAME at the apex still won't solve CNAME + MX or CNAME + DNAME or CNAME + TXT or CNAME + just about any other type. The zone apex has lots of data stored at it. You have to update validators. You have to do a DNSSEC algorithm bump. You need to update signers and authoritative servers to enforce the algorithm bump. You have to update recursive servers to know about the new CNAME semantics. You have to have a transition strategy. ... which means it may take many years for it to happen (IF it happens). I actually like the idea of the ENAME record, mostly because I find it simpler to configure, but I do wonder how we would ever get it deployed. Over the past couple of years as we've been looking at what we can do to accelerate DNSSEC deployment, one of the barriers has been that many registrars and DNS hosting providers have simply not provided the ability for customers to enter in DNSSEC-related records through the GUIs that the customers use. For instance, they can't enter in a DS record. There is no way for them to do this. I still have this problem with one of the registrars I use for several of my domains. And when I've contacted registrars about why they haven't offered it there are the usual litany of excuses about how customers aren't asking for it, there's no business case, they don't want to add a field that might cause support issues, etc., etc. This is changing now... but a major reason is probably that ICANN mandated that registrars had to support accepting these records (DS/DNSKEY) as part of the 2013 Registrar Accreditation Agreement (RAA). Similarly, a few years back I had issues with several DNS hosting providers that were providing no way to enter AAAA records. So if you wanted IPv6 you had to use a different DNS provider. I haven't really looked... but I wonder how many DNS hosting providers do allow the entry of DNAME records. (I just checked... and mine *does*, which is good.) Many of us here on this list have no problem whatsoever running our own DNS servers, editing zone files (by hand, even), and other normal sysadmin things... this stuff is trivial for most/many of us. But for "regular" users out there, they don't care about any of that. All they want to do is have a website and email that works. They just registered "toms.plumbing" and want to point that to their website... and ideally they'd like to do that WITHOUT the "www." on the front. They want to go to their DNS hosting provider and enter the appropriate info in the GUI and just have it work. If we are suggesting adding a new ENAME record, I think we need to think about how it will get out there to all the DNS hosting vendors - and also *why* they might be motivated to do so. Similarly, with SRV records, I think part of the challenge is just helping people to understand what they have to do to configure them. A CNAME record is super easy and simple to enter. A SRV record is a lot more complicated: _sip._tcp.example.com<http://tcp.example.com> 86400 IN SRV 10 10 5060 sipsvr.example.com<http://sipsvr.example.com>. I don't even remember the format without looking it up... and while I understand the value of the priority and weighting fields, I don't think most people will care. And yes, this is something that DNS hosting providers could conceivably hide behind a menu choice about redirecting your domain to another website or something like that. But the DNS hosting provider has to do that... or more precisely the software they use has to do it. The SRV records, at least, do seem to be supported by DNS hosting providers. We'd just need applications and services to actually *use* them. Personally, I wish we *could* just add a simple CNAME record at the zone apex... but I do understand why we can't in terms of the need to also support other services like email. Whatever we come up with needs to be simple enough that DNS hosting providers can make it easily available to customers without having to make significant changes or incurring support issues. My 2 cents, Dan P.S. I think the larger challenge for ENAME will be to get validators updated. We're having a big enough challenge right now getting DNS resolvers updated to do DNSSEC validation - largely because DNS resolvers are installed on a ton of boxes like "home routers" that almost never get updated. The path to getting those updated may involve replacement lifecycles on the level of years. -- Dan York Senior Content Strategist, Internet Society y...@isoc.org<mailto:y...@isoc.org> +1-802-735-1624 Jabber: y...@jabber.isoc.org<mailto:y...@jabber.isoc.org> Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
