[dns-operations] Announcement - DNS flag day on 2019-02-01

[Rayhelson, Michael]

Thank you both. 

By the way, to be clear -  we certainly do not intend to be the ones who will be forcing the DNS community into ugly workarounds unnecessarily.
We will see if we can fit it to our Q4 plans.  Although, to set the expectations, this is not a commitment at this point - because when the rubber hits the road, work items without deadlines tend to lose to the ones with.

So, if you have some timeframe in mind for needing EDNS1 - it would be very useful for us to know. Especially if we would be blocking something that is supposed to be happening before Q4.

On 5/30/18, 10:33 PM, "Paul Vixie" <paul at redbarn.org> wrote:

    On Thursday, May 31, 2018 5:22:23 AM GMT Robert wrote:
    > On Wed, May 30, 2018 at 6:22 PM, Paul Vixie <paul at redbarn.org> wrote:
    > > we should probably not, ever, have put in any EDNS workarounds. let it
    > > fail
    > > and start the shouting and finger pointing early. generally speaking, if
    > > AWS customers see less web traffic, AWS will fix their DNS.
    > 
    > Isn't that what Michael's question is though? My reading of the flag
    > day is it removes the work-arounds in resolver software for DNS
    > systems which drop EDNS0 queries.  The DNS flag day website links to a
    > tool which flags all EDNS faults with authoritative nameservers and
    > specifically states: "must be green message All Ok". Is that actually
    > true for the action being taken on 2019-02-01?
    
    no. you're right, as a colleague inside AWS also reminded me just now.
    
    > My reading of the website leads me to believe after the work-arounds
    > are removed authoritative nameservers which respond to EDNS1 with
    > anything other than BADVERS will still work just fine. I don't think
    > the intention behind the statement "not seeing any clear customer
    > benefit in fixing this in the next few months" is the same as "don’t
    > have time to do this". The former statement, to me, is asking for a
    > why when it appears there will be no impact for not correctly
    > responding to EDNS1.
    
    true, and i hereby retract that statement.
    
    > The why on this one seems to be "As a protocol designer and DNS
    > resolver software maintainer, I would like to develop and implement
    > EDNS1 which requires at present time DNS authorities respond to EDNS1
    > queries with BADVERS". There's probably more to it than that, like why
    > customers would want EDNS1 or what in general you're trying to
    > accomplish (pro tip: referencing a case where you were able to live
    > without it is not really a selling point). But I'm sure if there was a
    > version 0 of something, we'd probably want a version 1 at some point,
    > and it isn't really shocking behaviour to return an error when
    > presented with a version you're not expecting (I'm thinking of how
    > this works with HTTP versions).
    
    if AWS is the only BADVERS-withholder and they can fix it, we're done. but if 
    the problem is broader, then EDNS1 will have to use an OPT6 RR or some such, 
    because OPT will be broken by practice, rather than just by sloppy design.
    
    (EDNS1 would mandate not just cookies but DTLS, to ensure that noone who 
    claimed to support it wasn't actually doing what it took to support it -- a 
    failure of the EDNS0 design, which in case it's not obvious, was my failure.)
    
    > My suggestion is you clarify what the DNS flag day actually will
    > impact and provide guidance on how to interpret the results of the
    > validation tool to untangle the two issues: DNS systems which drop all
    > EDNS queries, and BADVERS for EDNS1.
    
    i think this thread will have that effect. thanks for bringing light.
    
    vixie