systemd-resolved: introduction to split DNS

Fedora 33 switches the default DNS resolver to systemd-resolved. In simple terms this means that systemd-resolved will run as a daemon. All programs wanting to translate domain names to network addresses will talk to it. This replaces the current default lookup mechanism where each program individually talks to remote servers and there is no shared cache.

If necessary systemd-resolved will contact remote DNS servers. systemd-resolved is a 8220stub resolver8221it doesn8217t resolve all names itself by starting at the root of the DNS hierarchy and going down label by label but forwards the queries to a remote server. .

A single daemon handling name lookups provides significant benefits. The daemon caches answers which speeds answers for frequently used names. The daemon remembers which servers are non-responsive while previously each program would have to figure this out on its own after a timeout. Individual programs only talk to the daemon over a local transport and are more isolated from the network. The daemon supports fancy rules which specify which name servers should be used for which domain namesin fact the rest of this article is about those rules.

...

Read Full Post

News Link: https://fedoramagazine.org/systemd-resolved-introduction-to-split-dns/.
RSS Link: https://fedoramagazine.org/feed/.

Linux Chatter is a news aggregator service that curates some of the best Linux, Cloud, Technical Guides, Hardware and Security news. We display just enough content from the original post to spark your interest. If you like the topic, then click on the 'read full post' button to visit the author's website. Use Linux Chatter to find content from amazing authors!

Note: The content provided has been modified and is not displayed as intended by the author. Any trademarks, copyrights and rights remain with the source.

Disclaimer: Linux Chatter sources content from RSS feeds and personal content submissions. The views and opinions expressed in these articles are those of the authors and do not necessarily reflect those of Linux Chatter.