Oh, what about this? https://tools.ietf.org/html/draft-sury-dnsext-cname-dname-00
:-) O. -- Ondřej Surý ond...@isc.org > On 19 Jun 2018, at 15:18, Petr Špaček <petr.spa...@nic.cz> wrote: > > Hello dnsop, > > beware, material in this e-mail might cause your head to explode :-) > > This proposal is based on following observations: > - It seems that DNS protocol police lost battle about CNAME at apex, > is is deployed on the Internet. > - Major DNS resolvers like BIND, Unbound, PowerDNS Recursor, dnsmasq > already have code to cope with the "impossible" case of CNAME at the > apex and deal with it in ways which do not break stuff on resolver > side. > - Authoritative servers of vendors named above refuse to serve CNAME at > apex. > - There are CDNs etc. which allow users to create CNAME at apex > no matter what the standards and "normal" servers say and do. > (We have found out this because Knot Resolver is missing hacks for CNAME > at apex and users complain that "it works with every other resolver".) > > > Take a deep breath! > > > Given that resolver side somehow works already ... > could we standardize this obvious violation of RFC 1035? > > It is very clear violation of the standard, but almost everyone found > his way around it using different hacks. These hacks are not going away > because all the CDNs just don't care about standards so we will have > to maintain this code no matter what a great solution we will invent for > future. I.e. adding ANAME will just increase complexity because CNAME at apex > will be there for a long time (if not forever). > > I personally do not like this but it seems better to think though > corner cases in code we already have in production (i.e. think through > current hacks for CNAME at apex) instead of inventing new things like ANAME > (or whatever else). > > Opinions? Tomatoes? Can it work? If not, why not? > > -- > Petr Špacek @ CZ.NIC > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
