This is the wrong list for this as this is a protocol issue. Redirecting to dns...@ietf.org.
In message <50da0744-6dda-446a-b4ae-c897f440d...@icsi.berkeley.edu>, 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: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
