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 mats.dufb...@internetstiftelsen.se Technical Expert Internetstiftelsen (The Swedish Internet Foundation) Mobile: +46 73 065 3899 https://internetstiftelsen.se/
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop