Clarify latest DN42 article

1 files changed, 28 insertions, 14 deletions

diff --git a/_posts/2025-06-16-oops-dn42-stops-working.md b/_posts/2025-06-16-oops-dn42-stops-working.md
index 52736d6..26d4ed7 100644
--- a/_posts/2025-06-16-oops-dn42-stops-working.md
+++ b/_posts/2025-06-16-oops-dn42-stops-working.md
@@ -2,18 +2,20 @@
 layout: post
 title: Oops, DN42 stopped working
 date: 2025-06-16 20:39 +0200
+last_modified_at: 2025-06-17 18:12 +0200
 lang: en
 categories: tech
 ---
 
-As you might know, I participate in DN42.  I have a somewhat peculiar setup, in
+As you might know, I participate in [DN42]({% link dn42.md %}).
+I have a somewhat peculiar setup, in
 which some VPS run the routing daemons, and my home router simply has a VPN
 connection to them and statically routes everything `fd00::/8` to them. The router
-runs OpenWRT, and has dnsmasq setup to resolve dn42 domains via the DN42 anycast
+runs OpenWRT, and has dnsmasq setup to resolve DN42 domains via the DN42 anycast
 servers. I set this up *months ago*, it worked, I was happy, and didn't need it
 since.
 
-Cue last weekend. Suddenly the resolution didn't work anymore. It simply timed
+Cue last weekend. "Suddenly" the resolution didn't work anymore. It simply timed
 out. So I connected to my VPS (which is running DN42
 [in a namespace]({%post_url 2025-02-02-dn42-put-it-in-a-box-linux-network-namespace %}))
 and took a look at tcpdump. Inside the namespace, I saw the strange lines
@@ -29,28 +31,40 @@ And all the time I was thinking… "huh??? Why is `fd3e:bc05:2d6::80` unreachabl
 It is **clearly** in the `ip -6 a` output!!!".  I looked through all the
 iptables statistics and couldn't find the culprit.
 
-A join in the dn42 IRC and some back and forth later, someone suggested
-"Hey, what's with the fd7a… address? Is there a route for *that*?".
+A join in the DN42 IRC and some back and forth later, someone suggested
+"Hey, what's with the `fd7a:…` address? Is there a route for *that*?".
 
 And of course, no, it wasn't! I was so focused on the ICMP6 message that I
 didn't notice the incoming line.  As you can read in my other article linked
 above, I perform NAT. Of course in that case it probably wouldn't make sense for the
 ICMP6 message to tell someone that there's no route for the original IP (before NAT).
 
-So, but… where does the fd7a address come from? The answer is "Tailscale".
-Unfortunately, it decided to use the fd00::/8 IP range, which collides with DN42.
-But… why is that address used at all for the DNS request?
+**So, but… where does the `fd7a:…` address come from?**<br/>
+The answer is [Tailscale]({% post_url 2024-12-08-trying-out-tailscale %}).
+Unfortunately, they decided to use the `fd00::/8` IP range, which collides with DN42.
+I didn't do any DN42 stuff since installing it, so I didn't notice that.<br/>
+**But… why is that address used at all for the DNS request?**<br/>
 Weeeeell… I found out as well. It comes from OpenWRT. I simply set up
 a static route there, and Linux does its best to determine the source address for the
-DNS request. And it seems the Tailscale one was a closer match than my own DN42
-prefix. So, how to fix that?  [It's not as easy as you
-think!](https://github.com/openwrt/openwrt/issues/13720). Merely using the
-"source" option in the config file would work for IPv4, but for IPv6 it has a
-different meaning!
+DNS request. And it seems the Tailscale one was a closer match than 
+the address from my own DN42 prefix.<br/>
+**So, how to fix that?**<br/>
+[It's not as easy as you think!](https://github.com/openwrt/openwrt/issues/13720).
+Merely using the "source" option in the config file would work for IPv4, but
+for IPv6 it has a different meaning!<br/>
+**But why does it say "no route to host" instead of using a default route?**<br/>
+Because I configured bird to insert an "unreachable" route for the `fd::/8` prefix
+to avoid leaking traffic.
+```
+# ip -6 route show fd00::/8 table dn42
+unreachable fd00::/8 dev lo proto bird src fd3e:bc05:2d6::1 metric 500 pref medium
+```
 
 At this point, it's Monday evening. Unnerved, I threw my hands in the air and
 simply put a line of
-`ip -6 route replace fd00::/8 ... src <my-openwrt-dn42-address>`
+```
+ip -6 route replace fd00::/8 ... src <my-openwrt-dn42-address>
+```
 in `/etc/rc.local` and called it a day.  My setup
 works again, and I learned something again. Don't just look at the last line,
 look at the whole picture.  A lesson I actually already learned in the