Re: [dnsext] BADVER/FORMERR

[Mark Andrews <[e-mail]>]

In message <009a01cca36b$6224d170$266e7450$@[e-mail]>, "Marc Lampo" writes:
> 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 ?

It doesn't matter if it assigned or reserved.  It is supposed
to elicit BADVER from the server 255 is yet to be defined.
 
> 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:[e-mail]] 
> Sent: 14 November 2011 11:23 PM
> To: Marc Lampo
> Cc: [e-mail]
> Subject: Re: [dnsext] BADVER/FORMERR
> 
> 
> In message <026401cca2d5$3d91a270$b8b4e750$@[e-mail]>, "Marc Lampo"
> writes:
> > 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.
> 
> 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.
> 
> > 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:[e-mail]] 
> > Sent: 11 November 2011 03:50 AM
> > To: [e-mail]
> > Subject: [dnsext] BADVER/FORMERR
> > 
> > 
> > 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:	[phone]		         INTERNET: [e-mail]
> > 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]                 INTERNET: [e-mail]
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]