Re: [Bundled-domain-names] A suggestion for 2017

In message <alpine.OSX.2.11.1612301239370.43575@ary.qy>, "John R Levine" writes
:
> On Fri, 30 Dec 2016, tjw ietf wrote:
> > I would love to see a solid draft appear that discussed 'CNAME at APEX' in
> > an attempt to standardize what every vendor has been working on.
> 
> It would be nice, but it's a big can o' worms.  The issue is that the DNS 
> has two separate and only loosely connected parts.  The larger part is the 
> binary query/response protocol which everyone implements, since any DNS 
> client in principle has to be able to query any DNS server and understand 
> the response.
> 
> The other part is the master file format and AXFR and IXFR or whatever you 
> use to provide zone files or zone-file-like-things to your authoritative 
> servers.  You can use whatever you want since only your own authoritative 
> servers need to understand each other.  So while a lot of servers use the 
> 1034/1035 master file format and AXFR/IXFR, a lot don't.  They may use 
> some other format (djbdns) or they may use a database (powerdns) or they 
> may invent them on the fly (various hacks at Cloudflare and other places.) 
> They may use rsync or database replication or something else to keep the 
> servers in sync.
> 
> So while there are a lot of places with an ANAME hack (which is useful 
> more places than pseudo-cname at the apex), the way they do it depends on 
> a lot of stuff beyond what you can put in a master file.
> 
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
> 
> _______________________________________________
> Bundled-domain-names mailing list
> Bundled-domain-names@ietf.org
> https://www.ietf.org/mailman/listinfo/bundled-domain-names

And 99.99% of ANAME/CNAME at the apex would be better solved with
a "name to server name" record that is application specific.  That
is what the ANAME/CNAME is being used for.  We tried to do a generic
record with SRV but people didn't take it up for http.

"name ANAME server" would become a collection of A, AAAA and HTTPSRV
records (rather than a collection of A and AAAA records) with the
aim to retire the ANAME processing at date <TBD>.  Any existing ANAME
construct would become just HTTPSRV as of that date.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org