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

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]