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

Anthony Eden <anthony.eden@dnsimple.com>于2018年6月20日周三 上午12:06写道：

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

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