Subject: Re: [dnsext] BADVER/FORMERR

From: "Michael Sheldon" <[email-masked]>
Date: Tue, 15 Nov 2011 15:30:55 -0700

> -------- Original Message --------
> Subject: Re: [dnsext] BADVER/FORMERR
> From: Dick Franks <[email-masked]>
> Date: Tue, November 15, 2011 11:32 am
> To: Ray Bellis <[email-masked]>
> Cc: dnsext <[email-masked]>
> 

> Part of Mark A's argument is that the semantics for QDCOUNT = 0 should
> be considered well defined because no standard query processing is
> involved if there is no question to process.

Really? Exactly what part of any RFC defines what should be returned on
a QUERY where QDCOUNT == 0? Unless you found something I haven't seen,
it's not only not well-defined, it's not defined at all. 

> Furthermore, he noted that an empty question section is (trivially)
> parsable, and cites three plausible scenarios where such a query might
> be useful.

He defines circumstances where he can learn things from the server by
deliberately sending invalid data, thus eliciting an error message. So
we've already defined that he's deliberately sending contextually bogus
data. The question is, if everything in the EDNS section is correct,
what would the response be to QDCOUNT=0? Unless you can convince me
there is a valid non-error response to this, I see nothing wrong with
returning a response based on the first error I find and discontinuing
parsing at that point. In my opinion, a query with no query is a format
error. Any further errors beyond that point are irrelevant.

My suggestion Mark, is to put some kind of question in the packet, the
size difference is frankly insignificant.

Michael Sheldon
Dev-DNS Services
GoDaddy.com

---

From: Mark Andrews <[email-masked]>
Date: Wed, 16 Nov 2011 11:49:45 +1100

In message <20111115153055.205a61dff9fc1684c258b274662bb912.4a8b265d31.wbe@emai
> it's not only not well-defined, it's not defined at all. 

Actually if you follow the algorithm you end up with NOERROR.  Most of
the steps become no-ops.

Set or clear RA.
There is no QNAME so you can't find a zone.
There is no QNAME so you can't recurse and add records.
There is no additional data to add.
You return the response which is empty/NOERROR.
 
> error. Any further errors beyond that point are irrelevant.

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.

> Michael Sheldon
> Dev-DNS Services
> GoDaddy.com
> 
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Wed, 16 Nov 2011 08:53:37 -0500

At 11:49 +1100 11/16/11, Mark Andrews wrote:
>..."Michael Sheldon" writes:

>>  ...what part of any RFC defines what should be returned on
>>  a QUERY where QDCOUNT == 0? ... it's not defined at all.
>

I can see what Mark is saying but I don't think it is the only possible answer.

One problem with this thread is that it is taking the RFCs too 
literally.  From FYI17 (The Tao) what's more important than the 
written word is running code.  With the goal of the IETF documents to 
document what it means to be interoperable, the place to start when 
looking at gaps in the documents is "what does running code do" and 
then come to a consensus.

I.e., because you can interpret the RFC to mean something when it 
says nothing is a flimsy place to start an argument.

Part of my motivation to post here is that I've spent a lot of time 
over the past year wading through paper trails trying to find details 
of the protocol, details relating to things like the KX record and 
other vestigial components.  Comparing what the text comes up with to 
popular implementations, I found that the running code does not 
always meet the specification.  The problem here isn't the code being 
non-conformant, it's the specifications falling behind.  (If it were 
the other way around, we'd see operational hang ups.)  From this, I 
wouldn't take the specifications to be that literal.

I'd suggest going back to "what do we think the right response to an 
empty Question section should be" and then see if the installed code 
base is acceptable as is, and then document any decisions.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Vote for the word of the day:
"Papa"razzi - father that constantly takes photos of the baby
Corpureaucracy - The institution of corporate "red tape"

---

From: Johan Ihrén <[email-masked]>
Date: Wed, 16 Nov 2011 19:39:50 +0100

> 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

---

From: David Conrad <[email-masked]>
Date: Wed, 16 Nov 2011 11:13:39 -0800

On Nov 16, 2011, at 5:53 AM, Edward Lewis wrote:
> I'd suggest going back to "what do we think the right response to an empty Question section should be" and then see if the installed code base is acceptable as is, and then document any decisions.

+1 (Ed and I agreeing on something??  What is this world coming to?)

I get a bit of heartburn when folks try to extrapolate (interpolate) RFCs, particularly the older ones, as they're really not suited  for that. I believe a much better approach in these cases is to try to figure out:

a) what is the desired behavior
b) what breaks in the deployed base if that behavior is implemented.

and then, as Ed says, document decisions made in an 'updates' RFC. 

Regards,
-drc

---

From: Dick Franks <[email-masked]>
Date: Thu, 17 Nov 2011 01:39:44 +0000

On 16 November 2011 13:53, Edward Lewis <[email-masked]> wrote:

> I.e., because you can interpret the RFC to mean something when it says
> nothing is a flimsy place to start an argument.
RFC1035 does not say nothing. It says that the question section is a
list of QDCOUNT elements. QDCOUNT is an unsigned 16 bit integer. From
which we deduce that the question section can possibly be empty.

> I'd suggest going back to "what do we think the right response to an empty
> Question section should be" ...
Mark Andrews has done exactly that and presented a plausible argument
for NOERROR.
I agree with him.

We think the right response to an empty Question section should be NOERROR.

> ... and then see if the installed code base is
> acceptable as is, and then document any decisions.
Code maintainers are free to review the arguments and decide for
themselves what to do.

--Dick

---

From: Ray Bellis <[email-masked]>
Date: Thu, 17 Nov 2011 05:22:33 +0000

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

My intent is not to restrict (future) use of QDCOUNT > 1   [*]

I just believe that it's very reasonable for a _current_ implementation to do:

    if (opcode == QUERY && qdcount != 1) return FORMERR

very early in query processing.

[*]   That said, I did do some work earlier this year looking into the possible semantics of if not multiple QNAMES, at least multiple QTYPEs in a query using an EDNS option.  I wrote a draft, but then decided the problem was too hard.

Ray