Subject: [dnsext] BADVER/FORMERR

From: Mark Andrews <[email-masked]>
Date: Fri, 11 Nov 2011 13:50:07 +1100

I was looking for a good way to test for EDNS support and hacked
dig to send out a empty question section when the EDNS version was
set to 255 and got what I believe to be incorrect responses from K
and L.  EDNS version processing is supposed to take precedence over
examining the query section as the EDNS version can influence the
interpretion of the question section.  I believe the correct response
should be BADVERS.  Adding a question elicited BADVERS.

Do others agree with my interpretion of rcode precedence?

Mark

marka% bin/dig/dig +edns=255 +norec @k.root-servers.net

; <<>> DiG 9.9.0b1 <<>> +edns=255 +norec @k.root-servers.net
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 40361
;; flags: qr; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; Query time: 255 msec
;; SERVER: 2001:7fd::1#53(2001:7fd::1)
;; WHEN: Fri Nov 11 13:34:50 2011
;; MSG SIZE  rcvd: 12

marka% bin/dig/dig +edns=255 +norec @l.root-servers.net

; <<>> DiG 9.9.0b1 <<>> +edns=255 +norec @l.root-servers.net
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 34663
;; flags: qr; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; Query time: 175 msec
;; SERVER: 2001:500:3::42#53(2001:500:3::42)
;; WHEN: Fri Nov 11 13:35:08 2011
;; MSG SIZE  rcvd: 12

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

---

From: Ray Bellis <[email-masked]>
Date: Fri, 11 Nov 2011 12:42:24 +0000

>  EDNS version processing is supposed to take precedence
> over examining the query section

Defined where?  I don't see anything like that in RFC 2308.

> as the EDNS version can influence the interpretion of the
> question section.  

Ditto.

Just out of interest, are there any _existing_ legitimate circumstances where QDCOUNT != 1 ?

Ray

---

From: Florian Weimer <[email-masked]>
Date: Fri, 11 Nov 2011 12:47:37 +0000

* Mark Andrews:

> the EDNS version can influence the interpretion of the question
> section.

Only in a very limited ways because the EDNS version is accessible only
*after* the question section has been parsed.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Mark Andrews <[email-masked]>
Date: Sat, 12 Nov 2011 19:49:28 +1100

> Defined where?  I don't see anything like that in RFC 2308.

EDNS is RFC 2671.  If you don't support the EDNS version in the
request you must send back BADVER.  At that point trying to process
the question section, whatever it is, is moot as the RCODE has
already been set.

> Just out of interest, are there any _existing_ legitimate circumstances where

Seeing if a server is alive.
Getting the EDNS UDP size prior to sending a UPDATE. 
Getting the EDNS version prior to anything.

If I set qcount=2 with ./in/a and ./in/aaaa and edns=50 the correct
rcode for a edns=0 server is BADVER.

---

From: Ray Bellis <[email-masked]>
Date: Sat, 12 Nov 2011 14:11:54 +0000

On 12 Nov 2011, at 16:49, Mark Andrews wrote:
> EDNS is RFC 2671.

Yes, 2308 was a mistake.  I did of course mean RFC 2671.

> If you don't support the EDNS version in the

Again, I ask, where is this defined?

I can't see anything in _2671_ that says that processing of the EDNS version number takes priority over any other input checking that might be performed by a server.

As far as I can see, the only pertinent text in 2671, and the (expired) 2671bis draft is this:

"If a responder does not implement the VERSION level of the request, then it answers with RCODE=BADVERS"
which doesn't even have a 2119-level compliance requirement word in it.

> rcode for a edns=0 server is BADVER.

Why not something else?  Because *BIND* doesn't do it that way?

Ray

---

From: David Conrad <[email-masked]>
Date: Sat, 12 Nov 2011 08:58:12 -0800

Ray,

> which doesn't even have a 2119-level compliance requirement word in it.

Is a 2119 word required?

> Why not something else?  Because *BIND* doesn't do it that way?

I suspect it is better to focus on what makes the most sense from a protocol perspective rather than what particular implementations might have done.

Since EDNS is an extension mechanism and QDCOUNT was defined in the base specification, it would seem to make sense to me to check EDNS version before determining whether the QDCOUNT value makes sense (after all, a future EDNS version could redefine the semantics of QDCOUNT).

What would be your argument for the reverse?

Regards,
-drc

---

From: Ray Bellis <[email-masked]>
Date: Sat, 12 Nov 2011 17:11:45 +0000

> What would be your argument for the reverse?

