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

FS#747 - default dns service doesn't provide qname minimization #5724

Closed
openwrt-bot opened this issue Apr 30, 2017 · 5 comments
Closed

FS#747 - default dns service doesn't provide qname minimization #5724

openwrt-bot opened this issue Apr 30, 2017 · 5 comments
Labels

Comments

@openwrt-bot
Copy link

dsvensson:

Supply the following if possible:

  • Device problem occurs on

All

  • Software versions of LEDE release, packages, etc.

All

  • Steps to reproduce
  • Perform a DNS resolution

qname minimization reduces the amount of information to sent via each lookup, this is to my knowledge not supported by dnsmasq which is the default DNS resolver in LEDE. It would be nice if support was added to it, or if it was replaced by some other name server that tries to reduce the amount of information leaked to foreign servers.

The spec:
https://tools.ietf.org/html/draft-ietf-dnsop-qname-minimisation-09

Unbound plugs this leak, does it lack anything that LEDE uses?

@openwrt-bot
Copy link
Author

dsvensson:

The point here is being privacy friendly by default, rather than requiring users to install unbound on their own.

@openwrt-bot
Copy link
Author

EricLuehrsen:

qname minimization is only meaningful with recursion. stub resolving just sends to a few resolvers anyway. dnsmasq is default and it is consistent in behavior to OEM as sold. This makes the transition smoother for some. Its easier on bandwidth for those with poor connections.

As a the Unbound package maintainer I am sympethetic to [your,similar] goals. This is why I have put in so much effort to add its UCI in the last months. With odhcpd you even get similar local dns behavior to dnsmasq. However this is only recent work. I still consider it a optional package. I would not expect core group acceptance of whole sale replacement for awhile.

@openwrt-bot
Copy link
Author

dsvensson:

Thanks for the update. Should this issue remain open until awhile has passed, or closed for now?

@openwrt-bot
Copy link
Author

EricLuehrsen:

The clock for "Awhile" may not be turning yet. There are technical concerns as well. Example implementation, odhcpd cannot do tftp for network boot. Example use case, recursion (Unbound) should only be at the gateway and stub resolving (dnsmasq) should occur in subnets. Example politics, consumer privacy is legally protected better some places and permitts a level of trust with ISP DNS.

@jow-
Copy link
Contributor

jow- commented Jun 8, 2023

Not applicable to dnsmasq / stub forwarder use case.

@jow- jow- closed this as completed Jun 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants