QNAME minimisation failures happen for 2 reasons. 1. Bad implementations of DNS that don’t return ENTs in a zone.
2. Failure to add delegating NS records to the parent zone resulting in no ENT being emitted when both the child and parent server are served by the same server. If we had kept going with bit-string labels querying for the longest sequence of labels on the RHS without a bit-string label would have been been the way to get to the servers that supported bit-string labels. DNS COOKIES has problems because there are bad implementations of EDNS out there. Whatever we did when introducing them ran up against broken implementations (includes bad firewalls) (DNS COOKIES alone or EDNS(1) and DNS COOKIES). 1. Servers that DO NOT respond to queries with EDNS options present. 2. Servers that return BADVERS, NOTIMP to EDNS queries (STD13 says return FORMERR to unknown queries). RFC 6891 turned this to NOERROR on unknown EDNS option. 3. Servers that echo back the option, who is insane enough to send bits that you don’t understand them meaning of! (this one is not fatal for DNS COOKIE). 4. Servers that don’t return BADVERS to EDNS(1) + EDNS Options but return FORMERR. 5. Servers that don’t answer EDNS(1) + EDNS Options. 6. Load balance front ends that punted to poorly configured backends when they saw a EDNS option. This leads to NXDOMAIN and other bad data being returned. 7. Other random rcodes. All of this was testable for by developers when they introduce EDNS to their servers. EDNS has 3 extension mechanism. That is not a lot of test case to write and think about does the response you see make sense? EDNS(1) query (behaviour fully described in RFC 2671) EDNS unknown option query (behaviour fully described in RFC 6891) EDNS unknown flag query (behaviour fully described in RFC 2671) EDNS(1) query + EDNS unknown option (behaviour fully described in RFC 6891) EDNS(1) query + EDNS unknown flag (behaviour fully described in RFC 2671) EDNS unknown option + EDNS unknown flag (behaviour fully described in RFC 6891) EDNS(1) query + EDNS option + EDNS unknown flag (behaviour fully described in RFC 6891) One shouldn’t have to say to DNS developers “test you servers against possible extension methods before you ship it!" That should be part and parcel of adding EDNS support. I can find servers that fail one or more of every one of these tests. > On 21 Mar 2018, at 2:12 am, Stephane Bortzmeyer <bortzme...@nic.fr> wrote: > > On Tue, Mar 20, 2018 at 07:29:50AM +0000, > tjw ietf <tjw.i...@gmail.com> wrote > a message of 94 lines which said: > >> At the end of Tuesday's session we're having Bert Hubert from Power DNS >> give a talk on what he views "The Camel". > > Unlike the popular saying > <https://en.wikipedia.org/wiki/Design_by_committee#Aphorisms>, camels > are extraordinary animals, well adapted to their harsh environment > <https://en.wikipedia.org/wiki/Camel#Ecological_and_behavioral_adaptations> > and usable for many things, even war > <https://en.wikipedia.org/wiki/Camel_cavalry>. If the DNS is a camel, > this is great! > >> "In past years, DNS has been enhanced with DNSSEC, QName >> Minimization, [...] > > I dispute the idea that QNAME minimization is an addition. It is not a > change in the protocol, and it was even possible from the beginning > (Section 5.3.3 of [RFC1034] or Section 7.2 of [RFC1035] do NOT mandate > QNAME maximimization, it is just an accidental evolution). > > _______________________________________________ > 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
