Thanks to these notes on setting up the route64 tunnelbroker on mikrotik, I can confirm it works. Route64 supports wireguard for the tunnel and give out a /56 subnet, so one can have 256 /64 subnets. The cable modem needs to forward a particular UDP port to the mikrotik router on the internal network which does the wireguard magic.

(1) Create route64 tunnel, enter your public IP, select wireguard, show config:

[Interface]
PrivateKey = <private key>
Address = 2a11:6c7:f03:123::2/64

[Peer]
PublicKey = FkVCzA3bhSrqOUhXNxVHDXSLDvWHUa7BGj75uuh85TE=
AllowedIPs = ::/1, 8000::/1
Endpoint = 165.140.142.113:<port>
PersistentKeepAlive = 30

(2) Note the subnet configuration given by route64

For example: 2a11:6c7:2001:5300::/56

(3) Setup wireguard

(3.1) Add new wireguard interface

/interface wireguard add mtu=1420 name=wireguard1 private-key=<private key>

(3.2) Add new wireguard peer

/interface wireguard peers add allowed-address=::/1,8000::/1 endpoint-address=165.140.142.113 endpoint-port=<port> interface=wireguard1 persistent-keepalive=30s public-key="FkVCzA3bhSrqOUhXNxVHDXSLDvWHUa7BGj75uuh85TE="

(4) Setup IPv6

I find it more convenient to use the command-line...

(4.1) WAN side

Add route64 IPv6 address to wireguard interface and add IPv6 route.

/ipv6 address add address=2a11:6c7:f03:123::2/64 interface=wireguard1
/ipv6 route add dst-address=2000::/3 gateway=wireguard1

(4.2) LAN side

Route64 gives us a /56 subnet, which we can divide into 256 /64 subnets and give out via SLAAC / neighbor discovery (ND). Let's use the 2a11:6c7:2001:5301::/64 prefix.

/ipv6 nd set [ find default=yes ] interface=bridge mtu=1420
/ipv6 address add address=2a11:6c7:2001:5301::/64 advertise=yes interface=bridge

My IPv6 tunnel adventures are coming to an end... Still, I'd like to see Salzburg AG offer native IPv6.

posted at: 20:14 | path: /configuration | permanent link

RFC9460 is about "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)". The idea is to signal to web browsers that the connection to the server shall be encrypted (similar to HSTS), as well as HTTP protocol preferences: HTTP/3 (QUIC), HTTP/2, fallback to HTTP/1.1. The protocol handshake can thus be performed quicker. The SVCB records allow configuration for load balancing, failover, encrypted ClientHello support, etc.

The proposed DNS record looks as follows:

example.com. IN HTTPS 1 . alpn="h3,h2" ipv4hint="23.209.46.91" ipv6hint="2600:1413:b000:13::b857:c185"

ALPN indicates for protocol preference and fallback. The IP hint may speed up connection performance. In particular when a different "target" is to be used (here it's just ".").

More here.

posted at: 16:20 | path: /configuration | permanent link

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.

How does Docker configure the container's DNS?

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.

The problem

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

Oh no, Snap!

Ubuntu can package docker as a Snap, adding some more complication...

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!

Configuration changes

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