hosts despite `use_hosts_file == true` #899

New issue

Closed

opened 2026-03-16 00:47:58 +03:00 by kerem · 3 comments

kerem commented

2026-03-16 00:47:58 +03:00

Owner

Originally created by @hch12907 on GitHub (Feb 18, 2024).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2148

Describe the bug

I added 201.11.11.11 example.com to /etc/hosts. Pinging example.com shows that I am pinging the IP, so the hosts configuration is correct and working. But when I used dig example.com on my DNS forwarder it returned 93.184.216.34 (the actual IP of example.com from upstream DNS) instead of the IP inside the hosts file.

To Reproduce

Here is a small snippet:

use std::str::FromStr;
use std::sync::Arc;
use std::time::Duration;

use hickory_proto::op::Query;
use hickory_proto::rr::LowerName;
use hickory_resolver::config::{NameServerConfigGroup, ResolverOpts};
use hickory_resolver::{Hosts, Name};
use hickory_server::authority::{AuthorityObject, Catalog, ZoneType};
use hickory_server::store::forwarder::{ForwardAuthority, ForwardConfig};
use hickory_server::ServerFuture;
use tokio::net::{TcpListener, UdpSocket};

#[tokio::main]
async fn main() {
    let hosts = Hosts::new();
    println!("{:?}", hosts.lookup_static_host(&Query::query(Name::from_utf8("example.com").unwrap(), hickory_proto::rr::RecordType::A)));

    let mut catalog = Catalog::new();

    let forward_config = ForwardConfig {
        name_servers: NameServerConfigGroup::quad9_tls(),
        options: Some(ResolverOpts::default())
    };

    let authority = ForwardAuthority::try_from_config(
        Name::from_str(".").unwrap(), ZoneType::Forward, &forward_config).unwrap();

    catalog.upsert(LowerName::from_str(".").unwrap(), Box::new(Arc::new(authority)) as Box<dyn AuthorityObject>);

    let mut server_future = ServerFuture::new(catalog);
    let udp_socket = UdpSocket::bind("127.0.0.1:8000").await.unwrap();
    server_future.register_socket(udp_socket);
    let tcp_socket = TcpListener::bind("127.0.0.1:8000").await.unwrap();
    server_future.register_listener(tcp_socket, Duration::from_secs(3));

    server_future.block_until_done().await.unwrap();
}

Expected behavior
As expected, the snippet above prints Some(...) with the correct RData Some(A(A(201.11.11.11))).

But unexpectedly, dig @127.0.0.1 -p 8000 example.com still returned 93.184.216.34. It should be 201.11.11.11.

System:

OS: Linux
Architecture: x86_64
Version: Arch Linux
rustc version: 1.75.0

Version:
Crate: hickory-resolver / hickory-server
Version: 0.24.0

Originally created by @hch12907 on GitHub (Feb 18, 2024). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2148 **Describe the bug** I added `201.11.11.11 example.com` to `/etc/hosts`. Pinging `example.com` shows that I am pinging the IP, so the hosts configuration is correct and working. But when I used `dig example.com` on my DNS forwarder it returned `93.184.216.34` (the actual IP of `example.com` from upstream DNS) instead of the IP inside the hosts file. **To Reproduce** Here is a small snippet: ```rust use std::str::FromStr; use std::sync::Arc; use std::time::Duration; use hickory_proto::op::Query; use hickory_proto::rr::LowerName; use hickory_resolver::config::{NameServerConfigGroup, ResolverOpts}; use hickory_resolver::{Hosts, Name}; use hickory_server::authority::{AuthorityObject, Catalog, ZoneType}; use hickory_server::store::forwarder::{ForwardAuthority, ForwardConfig}; use hickory_server::ServerFuture; use tokio::net::{TcpListener, UdpSocket}; #[tokio::main] async fn main() { let hosts = Hosts::new(); println!("{:?}", hosts.lookup_static_host(&Query::query(Name::from_utf8("example.com").unwrap(), hickory_proto::rr::RecordType::A))); let mut catalog = Catalog::new(); let forward_config = ForwardConfig { name_servers: NameServerConfigGroup::quad9_tls(), options: Some(ResolverOpts::default()) }; let authority = ForwardAuthority::try_from_config( Name::from_str(".").unwrap(), ZoneType::Forward, &forward_config).unwrap(); catalog.upsert(LowerName::from_str(".").unwrap(), Box::new(Arc::new(authority)) as Box<dyn AuthorityObject>); let mut server_future = ServerFuture::new(catalog); let udp_socket = UdpSocket::bind("127.0.0.1:8000").await.unwrap(); server_future.register_socket(udp_socket); let tcp_socket = TcpListener::bind("127.0.0.1:8000").await.unwrap(); server_future.register_listener(tcp_socket, Duration::from_secs(3)); server_future.block_until_done().await.unwrap(); } ``` **Expected behavior** As expected, the snippet above prints `Some(...)` with the correct RData `Some(A(A(201.11.11.11)))`. But unexpectedly, `dig @127.0.0.1 -p 8000 example.com` still returned `93.184.216.34`. It should be `201.11.11.11`. **System:** - OS: Linux - Architecture: x86_64 - Version: Arch Linux - rustc version: 1.75.0 **Version:** Crate: `hickory-resolver` / `hickory-server` Version: 0.24.0

kerem closed this issue

2026-03-16 00:48:03 +03:00

kerem commented

2026-03-16 00:48:10 +03:00

Author

Owner

@hch12907 commented on GitHub (Feb 18, 2024):

This is because AsyncResolver::inner_lookup doesn't take hosts into account. Only AsyncResolver::lookup_ip does.

@hch12907 commented on GitHub (Feb 18, 2024): This is because `AsyncResolver::inner_lookup` doesn't take `hosts` into account. Only `AsyncResolver::lookup_ip` does.

kerem commented

2026-03-16 00:48:15 +03:00

Author

Owner

@djc commented on GitHub (Feb 29, 2024):

How/why do you end up calling inner_lookup(), if not via lookup_ip()?

@djc commented on GitHub (Feb 29, 2024): How/why do you end up calling `inner_lookup()`, if not via `lookup_ip()`?

kerem commented

2026-03-16 00:48:20 +03:00

Author

Owner

@hch12907 commented on GitHub (Mar 1, 2024):

(Going by memory since I am not with my laptop currently) ForwardAuthority calls AsyncResolver::lookup(), which in turn calls inner_lookup().

@hch12907 commented on GitHub (Mar 1, 2024): (Going by memory since I am not with my laptop currently) `ForwardAuthority` calls `AsyncResolver::lookup()`, which in turn calls `inner_lookup()`.

kerem referenced this issue

2026-03-16 02:24:56 +03:00

[PR #899] [MERGED] Allow for custom rustls::ClientConfig to be passed to the Resolver #1780