Subject: [DNSOP] Neglect for RFC3597 for 128 <= RTYPES < 256. Should such RTYPES be off limits to allocation?

From: Nicholas Weaver <[email-masked]>
Date: Wed, 1 Dec 2010 11:39:02 -0800

Much to my embarrassment, our Netalyzr test for RFC3597 (unknown RRTYPE handling.  We used RRTYPE=169 for our testing, as its unassigned yet a convenient mnemonic) was broken for us by the upstream authorities in our path without my realizing it:

	Bad enough is that all of the authorities for icsi.berkeley.edu and berkeley.edu are running BIND of various versions (including the latest), which it turns out all return FORMERR for unknown RTYPE requests where 128 <= RRTYPE < 256.  [1]  

	Now true these are 'meta' RRTYPEs (my screwup for using, only now do I realize that), but RFC 5395 does state that sometimes meta types may be queried directly (with any processing optional), so you'd hope that between that and RFC3597, it would work.  In didn't.

	That was bad.  But it gets worse.  Namely, all ROOTS but h, k, and l fail to properly handle an unknown RTYPE in that range:

dig +norecurse TYPE169 txt.aoeuauoe.netalyzr.icsi.berkeley.edu @c.root-servers.net

Compare with

dig +norecurse TYPE169 txt.aoeuauoe.netalyzr.icsi.berkeley.edu @h.root-servers.net
or
dig +norecurse TYPE256 txt.aoeuauoe.netalyzr.icsi.berkeley.edu @c.root-servers.net

As far as I can tell, this lovely bug came about because somewhere a decision was made that RFC3597 should not apply to meta RRTYPEs (128 - 255).

So the question becomes:  Should all 128 <= RRTYPE < 256 be marked as forbidden for subsequent allocation, unless transparent relaying is not required?  (that is, ONLY be used for DIRECT, UNPROXIED, UNFORWARDED communication between two DNS speakers).
 
Because otherwise these meta RRTYPEs clearly don't work: the installed base of bind is too much to begin with, plus this behavior even extends to the roots!

[1]  Compare (trimmed for readability):
nweaver% dig +norecurse type169 txt.aoeuaoeu.netalyzr.icsi.berkeley.edu @adns1.berkeley.edu

; <<>> DiG 9.6.0-APPLE-P2 <<>> +norecurse type169 txt.aoeuaoeu.netalyzr.icsi.berkeley.edu @adns1.berkeley.edu
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 39144
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;txt.aoeuaoeu.netalyzr.icsi.berkeley.edu. IN TYPE169

with
nweaver% dig +norecurse type16 txt.aoeuaoeu.netalyzr.icsi.berkeley.edu @adns1.berkeley.edu

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43151
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;txt.aoeuaoeu.netalyzr.icsi.berkeley.edu. IN TXT

;; AUTHORITY SECTION:
netalyzr.icsi.berkeley.edu. 3600 IN     NS      roland.icir.org.

;; ADDITIONAL SECTION:
roland.icir.org.        3600    IN      A       192.150.187.31

and
dig +norecurse type256 txt.aoeuaoeu.netalyzr.icsi.berkeley.edu @adns1.berkeley.edu
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2103
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;txt.aoeuaoeu.netalyzr.icsi.berkeley.edu. IN TYPE256

;; AUTHORITY SECTION:
netalyzr.icsi.berkeley.edu. 3600 IN     NS      roland.icir.org.

;; ADDITIONAL SECTION:
roland.icir.org.        3600    IN      A       192.150.187.31

This particular system is running the latest version of bind:

nweaver% dig +short chaos txt version.bind @adns1.berkeley.edu
"9.7.2-P2"

---

From: Mark Andrews <[email-masked]>
Date: Thu, 02 Dec 2010 12:09:27 +1100

This is the wrong list for this as this is a protocol issue.  Redirecting
to [email-masked].

In message <[email-masked]>, Nicholas W
eaver writes:
> 	Much to my embarrassment, our Netalyzr test for RFC3597 (unknown RRTYPE
>  handling.  We used RRTYPE=169 for our testing, as its unassigned yet a conve
> nient mnemonic) was broken for us by the upstream authorities in our path wit
> hout my realizing it:
> 
> 	Bad enough is that all of the authorities for icsi.berkeley.edu and ber
> keley.edu are running BIND of various versions (including the latest), which 
> it turns out all return FORMERR for unknown RTYPE requests where 128 <= RRTYP
> E < 256.  [1]  
> 
> 	Now true these are 'meta' RRTYPEs (my screwup for using, only now do I 
> realize that), but RFC 5395 does state that sometimes meta types may be queri
> ed directly (with any processing optional), so you'd hope that between that a
> nd RFC3597, it would work.  In didn't.

I'm trying to envision a response to a meta query that would pass
through the normal acceptance tests for a cache and still be useful
apart from NODATA (zero answers after CNAME/DNAME processing not
zero answers that match the query type, we so need a explict NODATA
rcode) / NXDOMAIN.  The type in the query needs to be in the answer
for unknown types to pass through a cache.

A meta query answer for ALLADDRESSES for example (returns A and
AAAA and X25 and ...) won't pass through opaque cache as the records
won't be accepted and would become NODATA once you strip out all
the unexpected stuff.

Having the cache reject the query is better than potentially returning
a bad answer.

ALLADDRESSES can be implemented as a ordinary qtype if you want
opportunistic responses.

> 	That was bad.  But it gets worse.  Namely, all ROOTS but h, k, and l fa
> il to properly handle an unknown RTYPE in that range:

Parent servers should be returning referrals.  I'll generate a
ticket for this.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]