Summary
RecursiveResolutionBackend's referral handling (referral_authorities / resolve_iterative in src/resolver/mod.rs) only follows a delegation when the parent zone supplies A/AAAA glue records for the child zone's nameservers in the same response. When a zone delegates to nameservers that are out-of-bailiwick with no glue possible (a "glueless delegation"), the referral is dropped entirely and resolution fails.
Repro
redis.io (and github.io) delegate to Amazon Route 53 nameservers spread across other TLDs:
redis.io. NS ns-1248.awsdns-28.org.
redis.io. NS ns-247.awsdns-30.com.
redis.io. NS ns-1731.awsdns-24.co.uk.
redis.io. NS ns-791.awsdns-34.net.
The .io registry cannot provide glue for names under .org/.com/.co.uk/.net, so the referral response has NS records but no usable additional-section glue for any of them.
In referral_authorities, every NS target name fails ns_name_allowed_for_delegation (none are in-bailiwick under redis.io or its parent io), so the names set ends up empty and the function returns None. resolve_iterative then falls into has_delegation_for_question, which is true (the NS record's owner matches), so it's counted as RecursiveBailiwickReject and the query fails with NoBackendsAvailable/SERVFAIL — even though the delegation is completely legitimate and any standards-compliant recursive resolver would just resolve the NS hostnames themselves.
Impact
Any domain hosted on third-party/managed DNS with nameservers outside the delegated zone's bailiwick (common with Route 53, some Cloudflare/other DNS-hosting setups) fails to resolve through rdns's recursive backend. This was undetected because the existing perf-test domain set (google.com, facebook.com, amazon.com, cloudflare.com, wikipedia.org) all happen to use in-bailiwick or otherwise-glued nameservers.
Expected fix
When a referral's NS records have no usable glue, recursively resolve the NS hostnames themselves (as their own A/AAAA queries through the same resolver) before giving up on the delegation, subject to the existing recursion-depth/timeout bounds.
Where
src/resolver/mod.rs: referral_authorities, resolve_iterative (RecursiveResolutionBackend)
Summary
RecursiveResolutionBackend's referral handling (referral_authorities/resolve_iterativeinsrc/resolver/mod.rs) only follows a delegation when the parent zone supplies A/AAAA glue records for the child zone's nameservers in the same response. When a zone delegates to nameservers that are out-of-bailiwick with no glue possible (a "glueless delegation"), the referral is dropped entirely and resolution fails.Repro
redis.io(andgithub.io) delegate to Amazon Route 53 nameservers spread across other TLDs:The
.ioregistry cannot provide glue for names under.org/.com/.co.uk/.net, so the referral response has NS records but no usable additional-section glue for any of them.In
referral_authorities, every NS target name failsns_name_allowed_for_delegation(none are in-bailiwick underredis.ioor its parentio), so thenamesset ends up empty and the function returnsNone.resolve_iterativethen falls intohas_delegation_for_question, which is true (the NS record's owner matches), so it's counted asRecursiveBailiwickRejectand the query fails withNoBackendsAvailable/SERVFAIL — even though the delegation is completely legitimate and any standards-compliant recursive resolver would just resolve the NS hostnames themselves.Impact
Any domain hosted on third-party/managed DNS with nameservers outside the delegated zone's bailiwick (common with Route 53, some Cloudflare/other DNS-hosting setups) fails to resolve through rdns's recursive backend. This was undetected because the existing perf-test domain set (google.com, facebook.com, amazon.com, cloudflare.com, wikipedia.org) all happen to use in-bailiwick or otherwise-glued nameservers.
Expected fix
When a referral's NS records have no usable glue, recursively resolve the NS hostnames themselves (as their own A/AAAA queries through the same resolver) before giving up on the delegation, subject to the existing recursion-depth/timeout bounds.
Where
src/resolver/mod.rs:referral_authorities,resolve_iterative(RecursiveResolutionBackend)