Mark complained that two of the root servers gave "incorrect" answers when sent unknown EDNS versions.

I'm merely asking that he justify his assertion that EDNS version processing MUST take priority over anything else, because I don't see it in the standards.

>From a software implementation point of view it's _massively_ simpler and more efficient to send back an immediate FORMERR if QDCOUNT != 1 than it is to have to parse everything else up to and including the OPT RR (including compression pointers) in order to give back a BADVERS error.

Ray

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sat, 12 Nov 2011 14:01:11 -0500

> Do others agree with my interpretion of rcode precedence?

<no hat>
Formerr is perfectly valid return code.
It is the first error you detect and you can stop processing
right then.
(This assumes that the QR=0)

Reasoning: You sent a question that is not a real question
I see nothing in ENDS0 rfcs that say you need to look into the
opt record if the DNS packet is malformed, QR=0 and QDCOUNT=0
is malformed packet IMHO.

	Olafur

---

From: Mark Andrews <[email-masked]>
Date: Sun, 13 Nov 2011 09:14:05 +1100

> is malformed packet IMHO.

Even if FORMERR is returned, the response is also missing the OPT
record which is required to be sent by EDNS aware servers.  If you
can't parse the packet to get to the OPT record then a 12 octet
FORMERR is appropriate.  This packet is parsable.

   VERSION         Indicates the implementation level of whoever sets
                   it.  Full conformance with this specification is
                   indicated by version "0."  Requestors are encouraged
                   to set this to the lowest implemented level capable
                   of expressing a transaction, to minimize the
                   responder and network load of discovering the
                   greatest common implementation level between
                   requestor and responder.  A requestor's version
                   numbering strategy should ideally be a run time
                   configuration option.

                   If a responder does not implement the VERSION level
                   of the request, then it answers with RCODE=BADVERS.
                   All responses will be limited in format to the
                   VERSION level of the request, but the VERSION of each
                   response will be the highest implementation level of
                   the responder.  In this way a requestor will learn
                   the implementation level of a responder as a side
                   effect of every response, including error responses,
                   including RCODE=BADVERS.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sat, 12 Nov 2011 22:57:58 -0500

On 12/11/2011 17:14, Mark Andrews wrote:
> In message<[email-masked]>, Olafur Gudmundsson writes:

<no-hat>
#1 I can reason that it is OK to stop parsing a packet after an format 
error is detected .
The text above does not clearly support your interpretation nor mine.
(I might even be tempted to say, randomly dropping the packet is also 
acceptable).
Sending Refused is also in contention, but not helpful.

#2 From your original message you seemed to be asking about the error 
code, not if the missing OPT record was appropriate.

Strictly speaking given how narrow the error reporting channel in DNS is 
either interpretation is acceptable i.e. First Error detected or Most 
Significant error, responders should be ready to handle both.
But at the same time I understand your desire to have an easy way to 
detect the ENDS0 version.

	Olafur

---

From: "Marc Lampo" <[email-masked]>
Date: Mon, 14 Nov 2011 14:56:42 +0100 (CET)

Hello Mark,

Interesting path you are following ...

>From my position (in the Internet with respect to anycast servers),
I get answers you consider not correct from
All of a, h, k and l root-servers.net.

Additionally, when I query a.root-servers.net. with QDCOUNT == 1,
the rcode becomes indeed BADVERS (extended : value 16),
but amazingly the name servers additionally sets the lowest bit in the
flags :
"non-authenticaded data: Acceptable" (that's the CD bit, if I'm not
mistaken).

The problem seems to be : "which error precedes which error ?"
(as there is only one possibility for "rcode" in the packet)
So, first detect the QDCOUNT == 0 and return FORMERR because of that,
or, also detect that EDNS type is 255, so : undefined and return BADVERS
because of that.

But what I fail to see is : why send EDNS with value 255 ?
Why not simply a regular EDNS0 ?
Because in that case (only one error),
the authoritative name server can always add EDNS0 in its reply with the
UDP payload
(you are interested in in the first place).
We don't *have* to send an EDNS with bad version number in order to obtain
the information ?
Or do you want to *force* EDNS0 in the reply by sending a query
that results in a Returncode >15 so that EDNS0 is needed to get that
returncode back ?

Kind regards,

Marc

-----Original Message-----
From: Mark Andrews [mailto:[email-masked]] 
Sent: 11 November 2011 03:50 AM
To: [email-masked]
Subject: [dnsext] BADVER/FORMERR

Mark

;; Query time: 255 msec

;; Query time: 175 msec

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Nov 2011 09:23:02 +1100

