Subject: [DNSOP] Neither authenticated nor SERVFAIL

From: Mats Dufberg <[email-masked]>
Date: Thu, 9 Dec 2021 17:16:02 +0000

A validating resolver is expected to either return the AD flag for authenticated data or SERVFAIL for data that cannot be authenticated when answering for data in a signed zone. I have here an example of a signed zone that resolvers return data from that is neither AD set nor SERVFAIL.

If you query for "lindforslaw.se A" you will get an authenticated answer (AD):

; <<>> DiG 9.10.6 <<>> lindforslaw.se A +dns +mult @8.8.8.8

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13333

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

There is a wildcard record in the zone, and if you query for that you will also get authenticated answer, as expected.

; <<>> DiG 9.10.6 <<>> *.lindforslaw.se A +dns +mult @8.8.8.8

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30395

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

(...)

;; ANSWER SECTION:

*.lindforslaw.se. 3408 IN     A 194.9.94.86

*.lindforslaw.se. 3408 IN     A 194.9.94.85

*.lindforslaw.se. 3408 IN     RRSIG A 8 2 3600 (...)

If you query for something that matches that wildcard, e.g. "x.lindforslaw.se A", then AD is not set, but it is not SERVFAIL.

; <<>> DiG 9.10.6 <<>> x.lindforslaw.se A +dns +mult @8.8.8.8

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10661

;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 1

(...)

;; ANSWER SECTION:

x.lindforslaw.se. 3600 IN     A 194.9.94.86

x.lindforslaw.se. 3600 IN     A 194.9.94.85

x.lindforslaw.se. 3600 IN     RRSIG A 8 2 3600 (...)

When data comes from a signed zone, then if the resolver can validate the response, it should set the AD flag, else return a SERVFAIL. Does anyone disagree? Does anyone have an explanation to the behavior?

I get the same responses from different resolvers.

Mats

--
---
Mats Dufberg
[email-masked]
Technical Expert
Internetstiftelsen (The Swedish Internet Foundation)
Mobile: +46 73 065 3899
https://internetstiftelsen.se/

---

From: Vladimír Čunát <[email-masked]>
Date: Thu, 9 Dec 2021 18:35:10 +0100

On 09/12/2021 18.16, Mats Dufberg wrote:
>
> If you query for something that matches that wildcard, e.g. 
> "x.lindforslaw.se A", then AD is not set, but it is not SERVFAIL.
>
The wildcard proof involves an opt-out NSEC3 record in this case.  That 
means a delegation might exist instead of the wildcard expansion, but 
that can't be (dis)proven.

--Vladimir | knot-resolver.cz

---

From: Paul Vixie <[email-masked]>
Date: Thu, 9 Dec 2021 09:39:10 -0800

Mats Dufberg wrote on 2021-12-09 09:16:
> ...
> 
> ;; ANSWER SECTION:
> x.lindforslaw.se.3600 IN A 194.9.94.86
> x.lindforslaw.se.3600 IN A 194.9.94.85
> x.lindforslaw.se.3600 IN RRSIG A 8 2 3600 (...)
> 
> When data comes from a signed zone, then if the resolver can validate 
> the response, it should set the AD flag, else return a SERVFAIL. Does 
> anyone disagree? Does anyone have an explanation to the behavior?
> 
> ...

the response seen from that authority via dig +trace +dnssec is "odd".

> x.lindforslaw.se. 3600 IN RRSIG A 8 2 3600 ...
> 2c7045fto8aflnjrb560cdu1m30p5re0.lindforslaw.se. 3600 IN NSEC3 1 1 1 AB ...
> 2c7045fto8aflnjrb560cdu1m30p5re0.lindforslaw.se. 3600 IN RRSIG NSEC3 8 3 3600 ...
> ;; Received 753 bytes from 93.188.0.20#53(ns1.loopia.se) in 156 ms

i can't easily tell whether that RRSIG covers both A records, but its 
placement in the response message immediately following the first of the 
two A records is suspicious. with qtype ANY this odd placement does not 
occur, but with qtype A it does.

