edns fails for afnic.fr ... seems to be false alert

[sandoche2k]

From Zonemaster CLI:

9.27 WARNING   Nameserver ns2.nic.fr/192.93.0.4 accepts an unsupported EDNS version.
   9.28 WARNING   Nameserver ns3.nic.fr/192.134.0.49 accepts an unsupported EDNS version.
   9.30 WARNING   Nameserver ns1.nic.fr/192.134.4.1 accepts an unsupported EDNS version.

But EDNS compliance testing passes : https://ednscomp.isc.org/ednscomp/87d77657eb

[vlevigneron]

I just did a test and ran wireshark. What I can observe is that we send a packet with EDNS version 1 (which is not a valid vesion number) then we get an answer with NOERROR. According to the specs, the message you have is what is expected.

[sandoche2k]

I did a dig and i do not get that

sandoche@sandoche:~$ dig +edns=1 soa afnic.fr @ns1.nic.fr

; <<>> DiG 9.10.3-P4-Ubuntu <<>> +edns=1 soa afnic.fr @ns1.nic.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: BADVERS, id: 46168
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1432
;; QUESTION SECTION:
;afnic.fr.			IN	SOA

;; Query time: 1 msec
;; SERVER: 192.134.4.1#53(192.134.4.1)
;; WHEN: Fri Jan 18 23:55:20 CET 2019
;; MSG SIZE  rcvd: 37

[sandoche2k]

sandoche@sandoche:~$ dig +edns=1 soa afnic.fr @192.134.4.1

; <<>> DiG 9.10.3-P4-Ubuntu <<>> +edns=1 soa afnic.fr @192.134.4.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: BADVERS, id: 6251
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1432
;; QUESTION SECTION:
;afnic.fr.			IN	SOA

;; Query time: 1 msec
;; SERVER: 192.134.4.1#53(192.134.4.1)
;; WHEN: Fri Jan 18 23:57:43 CET 2019
;; MSG SIZE  rcvd: 37

[vlevigneron]

OK, I got it, Extended RCODE are not processed the same way in LDNS. I have to check both rcode and edns-rcode to compute RCODE value (perhaps we could improve specs to disambiguate that).

[sandoche2k]

I do not see how i could improve the specs "https://github.com/zonemaster/zonemaster/blob/develop/docs/specifications/tests/Nameserver-TP/nameserver10.md"

Any inputs?

[vlevigneron]

@sandoche2k perhaps make a reference to both https://tools.ietf.org/html/rfc6891#section-9 and https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6.

[sandoche2k]

So, if i understand clearly, you want a reference to the RCODE BADVERS in Nameserver10?

[vlevigneron]

@sandoche2k No, I would like a specification that is self sufficient. I mean, I wrote the code corresponding to the specs but I had not in mind the whole RFC at that time (I read it again since). That's why I made a mistake while implementing. BADVERS is not a legal RCODE value in the DNS header but a combination of RCODE and extended-RCODE (in OPT RR). I guess it would be easier for a mutual understanding if the specs could detail RCODE and extended-RCODE values expected or include the following excerp from RFC 6891, especially if we come back in one or two years on this test case.

[RFC2671] expands the RCODE space from 4 bits to 12 bits.  This
   allows more than the 16 distinct RCODE values allowed in [RFC1035].
   IETF Review is required to add a new RCODE.

   This document assigns EDNS Extended RCODE 16 to "BADVERS" in the DNS
   RCODES registry.

[sandoche2k]

Ok.. I will add that for the respective specifications.

[sandoche2k]

Refer to zonemaster/zonemaster#668