Subject: [DNSOP] Big reduction in the number of TLD zones blocking EDNS(1) queries

From: Mark Andrews <[email-masked]>
Date: Sun, 09 Aug 2015 06:35:28 +1000

As of the 8th of August there was a big reduction in the
	number of TLD zones which filtered queries with unknown
	EDNS version or unknown EDNS flags.

	While there is still work to do to improve EDNS compliance
	this is a big step forward.  Thank you.

	https://ednscomp.isc.org/compliance/summary.html

	As some of the operators involved also serve part of the
	Alexa top 1000, a visible step improvement has been seen
	there as well.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Sat, 8 Aug 2015 16:46:38 -0400 (EDT)

> 	this is a big step forward.  Thank you.

And thanks to you Mark for your efforts in making that happen!

Paul

---

From: manning <[email-masked]>
Date: Sat, 8 Aug 2015 14:19:12 -0700

Of course this means that EDNS, for all its promise as an extension to allow for more flags/signaling is effectively dead, since anything other than EDNS(0)
will now be blocked.  Not sure I agree that EDNS compliance is identical to EDNS(0) compliance.  

manning
[email-masked]
PO Box 6151
Playa del Rey, CA 90296
310.322.8102

On 8August2015Saturday, at 13:46, Paul Wouters <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Joe Abley <[email-masked]>
Date: Sat, 8 Aug 2015 18:18:48 -0400

Hi Bill,

Not sure what you mean. Wasn't the point of Mark's email roughly the
opposite of what you said?

Compliance with EDNS(0) presumably means compliance with RFC 6891.
That specification includes handling of unknown EDNS options.

Joe

Aue Te Ariki! He toki ki roto taku mahuna!

> On Aug 8, 2015, at 17:19, manning <[email-masked]> wrote:
>

---

From: manning <[email-masked]>
Date: Sat, 8 Aug 2015 16:22:46 -0700

You may be correct.   The subject suggests TLD servers and their upstreams block EDNS(1) (was this a considered choice or an implementation artifact)
and there has been a reduction in blocking at the server level.  Unclear if this is a deliberate choice or an upgrade artifact that the server admins or the ISP upstreams
have made an explicit choice to enable EDNS(unknown) processing at the server.

manning
[email-masked]
PO Box 6151
Playa del Rey, CA 90296
310.322.8102

---

From: Joe Abley <[email-masked]>
Date: Sat, 8 Aug 2015 19:29:26 -0400

At a guess I would imagine that the widespread interest in the most
recent BIND9 assertion failures with TKEY queries have caused code to
be upgraded everywhere. Some older versions of BIND9 followed the
pre-6891 specification for unknown EDNS types; perhaps that has had a
positive impact on Mark's testing.

The ability to shut down old versions of BIND9 remotely and force an
upgrade is a pretty nice feature, in a way :-)

> On Aug 8, 2015, at 19:24, manning <[email-masked]> wrote:
>

---

From: manning <[email-masked]>
Date: Sat, 8 Aug 2015 17:11:21 -0700

Causing a shutdown does not automatically Force an upgrade…

And you are correct, there are other DNS Kill Switches still out there.  One has to wonder if they are coding oversights or deliberate inclusions.

/bill

---

From: 🔒Roy Arends <[email-masked]>
Date: Sun, 9 Aug 2015 01:34:27 +0100

> On 9 Aug 2015, at 01:11, manning <[email-masked]>

> there are other DNS Kill Switches still out there.  

Yeah? Which ones?

Roy

---

From: Mark Andrews <[email-masked]>
Date: Sun, 09 Aug 2015 13:51:01 +1000

> positive impact on Mark's testing.

No.  BIND 9 was always compatible with RFC 6891.  That said upgrading
servers got the CDS attributes fix deployed.  Most of the TLD servers
that were incorrectly responding with REFUSED to CDS now don't
though there are still some.

	https://ednscomp.isc.org/compliance/tld-typereport.txt

The EDNS version blocking  was IPv4 firewalls.  The servers behind
the firewall are not RFC 6891 compliant as they ignore the EDNS
version field which BIND doesn't.  But getting one issue fixed is
a good start.  It also dramatically reduced the time to test all
the servers.

>From what I can see there are only 5 TLD's left with firewalls that
are filtering based on EDNS version / EDNS flags.  This is a big
improvement.

	https://ednscomp.isc.org/compliance/tld-report.html

Mark

> > You may be correct.   The subject suggests TLD servers and their upstreams 
> block EDNS(1) (was this a considered choice or an implementation artifact)
> > and there has been a reduction in blocking at the server level.  Unclear if
>  this is a deliberate choice or an upgrade artifact that the server admins or
>  the ISP upstreams
> >>> Of course this means that EDNS, for all its promise as an extension to al
> low for more flags/signaling is effectively dead, since anything other than E
> DNS(0)

---

From: Warren Kumari <[email-masked]>
Date: Sun, 9 Aug 2015 09:17:22 -0400

On Saturday, August 8, 2015, 🔒Roy Arends <[email-masked]> wrote:

>
> > On 9 Aug 2015, at 01:11, manning <[email-masked] <javascript:;>>
>
I'll tell you in 18 - 24 months...

:-P

W

> [email-masked] <javascript:;>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Florian Weimer <[email-masked]>
Date: Sun, 9 Aug 2015 22:59:27 +0200

On 08/09/2015 01:29 AM, Joe Abley wrote:
> be upgraded everywhere.

That seems unlikely to me.  Many operators only deploy minimal changes,
*especially* during an unscheduled security update.  If you were running
BIND 9.3 before, you are essentially running it afterwards as well.

-- 
Florian Weimer / Red Hat Product Security