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

[Mark Andrews <[e-mail]>]

> On 17 Sep 2018, at 5:43 pm, Mukund Sivaraman <[e-mail]> wrote:
> 
> Hi Stephane
> 
> On Mon, Sep 17, 2018 at 09:14:14AM +0200, Stephane Bortzmeyer wrote:
>> On Sun, Sep 16, 2018 at 03:26:56PM +0530,
>> Mukund Sivaraman <[e-mail]> wrote 
>> a message of 66 lines which said:
>> 
>>> Adding resolver support (to resolvers that don't have it, i.e.,
>>> vs. RFC 1035) does not appear to break current DNS, i.e., it can be
>>> proposed now.
>> 
>> [Algorithm deleted]
>> 
>> The difficult thing is not to specify what the new resolvers will have
>> to do, but to describe what will happen with the current
>> resolvers. What will happen when "CNAME at apex" will be deployed,
>> assuming X % of the resolvers will not be upgraded?
> 
> I fully realise what you're saying.
> 
> The suggestion is only to require support in resolvers going forward for
> CNAME co-existing with other types for now. That should not break any
> detail of how DNS is used today.
> 
> Whether CNAME + other types at apex can be used in the future would be
> an operational decision for that time of the world.
> 
> Similar things can be said of other proposals.
> 
> * If SRV for HTTP is brought into use, what about X% of user agents that
>  don't have support for it?

Initially none.  That however doesn’t stop a site publishing SRV records for
itself.  They do no harm being published.  As browsers and other clients deploy
add SRV support they will use them.  If you have the SRV records point to
secondary addresses you can actually track the deployment of SRV in your
client population.

e.g.

example.com AAAA 2001:0DB8::1
_http._tcp.example.com SRV 0 0 80 server.example.net
server.example.net AAAA 2001:0DB8::2

I would also expect a relatively large client population using SRV records given
the rate Firefox and Chrome browsers are upgraded.  SRV lookups work for lots of
other protocols.  SRV records also make it through firewalls and IDS today.

Sites can look at the clients that are still using legacy A/AAAA records as well
as the user agent so they know who and what to target to get SRV support added.

There is no simple / reliable way to measure the client population support for
accepting CNAME co-existance.

> * If a new RR type is introduced, what about X% of resolvers that do not
>  support it?
> 
> Although it changes current DNS protocol, AFAICT there does not seem to
> be anything badly wrong with allowing CNAME + other types at a node,
> where the CNAME is considered a fallback when the required type doesn't
> exist.

Which is a matter of opinion.  Even if support was started today it would be
a decade at least, maybe two, before you could use MX + CNAME instead of
MX + A/AAAA synthesis.  DNS servers are just not upgraded that fast.

> Repeating what the original post's author Petr said, this seems to be a
> simpler change than adding other types for similar benefit, esp. when
> hacks are already necessary to workaround the case of CNAME and other
> types co-existing that are seen in the DNS.
> 
> 		Mukund
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]