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 <m...@mukund.org> 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?
* 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.
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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
