Anthony Eden <anthony.e...@dnsimple.com>于2018年6月20日周三 上午12:06写道：
> On Tue, Jun 19, 2018 at 4:47 PM, Lanlan Pan <abby...@gmail.com> wrote: > >> >> >> Petr Špaček <petr.spa...@nic.cz>于2018年6月19日周二 下午9:19写道： >> >>> 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). >>> >> I think ANAME RR is hard to compatible with many old version resolvers. >> If there are mutiple ANAME RR at compatible resolvers, authoritatives may >> not know that resolvers will choose which A RR for client response. >> >> ANAME can ease apex CNAME configuration, maybe a work round is that >> authoritatives directly return A RR to resolvers (but not ANAME RR). >> > > This is essentially what those of us who implemented ANAME in > authoritative name servers do right now. The original draft I started about > ALIAS records also spelled out only this solution with some operational > guidance on best practices. > Section 4. Recursive Server Behavior: send client subnet when query ANAME target ? Would it be simpler director send client subnet when first query ? Anyway, one of ANAME's benefits is that it can return both AAAA and A in one response. > >> >>> 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 >>> >> -- >> 致礼 Best Regards >> >> 潘蓝兰 Pan Lanlan >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> >> > > > -- > DNSimple.com > http://dnsimple.com/ > Twitter: @dnsimple > -- 致礼 Best Regards 潘蓝兰 Pan Lanlan
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
