In message <[email protected]>, Florian Weimer writes: > * Mark Andrews: > > > Yet somehow firewall vendors choose to do everything BUT what they > > were instructed to do thereby causing a denial of service. > > A lot of what you propose is quite reasonable, but requires extensive > gymnastics to align with the RFCs, which do not actually foster > interoperability in the way they impose certain requirements on > implementation behavior. There were proposals to add better protocol > negotiation capabilities to DNS, but there wasn't enough interest in > them back when the IETF was still working on the protocol. > > > Unknown types should get NOERROR, NXDOMAIN or YXDOMAIN as a response.
A meta type is not a type. We do actually have a RFC which specifies the ranges reservered for meta types. MAILA and TYPE128 are meta types. > Real-world implementations disagree: > > ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +norecurse +nsid > @f.root-servers.net www.isc.org TYPE128 > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 31534 > ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ; NSID: 66 72 61 31 61 2e 66 2e 72 6f 6f 74 2d 73 65 72 76 65 72 73 2e 6f > 72 67 (f) (r) (a) (1) (a) (.) (f) (.) (r) (o) (o) (t) (-) (s) (e) (r) > (v) (e) (r) (s) (.) (o) (r) (g) > ;; QUESTION SECTION: > ;www.isc.org. IN TYPE128 > > ;; Query time: 13 msec > ;; SERVER: 192.5.5.241#53(192.5.5.241) > ;; WHEN: Sun Oct 19 15:47:08 2014 > ;; MSG SIZE rcvd: 68 > > ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +norecurse +nsid > @f.root-servers.net www.isc.org MAILA +dnssec > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 35585 > ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ; NSID: 66 72 61 31 61 2e 66 2e 72 6f 6f 74 2d 73 65 72 76 65 72 73 2e 6f > 72 67 (f) (r) (a) (1) (a) (.) (f) (.) (r) (o) (o) (t) (-) (s) (e) (r) > (v) (e) (r) (s) (.) (o) (r) (g) > ;; QUESTION SECTION: > ;www.isc.org. IN MAILA > > ;; Query time: 12 msec > ;; SERVER: 192.5.5.241#53(192.5.5.241) > ;; WHEN: Sun Oct 19 15:48:22 2014 > ;; MSG SIZE rcvd: 68 > > ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +norecurse +bufsize=1200 +nsid > +dnssec @g.root-servers.net www.isc.org MAILA > ; (1 server found) > ;; global options: +cmd > ;; connection timed out; no servers could be reached > > ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +norecurse +bufsize=1200 +nsid > +dnssec @g.root-servers.net www.isc.org TYPE10000 > ; (1 server found) > ;; global options: +cmd > ;; connection timed out; no servers could be reached > > > Algorithm determines the response code. NOTIMP is NOT the correct > > response to a unknown qtype based on RFC 1034. > > What can I sayâI agree, but that's not how existing DNS > implementations behave. And meta types are the exception (we have a reserved meta range since 103[45]) where NOERROR NODATA doesn't make sense to be sent. NXDOMAIN and YXDOMAIN still make sense. That or we need to start returning NXRRSET instead of NOERROR NODATA to be able to differentiate the different responses. EDNS(1) would be a good way to signal that NXRRSET was understood instead of NOERROR NODATA except it would be a pain it the proverbial to do this because of stupid firewall vendors who think that we don't need to support EDNS version negotiation by dropping EDNS(1) queries. Or we ban new meta types. Use a new opcode META with different semantics to QUERY. You will also see that NOIMP is only for unimplemented meta types which is why you picked 128 being the beginning of the meta type range. Now if you ask a question with a unknown TYPE outside of the meta type range you get NOERROR NODATA. ; <<>> DiG 9.11.0pre-alpha <<>> type300 . @f.root-servers.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24520 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. IN TYPE300 ;; AUTHORITY SECTION: . 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2014101901 1800 900 604800 86400 ;; Query time: 164 msec ;; SERVER: 2001:500:2f::f#53(2001:500:2f::f) ;; WHEN: Mon Oct 20 09:24:03 EST 2014 ;; MSG SIZE rcvd: 103 > > Did I say REFLECT a packet? I said CONSTRUCT a packet. In > > particular one that is 12 bytes long, consisting of only a DNS > > packet header. > > And you really want the client to process this response, even with the > QNAME mismatch? Not sure if this is a good idea, unless you have very > good recovery code for spoofed FORMERRs. I want the server to send back a "I do not understand this packet message". As for spoofed FORMERRs you have to deal with them like everything else that can be spoofed. Somethings do more damage than others when spoofed. FORMERR leads to a downgrade/denial of service. FORMERR also causes you to move onto the next server. You can also retry the query. Similarly, BADVERS and NOTIMP could be spoofed. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
