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 #1099] Use res_init to obtain unix DNS configurations? #605

New issue

Closed

opened 2026-03-15 23:25:26 +03:00 by kerem · 8 comments

kerem commented

2026-03-15 23:25:26 +03:00

Owner

Originally created by @Mygod on GitHub (May 10, 2020).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1099

/etc/resolver.conf might not be the best way to do this, e.g. Android does not have this file. Perhaps we could try to use res_init or res_ninit as per this answer?

Originally created by @Mygod on GitHub (May 10, 2020). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1099 `/etc/resolver.conf` might not be the best way to do this, e.g. Android does not have this file. Perhaps we could try to use `res_init` or `res_ninit` as per [this answer](https://stackoverflow.com/a/4251093/2245107)?

kerem

2026-03-15 23:25:26 +03:00

closed this issue
added the
enhance

crate:resolver
labels

kerem commented

2026-03-15 23:25:42 +03:00

Author

Owner

@bluejekyll commented on GitHub (May 10, 2020):

Seems reasonable. I'm not sure if we want this across the board, but clearly for Android this would be a good change.

Trust-DNS used to have internal parsing logic for resolv.conf, but that was all migrated to the resolv-conf crate. My suggestion is that we either put an FFI into that crate, or create a new separate crate that returns the same structures as the resolv-conf crate.

I'd be happy for us to integrate this for Android initially, and then see about using it at some point in the future across more OSes.

@bluejekyll commented on GitHub (May 10, 2020): Seems reasonable. I'm not sure if we want this across the board, but clearly for Android this would be a good change. Trust-DNS used to have internal parsing logic for resolv.conf, but that was all migrated to the `resolv-conf` crate. My suggestion is that we either put an FFI into that crate, or create a new separate crate that returns the same structures as the `resolv-conf` crate. I'd be happy for us to integrate this for Android initially, and then see about using it at some point in the future across more OSes.

kerem commented

2026-03-15 23:25:47 +03:00

Author

Owner

@Mygod commented on GitHub (May 10, 2020):

Another thing to take into consideration is that DNS nameservers are subject to change, especially on a mobile device (disconnecting from a Wi-Fi might cause the device to use another nameserver). Android has a native async resolve API, but that was only added in Android 10. This res_init approach might be preferable for legacy versions.

@Mygod commented on GitHub (May 10, 2020): Another thing to take into consideration is that DNS nameservers are subject to change, _especially_ on a mobile device (disconnecting from a Wi-Fi might cause the device to use another nameserver). Android has a [native async resolve API](https://developer.android.com/ndk/reference/group/networking#group___networking_1ga4faf1bb0d7fd38c2153eebefcfb8f056), but that was only added in Android 10. This `res_init` approach might be preferable for legacy versions.

kerem commented

2026-03-15 23:25:52 +03:00

Author

Owner

@bluejekyll commented on GitHub (May 10, 2020):

Yes, we don't currently have a strong design around the dynamic nature of DNS configuration on mobile (or less frequently laptops). It is something that we should support, at the moment, it would require a new resolver to be constructed on configuration changes.

I'm assuming res_init will change upon any change to DNS configuration at the OS level.

@bluejekyll commented on GitHub (May 10, 2020): Yes, we don't currently have a strong design around the dynamic nature of DNS configuration on mobile (or less frequently laptops). It is something that we should support, at the moment, it would require a new resolver to be constructed on configuration changes. I'm assuming `res_init` will change upon any change to DNS configuration at the OS level.

kerem commented

2026-03-15 23:25:57 +03:00

Author

Owner

@Mygod commented on GitHub (May 10, 2020):

Well I have bad news for you...

@Mygod commented on GitHub (May 10, 2020): Well I have [bad news](https://thesquareplanet.com/blog/the-story-of-a-rust-bug/) for you...

kerem commented

2026-03-15 23:26:02 +03:00

Author

Owner

@bluejekyll commented on GitHub (May 10, 2020):

What's the bad news? that's all stdlib related, isn't it? res_init has FFI in libc, should be exposed on Android, isn't that the start to what we want?

@bluejekyll commented on GitHub (May 10, 2020): What's the bad news? that's all stdlib related, isn't it? res_init has FFI in libc, should be exposed on Android, isn't that the start to what we want?

kerem commented

2026-03-15 23:26:07 +03:00

Author

Owner

@Mygod commented on GitHub (May 10, 2020):

Oh the point is that res_init seems to cache system resolver configuration at the time of invocation instead.

@Mygod commented on GitHub (May 10, 2020): Oh the point is that `res_init` seems to cache system resolver configuration at the time of invocation instead.

kerem commented

2026-03-15 23:26:12 +03:00

Author

Owner

@bluejekyll commented on GitHub (May 11, 2020):

Ah. I see.

@bluejekyll commented on GitHub (May 11, 2020): Ah. I see.

kerem commented

2026-03-15 23:26:17 +03:00

Author

Owner

@Mygod commented on GitHub (May 20, 2020):

Looks like res_ninit is buggy as well. We should stick to current implementation perhaps.

@Mygod commented on GitHub (May 20, 2020): Looks like [`res_ninit` is buggy as well](https://stackoverflow.com/q/49579030/2245107). We should stick to current implementation perhaps.