Re: [DNSOP] Any website publishers who use CDNs on the list?

[Måns Nilsson <[e-mail]>]

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 ([e-mail]):
> Subject: [DNSOP] Any website publishers who use CDNs on the list? Date: Fri, Nov 02, 2018 at 10:57:33AM +0000 Quoting Dan York ([e-mail]):
> > 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            [phone]
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.