[GH-ISSUE #2724] Recent breakage in internet-based tests #1050

New issue

Closed

opened 2026-03-16 01:26:15 +03:00 by kerem · 3 comments

kerem commented

2026-03-16 01:26:15 +03:00

Owner

Originally created by @divergentdave on GitHub (Jan 15, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2724

The example.com. zone changed recently, to use Akamai servers via a CNAME. As a result, our expected results in various tests are now incorrect. There are also two IPv4 addresses now, instead of one before.

I'm also seeing SERVFAIL responses from Google Public DNS when querying it over HTTP/2 or HTTP/3, but only in certain unit tests. Running cargo run --bin dns --all-features -- -p h3 -n 8.8.8.8:443 -t dns.google -e /dns-query query www.example.com. A works fine.

Originally created by @divergentdave on GitHub (Jan 15, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2724 The `example.com.` zone changed recently, to use Akamai servers via a CNAME. As a result, our expected results in various tests are now incorrect. There are also two IPv4 addresses now, instead of one before. I'm also seeing SERVFAIL responses from Google Public DNS when querying it over HTTP/2 or HTTP/3, but only in certain unit tests. Running `cargo run --bin dns --all-features -- -p h3 -n 8.8.8.8:443 -t dns.google -e /dns-query query www.example.com. A` works fine.

kerem closed this issue

2026-03-16 01:26:30 +03:00

kerem commented

2026-03-16 01:26:36 +03:00

Author

Owner

@divergentdave commented on GitHub (Jan 15, 2025):

Update: The SERVFAIL errors are just because these particular unit tests were very low-level, and constructed requests that did not include an OPT pseudo-record increasing the maximum payload. All the extra CNAME records in the answer meant that the default buffer size was no longer sufficient.

@divergentdave commented on GitHub (Jan 15, 2025): Update: The SERVFAIL errors are just because these particular unit tests were very low-level, and constructed requests that did not include an OPT pseudo-record increasing the maximum payload. All the extra CNAME records in the answer meant that the default buffer size was no longer sufficient.

kerem commented

2026-03-16 01:26:41 +03:00

Author

Owner

@divergentdave commented on GitHub (Jan 15, 2025):

I think we can expect a higher rate of flux in IP addresses of www.example.com., now that it is on Akamai. We need a new query to make in internet-based tests, to avoid repeat issues. hickory-dns.org is a reasonable candidate, since it's not under someone else's control. The A/AAAA records point to GitHub Pages. It seems like the four IP addresses are fairly stable, based on the documentation. If the zone is configured with ALIAS/ANAME, then there's still a possibility they may change if GitHub changes their infrastructure in the future. We could instead create a TXT record on hickory-dns.org containing "Hello, world" or similar, and then query that. This way, the record would only serve one purpose, so it wouldn't ever have to change.

@divergentdave commented on GitHub (Jan 15, 2025): I think we can expect a higher rate of flux in IP addresses of `www.example.com.`, now that it is on Akamai. We need a new query to make in internet-based tests, to avoid repeat issues. `hickory-dns.org` is a reasonable candidate, since it's not under someone else's control. The A/AAAA records point to GitHub Pages. It seems like the four IP addresses are fairly stable, based on the documentation. If the zone is configured with ALIAS/ANAME, then there's still a possibility they may change if GitHub changes their infrastructure in the future. We could instead create a TXT record on `hickory-dns.org` containing "Hello, world" or similar, and then query that. This way, the record would only serve one purpose, so it wouldn't ever have to change.

kerem commented

2026-03-16 01:26:46 +03:00

Author

Owner

@divergentdave commented on GitHub (Jan 15, 2025):

Another wrinkle: DNSSEC signatures now only cover from the root up to the www.example.com IN CNAME record. When chasing the CNAME, the Akamai zones are unsigned, so we now get an "Insecure" validation outcome instead on those records.

$ delv @8.8.8.8 www.example.com. A
; fully validated
www.example.com.	133	IN	CNAME	www.example.com-v4.edgesuite.net.
www.example.com.	133	IN	RRSIG	CNAME 13 3 300 20250205003349 20250115021057 51304 example.com. W+wk1eS/qxGSj3YuY8c679YyYErOMjBdo6s7OZKIrNBQpmsUnkkCTpT0 Gzk9rrkvc4eSKJFgECbenDIq7O5gBQ==

; unsigned answer
www.example.com-v4.edgesuite.net. 21107	IN CNAME a1422.dscr.akamai.net.
a1422.dscr.akamai.net.	20	IN	A	23.59.169.132
a1422.dscr.akamai.net.	20	IN	A	23.59.169.142

Relatedly, the hickory-dns.org zone is unsigned, and we rely on this fact in a test. (sec_lookup_fails_test in crates/resolver/src/resolver.rs)

@divergentdave commented on GitHub (Jan 15, 2025): Another wrinkle: DNSSEC signatures now only cover from the root up to the `www.example.com IN CNAME` record. When chasing the CNAME, the Akamai zones are unsigned, so we now get an "Insecure" validation outcome instead on those records. ``` $ delv @8.8.8.8 www.example.com. A ; fully validated www.example.com. 133 IN CNAME www.example.com-v4.edgesuite.net. www.example.com. 133 IN RRSIG CNAME 13 3 300 20250205003349 20250115021057 51304 example.com. W+wk1eS/qxGSj3YuY8c679YyYErOMjBdo6s7OZKIrNBQpmsUnkkCTpT0 Gzk9rrkvc4eSKJFgECbenDIq7O5gBQ== ; unsigned answer www.example.com-v4.edgesuite.net. 21107 IN CNAME a1422.dscr.akamai.net. a1422.dscr.akamai.net. 20 IN A 23.59.169.132 a1422.dscr.akamai.net. 20 IN A 23.59.169.142 ``` Relatedly, the `hickory-dns.org` zone is unsigned, and we rely on this fact in a test. (`sec_lookup_fails_test` in `crates/resolver/src/resolver.rs`)

kerem referenced this issue

2026-03-16 03:27:40 +03:00

[PR #1050] [MERGED] Export CAA Property::as_str #1911

kerem referenced this issue

2026-03-16 03:42:51 +03:00

[PR #1050] [MERGED] Export CAA Property::as_str #1916