> or, also detect that EDNS type is 255, so : undefined and return BADVERS

255 is reserved not wrong.

> But what I fail to see is : why send EDNS with value 255 ?

I want to send a query which will force the EDNS version on the OPT
record to be *changed* by the server at the remote end.  There are
too many nameservers out there that don't understand EDNS yet still
return OPT records from the query.  You can see them by changing
the EDNS UDP size and seeing the change reflected back to you.

I'm also looking to do this with smallest sized packets that I can.

---

From: Dick Franks <[email-masked]>
Date: Tue, 15 Nov 2011 04:34:48 +0000

IMHO, we should consider separately whether FORMERR is a proper
response to a query with zero QDCOUNT.

The text of RFC1035 (4.1.2) describes the question section thus:

  The question section is used to carry the "question" in most queries,
  i.e., the parameters that define what is being asked.  The section
  contains QDCOUNT (usually 1) entries, each of the following format ...

This certainly does not exclude the possibility of an empty question
section in a query packet and hence there is no justification for
responding with FORMERR.

No additional legislation should be necessary; implementations which
return FORMERR in response to zero QDCOUNT are non-compliant with
RFC1035. Client-side code which relies upon such behaviour is
similarly non-compliant.

--Dick

---

From: Ray Bellis <[email-masked]>
Date: Tue, 15 Nov 2011 05:55:57 +0000

> response to a query with zero QDCOUNT.

or _anything_ other than QDCOUNT == 1

> section in a query packet and hence there is no justification for

Actually, it's vague in RFC 1035.

RFC 1034 is quite specific about "_the_ query name" (singular) in the context of standard query processing (see e.g. §3.7)

I therefore interpret that parenthetical comment as applying to other OPCODE values than "QUERY".  For example IQUERY does (did) use QDCOUNT == 0.

> RFC1035. Client-side code which relies upon such behaviour is

The semantics for QDCOUNT != 1 are not defined for "QUERY" so (IMHO) FORMERR is appropriate.

Ray

---

From: "Marc Lampo" <[email-masked]>
Date: Tue, 15 Nov 2011 08:51:28 +0100 (CET)

Point taken - about what you want to achieve with such a query.

However, according to IANA, numbers 1...255 are unassigned !
 --> I see no indication of value 255 being reserved ?

Registry Name: EDNS version Number (8 bits)
Reference: [RFC2671]
Registration Procedures: Standards Action

Registry:
Range     Description              Reference
--------  -----------------------  ---------
0         EDNS version 0           [RFC2671]
1-255     Unassigned
(cfr : http://www.iana.org/assignments/dns-parameters)

Kind regards,

Marc

-----Original Message-----
From: Mark Andrews [mailto:[email-masked]] 
Sent: 14 November 2011 11:23 PM
To: Marc Lampo
Cc: [email-masked]
Subject: Re: [dnsext] BADVER/FORMERR

In message <026401cca2d5$3d91a270$b8b4e750$@[email-masked]>, "Marc Lampo"

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Nov 2011 22:08:00 +1100

>  --> I see no indication of value 255 being reserved ?

It doesn't matter if it assigned or reserved.  It is supposed
to elicit BADVER from the server 255 is yet to be defined.

---

From: Dick Franks <[email-masked]>
Date: Tue, 15 Nov 2011 18:32:57 +0000

> Actually, it's vague in RFC 1035.
RFC1035 (warts and all) is, until someone feels brave enough to
rewrite it, the base specification.

The question section is defined to be a list of question items. If the
intention had been to require exactly one question, it would have been
specified in the same way as the header, and QDCOUNT eliminated
entirely.

> RFC 1034 is quite specific about "_the_ query name" (singular) in the context of standard query processing (see e.g. §3.7)
RFC1034  §3.7 is not relevant here.  The concept of "standard query
processing" is meaningless if the question section is empty.

> I therefore interpret that parenthetical comment as applying to other OPCODE values than "QUERY".  For example IQUERY does (did) use QDCOUNT == 0.
I would interpret it as a non-normative comment (usually!).
RFC1035 §4.1.2 is describing the structure of the question section in
general, not QUERY in particular.
Unless there is an obscure RFC lurking somewhere which specifically
forbids an empty question section, then RFC1035 wins and a whole
worldful of implementations are non-compliant.

> The semantics for QDCOUNT != 1 are not defined for "QUERY" so (IMHO) FORMERR is appropriate.
The semantics for QDCOUNT > 1 are certainly not defined for QUERY.

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.

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

--Dick