Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Forwarder seems to not use /etc/hosts despite use_hosts_file == true #2148

Open
hch12907 opened this issue Feb 18, 2024 · 3 comments · May be fixed by #2149
Open

Forwarder seems to not use /etc/hosts despite use_hosts_file == true #2148

hch12907 opened this issue Feb 18, 2024 · 3 comments · May be fixed by #2149

Comments

@hch12907
Copy link
Contributor

hch12907 commented Feb 18, 2024

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

@hch12907
Copy link
Contributor Author

hch12907 commented Feb 18, 2024

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

@hch12907 hch12907 linked a pull request Feb 19, 2024 that will close this issue
@djc
Copy link
Collaborator

djc commented Feb 29, 2024

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

@hch12907
Copy link
Contributor Author

hch12907 commented Mar 1, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants