> On 14 Nov 2017, at 12:48 pm, Joe Abley <jab...@hopcount.ca> wrote: > > On Nov 14, 2017, at 09:37, George Michaelson <g...@algebras.org> wrote: > >> Stephane, I don't entirely understand your response. old systems can >> never understand new code point assignments, or know what to do with >> it, no proposed change can alter this. Middleboxes dropping unexpected >> things will hit almost any proposed modification of packets in flight. > > The implication is, I think, that some new code points are more likely to > survive the attention of Sauron's Middleware than others. > > We have seen claims in the past that new RRTYPEs, new EDNS(0) options, new > EDNS(i) with i > 0, new records in ADDITIONAL sections, etc that will all > fall fail of middleware or other dependent systems. What's not clear is the > relative impact of each, but it seems intuitively true that the impact of > each is probably not the same. > > For example, I bet it's more practical to implement a new EDNS(0) option than > it is to deploy EDNS(1), but I have no science to back up that intuition.
Only marginally. Both are deployable between recursive server and authoritative. It’s easy enough to detect mis-implementations and fallback though one shouldn’t have to do that. If Amazon (bad EDNS version negotiation), GoDaddy (bad EDNS flags handling) and Microsoft (bad EDNS version negotiation, bad EDNS options) would fix their respective DNS server farms we would have much improved error rates. Amazon, GoDaddy have removed the firewall entries that were dropping the test queries since testing started. I can’t remember if Microsoft was blocking queries. Amazon’s mis-implementation needs to be fixed before they start serving any signed zones as the answers to EDNS(1) queries appear as if they come from a server that doesn’t support EDNS at all (no opt record returned). 18f.gov. @205.251.192.110 (ns-110.awsdns-13.com.): dns=ok edns=ok edns1=noerror,noopt,soa edns@512=ok ednsopt=ok edns1opt=noerror,noopt,soa do=ok ednsflags=ok optlist=ok,nsid,subnet signed=ok ednstcp=ok 29palmsbomi-nsn.gov. @208.109.255.45 (ns70.domaincontrol.com.): dns=ok edns=ok edns1=ok edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=mbz optlist=ok,nsid signed=ok ednstcp=ok boimi.gov. @64.4.48.6 (ns2-06.azure-dns.net.): dns=ok edns=ok edns1=noerror,badversion edns@512=ok ednsopt=echoed edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok http://ednscomp.isc.org/compliance/summary.html > If only there was some kind of research group adept at wide-scale measurement > from the end-user perspective that could shed some light on this! > > > Joe > _______________________________________________ > 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
