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

Revisit MDNS_MINIMAL reverse lookup #46

Closed
agoode opened this issue Feb 13, 2018 · 6 comments
Closed

Revisit MDNS_MINIMAL reverse lookup #46

agoode opened this issue Feb 13, 2018 · 6 comments

Comments

@agoode
Copy link
Collaborator

agoode commented Feb 13, 2018

It is not clear why only minimal mode has this:
/* Only query for 169.254.0.0/16 IPv4 in minimal mode */

Is it something we can remove? I don't know what harm there is in handling more reverse queries. Probably a latency issue?

@smcv
Copy link

smcv commented Apr 17, 2018

The harm is that many apps and services do reverse lookups (gethostbyaddr) on arbitrary IP addresses (perhaps local, perhaps not, and there's no particularly good way to tell). If there is no reverse DNS for a particular IP address, and there is nobody on the local LAN advertising a PTR record for that IP address, then nss-mdns will block for several seconds before it gives up and returns control to the application.

For forward resolution (gethostbyname) there's an obvious default - if the name is in .local. then resolve it, else don't - and a way to configure other domain names to resolve via Avahi. For reverse resolution there currently isn't.

Reverse resolution seems less critical than forward (you need forward resolution to connect to services, but you only need reverse resolution for logging or debugging), so if an app does it anyway, distributions don't want a default that will add significant time delays for little benefit. When users find that installing nss-mdns makes their app slow, they will normally blame nss-mdns, not their app.

@smcv
Copy link

smcv commented Apr 17, 2018

More concretely, one of the goals of limiting reverse resolution to link-local IPv4 is: suppose I run mtr or a similar traceroute tool, and one of the hops between one ISP and the next doesn't have reverse-DNS (because it's some internal router). mtr shouldn't block for several seconds asking my local LAN "hey, does anyone know who 108.170.238.116 is?" before it continues.

Similarly, if something like SpamAssassin is using reverse DNS to check whose an IP address is, there's little point in asking my local LAN if they know; they probably don't, and it will just delay processing.

@lathiat
Copy link

lathiat commented Apr 17, 2018

I agree with the above. One possible option would be to do a cache only or all_for_now style response. And never wait. And only for IP addresses in a subnet on a local interface (otherwise we open up some security issues too - it also would potentially leak info about what DNS names / IPS people are looking up)

@smcv
Copy link

smcv commented Apr 17, 2018

That's a good point about information leaks... although if you're on a subnet with someone, you can probably already see their DNS lookups unless they have taken steps to use Tor or similar (DNSSEC doesn't protect confidentiality, only integrity), so you can already know what IP addresses they're looking up. Switched networks mitigate that but don't prevent it, since switches often fail open when flooded.

While looking at updating Debian's nss-mdns package (from Lennart's 0.10 to this fork) I wondered whether the reverse change would be useful: make mdns{,4,6} continue to do forward lookup (gethostbyname) for whatever is listed in mdns.allow (or .local., subject to SOA checks, if empty), but make it only do reverse lookup (gethostbyaddr) for link-local addresses like mdns{,4,6}_minimal does. That would make mdns{,4} something that distributions can seriously consider enabling by default, rather than always using mdns{,4}_minimal.

@smcv
Copy link

smcv commented Apr 23, 2018

FYI, in Debian, I dropped mdns4 from our default setup (leaving only mdns4_minimal) in response to this bug report from the (then-)upstream developer: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433943

Please drop the final "mdns4" from the default nsswitch.conf line. While
it is quite useful to enable proper reverse lookups on non-link-local
addresses it also has the big drawback that if there is neither avahi
nor classic dns set up for an IP address this module has to timeout
before the reverse lookup can fail. This becomes a problem because many
programs freeze during these lookups, one being ssh on every single
incoming connection.

Since Avahi is intended to be a "zero configuration" system, one that
"just works", this means that it is preferable to guarantee that we don't
break on any system, even when this means that a certain amount of
functionality is lost.

Unfortunately I don't know any better solution for this mess than just
dropping "mdns4" from the line.

In effect the line to use should look like this:

hosts:          files mdns4_minimal [NOTFOUND=return] dns

I already made a similar change in the Fedora packages.

Lennart

@agoode
Copy link
Collaborator Author

agoode commented Sep 4, 2018

I think #65 would address this issue.

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

No branches or pull requests

3 participants