Niche detail you usually don't need. The main peering page is /.
Each POP originates a more-specific IPv6 /58 via eBGP alongside the /27 and /48 anycast, so v6 traffic to a node-specific address routes directly to that node instead of falling to anycast. Use these for diagnostics or when you want to pin to a single POP:
| 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-length: fdfd:27b9:f174::/48 → 58; the v6 /58 carve-outs are ROA-valid and propagate via eBGP to direct peers (the IX route-server export remains stub-only). For IPv4 you only ever see the /27 anycast: each node's unique v4 source address exists internally as a /32 over iBGP, so a packet that lands on any of our routers is redirected to the originating node — the more-specifics are never advertised externally. jp-tyo01 originates v6 only; its v4 NLRI is carried via RFC 8950 ENH on iBGP for transit.
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 the iBGP tunnels; 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. Babel runs over the iBGP WireGuard tunnels between all core nodes (au-bne01, us-lax01, de-fra01, jp-tyo01, us-ewr01, hk-hkg01, sg-sin01) as a fast-failover IGP: 1 s Hellos give ~3 s tunnel-down detection vs BGP's ~90–240 s hold. It carries only each node's host loopbacks (v4 /32 + v6 /128) — nothing external, no anycast supernet; the service /58 carve-outs ride iBGP. Every Babel interface runs at a flat cost (type wired; rxcost 96) so the metric doesn't jitter with RTT. Babel exists so iBGP gateway recursive next-hops stay resolvable: when a direct iBGP link drops, traffic between two nodes reroutes via a third until BGP reconverges.
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 · direct peer / 1-hop path → 120 · all-PFS path (64511, 34) → 110 · default → 100 · any cleartext hop (64511, 31) → 90. The encryption tier reflects the worst hop seen in the path.