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

2018-09-17 Thread Mark Andrews
> On 17 Sep 2018, at 5:43 pm, Mukund Sivaraman 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 wrote >> a message of 66 lines which said: >> >>> Adding resolver support (to

[DNSOP] Protocol Action: 'DNS Terminology' to Best Current Practice (draft-ietf-dnsop-terminology-bis-14.txt)

2018-09-17 Thread The IESG
The IESG has approved the following document: - 'DNS Terminology' (draft-ietf-dnsop-terminology-bis-14.txt) as Best Current Practice This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Ignas Bagdonas. A URL of this

[DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-session-signal-15: (with DISCUSS and COMMENT)

2018-09-17 Thread Benjamin Kaduk
Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-session-signal-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer

[DNSOP] Protocol Action: 'Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY' to Proposed Standard (draft-ietf-dnsop-refuse-any-07.txt)

2018-09-17 Thread The IESG
The IESG has approved the following document: - 'Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY' (draft-ietf-dnsop-refuse-any-07.txt) as Proposed Standard This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren

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

2018-09-17 Thread Mukund Sivaraman
Hi Evan On Mon, Sep 17, 2018 at 04:11:24PM +, Evan Hunt wrote: > On Mon, Sep 17, 2018 at 01:13:27PM +0530, Mukund Sivaraman wrote: > > 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

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

2018-09-17 Thread Evan Hunt
On Mon, Sep 17, 2018 at 01:13:27PM +0530, Mukund Sivaraman wrote: > 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

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

2018-09-17 Thread Mukund Sivaraman
Hi Petr On Mon, Sep 17, 2018 at 12:29:13PM +0200, Petr Špaček wrote: > Originally I thought that current workarounds for CNAME at apex (which > are almost everywhere) deal with it in a more deterministic way. Do you mean the current workarounds in resolver implementations? These can be brought

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

2018-09-17 Thread Petr Špaček
On 17/09/2018 11:30, Mukund Sivaraman wrote: > Hi Ray > > On Mon, Sep 17, 2018 at 09:47:50AM +0100, Ray Bellis wrote: >> On 17/09/2018 08:43, Mukund Sivaraman wrote: >> >>> The suggestion is only to require support in resolvers going forward for >>> CNAME co-existing with other types for now.

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

2018-09-17 Thread Mukund Sivaraman
Hi Ray On Mon, Sep 17, 2018 at 09:47:50AM +0100, Ray Bellis wrote: > On 17/09/2018 08:43, Mukund Sivaraman wrote: > > > 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

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

2018-09-17 Thread Ray Bellis
On 17/09/2018 08:43, Mukund Sivaraman wrote: > 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. > Although it changes current DNS protocol, AFAICT there does

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

2018-09-17 Thread Mukund Sivaraman
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 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

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

2018-09-17 Thread Ray Bellis
On 17/09/2018 08:11, Stephane Bortzmeyer wrote: Since the main use case is "people with a domain name such as example.com, who wants https://example.com/ to actually work, and who hosts the stuff at a CDN where the IP address is wildly variable so they cannot use A or records", I

Re: [DNSOP] TSIG - BADKEY error handling appears to be underspecified.

2018-09-17 Thread Klaus Malorny
On 17.09.18 02:27, Mark Andrews wrote: Actually having the clients time and fudge in those fields for BADKEY provides spoofing protection for the unsigned responses. This is especially important with opportunistic TSIG,which is what TSIG with a WKK will be, as there is no longer the presumption

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

2018-09-17 Thread Stephane Bortzmeyer
On Sun, Sep 16, 2018 at 03:26:56PM +0530, Mukund Sivaraman 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

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

2018-09-17 Thread Stephane Bortzmeyer
On Mon, Sep 17, 2018 at 03:51:34AM +, Evan Hunt wrote a message of 124 lines which said: > I don't see how we can responsibly declare a new standard which, if > followed, will break every prior implementation. Apex CNAME is the > sort of solution that's clear, simple, and wrong. +1 >