[dns-operations] need someone else to look at these servers

[Mark Andrews]

In message <87k33wnosv.fsf at mid.deneb.enyo.de>, 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: marka at isc.org