starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 03:05:51 +03:00

[GH-ISSUE #2306] hickory as validating resolver times out against bind security aware name server #964

New issue

Closed

opened 2026-03-16 01:06:13 +03:00 by kerem · 5 comments

kerem commented

2026-03-16 01:06:13 +03:00

Owner

Originally created by @justahero on GitHub (Jul 10, 2024).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2306

Describe the bug

When running hickory-dns as a validating resolver with bind as a security-aware name server the client dig can cause the resolver to timeout, hickory then crashes.

To Reproduce

Run the following test

DNS_TEST_VERBOSE_DOCKER_BUILD=1 DNS_TEST_PEER=bind DNS_TEST_SUBJECT="hickory $(dirname $(pwd))" \
  cargo t --manifest-path conformance/Cargo.toml -p conformance-tests -- \
  resolver::dnssec::rfc4035::section_5::section_5_3::rrsig_rr_inception_time_is_set_in_the_future --nocapture

Other tests fail too.

Expected behavior

The test should pass. Running the same test against unbound (DNS_TEST_PEER=unbound) passes the test. It could be caused by insufficiently configuring bind, but the effect itself it has on hickory might be worth checking regardless.

System:

OS: Ubuntu 22.04
Architecture: x86_64
Version: 22.04
rustc version: rustc 1.79.0 (129f3b996 2024-06-10)

Version:
Crate: resolver (most likely)
Version: 514f713afd

Additional context

The hickory output is pretty large, appended here are the first dozen lines that might indicate the issue.

stdout output

1720617644:DEBUG:hickory_server::server::server_future:107:received udp request from: 192.168.144.4:36627
1720617644:DEBUG:hickory_server::server::server_future:1097:request:17452 src:UDP://192.168.144.4#36627 type:QUERY dnssec:false QUERY:.:SOA:IN qflags:RD
1720617644:DEBUG:hickory_server::authority::catalog:139:query received: 17452
1720617644:DEBUG:hickory_server::authority::catalog:385:searching authorities for: .
1720617644:DEBUG:hickory_server::authority::catalog:408:request: 17452 found authority: .
1720617644:DEBUG:hickory_server::authority::catalog:456:no DAU in request, used default SupportAlgorithms
1720617644:DEBUG:hickory_server::authority::catalog:488:performing name: . type: SOA class: IN on .
1720617644:DEBUG:hickory_server::authority::authority_object:197:performing name: . type: SOA class: IN on .
1720617644:DEBUG:hickory_server::store::recursor::authority:130:recursive lookup: . SOA LookupOptions { dnssec_ok: false, supported_algorithms: SupportedAlgorithms { bit_map: 0 } }
1720617644:DEBUG:hickory_proto::xfer::dns_handle:64:querying: . SOA
1720617644:DEBUG:hickory_recursor::recursor_dns_handle:163:using roots for . nameservers
1720617644:INFO:hickory_recursor::recursor_pool:94:querying . for . IN NS
1720617644:DEBUG:hickory_proto::xfer::dns_handle:64:querying: . NS
1720617644:DEBUG:hickory_resolver::name_server::name_server_pool:258:sending request: [Query { name: Name("."), query_type: NS, query_class: IN }]
1720617644:DEBUG:hickory_resolver::name_server::name_server:107:reconnecting: NameServerConfig { socket_addr: 192.168.144.2:53, protocol: Udp, tls_dns_name: None, trust_negative_responses: false, bind_addr: None }
1720617644:DEBUG:hickory_proto::xfer:170:enqueueing message:QUERY:[Query { name: Name("."), query_type: NS, query_class: IN }]
1720617644:DEBUG:hickory_proto::udp::udp_client_stream:228:final message: ; header 42266:QUERY:RD:NoError:QUERY:0/0/1
; edns version: 0 dnssec_ok: true z_flags: 0x0000 max_payload: 1232 opts: 0
; query
;; . IN NS

1720617644:DEBUG:hickory_proto::udp::udp_stream:309:created socket successfully
1720617644:DEBUG:hickory_proto::udp::udp_client_stream:395:received message id: 42266
1720617644:DEBUG:hickory_proto::error:397:Response:; header 42266:RESPONSE:RD,AA:NoError:QUERY:2/0/1
; edns version: 0 dnssec_ok: true z_flags: 0x0000 max_payload: 1232 opts: 0
; query
;; . IN NS
; answers 2
. 86400 IN NS primary0.nameservers.com.
. 86400 IN RRSIG NS RSASHA256 0 86400 1720631479 1720620679 30213 . jDIhakHZSR4bQyOi7nBH58+kIaOxYa5R4sjMFIjJ+VuCyiZcnlpiK5Pvl4MKYE8Rr4efAUBbA5uBSTgXgpAhNgIPxLhmH/Idngu0HNANklGrUEuq+LJ1vKLrDnBRuZ9dfgGufZwzVf036ytavYioj8cPOdrci40s8m0McEf2tgGkdg2PWHtvXMEEeIbalmcsK0cCjaLC4p2UPEHrKdR1NJ8KREXSfKEAWbbu4O+yRzfWRTCp8RwBX2rN6wHqg6u83NJtX/BuW6B6sLdiFn2GSmVJFJVnzwoyJDqHYJ771Q9DrfedVCyhju+7wu6XhJ4Gu/OHLSDTIeabDGQtUuqf+Q==
; nameservers 0
; additionals 1

1720617644:INFO:hickory_recursor:91:response: 42266:RESPONSE:RD,AA:NoError:QUERY:2/0/1
1720617644:DEBUG:hickory_recursor::recursor_dns_handle:234:glue not found for primary0.nameservers.com.
1720617644:DEBUG:hickory_recursor::recursor_dns_handle:243:need glue for .
1720617644:DEBUG:hickory_recursor::recursor_dns_handle:163:using roots for com. nameservers
1720617644:INFO:hickory_recursor::recursor_pool:94:querying . for com. IN NS
1720617644:DEBUG:hickory_proto::xfer::dns_handle:64:querying: com. NS
1720617644:DEBUG:hickory_resolver::name_server::name_server_pool:258:sending request: [Query { name: Name("com."), query_type: NS, query_class: IN }]
1720617644:DEBUG:hickory_resolver::name_server::name_server:121:existing connection: NameServerConfig { socket_addr: 192.168.144.2:53, protocol: Udp, tls_dns_name: None, trust_negative_responses: false, bind_addr: None }
1720617644:DEBUG:hickory_proto::xfer:170:enqueueing message:QUERY:[Query { name: Name("com."), query_type: NS, query_class: IN }]
1720617644:DEBUG:hickory_recursor::recursor_dns_handle:163:using roots for com. nameservers
1720617644:DEBUG:hickory_proto::udp::udp_client_stream:228:final message: ; header 8345:QUERY:RD:NoError:QUERY:0/0/1
; edns version: 0 dnssec_ok: true z_flags: 0x0000 max_payload: 1232 opts: 0
; query
;; com. IN NS

1720617644:DEBUG:hickory_proto::udp::udp_stream:309:created socket successfully
1720617644:DEBUG:hickory_proto::udp::udp_client_stream:395:received message id: 8345
1720617644:DEBUG:hickory_proto::error:397:Response:; header 8345:RESPONSE:RD,AA:NoError:QUERY:0/4/1
; edns version: 0 dnssec_ok: true z_flags: 0x0000 max_payload: 1232 opts: 0
; query
;; com. IN NS
; answers 0
; nameservers 4
. 86400 IN SOA primary0.nameservers.com. admin0.nameservers.com. 2024010101 1800 900 604800 86400
. 86400 IN RRSIG SOA RSASHA256 0 86400 1720631479 1720620679 30213 . W1lhSej/BHW7AUfeItfb1uioD0R6JarE5lGddPPOagkR7avFToNaRC8kPVyTK0bWw4N3WDu9bcxCjQ5c7UETmoElmS1TdSBHtfDObzPj1DLkFeqkzWRrv/IcCsJlGyi51b/W0C/qr40ocyp+gPqKLioWM60zd1Kvy/JX8q8C6Z3ltZVnQ/xGoJf1umXZQ35VRjqLom8WCQEiYrvT6yU9uvmQwFrtI5nhrpCorqq6Ek3YZjLZoxOV5E/b7g7sl2JaWswMwXHgirIQJjXSwM2fRWLrzQhWBeJjlV4c6LMseEAXwNtB6Pko1UxyMLYvohC5dnHoU59E5A1JZeDTt8jIXw==
ob3tg7biatorsf0a64vdc83564qu1c2v. 86400 IN NSEC3 1 1 1 - HWCPMSFB76MCOF3SLNZ57TG4AIOWW3DY
ob3tg7biatorsf0a64vdc83564qu1c2v. 86400 IN RRSIG NSEC3 RSASHA256 1 86400 1720631479 1720620679 30213 . nfugNBKIo/1IuQDHL0kwW/ouH7Gim8UzRFHfpWxq2BoM7GP7IwjLEQn9ydcRJq3klH6Gs8nZgovwyOqfwjs9MfkmncjiwBxciDmqqnpdN5mU1GTqYT1GPTgI0H0s9SWXxJgoolQ90w00cL5YT86zVfq6XDnTIexgw7OfKakgC/RZwuzvWlpE3EfFWuNCoR30SSarV0pAsVP1Boolqf7R7Zi3K8LBbcYisKrKVhG/6HNdnfFtqqHtAqxCC0EYkwnWyDkKLBhY/S+42MTtsdDLPmdRcnrKDGOj2NtToEjRZj57jAm947zUuvIz7onbSiExB0m2qXXz48bQub1NAxe4Vw==
; additionals 1

1720617644:WARN:hickory_recursor::recursor_dns_handle:143:lookup error: proto error: no records found for Query { name: Name("com."), query_type: NS, query_class: IN }
1720617644:DEBUG:hickory_recursor::recursor_dns_handle:104:ns forwarded to .
1720617644:DEBUG:hickory_recursor::recursor_dns_handle:163:using roots for . nameservers
1720617644:DEBUG:hickory_recursor::recursor_dns_handle:131:cached data Ok(Lookup { query: Query { name: Name("."), query_type: NS, query_class: IN }, records: [Record { name_labels: Name("."), dns_class: IN, ttl: 86400, rdata: NS(NS(Name("primary0.nameservers.com."))), proof: Indeterminate }, Record { name_labels: Name("."), dns_class: IN, ttl: 86400, rdata: DNSSEC(RRSIG(RRSIG(SIG { type_covered: NS, algorithm: RSASHA256, num_labels: 0, original_ttl: 86400, sig_expiration: 1720631479, sig_inception: 1720620679, key_tag: 30213, signer_name: Name("."), sig: [140, 50, 33, 106, 65, 217, 73, 30, 27, 67, 35, 162, 238, 112, 71, 231, 207, 164, 33, 163, 177, 97, 174, 81, 226, 200, 204, 20, 136, 201, 249, 91, 130, 202, 38, 92, 158, 90, 98, 43, 147, 239, 151, 131, 10, 96, 79, 17, 175, 135, 159, 1, 64, 91, 3, 155, 129, 73, 56, 23, 130, 144, 33, 54, 2, 15, 196, 184, 102, 31, 242, 29, 158, 11, 180, 28, 208, 13, 146, 81, 171, 80, 75, 170, 248, 178, 117, 188, 162, 235, 14, 112, 81, 185, 159, 93, 126, 1, 174, 125, 156, 51, 85, 253, 55, 235, 43, 90, 189, 136, 168, 143, 199, 15, 57, 218, 220, 139, 141, 44, 242, 109, 12, 112, 71, 246, 182, 1, 164, 118, 13, 143, 88, 123, 111, 92, 193, 4, 120, 134, 218, 150, 103, 44, 43, 71, 2, 141, 162, 194, 226, 157, 148, 60, 65, 235, 41, 212, 117, 52, 159, 10, 68, 69, 210, 124, 161, 0, 89, 182, 238, 224, 239, 178, 71, 55, 214, 69, 48, 169, 241, 28, 1, 95, 106, 205, 235, 1, 234, 131, 171, 188, 220, 210, 109, 95, 240, 110, 91, 160, 122, 176, 183, 98, 22, 125, 134, 74, 101, 73, 20, 149, 103, 207, 10, 50, 36, 58, 135, 96, 158, 251, 213, 15, 67, 173, 247, 157, 84, 44, 161, 142, 239, 187, 194, 238, 151, 132, 158, 6, 187, 243, 135, 45, 32, 211, 33, 230, 155, 12, 100, 45, 82, 234, 159, 249] }))), proof: Indeterminate }], valid_until: Instant { tv_sec: 150555, tv_nsec: 48094045 } })
1720617644:DEBUG:hickory_recursor::recursor_dns_handle:234:glue not found for primary0.nameservers.com.
1720617644:DEBUG:hickory_recursor::recursor_dns_handle:243:need glue for .
1720617644:DEBUG:hickory_recursor::recursor_dns_handle:163:using roots for com. nameservers
1720617644:INFO:hickory_recursor::recursor_pool:94:querying . for com. IN NS
1720617644:DEBUG:hickory_proto::xfer::dns_handle:64:querying: com. NS

Originally created by @justahero on GitHub (Jul 10, 2024). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2306 **Describe the bug** When running `hickory-dns` as a validating resolver with `bind` as a security-aware name server the client `dig` can cause the resolver to timeout, hickory then crashes. **To Reproduce** Run the following test ```shell DNS_TEST_VERBOSE_DOCKER_BUILD=1 DNS_TEST_PEER=bind DNS_TEST_SUBJECT="hickory $(dirname $(pwd))" \ cargo t --manifest-path conformance/Cargo.toml -p conformance-tests -- \ resolver::dnssec::rfc4035::section_5::section_5_3::rrsig_rr_inception_time_is_set_in_the_future --nocapture ``` Other tests fail too. **Expected behavior** The test should pass. Running the same test against `unbound` (`DNS_TEST_PEER=unbound`) passes the test. It could be caused by insufficiently configuring `bind`, but the effect itself it has on hickory might be worth checking regardless. **System:** - OS: Ubuntu 22.04 - Architecture: x86_64 - Version: 22.04 - rustc version: rustc 1.79.0 (129f3b996 2024-06-10) **Version:** Crate: resolver (most likely) Version: 514f713afdf66ba80677e7c34c29fb5030878233 **Additional context** The hickory output is pretty large, appended here are the first dozen lines that might indicate the issue. <details> <summary>stdout output</summary> ``` 1720617644:DEBUG:hickory_server::server::server_future:107:received udp request from: 192.168.144.4:36627 1720617644:DEBUG:hickory_server::server::server_future:1097:request:17452 src:UDP://192.168.144.4#36627 type:QUERY dnssec:false QUERY:.:SOA:IN qflags:RD 1720617644:DEBUG:hickory_server::authority::catalog:139:query received: 17452 1720617644:DEBUG:hickory_server::authority::catalog:385:searching authorities for: . 1720617644:DEBUG:hickory_server::authority::catalog:408:request: 17452 found authority: . 1720617644:DEBUG:hickory_server::authority::catalog:456:no DAU in request, used default SupportAlgorithms 1720617644:DEBUG:hickory_server::authority::catalog:488:performing name: . type: SOA class: IN on . 1720617644:DEBUG:hickory_server::authority::authority_object:197:performing name: . type: SOA class: IN on . 1720617644:DEBUG:hickory_server::store::recursor::authority:130:recursive lookup: . SOA LookupOptions { dnssec_ok: false, supported_algorithms: SupportedAlgorithms { bit_map: 0 } } 1720617644:DEBUG:hickory_proto::xfer::dns_handle:64:querying: . SOA 1720617644:DEBUG:hickory_recursor::recursor_dns_handle:163:using roots for . nameservers 1720617644:INFO:hickory_recursor::recursor_pool:94:querying . for . IN NS 1720617644:DEBUG:hickory_proto::xfer::dns_handle:64:querying: . NS 1720617644:DEBUG:hickory_resolver::name_server::name_server_pool:258:sending request: [Query { name: Name("."), query_type: NS, query_class: IN }] 1720617644:DEBUG:hickory_resolver::name_server::name_server:107:reconnecting: NameServerConfig { socket_addr: 192.168.144.2:53, protocol: Udp, tls_dns_name: None, trust_negative_responses: false, bind_addr: None } 1720617644:DEBUG:hickory_proto::xfer:170:enqueueing message:QUERY:[Query { name: Name("."), query_type: NS, query_class: IN }] 1720617644:DEBUG:hickory_proto::udp::udp_client_stream:228:final message: ; header 42266:QUERY:RD:NoError:QUERY:0/0/1 ; edns version: 0 dnssec_ok: true z_flags: 0x0000 max_payload: 1232 opts: 0 ; query ;; . IN NS 1720617644:DEBUG:hickory_proto::udp::udp_stream:309:created socket successfully 1720617644:DEBUG:hickory_proto::udp::udp_client_stream:395:received message id: 42266 1720617644:DEBUG:hickory_proto::error:397:Response:; header 42266:RESPONSE:RD,AA:NoError:QUERY:2/0/1 ; edns version: 0 dnssec_ok: true z_flags: 0x0000 max_payload: 1232 opts: 0 ; query ;; . IN NS ; answers 2 . 86400 IN NS primary0.nameservers.com. . 86400 IN RRSIG NS RSASHA256 0 86400 1720631479 1720620679 30213 . jDIhakHZSR4bQyOi7nBH58+kIaOxYa5R4sjMFIjJ+VuCyiZcnlpiK5Pvl4MKYE8Rr4efAUBbA5uBSTgXgpAhNgIPxLhmH/Idngu0HNANklGrUEuq+LJ1vKLrDnBRuZ9dfgGufZwzVf036ytavYioj8cPOdrci40s8m0McEf2tgGkdg2PWHtvXMEEeIbalmcsK0cCjaLC4p2UPEHrKdR1NJ8KREXSfKEAWbbu4O+yRzfWRTCp8RwBX2rN6wHqg6u83NJtX/BuW6B6sLdiFn2GSmVJFJVnzwoyJDqHYJ771Q9DrfedVCyhju+7wu6XhJ4Gu/OHLSDTIeabDGQtUuqf+Q== ; nameservers 0 ; additionals 1 1720617644:INFO:hickory_recursor:91:response: 42266:RESPONSE:RD,AA:NoError:QUERY:2/0/1 1720617644:DEBUG:hickory_recursor::recursor_dns_handle:234:glue not found for primary0.nameservers.com. 1720617644:DEBUG:hickory_recursor::recursor_dns_handle:243:need glue for . 1720617644:DEBUG:hickory_recursor::recursor_dns_handle:163:using roots for com. nameservers 1720617644:INFO:hickory_recursor::recursor_pool:94:querying . for com. IN NS 1720617644:DEBUG:hickory_proto::xfer::dns_handle:64:querying: com. NS 1720617644:DEBUG:hickory_resolver::name_server::name_server_pool:258:sending request: [Query { name: Name("com."), query_type: NS, query_class: IN }] 1720617644:DEBUG:hickory_resolver::name_server::name_server:121:existing connection: NameServerConfig { socket_addr: 192.168.144.2:53, protocol: Udp, tls_dns_name: None, trust_negative_responses: false, bind_addr: None } 1720617644:DEBUG:hickory_proto::xfer:170:enqueueing message:QUERY:[Query { name: Name("com."), query_type: NS, query_class: IN }] 1720617644:DEBUG:hickory_recursor::recursor_dns_handle:163:using roots for com. nameservers 1720617644:DEBUG:hickory_proto::udp::udp_client_stream:228:final message: ; header 8345:QUERY:RD:NoError:QUERY:0/0/1 ; edns version: 0 dnssec_ok: true z_flags: 0x0000 max_payload: 1232 opts: 0 ; query ;; com. IN NS 1720617644:DEBUG:hickory_proto::udp::udp_stream:309:created socket successfully 1720617644:DEBUG:hickory_proto::udp::udp_client_stream:395:received message id: 8345 1720617644:DEBUG:hickory_proto::error:397:Response:; header 8345:RESPONSE:RD,AA:NoError:QUERY:0/4/1 ; edns version: 0 dnssec_ok: true z_flags: 0x0000 max_payload: 1232 opts: 0 ; query ;; com. IN NS ; answers 0 ; nameservers 4 . 86400 IN SOA primary0.nameservers.com. admin0.nameservers.com. 2024010101 1800 900 604800 86400 . 86400 IN RRSIG SOA RSASHA256 0 86400 1720631479 1720620679 30213 . W1lhSej/BHW7AUfeItfb1uioD0R6JarE5lGddPPOagkR7avFToNaRC8kPVyTK0bWw4N3WDu9bcxCjQ5c7UETmoElmS1TdSBHtfDObzPj1DLkFeqkzWRrv/IcCsJlGyi51b/W0C/qr40ocyp+gPqKLioWM60zd1Kvy/JX8q8C6Z3ltZVnQ/xGoJf1umXZQ35VRjqLom8WCQEiYrvT6yU9uvmQwFrtI5nhrpCorqq6Ek3YZjLZoxOV5E/b7g7sl2JaWswMwXHgirIQJjXSwM2fRWLrzQhWBeJjlV4c6LMseEAXwNtB6Pko1UxyMLYvohC5dnHoU59E5A1JZeDTt8jIXw== ob3tg7biatorsf0a64vdc83564qu1c2v. 86400 IN NSEC3 1 1 1 - HWCPMSFB76MCOF3SLNZ57TG4AIOWW3DY ob3tg7biatorsf0a64vdc83564qu1c2v. 86400 IN RRSIG NSEC3 RSASHA256 1 86400 1720631479 1720620679 30213 . nfugNBKIo/1IuQDHL0kwW/ouH7Gim8UzRFHfpWxq2BoM7GP7IwjLEQn9ydcRJq3klH6Gs8nZgovwyOqfwjs9MfkmncjiwBxciDmqqnpdN5mU1GTqYT1GPTgI0H0s9SWXxJgoolQ90w00cL5YT86zVfq6XDnTIexgw7OfKakgC/RZwuzvWlpE3EfFWuNCoR30SSarV0pAsVP1Boolqf7R7Zi3K8LBbcYisKrKVhG/6HNdnfFtqqHtAqxCC0EYkwnWyDkKLBhY/S+42MTtsdDLPmdRcnrKDGOj2NtToEjRZj57jAm947zUuvIz7onbSiExB0m2qXXz48bQub1NAxe4Vw== ; additionals 1 1720617644:WARN:hickory_recursor::recursor_dns_handle:143:lookup error: proto error: no records found for Query { name: Name("com."), query_type: NS, query_class: IN } 1720617644:DEBUG:hickory_recursor::recursor_dns_handle:104:ns forwarded to . 1720617644:DEBUG:hickory_recursor::recursor_dns_handle:163:using roots for . nameservers 1720617644:DEBUG:hickory_recursor::recursor_dns_handle:131:cached data Ok(Lookup { query: Query { name: Name("."), query_type: NS, query_class: IN }, records: [Record { name_labels: Name("."), dns_class: IN, ttl: 86400, rdata: NS(NS(Name("primary0.nameservers.com."))), proof: Indeterminate }, Record { name_labels: Name("."), dns_class: IN, ttl: 86400, rdata: DNSSEC(RRSIG(RRSIG(SIG { type_covered: NS, algorithm: RSASHA256, num_labels: 0, original_ttl: 86400, sig_expiration: 1720631479, sig_inception: 1720620679, key_tag: 30213, signer_name: Name("."), sig: [140, 50, 33, 106, 65, 217, 73, 30, 27, 67, 35, 162, 238, 112, 71, 231, 207, 164, 33, 163, 177, 97, 174, 81, 226, 200, 204, 20, 136, 201, 249, 91, 130, 202, 38, 92, 158, 90, 98, 43, 147, 239, 151, 131, 10, 96, 79, 17, 175, 135, 159, 1, 64, 91, 3, 155, 129, 73, 56, 23, 130, 144, 33, 54, 2, 15, 196, 184, 102, 31, 242, 29, 158, 11, 180, 28, 208, 13, 146, 81, 171, 80, 75, 170, 248, 178, 117, 188, 162, 235, 14, 112, 81, 185, 159, 93, 126, 1, 174, 125, 156, 51, 85, 253, 55, 235, 43, 90, 189, 136, 168, 143, 199, 15, 57, 218, 220, 139, 141, 44, 242, 109, 12, 112, 71, 246, 182, 1, 164, 118, 13, 143, 88, 123, 111, 92, 193, 4, 120, 134, 218, 150, 103, 44, 43, 71, 2, 141, 162, 194, 226, 157, 148, 60, 65, 235, 41, 212, 117, 52, 159, 10, 68, 69, 210, 124, 161, 0, 89, 182, 238, 224, 239, 178, 71, 55, 214, 69, 48, 169, 241, 28, 1, 95, 106, 205, 235, 1, 234, 131, 171, 188, 220, 210, 109, 95, 240, 110, 91, 160, 122, 176, 183, 98, 22, 125, 134, 74, 101, 73, 20, 149, 103, 207, 10, 50, 36, 58, 135, 96, 158, 251, 213, 15, 67, 173, 247, 157, 84, 44, 161, 142, 239, 187, 194, 238, 151, 132, 158, 6, 187, 243, 135, 45, 32, 211, 33, 230, 155, 12, 100, 45, 82, 234, 159, 249] }))), proof: Indeterminate }], valid_until: Instant { tv_sec: 150555, tv_nsec: 48094045 } }) 1720617644:DEBUG:hickory_recursor::recursor_dns_handle:234:glue not found for primary0.nameservers.com. 1720617644:DEBUG:hickory_recursor::recursor_dns_handle:243:need glue for . 1720617644:DEBUG:hickory_recursor::recursor_dns_handle:163:using roots for com. nameservers 1720617644:INFO:hickory_recursor::recursor_pool:94:querying . for com. IN NS 1720617644:DEBUG:hickory_proto::xfer::dns_handle:64:querying: com. NS ``` </details>

kerem

2026-03-16 01:06:13 +03:00

closed this issue
added the
bug
label

kerem commented

2026-03-16 01:06:29 +03:00

Author

Owner

@japaric commented on GitHub (Jul 12, 2024):

7 conformance tests fail when the TEST_PEER is set to BIND instead of unbound (nsd) and TEST_SUBJECT is hickory. TEST_SUBJECT=unbound + TEST_PEER=bind does not produce any failure.

currently investigating but at first glance it seems that the test resolver::dnssec::rfc4035::section_3::section_3_2::do_bit_not_set_in_request also goes into some sort of loop as what has been reported here because the tshark capture file in the TEST_SUBJECT=hickory case is 40x times longer than in the SUBJECT=unbound case

@japaric commented on GitHub (Jul 12, 2024): 7 conformance tests fail when the TEST_PEER is set to BIND instead of `unbound` (`nsd`) and TEST_SUBJECT is hickory. TEST_SUBJECT=unbound + TEST_PEER=bind does not produce any failure. currently investigating but at first glance it seems that the test `resolver::dnssec::rfc4035::section_3::section_3_2::do_bit_not_set_in_request` also goes into some sort of loop as what has been reported here because the `tshark` capture file in the TEST_SUBJECT=hickory case is 40x times longer than in the SUBJECT=unbound case

kerem commented

2026-03-16 01:06:34 +03:00

Author

Owner

@japaric commented on GitHub (Jul 12, 2024):

Sebastian said

It could be caused by insufficiently configuring bind

given that

TEST_SUBJECT=unbound + TEST_PEER=bind does not produce any failure

I would think that BIND is properly configured and that hickory should not fail any test that unbound passes

@japaric commented on GitHub (Jul 12, 2024): Sebastian said > It could be caused by insufficiently configuring bind given that > TEST_SUBJECT=unbound + TEST_PEER=bind does not produce any failure I would think that BIND is properly configured and that hickory should not fail any test that unbound passes

kerem commented

2026-03-16 01:06:39 +03:00

Author

Owner

@japaric commented on GitHub (Jul 12, 2024):

I have come up with a minimal repro in #2309

7 conformance tests fail when the TEST_PEER is set to BIND instead of unbound (nsd) and TEST_SUBJECT is hickory.

the one thing these 7 failures had was that the DNS network consisted of a single nameserver, the root nameserver.

what appears to be the problem is that BIND does not include a glue record (an A record) when it responds to NS queries which is a common way to give a referral to another nameserver (a NS + A record pair that is)

the problem appears to be that when hickory-dns see that response to . NS lacks an A record, it will try to get that information from the authoritative nameserver. the NS . response includes the domain primaryNN.nameservers.com. so hickory will send out queries like com. NS and nameservers.com. NS but the only . nameserver it knows about cannot answer those queries. hickory gets stuck in that loop of trying to get the primaryNN.nameservers.com. A record from the authority over nameservers.com. when in fact the . nameserver can serve that record.

This is not a bug in DNSSEC functionality but rather a bug in plain DNS recursive resolution. the regression test in #2309 does not use any DNSSEC functionality, e.g. signed zone files.

@japaric commented on GitHub (Jul 12, 2024): I have come up with a minimal repro in #2309 > 7 conformance tests fail when the TEST_PEER is set to BIND instead of unbound (nsd) and TEST_SUBJECT is hickory. the one thing these 7 failures had was that the DNS network consisted of a single nameserver, the root nameserver. what appears to be the problem is that BIND does not include a glue record (an A record) when it responds to NS queries which is a common way to give a referral to another nameserver (a NS + A record pair that is) the problem appears to be that when hickory-dns see that response to `. NS` lacks an A record, it will try to get that information from the authoritative nameserver. the `NS .` response includes the domain `primaryNN.nameservers.com.` so hickory will send out queries like `com. NS` and `nameservers.com. NS` but the only `.` nameserver it knows about cannot answer those queries. hickory gets stuck in that loop of trying to get the `primaryNN.nameservers.com. A` record from the authority over `nameservers.com.` when in fact the `.` nameserver can serve that record. This is not a bug in DNSSEC functionality but rather a bug in plain DNS recursive resolution. the regression test in #2309 does not use any DNSSEC functionality, e.g. signed zone files.

kerem commented

2026-03-16 01:06:44 +03:00

Author

Owner

@marcus0x62 commented on GitHub (Jul 30, 2024):

I ran into this bug while doing some testing and did some more research. The root cause is mutual recursion between ns_pool_for_zone and resolve in recursor_dns_handle.rs, specifically the calls to resolve here and here.

I describe this in more detail in the PR, but, essentially the possibility of infinite recursion exists in the following circumstances:

The parent DNS server for a zone returns NS records with no glue
All returned NS records point to child records of the zone being queried (e.g., ns1.example.com for ns.example.com)

Triggering this bug in the wild depends mostly on point #1 -- whether or not the parent DNS server returns glue records. BIND seems to be particularly idiosyncratic in that respect.

@marcus0x62 commented on GitHub (Jul 30, 2024): I ran into this bug while doing some testing and did some more research. The root cause is mutual recursion between ns_pool_for_zone and resolve in recursor_dns_handle.rs, specifically the calls to resolve [here](https://github.com/hickory-dns/hickory-dns/blob/34698f5b43a6330a100b6d7ea407e3a5cb2dd154/crates/recursor/src/recursor_dns_handle.rs#L347) and [here](https://github.com/hickory-dns/hickory-dns/blob/34698f5b43a6330a100b6d7ea407e3a5cb2dd154/crates/recursor/src/recursor_dns_handle.rs#L352). I describe this in more detail in the PR, but, essentially the possibility of infinite recursion exists in the following circumstances: 1. The parent DNS server for a zone returns NS records with no glue 2. All returned NS records point to child records of the zone being queried (e.g., ns1.example.com for ns.example.com) Triggering this bug in the wild depends mostly on point #1 -- whether or not the parent DNS server returns glue records. BIND seems to be particularly idiosyncratic in that respect.

kerem commented

2026-03-16 01:06:49 +03:00

Author

Owner

@marcus0x62 commented on GitHub (Aug 27, 2024):

This should be resolved with the merging of PR #2332

@marcus0x62 commented on GitHub (Aug 27, 2024): This should be resolved with the merging of PR #2332

kerem referenced this issue

2026-03-16 02:27:31 +03:00

[PR #964] [MERGED] temporarily ignore audit failure of spin #1821