On Tue, Oct 18, 2022 at 02:02:48AM -0400, Viktor Dukhovni wrote:
> However, resolvers generally don't send explicit DS queries. Instead,
> when the parent zone is signed, they set the DO bit and expect any
> referrals to either include the signed DS records, or authenticated
> denial of existence thereof.
Perhaps "generally" is too strong, some do and some don't. The
validator module in "libunbound" does in fact walk down the tree probing
for DS records:
...
[1666075678] libunbound[59247:0] info: prime trust anchor
[1666075678] libunbound[59247:0] info: generate keytag query _ta-4f66. NULL
IN
[1666075678] libunbound[59247:0] info: resolving . DNSKEY IN
[1666075678] libunbound[59247:0] info: resolving _ta-4f66. NULL IN
[1666075678] libunbound[59247:0] info: response for . DNSKEY IN
[1666075678] libunbound[59247:0] info: reply from <.> 2001:500:1::53#53
[1666075678] libunbound[59247:0] info: query response was ANSWER
[1666075678] libunbound[59247:0] info: validate keys with anchor(DS):
sec_status_secure
[1666075678] libunbound[59247:0] info: Successfully primed trust anchor .
DNSKEY IN
[1666075678] libunbound[59247:0] info: validated DS gov. DS IN
[1666075678] libunbound[59247:0] info: resolving gov. DNSKEY IN
[1666075678] libunbound[59247:0] info: response for _ta-4f66. NULL IN
[1666075678] libunbound[59247:0] info: reply from <.> 199.9.14.201#53
[1666075678] libunbound[59247:0] info: query response was NXDOMAIN ANSWER
[1666075678] libunbound[59247:0] info: response for gov. DNSKEY IN
[1666075678] libunbound[59247:0] info: reply from <gov.>
2001:500:4431::2:30#53
[1666075678] libunbound[59247:0] info: query response was ANSWER
[1666075678] libunbound[59247:0] info: validated DNSKEY gov. DNSKEY IN
[1666075678] libunbound[59247:0] info: validated DS treasury.gov. DS IN
[1666075678] libunbound[59247:0] info: resolving treasury.gov. DNSKEY IN
[1666075678] libunbound[59247:0] info: response for treasury.gov. DNSKEY IN
[1666075678] libunbound[59247:0] info: reply from <treasury.gov.>
2610:108:3100:100a::20:53#53
[1666075678] libunbound[59247:0] info: query response was ANSWER
[1666075678] libunbound[59247:0] info: validated DNSKEY treasury.gov.
DNSKEY IN
[1666075678] libunbound[59247:0] info: resolving fiscal.treasury.gov. DS IN
[1666075678] libunbound[59247:0] info: response for fiscal.treasury.gov. DS
IN
[1666075678] libunbound[59247:0] info: reply from <treasury.gov.>
2610:108:3100:100a::20:53#53
[1666075678] libunbound[59247:0] info: query response was nodata ANSWER
[1666075678] libunbound[59247:0] info: NSEC3s for the referral proved no DS.
[1666075678] libunbound[59247:0] info: Verified that unsigned response is
INSECURE
qa.ws.igt.fiscal.treasury.gov has address 199.169.199.63
While CloudFlare 1.1.1.1 sometimes fails to resolve the same name:
$ dig -t a @1.1.1.1 qa.ws.igt.fiscal.treasury.gov
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 35710
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; NSID: 34 34 37 6d 37 39 ("447m79")
; EDE: 12 (NSEC Missing): (failed to verify an insecure referral proof for
fiscal.treasury.gov.)
;; QUESTION SECTION:
;qa.ws.igt.fiscal.treasury.gov. IN A
and sometimes (different anycast location and cache content) succeeds:
$ dig -t a @1.1.1.1 qa.ws.igt.fiscal.treasury.gov
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46190
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; NSID: 33 38 36 6d 31 32 37 ("386m127")
;; QUESTION SECTION:
;qa.ws.igt.fiscal.treasury.gov. IN A
;; ANSWER SECTION:
qa.ws.igt.fiscal.treasury.gov. 30 IN A 199.169.199.63
--
Viktor.
_______________________________________________
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
