[dns-operations] Trouble with qa.ws.igt.fiscal.treasury.gov

Viktor Dukhovni ietf-dane at dukhovni.org
Tue Oct 18 06:59:48 UTC 2022


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.



More information about the dns-operations mailing list