Subject: Re: [DNSOP] Any website publishers who use CDNs on the list? Date: Fri, Nov 02, 2018 at 01:11:08PM +0100 Quoting Måns Nilsson (mansa...@besserwisser.org): > Subject: [DNSOP] Any website publishers who use CDNs on the list? Date: Fri, > Nov 02, 2018 at 10:57:33AM +0000 Quoting Dan York (y...@isoc.org): > > DNSOP subscribers, > > > > Are there any other publishers of websites on this list who use CDNs in > > front of their sites - and who are interested in the whole “CNAME at apex” > > issue? > > I am employed by an organisation who does this. > > I strongly oppose any work being done to slacken the restrictions around > CNAMES. At least in order to bodge together a fix for the "CDN problem".
And, now that I've read the backlog, I'd like to apologize for not having done that before, and also point out that I still, more so than before actually, count ANAME as a prime example of a bodge fix to the "CNAME on apex" issue. I have also read the draft. It made me realise that there is more Heath Robinson[0] than I ever could imagine in ANAME. Jumping in and out of secure, signing on the fly, sometimes, et c. It bears all the telltales of a reactive development. It is not that I don't realise there is a need to do /something/. CNAMES don't work for most scenarios. At the risk of sounding like a repetitive bore, what is actually needed is a way to say "for that domain name, apex or not, https[1] services are over there ---->". Without messing up the entire node in the tree and causing special processing in every name server and full service resolver. And without stomping the other interesting protocols that might like a RR on the node to be found. The entire effect that ANAME is supposed to have is achieved easier by publishing URI records. And by getting web browsers to ask for URI first. As a bonus, load balancers that send 302's (which by the way are much faster than DNS resolution, or so I'm told) can listen on 1000s of ports, because we do not have to point to 443 and listen on 80 as backup when we can specify the port and the protocol in the URI RR payload. DNSSEC compatibility? The node we're pointing to can be in another zone or in the same zone. Signed or not. Either way, we have predictable behaviour. If we need dynamic data along the way, we can push that work where it belongs, by putting the service names (domain name part in the URI we point to) in a special zone, perhaps run by the CDN. And the CDN can run a dynamic signed zone on every anycast master if they so wish. Without making much more of a mess than today. All this in RR's that exist today and can be deployed tomorrow. "Warum einfach, wenn es auch kompliziert geht?" -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 I'm having a RELIGIOUS EXPERIENCE ... and I don't take any DRUGS [0] "Rube Goldberg" to those from USA. [1] Or whatever, but we've bred a generation of devloprs (sic) who are unable to network without HTTP.
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop