starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-24 18:55:55 +03:00

[GH-ISSUE #307] Is there some simple "DNS proxy" example somewhere? #435

New issue

Open

opened 2026-03-15 22:27:54 +03:00 by kerem · 12 comments

kerem commented

2026-03-15 22:27:54 +03:00

Owner

Originally created by @vi on GitHub (Dec 1, 2017).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/307

I expect it to be simple, stateless, without database, DNSSEC (except for some passthough maybe), SSL and so on. Something like /usr/sbin/dnsproxy.

Is there anything like that?

Originally created by @vi on GitHub (Dec 1, 2017). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/307 I expect it to be simple, stateless, without database, DNSSEC (except for some passthough maybe), SSL and so on. Something like `/usr/sbin/dnsproxy`. Is there anything like that?

kerem added the

enhance

docs

labels

2026-03-15 22:27:54 +03:00

kerem commented

2026-03-15 22:28:05 +03:00

Author

Owner

@bluejekyll commented on GitHub (Dec 1, 2017):

At the moment I am not aware of anyone working on a DNS proxy as it relates to this project. I'm not sure if there is one in Rust based on another project, so you could investigate that.

To implement that on this library, I would expect some combination of bits of the server + the client would be used. I think all the core pieces are there, but I haven't ever looked at dnsproxy so I'm not fully aware of the feature set required for that.

@bluejekyll commented on GitHub (Dec 1, 2017): At the moment I am not aware of anyone working on a DNS proxy as it relates to this project. I'm not sure if there is one in Rust based on another project, so you could investigate that. To implement that on this library, I would expect some combination of bits of the server + the client would be used. I think all the core pieces are there, but I haven't ever looked at `dnsproxy` so I'm not fully aware of the feature set required for that.

kerem commented

2026-03-15 22:28:10 +03:00

Author

Owner

@vlad20012 commented on GitHub (Jul 22, 2020):

Hello!
Any news on this? Maybe someone started a project.

@vlad20012 commented on GitHub (Jul 22, 2020): Hello! Any news on this? Maybe someone started a project.

kerem commented

2026-03-15 22:28:15 +03:00

Author

Owner

@vi commented on GitHub (Jul 22, 2020):

I'm using my own specialised DNS proxy with cache. But that's not a proxy you would like to see probably.

@vi commented on GitHub (Jul 22, 2020): I'm using [my own specialised DNS proxy with cache](https://github.com/vi/dnscache). But that's not a proxy you would like to see probably.

kerem commented

2026-03-15 22:28:20 +03:00

Author

Owner

@nmittler commented on GitHub (Jun 13, 2023):

Hey guys,
I just ran across this (I was about to open a new feature request for a DNS proxy). The Istio project has been proxying DNS for a while. Their new proxy (ztunnel) is written in Rust and I've just started work for its DNS proxy, based on Trust-DNS: https://github.com/istio/ztunnel/pull/536.

I'm probably going to land that PR as-is, but perhaps we can use this as fuel to move forward on an official Trust-DNS proxy?

Thoughts?

@nmittler commented on GitHub (Jun 13, 2023): Hey guys, I just ran across this (I was about to open a new feature request for a DNS proxy). The Istio project has been proxying DNS for a while. Their new proxy (ztunnel) is written in Rust and I've just started work for its DNS proxy, based on Trust-DNS: https://github.com/istio/ztunnel/pull/536. I'm probably going to land that PR as-is, but perhaps we can use this as fuel to move forward on an official Trust-DNS proxy? Thoughts?

kerem commented

2026-03-15 22:28:25 +03:00

Author

Owner

@nmittler commented on GitHub (Jun 13, 2023):

@bluejekyll this issue is pretty old and appears to just ask a question even though it's marked as an enhancement. Should we perhaps rename the issue to make it more clear, or close this and create a feature request?

@nmittler commented on GitHub (Jun 13, 2023): @bluejekyll this issue is pretty old and appears to just ask a question even though it's marked as an enhancement. Should we perhaps rename the issue to make it more clear, or close this and create a feature request?

kerem commented

2026-03-15 22:28:30 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jun 13, 2023):

