Background: DNS resolution on Linux is controlled by /etc/resolv.conf
, where up to three nameservers can be configured among other things (search list, timeout, attempts, etc.)
Nameservers are queried in order, the second nameserver is only asked if there is no response from the first. When there is an answer (even a negative one), further nameservers are not consulted. This can be changed with the rotate
option.
The man page has more info.
At least for bridged container network configuration (default), Docker mounts some host files into the container:
$ mount ... /dev/nvme0n1p3 on /etc/resolv.conf type ext4 (rw,relatime,errors=remount-ro) /dev/nvme0n1p3 on /etc/hostname type ext4 (rw,relatime,errors=remount-ro) /dev/nvme0n1p3 on /etc/hosts type ext4 (rw,relatime,errors=remount-ro)
Hence, resolv.conf
that the resolver service of the host uses is used by the container.
I.e. on a system with systemd's resolved
, the nameservers used by resolved
will
be used by the container, and NOT the local resolver 172.0.0.53. I don't know why, I think this makes no sense
and complicates configuration.
All nameservers in /etc/resolv.conf
shall return the same information. However, this is not the case if
local, private and public nameservers are used. Private domains (such as example.local
) can only be
resolved by the private nameserver. This is in principle possible to configure in resolved
, but not easily passed on to the container.
In case multiple nameservers are configured for the container and the first local, private nameserver is unreliable or too slow, the fallback nameserver will be queried. This leads to sporadic host name lookup failure for private hosts on a local domain.
nameserver 172.x.y.z # private, can resolve example.local nameserver 1.1.1.1 # public
The dockerd
config file (--config-file=/var/snap/docker/nnnn/config/daemon.json
) for Snap
luckily lives in var/snap/docker/current/config/
and is editable, hurray!
Edit /var/snap/docker/current/config/daemon.json
to override DNS configuration for all containers:
{ "dns": ["172.x.y.z"] }Restart the docker container service:
sudo snap restart docker
posted at: 19:05 | path: /configuration | permanent link
This will probably the only post I do for Windows ever, happened to do support for a PC over Christman holiday season.
Thing is, security update KB5034441 fails to install with code 0x80070643. Of course, there can be multiple reason, but this Golen article (German) was spot on: the Windows recovery partition needs to be increased.
It refers to a Microsoft support page which has instructions for the command-line how to shrink the system partition and grow the recovery partition. Very nice incarnations
A appreciate the user friendlyness of tools I've never heard of: reagentc
, diskpart
.
After that (no reboot necessary), the update completes installation within seconds, very nice!
posted at: 13:07 | path: /configuration | permanent link
For servers that do not accept mail, there's "null MX". See RFC 7505.
posted at: 22:09 | path: /configuration | permanent link
RFC 8482 deprecates DNS ANY queries. These were mostly used for debugging, i.e. retrieving all information for a domain. DNS server now just respond with HINFO "RFC8482" ""
in the CPU and OS field of the HINFO response to indicate that information has been suppressed.
See also Cloudflare blog on this topic.
And the (hard to come by) configuration for bind9 is (tada!):
minimal-any yes;Use
dig +tcp
to get a full response (see here).
posted at: 10:24 | path: /configuration | permanent link
Another nice article showing off DNSSEC strength...
Generate SSHFP DNS records for by host (pmeerw.net):
$ ssh-keygen -r @ @ IN SSHFP 1 1 3b00267ed86c211026e6d8b8eb5d9a7d9e51cf7d @ IN SSHFP 1 2 189d464e8a13d2df66d882afdcb4220fb281ba1f19eda96aa35bf1a50188b0a7 @ IN SSHFP 2 1 adb06e3c4de279d2338bbec35a9a64c8661fb431 @ IN SSHFP 2 2 50e72d460ea86ad416b74b71f9b0c948bf42004ebf730290eff9d43fea9545a6 @ IN SSHFP 3 1 aaa45514f6bd534448ab7f09842fe1e13c269142 @ IN SSHFP 3 2 cc68f391aea002966cc3d7e84ce41dc73d4cfb6c2381e5b665f26603f8317dd3 @ IN SSHFP 4 1 7482ed5e3e6621978bd0bbd61f6b9740dcef252c @ IN SSHFP 4 2 eb77b6f29bee067d6524459e4cfc696881bd70908d514be682cb068746729594
SSH can silently connect to an SSH server (without asking to verify the host fingerprint!) if VerifyHostKeyDNS
is enabled: ssh -o VerifyHostKeyDNS=yes pmeerw@pmeerw.net
.
posted at: 22:58 | path: /configuration | permanent link