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"
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