Excuse my ignorance here, but could you explain how a proxy is different from a forwarder (in BIND terms)? We have forwarding built into the server library? We could expose that as a simpler binary if that’s all it takes.

@bluejekyll commented on GitHub (Jun 13, 2023): Excuse my ignorance here, but could you explain how a proxy is different from a forwarder (in BIND terms)? We have forwarding built into the server library? We could expose that as a simpler binary if that’s all it takes.

kerem commented

2026-03-15 22:28:35 +03:00

Author

Owner

@nmittler commented on GitHub (Jun 13, 2023):

Of course...

Some quick background: a ztunnel proxy runs on the same node as the client and acts on behalf of the client to enforce service mesh policy by intercepting all traffic to and from the client. The new work I'm doing will also have it intercept all DNS traffic (to port 53).

Ztunnel is updated by the Istio control plane to know all of the service VIPs and workload IPs in the entire service mesh. So if the client looks up a host to a known endpoint (e.g. my-service.my-namespace.svc.cluster.local), ztunnel will serve out of its local database and will indicate the response as authoritative. Everything else will be forwarded.

I believe that the main difference between this and the servers that exist in Trust-DNS today is the ability for it to optionally mark the response as authoritative. My Istio PR is pretty simple if you want to poke around. It creates a new RequestHandler that I call the Proxy. It uses a new trait Resolver, which will return whether or not the response is authoritative. This seemed to be the part that was missing from the current Authority API for this case.

Does this seem like valid use case for proxy in Trust-DNS?

@nmittler commented on GitHub (Jun 13, 2023): Of course... Some quick background: a ztunnel proxy runs on the same node as the client and acts on behalf of the client to enforce service mesh policy by intercepting all traffic to and from the client. The new work I'm doing will also have it intercept all DNS traffic (to port 53). Ztunnel is updated by the Istio control plane to know all of the service VIPs and workload IPs in the entire service mesh. So if the client looks up a host to a known endpoint (e.g. `my-service.my-namespace.svc.cluster.local`), ztunnel will serve out of its local database and will indicate the response as authoritative. Everything else will be forwarded. I believe that the main difference between this and the servers that exist in Trust-DNS today is the ability for it to optionally mark the response as authoritative. My [Istio PR](https://github.com/istio/ztunnel/pull/536) is pretty simple if you want to poke around. It creates a new `RequestHandler` that I call the `Proxy`. It uses a new trait `Resolver`, which will return whether or not the response is authoritative. This seemed to be the part that was missing from the current Authority API for this case. Does this seem like valid use case for proxy in Trust-DNS?

kerem commented

2026-03-15 22:28:41 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jun 13, 2023):

It sounds like there’s a distribution protocol that’s non-standard (not DNS based) for the, let’s call it, a hosts file with lookups defined there. Would we need to support that distribution protocol? Or is that just a file? Like, could we support a common interface that isn’t just for k8s? If so that’s more appealing. If not, I’m still ok with us building this into the project, but probably feature flag it off. What do you think?

@bluejekyll commented on GitHub (Jun 13, 2023): It sounds like there’s a distribution protocol that’s non-standard (not DNS based) for the, let’s call it, a hosts file with lookups defined there. Would we need to support that distribution protocol? Or is that just a file? Like, could we support a common interface that isn’t just for k8s? If so that’s more appealing. If not, I’m still ok with us building this into the project, but probably feature flag it off. What do you think?

kerem commented

2026-03-15 22:28:46 +03:00

Author

Owner

@nmittler commented on GitHub (Jun 13, 2023):

Oh, I wouldn't expect Trust-DNS to implement the protocol ... that's implementation-specific. I'd just rather not have to write a new RequestHandler for this. Ideally, Catalog would be the only RequestHandler. We would just implement an Authority that looks up the host locally and if found, returns an authoritative response. If not found, it would just forward on to the next authority. This isn't possible in the current API, since whether a response is authoritative is based on the type of Authority, rather than dynamic.

