Niche detail you usually don't need. The main peering page is /.
Each POP has its own IPv6 /58 inside our /48. These are internal only: we announce just the /27 and /48 anycast aggregates, so traffic to a node-specific address enters at the POP nearest to you and is carried to that node over our own backbone. The addresses still reach the intended node, which makes them useful for diagnostics:
| au-bne01 (Brisbane) | fdfd:27b9:f174:100::/58 |
| us-lax01 (Los Angeles) | fdfd:27b9:f174:200::/58 |
| de-fra01 (Frankfurt) | fdfd:27b9:f174:300::/58 |
| jp-tyo01 (Tokyo) | fdfd:27b9:f174:400::/58 |
| us-ewr01 (New Jersey) | fdfd:27b9:f174:600::/58 |
| hk-hkg01 (Hong Kong) | fdfd:27b9:f174:700::/58 |
| sg-sin01 (Singapore) | fdfd:27b9:f174:800::/58 |
Registry max-lengths: 172.20.159.128/27 → 27 and fdfd:27b9:f174::/48 → 58. No more-specific route is announced to any eBGP peer, IX route server, or collector. For IPv4 you likewise only see the /27: each node's unique v4 source address is an internal /32, so a packet that lands on any of our routers is carried to the originating node. jp-tyo01 originates v6 only.
Registry delegation uses a single anycast name; per-node geo names are also published for when you want to pin a query to one POP.
ns.headscarf175.dn42 | 172.20.159.132 · fdfd:27b9:f174:53::1 | anycast (whichever POP is closest) |
au-bne01.headscarf175.dn42 | 172.20.159.152 · fdfd:27b9:f174:100::1 | s1 (Brisbane) |
us-lax01.headscarf175.dn42 | 172.20.159.136 · fdfd:27b9:f174:200::1 | s2 (Los Angeles) |
de-fra01.headscarf175.dn42 | 172.20.159.144 · fdfd:27b9:f174:300::1 | s3 (Frankfurt) |
jp-tyo01.headscarf175.dn42 | fdfd:27b9:f174:400::1 | s4 (Tokyo), v6-only |
PowerDNS runs on au-bne01 (primary) with us-lax01 / de-fra01 / jp-tyo01 / us-ewr01 as secondaries (AXFR over our internal backbone; jp-tyo01 is v6-only). All zones are DNSSEC-signed. Zones served: headscarf175.dn42; the ENUM zone 2.4.8.0.4.2.4.0.tel.dn42 (our tel.dn42 number +04240842 — see the peering page); and reverse zones 128/27.159.20.172.in-addr.arpa + 4.7.1.f.9.b.7.2.d.f.d.f.ip6.arpa.
Internal only — peers never see it. BIRD OSPF (v2 for IPv4, v3 for IPv6) runs over the WireGuard mesh between all core nodes with a flat cost on every link, and carries only each node's loopbacks (v4 /32 + v6 /128) — nothing external, no anycast supernet. iBGP runs on a GRE tunnel per pair of nodes between those loopbacks, so when a mesh link fails OSPF reroutes the tunnel underneath without any BGP route being withdrawn or re-announced to peers. The IX leaf nodes advertise themselves as OSPF stub routers and never carry transit between other nodes.
Every node carries unreachable fd00::/8, unreachable 172.20.0.0/14, and unreachable 10.0.0.0/8 at a very high metric. Any DN42 destination not in BIRD's RIB therefore gets an ICMP destination unreachable rather than falling through to the node's clearnet IPv4/IPv6 default and egressing with a public source address. More-specific BIRD routes still win for known DN42 prefixes, and kernel-local routes win for our own anycast / per-POP / LAN addresses — the unreachable entries only ever catch genuinely-unknown DN42 space.
dn42.burble.com/roa/dn42_roa_46.json) — ROA-invalid routes are rejected on import at every POP independently.(65535, 0) → 0; otherwise by the destination's DN42 region and country tags, preferring an exit in the same region and country (3000), the same region (2500), the same country without a region tag (2000), and anything else (1000), plus 100 when learned directly from the origin AS.