Working with DNS settings in systemd-resolved in Ubuntu

In troubleshooting some DNS name resolution issues I started to get more familiar with systemd-resolved in Ubuntu. Specifically if you look at the traditional /etc/resolv.conf file it says something like this:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)

#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

# 127.0.0.53 is the systemd-resolved stub resolver.

# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 127.0.0.53

Hah hah! Subtly clever for any old hands in networking because "53" is the standard DNS port so 127.0.0.53 is a little clue to look for something specific.

Go ahead though - run "systemd-resolve --status", it doesn't require root, and it shows you a lot of info (the IPs of name servers have been change to protect the innocent...)

localadmin@ca-yvr-adm2:~$ systemd-resolve --status

Global

         DNS Servers: 10.1.1.11

                      10.2.2.12

          DNS Domain: sub.example.com

          DNSSEC NTA: 10.in-addr.arpa

                      16.172.in-addr.arpa

                      168.192.in-addr.arpa

                      <snip>

                      local

Link 1 (eno1)

      Current Scopes: none

       LLMNR setting: yes

MulticastDNS setting: no

      DNSSEC setting: no

    DNSSEC supported: no

The config file is easily found in "/etc/systemd/resolved.conf" and it's quite short and simple and it should look familiar if you have used other systemd configurations before. The configuration out-of-the-box will be blank with all options commented out. I wanted to add additional search domains to the Domains line, in the same space-delimited way you would traditionally do the search line in your resolve.conf.

[Resolve]

#DNS=

#FallbackDNS=

Domains=sub.example.com example.com example.local

#LLMNR=no

#MulticastDNS=no

#DNSSEC=no

#Cache=yes

#DNSStubListener=yes

Restart the same as you would any other systemd tool, and then re-check your resolved status

sudo systemctl restart systemd-resolved.service 

systemd-resolve --status

OR check your /etc/resolve.conf file because if your only change is to modify the search domains, it also appears there for the resolver to work normally.

Global

         DNS Servers: 10.1.1.11

                      10.2.2.12

          DNS Domain: sub.example.com example.com example.local

          DNSSEC NTA: 10.in-addr.arpa

                      16.172.in-addr.arpa

                      168.192.in-addr.arpa

                      <snip>

                      local

Normally you would be done... Here's a couple bonus tricks that may arise.

You can modify DNS settings by interface - furthermore this is handy for testing DNS changes and reverting before making the change in the config file. Check out systemd-resolve --help 

The multicast service may conflict with a .local domain. The symptom I had was that I could resolve a short name like "pc" but could not resolve an FQDN like "pc.example.local". If you are using .local and finding odd DNS resolution results, edit your nsswitch.conf  and move "dns" earlier than the mdns (keep it after "files" though to avoid breaking your hosts file).

I've tried to make this a quick and useful blurb on how to use systemd-resolved and get pointed in the right direction because the documentation available wasn't simple for simple cases - there is certainly a lot of tuning you can do with the resolver tools.

Ciao

Archiving Files (E.g. Deleting Stuff) is My Super Power!

This week one of the things I was working on was archiving a lot of files on a file in order to prune it down ahead of migrating that share to a new location.

In particular this share while only ~100GB has > 3M files on it! Any basic operations like checking folder sizes, applying ACLs, etc are very slow on xM files. Looking at the share with WinDirStat I found that there's a large number of folders each with 20-50K files in each. Furthermore the majority of these files were old (years) and not actively used so we decided to Archive (e.g. Delete) the contents of these folders.

I started by using 7-Zip and there's an option on the Add to Archive screen to "Delete files after compression":

And that's pretty good! ... But not if you've got hundreds of folders to process.

Instead, with a bit of PowerShell, we invoke 7-Zip from a script and use the -sdel switch to remove files after they've been archived. This PS we used to simply to stuff each sub-folder into an archive.

Get-ChildItem . -Directory |  ForEach-Object  {

 $Archive = $_.Name + ".zip"

 $Folder = $_.Name + "\"

 &"C:\Program Files\7-Zip\7z.exe" a $Archive $Folder -sdel

}

Pow!