@nmittler commented on GitHub (Jun 13, 2023): Oh, I wouldn't expect Trust-DNS to implement the protocol ... that's implementation-specific. I'd just rather not have to write a new `RequestHandler` for this. Ideally, `Catalog` would be the only `RequestHandler`. We would just implement an `Authority` that looks up the host locally and if found, returns an authoritative response. If not found, it would just forward on to the next authority. This isn't possible in the current API, since whether a response is authoritative is based on the type of Authority, rather than dynamic.

kerem commented

2026-03-15 22:28:51 +03:00

Author

Owner

@nmittler commented on GitHub (Jun 14, 2023):

@bluejekyll I think basically what this would come down to is to expand the server's LookupObject to include more details about the response (e.g. authoritative).

Looking around the codebase, there are several APIs that are very similiar and might be candidates for consolidation. Server has LookupObject which is similar to the resolver's Lookup, which is similar to the client/proto DnsResponse. IIUC, DnsResponse is the one object that actually contains everything ... perhaps that could somehow be made to replace the others?

@nmittler commented on GitHub (Jun 14, 2023): @bluejekyll I think basically what this would come down to is to expand the server's `LookupObject` to include more details about the response (e.g. authoritative). Looking around the codebase, there are several APIs that are very similiar and might be candidates for consolidation. Server has `LookupObject` which is similar to the resolver's `Lookup`, which is similar to the client/proto `DnsResponse`. IIUC, `DnsResponse` is the one object that actually contains everything ... perhaps that could somehow be made to replace the others?

kerem commented

2026-03-15 22:28:56 +03:00

Author

Owner

@nmittler commented on GitHub (Jul 1, 2023):

FYI I've moved the discussion of my proxy requirements to https://github.com/bluejekyll/trust-dns/issues/1983

@nmittler commented on GitHub (Jul 1, 2023): FYI I've moved the discussion of my proxy requirements to https://github.com/bluejekyll/trust-dns/issues/1983

kerem commented

2026-03-15 22:29:01 +03:00

Author

Owner

@mokeyish commented on GitHub (Jul 1, 2023):

@nmittler
How about smartdns-rs? 😁

just run smartdns run -c smartdns.conf

# Listen on local port 53
bind 127.0.0.1:53  

# Configure bootstrap-dns, if not configured, call the system_conf, 
# it is recommended to configure, so that it will be encrypted.
server https://1.1.1.1/dns-query  -bootstrap-dns -exclude-default-group
server https://8.8.8.8/dns-query  -bootstrap-dns -exclude-default-group

# Configure default upstream server
server https://cloudflare-dns/dns-query
server https://dns.quad9.net/dns-query
server https://dns.google/dns-query

# Configure the Office(Home) upstream server
server 192.168.1.1 -exclude-default-group -group office

# Domain names ending with ofc are forwarded to the office group for resolution
nameserver /ofc/office

# Set static IP for domain name
address /test.example.com/1.2.3.5

# Block Domains (Ad Blocking)
address /ads.example.com/#

@mokeyish commented on GitHub (Jul 1, 2023): @nmittler How about [smartdns-rs](https://github.com/mokeyish/smartdns-rs)? 😁 just run `smartdns run -c smartdns.conf` ```ini # Listen on local port 53 bind 127.0.0.1:53 # Configure bootstrap-dns, if not configured, call the system_conf, # it is recommended to configure, so that it will be encrypted. server https://1.1.1.1/dns-query -bootstrap-dns -exclude-default-group server https://8.8.8.8/dns-query -bootstrap-dns -exclude-default-group # Configure default upstream server server https://cloudflare-dns/dns-query server https://dns.quad9.net/dns-query server https://dns.google/dns-query # Configure the Office(Home) upstream server server 192.168.1.1 -exclude-default-group -group office # Domain names ending with ofc are forwarded to the office group for resolution nameserver /ofc/office # Set static IP for domain name address /test.example.com/1.2.3.5 # Block Domains (Ad Blocking) address /ads.example.com/# ```

kerem referenced this issue

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

[PR #435] [MERGED] tokio_reactor::Handle cleanup and support std::net structs again in server_future #1432