the BIND9 resolver in my home does the same (i set DO, it doesn't set 
AD, and the rcode is NOERROR.) this seems wrong, though if gdns does the 
same thing, it may reflect a loophole in the specification rather than a 
bug.

vixie

---

From: Mark Andrews <[email-masked]>
Date: Fri, 10 Dec 2021 07:41:57 +1100

> On 10 Dec 2021, at 04:39, Paul Vixie <paul=[email-masked]> wrote:
> 
> 
> 

Not really if you add +all or do a direct query.

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51279
;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;x.lindforslaw.se.		IN	A

;; ANSWER SECTION:
x.lindforslaw.se.	3600	IN	RRSIG	A 8 2 3600 20211223000000 20211202000000 21120 lindforslaw.se. PW8N95yQoi97s2yuAsK7kisv1Bluvtj5qWRaADowh58O0BJMjt+KnLZz RUzLibN0XFUlVnK3iu8cWWGrh2mcWTjEgWT4e9PJEWzu/1RNOBgeeUrY ENk433gOupmCEdQwUTwg4wKpv1VplB4z12xatSW2t93sguHY1Ylj7F4f 1RIpcs8ac6Tv2hQA1yFyr3bcNyMrzKdl/awVYofN22GhB0jc3WeiWBG2 Avl9ZMXVD39TA3vZ7vFVCfLI7CbFPESt3C473gUD1yCA28Ie+C7rSx1m zWlse91UoqGhz257Uqkvw0iiX2MIlU6o/EuDimBdPNHwI0sV9lwJjg7W arwWrw==
x.lindforslaw.se.	3600	IN	A	194.9.94.85
x.lindforslaw.se.	3600	IN	A	194.9.94.86

;; AUTHORITY SECTION:
2c7045fto8aflnjrb560cdu1m30p5re0.lindforslaw.se. 3600 IN NSEC3 1 1 1 AB 2C7045FTO8AFLNJRB560CDU1M30P5RE2
2c7045fto8aflnjrb560cdu1m30p5re0.lindforslaw.se. 3600 IN RRSIG NSEC3 8 3 3600 20211223000000 20211202000000 21120 lindforslaw.se. N6rzlp4QpwDHfWDA9hx1PLJTfOPXU99ijmR7KmLAecl6D2I+7QThItQw Cea3Qiu6oyIekPIcWM8oq3WhNpna39MiwIZRIWgXW/vUL9O+zsF4QSD3 2+oahlQDiVFvSlGCY9uKI+jYOUS1sHhMOkDOaxO7UY/PEYtLkFOY1ABY 2sQ1WCW61mHBVTxE3XC1ktMFZnXKnWOvI6Y+hc7fTFPptLGHTS1TOnDD +VWYf5UxaatiEhVX8MnclFoSG4MkQgaqK9NkxrT6MdiYWxmhtvR4yy8N YR8ErgT2VLiGnMOA3Lwt87PR29KZnaNH50GZAPY1UCiHlIL8DPzrjalo qk7ABg==

;; Query time: 324 msec
;; SERVER: 93.188.0.21#53(ns2.loopia.se) (UDP)
;; WHEN: Fri Dec 10 07:27:15 AEDT 2021
;; MSG SIZE  rcvd: 753

> 
> i can't easily tell whether that RRSIG covers both A records, but its placement in the response message immediately following the first of the two A records is suspicious. with qtype ANY this odd placement does not occur, but with qtype A it does.
> 
> the BIND9 resolver in my home does the same (i set DO, it doesn't set AD, and the rcode is NOERROR.) this seems wrong, though if gdns does the same thing, it may reflect a loophole in the specification rather than a bug.

Its a side effect of using OPTOUT.  You can’t prove or disprove the lack of a delegation at “x.lindforslaw.se”.
OPTOUT was designed for delegation heavy zones like COM, ORG, NET.  It was not intended to be used in enterprise,
home and similar zones.  It is also not the default.

> vixie
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]