Re: [dnsext] BADVER/FORMERR

[Johan Ihrén <[e-mail]>]

On Nov 16, 2011, at 01:49 , Mark Andrews wrote:

> QCOUNT > 1 is hard because there is one rcode and more that one possible
> response.
> 
> QCOUNT = 0 gets rid of all name based acl processing.
> QCOUNT = 0 is independent of the zones being served.
> QCOUNT = 0 in plain DNS gives you a test to see if the server is
> alive, whether it will recurse for you or not (RA), and whether it
> will in general answer queries for you.
> 
> Note QCOUNT > 1 is a valid in a response to a IQUERY.

While not immediately relevant to the current discussion I make the observation that once upon a time many, many moons ago there was discussions about a possible alternate design for DNSSEC called "slabs". The idea with slabs was that we could do away with the DO bit and the subtyping of the RRSIG by making two changes:

1. Combine RR + RRSIG(RR) into a new record which was a "slab" (a single RR that contained the unsigned RRset + the signature over the RRset). I.e. an A + RRSIG(A) would be an A-SIG, etc.

2. Instead of having resolvers signal DNSSEC interest via the DO bit they would query for both the A and the A-SIG in the same query, i.e. with a QDCOUNT=2. 

There were various pros and cons with this and in the end this is not what became DNSSEC as we know it today. 

And my point with lifting this old and mouldy stone is that I think it would be a mistake to go down the route it sounds to me that Ray is aiming for ("disallow anything but QDCOUNT=1 in if OPCODE=QUERY because that's most efficient"). 

RFC1035 doesn't say QDCOUNT=1 (then we wouldn't have that as a counter at all) and just because we here and now, today, may see a point to such a restriction does not mean that such a thing wouldn't come back and haunt us in the future when we come up with some new and clever usage that depends on the ability to have more than one query in the QUERY.

Ray: apologies in advance if I misinterpreted your position. If I did, my point still remains, though.

Johan