In message <-4512598740891104712@unknownmsgid>, Joe Abley writes:
> 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.
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
> The ability to shut down old versions of BIND9 remotely and force an
> upgrade is a pretty nice feature, in a way :-)
>
> Aue Te Ariki! He toki ki roto taku mahuna!
>
> > On Aug 8, 2015, at 19:24, manning <bmann...@karoshi.com> wrote:
> >
> > 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 serv
> er.
> >
> > manning
> > bmann...@karoshi.com
> > PO Box 6151
> > Playa del Rey, CA 90296
> > 310.322.8102
> >
> >
> >
> >
> >
> >
> >> On 8August2015Saturday, at 15:18, Joe Abley <jab...@hopcount.ca> wrote:
> >>
> >> 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 <bmann...@karoshi.com> wrote:
> >>>
> >>> 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)
> >>> will now be blocked. Not sure I agree that EDNS compliance is identical
> to EDNS(0) compliance.
> >>>
> >>> manning
> >>> bmann...@karoshi.com
> >>> PO Box 6151
> >>> Playa del Rey, CA 90296
> >>> 310.322.8102
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>> On 8August2015Saturday, at 13:46, Paul Wouters <p...@nohats.ca> wrote:
> >>>>>
> >>>>> On Sun, 9 Aug 2015, Mark Andrews wrote:
> >>>>>
> >>>>> 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.
> >>>>
> >>>> And thanks to you Mark for your efforts in making that happen!
> >>>>
> >>>> Paul
> >>>>
> >>>> _______________________________________________
> >>>> DNSOP mailing list
> >>>> DNSOP@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/dnsop
> >>>
> >>> _______________________________________________
> >>> DNSOP mailing list
> >>> DNSOP@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/dnsop
> >>
> >> _______________________________________________
> >> DNSOP mailing list
> >> DNSOP@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dnsop
> >
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
