[HN Gopher] Anatomy of a Linux DNS Lookup
___________________________________________________________________
Anatomy of a Linux DNS Lookup
Author : belter
Score : 98 points
Date : 2021-06-04 17:28 UTC (5 hours ago)
(HTM) web link (zwischenzugs.com)
(TXT) w3m dump (zwischenzugs.com)
| gtsop wrote:
| I actually went on to read this whole series a few months ago in
| search of what was wrong with some networking configuration I had
| at home. To no fault of the author, I felt like I trully learned
| a ton about DNS but couldn't apply that knowledge to solve my
| problem since ubuntu has added more stuff on top of these.
|
| I feel like the DNS situation is way too complicated, I really
| don't even know where the tunnel ends anymore. I resulted to
| using the GUI and hope it handles everything, which I hate
| because I want to understand what's happening under the hood. I
| felt powerless
| Pirate-of-SV wrote:
| In Kubernetes you can also add NodeLocal DNSCache [1] as a
| DaemonSet that injects iptable rules to cache DNS locally to
| offload the in-cluster coredns.
|
| [1] https://kubernetes.io/docs/tasks/administer-
| cluster/nodeloca...
| belter wrote:
| Follow up:
|
| Anatomy of a Linux DNS Lookup - Part II
| https://zwischenzugs.com/2018/06/18/anatomy-of-a-linux-dns-l...
|
| Anatomy of a Linux DNS Lookup - Part III
| https://zwischenzugs.com/2018/07/06/anatomy-of-a-linux-dns-l...
|
| Anatomy of a Linux DNS Lookup - Part IV
| https://zwischenzugs.com/2018/08/06/anatomy-of-a-linux-dns-l...
|
| Anatomy of a Linux DNS Lookup - Part V - Two Debug Nightmares
| https://zwischenzugs.com/2018/09/13/anatomy-of-a-linux-dns-l...
| necovek wrote:
| This does not cover the joy of eg. connecting to multiple
| networks (different DNS settings) with separate interfaces.
|
| Then you can hit DNS request hopping between servers too:
| https://github.com/systemd/systemd/issues/19209
| iso1631 wrote:
| Before networkmanager and systemd, pretty much every tool
| used gethostbyname, which used standard nsswitch which tended
| to be hosts, then resolv.conf
|
| resolv.conf would use the first one, and then timeout and use
| the next one
|
| Nice and simple.
|
| The quote
|
| "simply turn off systemd-resolved"
|
| Is usually the answer, but it's a constant uphill battle to
| fix broken behaviour.
|
| Of course Pottering doesn't care.
| iso1631 wrote:
| And straight away it's a downvote.
|
| Pottering, in that thread, literally says
|
| "I have the suspicion that this going to negatively affect
| about as many people as it positively affects..."
|
| https://askubuntu.com/questions/907246/how-to-disable-
| system... is a "good" solution to the problem in ubuntu
| necovek wrote:
| To be honest, systemd-resolved actually for the first time
| provides an option of a solution for this use-case.
| Properly configured, without CNAMEs involved, it would just
| do the right thing.
|
| Relying on resolv.conf meant using the first one unless it
| times out, which makes it impossible for me to connect to
| two private networks with their own hostname resolution, if
| a hostname resolves in both but to different addresses.
| iso1631 wrote:
| But how can you do that unless you are saying "map this
| _.foo.com to resolver A, and map_.bar.com to resolver B
| ".
|
| You have an option to install dnsmasq or whatever
| resolver you want for that very unusual use case without
| installing tons of more bloated demons on machines that
| simply don't need it. 99% of linux machines are not
| laptops connecting to multiple networks with private DNS
| servers, they have static network configurations, or a
| single network connection with dhcp. Of the rest, most
| are laptops, and sure you want some form of gui selection
| to choose your wireless network, and maybe even set up
| your vpns, but that's such a rare case.
|
| Also remember that private DNS servers are on the way out
| now on a desktop, with DoH being embedded at the browser
| layer, so this tiny use case will shrink even more.
|
| by all means have a "yum install dns-multipathd" or
| whatever as a resolver to solve this problem on the 1 in
| a thousand machines it helps on, but why have any
| software installed and listening on port 53 by default?
| Seems a needless security risk to me
| mr-wendel wrote:
| Not to be overlooked on this topic is this wonderful Tailscale
| blog entry:
|
| https://tailscale.com/blog/sisyphean-dns-client-linux/
|
| and corresponding HN:
| https://news.ycombinator.com/item?id=26821298 *
| disclaimer: I have no affiliation w/ Tailscale. I just wish I
| did.
| tyingq wrote:
| This predates systemd's decision to get involved via systemd-
| resolved. So now it's got another step :)
|
| Edit: Well, and also browsers doing DNS over https. It's pretty
| confusing these days to know which path your app took to resolve
| a name.
| iso1631 wrote:
| Also predates netplan. NetworkManager (another redhat tool to
| makes things "simpler", like systemd) is mentioned in part 3.
|
| I've used Debian based distributions for 20 years with nothing
| more than ifupdown, resolvconf, and occasionally dnsmasq, but
| no distro for old men and all that.
| znpy wrote:
| I'm looking forward for "old men" to retire.
|
| Stuff like systemd (and systemd-resolved) are wonderful
| innovation and that m god they're the de-facto standard on
| most desktops.
|
| And by the way, the joy of systemd-resolved is in complex
| stuff that become surprisingly easy.
|
| Example: split-horizon DNS. You're connected to a VPN network
| but you're only routing some subnets through that, not
| everything. Thus, you have to have DNS that query some DNS
| server inside the VPN for a set of domains, but keep using
| the usual DNS servers for everything else.
|
| It's surprisingly easy with systemd-resolved, but I'm not
| aware of any feasibility without a DNS server running on the
| local machine (albeit in resolver mode). Which usually would
| be dnsmasq, but at that point you might as well run systemd-
| resolved.
| iso1631 wrote:
| > Example: split-horizon DNS. You're connected to a VPN
| network but you're only routing some subnets through that,
| not everything. Thus, you have to have DNS that query some
| DNS server inside the VPN for a set of domains, but keep
| using the usual DNS servers for everything else.
|
| Why. I want to route 10.0.0.0/8 via a VPN, I don't know if
| "flargle.bazonga.com" resolves to 10.0.0.1 or 99.99.99.99
| until I do the lookup.
| znpy wrote:
| You might know beforehand.
|
| Your employer might have the whole intranet.employer.tld
| within the VPN. And everything within that network
| resolves to some 10.8.0.0/8 address.
| mark-wagner wrote:
| If bazonga.com is domain only accessible through the VPN
| then you most likely always want to look up
| flargle.bazonga.com through the VPN name servers. On the
| internet you'll get NXDOMAIN.
|
| However, this could be solved by setting the name servers
| always to the VPN name servers and make them recursive.
| But then, what if those name servers don't have internet
| access?
| tyingq wrote:
| "no distro for old men". Hah, that's great. I had a brief
| thought of a Javier Bardem as SystemD.
| eikenberry wrote:
| I did the same for years, with the addition of wireless tools
| when I switched to using laptops. With Buster and the
| additional networking features of systemd (and iwd for wifi),
| I was able to replace the whole stack with just 2-3 things.
| Much simpler in design and easier to setup and use.
|
| I wrote a small gist on the setup a couple years ago that is
| still mostly relevant. In case you're interested... https://g
| ist.github.com/eikenb/1e9faeb8210e639e8caa69e9832db...
| iso1631 wrote:
| 99% of my machines (everything apart from one laptop) has
| no wifi. Systemd is constantly
|
| Now of course I can return to basics and learn everything
| again from scratch. The problem with that approach is
| distros like Ubuntu frequently drop in new features which
| last 5 years, and then they're gone as they're no longer
| sexy. This reduces the payoff of learning something new,
| may as well just continue to fight.
|
| I probably won't use ubuntu on servers going forward as
| they broke the installer for 20.04 (they got rid of the
| nice simple debian-installer, which just needed a new
| kernel/initrd and a preseed tweak every 2 years) and
| replaced it with some live cd monstrosity. Managed to avoid
| netplan on 18.04. It's a pain, as it means spending mental
| effort to make changes to something that just works, and
| the whole reason I use linux is because it has "just
| worked" for 2 decades.
|
| It seems all these recent changes are aimed at people who
| want their linux machine to operate just like an OSX
| laptop.
| glitchcrab wrote:
| You can use autoinstall instead of d-i - I vastly prefer
| it over the arcane d-i configurations. d-i is one of
| those things which you get working and never touch again
| in case you break it.
|
| https://ubuntu.com/server/docs/install/autoinstall
| iso1631 wrote:
| I've used d-i with ubuntu since 6.10 and it just works.
|
| Never managed to find a base pxe boot for autoinstall,
| but it's just one of the many straws
|
| As I say, just one of the many reasons I'm trying to
| leave the tech industry, just like the unix greybeards
| were annoyed by young upstart linux people in the late
| 90s, these things are cyclical.
| eikenberry wrote:
| Without wifi it isn't very compelling vs. the good old
| /etc/network/interfaces setup, it's hard to get simpler
| than that. I still use that on my servers as well.
|
| I use Debian myself and know that they don't change tech
| lightly and will keep supporting Systemd for the
| foreseeable future. So that part isn't a concern for me.
| Can't help with the Ubuntu installer, I only ever used it
| for cloud deployments with cloudinit.
|
| Systemd is a mixed bag but overall I've been happy with
| it. I have been using it since Jesse and have never had
| any issues with it and definitely prefer it over sysv-
| init (which I always hated, every other init system is an
| improvement over it IMO... so low bar I guess).
| mike_d wrote:
| Which is super annoying when you actually want to run a DNS
| server and have to try and convince systemd-resolved to stay in
| its own lane.
| westurner wrote:
| Is there a good example of a Linux package that does this
| correctly?
| tyingq wrote:
| I suspect the big part is putting "DNSStubListener=no" into
| the [Resolve] section of /etc/systemd/resolved.conf if you
| want to have something else listening on port 53.
| jakobdabo wrote:
| Or you can just mask the service (better than disabling):
| systemctl mask systemd-resolved.service
|
| Other services to consider masking if you are not using
| SystemD for network configuration and time sync., etc.:
| systemctl mask systemd-hostnamed.service
| systemctl mask systemd-timesyncd.service
| systemctl mask systemd-networkd.service systemctl
| mask systemd-homed.service
| chrisweekly wrote:
| Thanks; got a writeup abt these you might be willing to
| share?
| andred14 wrote:
| We all know now that NASA lied about going to the moon so what
| else are they lying about???
| economusty wrote:
| I recently had to circumvent the systemd resolvd auto config for
| dns it would randomly fail.
| iso1631 wrote:
| Quite normal - https://askubuntu.com/questions/907246/how-to-
| disable-system... for example
___________________________________________________________________
(page generated 2021-06-04 23:01 UTC)