Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

On Tue, Jun 19, 2018 at 4:47 PM, Lanlan Pan <abbypan@gmail.com> wrote:

>
>
> Petr Špaček <petr.spacek@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.

>
>> 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