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

Petr Špaček petr.spacek at nic.cz
Fri Jun 1 09:48:06 UTC 2018


On 31.5.2018 20:27, Rayhelson, Michael wrote:
> 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.

Great, this is much appreaciated!

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

Understood. Please take into considerations development and support 
costs on your side and ALSO for everyone else.

Open-source DNS vendors have been paying support costs for all the 
workarounds for many years now, in case of EDNS specifically 19 years 
now. ISC additionally pays development cost of the EDNS compliance tool 
which is now used to survey domains etc. (Thank you ISC!)

Asking this community to postpone part of 19+ year effort get *just* 
standards compliance seems a bit too much, money and patience were 
already spent.

Besides other things ignoring BADVERS would require another change in 
the compliance tool, user intefaces, etc. which means yet another costs 
paid by someone else than AWS.

Just as though experiment, let's say that maintainers of the compliance 
test suite, web site etc. are fed up and are not willing to spend even 
more money on this. What would happen? AWS would be getting more support 
requests than it would be getting if this was fixed sooner rather than 
later.

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

Let's say that standards compliance now will save you annother 
unspecified flag day in future (which means cost for everyone involved), 
but it will *also* save *you* support costs *today*.

As a benefit if you fix it soon you can get your logo into the 
Supporters section of https://dnsflagday.net/ (if you wanted to).

Thank you for understanding.
Petr Špaček  @  dns-violations



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



More information about the dns-operations mailing list