[GH-ISSUE #2152] Reverse lookup fails when there are multiple PTR records #904

New issue

Closed

opened 2026-03-16 00:49:16 +03:00 by kerem · 1 comment

kerem commented

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

Owner

Originally created by @mladedav on GitHub (Feb 23, 2024).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2152

Description

When multiple PTR records are available, the resolver returns ResolveError with kind NoRecordsFound.

Reproduction

I don't know of any public server that has multiple PTR records. However, podman seems to have multiple (when I run it through docker compose with [aardvark-dns](https://archlinux.org/packages/?name=aardvark-dns)) so that may be a simple way to repro. Or just running hickory-dns as a server.

I did not try to repro with hickory itself so I do hope I'm not misdiagnosing the issue.

Expected behavior

The resolution succeeds.

System:

OS: Linux, inside podman
Architecture: x86_64
Version: Linux 38dc918649b0 6.1.71-1-MANJARO # 1 SMP PREEMPT_DYNAMIC Fri Jan 5 17:36:36 UTC 2024 x86_64 GNU/Linux
rustc version: 1.76.0 (07dca489a 2024-02-04)

Version:
Crate: resolver
Version: 0.24

Context

I can see in the logs that the DNS server serves a response. It works for me in docker where there is only one response so I assume that is the relevant difference although I may be wrong.

Details

Code:

        let resolver = AsyncResolver::tokio_from_system_conf().unwrap();
        let foo = resolver
            .lookup(
                Name::from_ascii("54.0.89.10.in-addr.arpa.").unwrap(),
                RecordType::PTR,
            )
            .await
            .unwrap();

calling reverse_lookup produces the same thing, I tried this directly if there were just an issue with converting the response.

Log:

2024-02-23T12:04:12.854877Z DEBUG hickory_proto::xfer::dns_handle: querying: 54.0.89.10.in-addr.arpa. PTR
2024-02-23T12:04:12.854930Z DEBUG hickory_resolver::name_server::name_server_pool: sending request: [Query { name: Name("54.0.89.10.in-addr.arpa."), query_type: PTR, query_class: IN }]
2024-02-23T12:04:12.854983Z DEBUG hickory_resolver::name_server::name_server: reconnecting: NameServerConfig { socket_addr: 10.89.0.1:53, protocol: Udp, tls_dns_name: None, trust_negative_responses: false, bind_addr: None }
2024-02-23T12:04:12.855039Z DEBUG hickory_proto::xfer: enqueueing message:QUERY:[Query { name: Name("54.0.89.10.in-addr.arpa."), query_type: PTR, query_class: IN }]
2024-02-23T12:04:12.855313Z DEBUG hickory_proto::udp::udp_client_stream: final message: ; header 32055:QUERY:RD:NoError:QUERY:0/0/0
; query
;; 54.0.89.10.in-addr.arpa. IN PTR

2024-02-23T12:04:12.855439Z DEBUG hickory_proto::udp::udp_stream: created socket successfully
2024-02-23T12:04:12.855824Z DEBUG hickory_proto::udp::udp_client_stream: received message id: 32055
2024-02-23T12:04:12.855855Z DEBUG hickory_resolver::error: Response:; header 32055:RESPONSE:RD,RA:NoError:QUERY:4/0/0
; query
;; 54.0.89.10.in-addr.arpa. IN PTR
; answers 4
. 60 IN PTR container-name-1.
. 60 IN PTR container-name-1.
. 60 IN PTR service-name.
. 60 IN PTR 04bf599db116.
; nameservers 0
; additionals 0

2024-02-23T12:04:12.855896Z DEBUG hickory_resolver::error: Response:; header 32055:RESPONSE:RD,RA:NoError:QUERY:4/0/0
; query
;; 54.0.89.10.in-addr.arpa. IN PTR
; answers 4
. 60 IN PTR container-name-1.
. 60 IN PTR container-name-1.
. 60 IN PTR service-name.
. 60 IN PTR 04bf599db116.
; nameservers 0
; additionals 0

thread 'main' panicked at src/main.rs:65:14:
called `Result::unwrap()` on an `Err` value: ResolveError { kind: NoRecordsFound { query: Query { name: Name("54.0.89.10.in-addr.arpa."), query_type: PTR, query_class: IN }, soa: None, negative_ttl: None, response_code: NoError, trusted: true } }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Originally created by @mladedav on GitHub (Feb 23, 2024). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2152 ### Description When multiple PTR records are available, the resolver returns `ResolveError` with kind `NoRecordsFound`. ### Reproduction I don't know of any public server that has multiple PTR records. However, podman seems to have multiple (when I run it through docker compose with `[aardvark-dns](https://archlinux.org/packages/?name=aardvark-dns)`) so that may be a simple way to repro. Or just running hickory-dns as a server. I did not try to repro with hickory itself so I do hope I'm not misdiagnosing the issue. ### Expected behavior The resolution succeeds. **System:** - OS: Linux, inside podman - Architecture: x86_64 - Version: Linux 38dc918649b0 6.1.71-1-MANJARO # 1 SMP PREEMPT_DYNAMIC Fri Jan 5 17:36:36 UTC 2024 x86_64 GNU/Linux - rustc version: 1.76.0 (07dca489a 2024-02-04) **Version:** Crate: resolver Version: 0.24 ### Context I can see in the logs that the DNS server serves a response. It works for me in docker where there is only one response so I assume that is the relevant difference although I may be wrong. <details><summary>Details</summary> Code: ```rust let resolver = AsyncResolver::tokio_from_system_conf().unwrap(); let foo = resolver .lookup( Name::from_ascii("54.0.89.10.in-addr.arpa.").unwrap(), RecordType::PTR, ) .await .unwrap(); ``` calling `reverse_lookup` produces the same thing, I tried this directly if there were just an issue with converting the response. Log: ``` 2024-02-23T12:04:12.854877Z DEBUG hickory_proto::xfer::dns_handle: querying: 54.0.89.10.in-addr.arpa. PTR 2024-02-23T12:04:12.854930Z DEBUG hickory_resolver::name_server::name_server_pool: sending request: [Query { name: Name("54.0.89.10.in-addr.arpa."), query_type: PTR, query_class: IN }] 2024-02-23T12:04:12.854983Z DEBUG hickory_resolver::name_server::name_server: reconnecting: NameServerConfig { socket_addr: 10.89.0.1:53, protocol: Udp, tls_dns_name: None, trust_negative_responses: false, bind_addr: None } 2024-02-23T12:04:12.855039Z DEBUG hickory_proto::xfer: enqueueing message:QUERY:[Query { name: Name("54.0.89.10.in-addr.arpa."), query_type: PTR, query_class: IN }] 2024-02-23T12:04:12.855313Z DEBUG hickory_proto::udp::udp_client_stream: final message: ; header 32055:QUERY:RD:NoError:QUERY:0/0/0 ; query ;; 54.0.89.10.in-addr.arpa. IN PTR 2024-02-23T12:04:12.855439Z DEBUG hickory_proto::udp::udp_stream: created socket successfully 2024-02-23T12:04:12.855824Z DEBUG hickory_proto::udp::udp_client_stream: received message id: 32055 2024-02-23T12:04:12.855855Z DEBUG hickory_resolver::error: Response:; header 32055:RESPONSE:RD,RA:NoError:QUERY:4/0/0 ; query ;; 54.0.89.10.in-addr.arpa. IN PTR ; answers 4 . 60 IN PTR container-name-1. . 60 IN PTR container-name-1. . 60 IN PTR service-name. . 60 IN PTR 04bf599db116. ; nameservers 0 ; additionals 0 2024-02-23T12:04:12.855896Z DEBUG hickory_resolver::error: Response:; header 32055:RESPONSE:RD,RA:NoError:QUERY:4/0/0 ; query ;; 54.0.89.10.in-addr.arpa. IN PTR ; answers 4 . 60 IN PTR container-name-1. . 60 IN PTR container-name-1. . 60 IN PTR service-name. . 60 IN PTR 04bf599db116. ; nameservers 0 ; additionals 0 thread 'main' panicked at src/main.rs:65:14: called `Result::unwrap()` on an `Err` value: ResolveError { kind: NoRecordsFound { query: Query { name: Name("54.0.89.10.in-addr.arpa."), query_type: PTR, query_class: IN }, soa: None, negative_ttl: None, response_code: NoError, trusted: true } } note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` </details>

kerem closed this issue

2026-03-16 00:49:21 +03:00

kerem commented

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

Author

Owner

@mladedav commented on GitHub (Feb 27, 2024):

On another look this seems to be an issue with aardvark-dns because the records point to . instead of the queried domain. Sorry for raising this here.

@mladedav commented on GitHub (Feb 27, 2024): On another look this seems to be an issue with `aardvark-dns` because the records point to `.` instead of the queried domain. Sorry for raising this here.

kerem referenced this issue

2026-03-16 02:25:12 +03:00

[PR #904] [MERGED] Bump serde from 1.0.101 to 1.0.102 #1782