DN42 - Ep.3 Registering a Domain and Setting Up Authoritative DNS in DN42 Foreword I am a novice in BGP. This article may contain imprecise content/naive understandings/elementary mistakes. If you find any issues, you are welcome to contact me via email, and I will correct them as soon as possible. If you find this unacceptable, it is recommended to close this article now. Assumption: You have already joined DN42, can normally send and receive routing tables, and can access IPs within DN42. Article Update Log {timeline} {timeline-item color="#50BFFF"} August 3, 2025: First edition published. {/timeline-item} {timeline-item color="#4F9E28"} March 15, 2026: Update typos. Thanks to @Auride. {/timeline-item} {/timeline} Motivation While debugging the network, I noticed that pinging or tracerouting others' DN42 IPs could display the reverse-resolved domain names, making it clear which nodes the route passed through, rather than just looking at IPs (as shown in the figure below). It's very intuitive, letting others see at a glance if you've taken a detour. Therefore, I decided to register my own DN42 domain and set up an authoritative DNS service. After reading Lantian's article, I saw he used a PowerDNS + MySQL master-slave synchronization solution. However, my server has limited performance (only 1 core, 1GB RAM), so I plan to use KnotDNS as the DNS server, utilizing the standard zone transfer protocol (AXFR/IXFR) for master-slave synchronization. Preparations {alert type="warning"} The domain names and IPs mentioned in this and subsequent chapters are my own. Please replace them with your own during actual deployment; values enclosed in angle brackets need to be changed according to your requirements. {/alert} I chose the domain: yori.dn42, and plan to deploy DNS servers on three machines: 172.20.234.225, fd18:3e15:61d0::1, ns1.yori.dn42 172.20.234.227, fd18:3e15:61d0::3, ns2.yori.dn42 172.20.234.229, fd18:3e15:61d0::5, ns3.yori.dn42 Among them, ns1.yori.dn42 will be the master node, and ns2, ns3 will be the slave nodes. Installing KnotDNS If port 53 on the system is occupied by a process like systemd-resolvd, disable it first: systemctl stop systemd-resolved systemctl disable systemd-resolved unlink /etc/resolv.conf echo "nameserver 8.8.8.8" > /etc/resolv.conf I am using Debian 12, so I'll use APT for installation: apt install knot knot-dnsutils -y Set KnotDNS to start automatically: systemctl enable knot Configuring KnotDNS Creating a Key First, create a key for synchronization: keymgr -t key_knsupdate Copy the output: # hmac-sha256:key_knsupdate:<your secret> key: - id: key_knsupdate algorithm: hmac-sha256 secret: <your secret> Editing the Configuration File Master Node Edit /etc/knot/knot.conf and fill in the following content: server: rundir: "/run/knot" user: knot:knot automatic-acl: on listen: [ <listen_address1>@53, <listen_address2>@53, ... ] log: - target: syslog any: info database: storage: "/var/lib/knot" ### Paste the Key generated in the previous step here # hmac-sha256:key_knsupdate:<your secret> key: - id: key_knsupdate algorithm: hmac-sha256 secret: <your secret> remote: - id: <DNS_Node_1_ID> address: <DNS_Node_1_IP>@53 - id: <DNS_Node_2_ID> address: <DNS_Node_2_IP>@53 - id: <DNS_Node_3_ID> address: <DNS_Node_3_IP>@53 acl: - id: acl_slave key: key_knsupdate action: transfer - id: acl_master key: key_knsupdate action: notify - id: acl_knsupdate key: key_knsupdate action: update template: - id: default storage: "/var/lib/knot" file: "%s.zone" zone: - domain: <DN42 Domain> notify: [ <Slave_Node_1_ID>, <Slave_Node_2_ID> ] acl: [ acl_slave, acl_knsupdate ] - domain: <IPv4 Reverse Lookup Domain> notify: [ <Slave_Node_1_ID>, <Slave_Node_2_ID> ] acl: [ acl_slave, acl_knsupdate ] - domain: <IPv6 Reverse Lookup Domain> notify: [ <Slave_Node_1_ID>, <Slave_Node_2_ID> ] acl: [ acl_slave, acl_knsupdate ] The listen addresses should include the machine's DN42 IPv4 and DN42 IPv6 addresses. For local debugging, you can add internal IPs like 127.0.0.1 and ::1. The Slave Node IDs are the IDs set in the remote section for the servers you designated as slave nodes. The address in remote can be an internal address, DN42 IPv4, or DN42 IPv6, used only for master-slave synchronization. If using an internal address, add it to the listen list. The template section sets the Zone file storage location to /var/lib/knot. The IPv4 Reverse Lookup Domain should follow the format specified in RFC 2317 based on your allocated IPv4 block. For example, my IPv4 block is 172.20.234.224/28, so my IPv4 reverse lookup domain should be 224/28.234.20.172.in-addr.arpa. This treats the last octet 224/28 as a whole, reverses the order of the remaining parts, and appends .in-addr.arpa. The IPv6 Reverse Lookup Domain should follow the format specified in RFC 3152 based on your allocated IPv6 block. For example, my IPv6 block is fd18:3e15:61d0::/48, so my IPv6 reverse lookup domain should be 0.d.1.6.5.1.e.3.8.1.d.f.ip6.arpa. This involves reversing the order of the nibbles in the network prefix (excluding the /48) and appending .ip6.arpa. Pad with zeros if necessary. {collapse} {collapse-item label="Example"} server: rundir: "/run/knot" user: knot:knot automatic-acl: on listen: [ 172.20.234.225@53, fd18:3e15:61d0::1@53, localhost@53, 127.0.0.1@53 ] log: - target: syslog any: info database: storage: "/var/lib/knot" # hmac-sha256:key_knsupdate:<key> key: - id: key_knsupdate algorithm: hmac-sha256 secret: <key> remote: - id: 225 # Master Node address: 172.20.234.225@53 - id: 227 # Slave Node address: 172.20.234.227@53 - id: 229 # Slave Node address: 172.20.234.229@53 acl: - id: acl_slave key: key_knsupdate action: transfer - id: acl_master key: key_knsupdate action: notify - id: acl_knsupdate key: key_knsupdate action: update template: - id: default storage: "/var/lib/knot" file: "%s.zone" zone: - domain: yori.dn42 notify: [ 227, 229 ] acl: [ acl_slave, acl_knsupdate ] - domain: 224/28.234.20.172.in-addr.arpa notify: [ 227, 229 ] acl: [ acl_slave, acl_knsupdate ] - domain: 0.d.1.6.5.1.e.3.8.1.d.f.ip6.arpa notify: [ 227, 229 ] acl: [ acl_slave, acl_knsupdate ] {/collapse-item} {/collapse} Slave Nodes The configuration for slave nodes is largely similar to the master node. Just change the listen addresses to the slave node's addresses and modify the zone section configuration as follows: --- a/knot.conf +++ b/knot.conf zone: - domain: <DN42 Domain> - notify: [ <Slave_Node_1_ID>, <Slave_Node_2_ID> ] - acl: [ acl_slave, acl_knsupdate ] + master: <Master_Node_ID> + zonefile-load: whole + acl: acl_master - domain: <IPv4 Reverse Lookup Domain> - notify: [ <Slave_Node_1_ID>, <Slave_Node_2_ID> ] - acl: [ acl_slave, acl_knsupdate ] + master: <Master_Node_ID> + zonefile-load: whole + acl: acl_master - domain: <IPv6 Reverse Lookup Domain> - notify: [ <Slave_Node_1_ID>, <Slave_Node_2_ID> ] - acl: [ acl_slave, acl_knsupdate ] + master: <Master_Node_ID> + zonefile-load: whole + acl: acl_master The Master Node ID is the ID set in the remote section for the server you designated as the master node. {collapse} {collapse-item label="Examp;e"} server: rundir: "/run/knot" user: knot:knot automatic-acl: on listen: [ 172.20.234.227@53, fd18:3e15:61d0::3@53, localhost@53, 127.0.0.1@53 ] log: - target: syslog any: info database: storage: "/var/lib/knot" # hmac-sha256:key_knsupdate:<key> key: - id: key_knsupdate algorithm: hmac-sha256 secret: <key> remote: - id: 225 address: 172.20.234.225@53 - id: 227 address: 172.20.234.227@53 - id: 229 address: 172.20.234.229@53 acl: - id: acl_slave key: key_knsupdate action: transfer - id: acl_master key: key_knsupdate action: notify - id: acl_knsupdate key: key_knsupdate action: update template: - id: default storage: "/var/lib/knot" file: "%s.zone" zone: - domain: yori.dn42 master: 225 zonefile-load: whole acl: acl_master - domain: 224/28.234.20.172.in-addr.arpa master: 225 zonefile-load: whole acl: acl_master - domain: 0.d.1.6.5.1.e.3.8.1.d.f.ip6.arpa master: 225 zonefile-load: whole acl: acl_master {/collapse-item} {/collapse} After writing the configuration file, run the following command to restart KnotDNS: systemctl restart knot Editing Zone Files All configurations in this section are done on the primary DNS server. For record values (not hostnames) that require domain names, unless otherwise specified, please follow the RFC 1034 specification and use FQDN format. DN42 Domain Navigate to /var/lib/knot and create a file named <dn42_domain>.zone. SOA Record The first record of the zone must be the SOA record. The SOA record is the Start of Authority record, containing basic information about the domain, such as the primary NS server address. Fill in the following content: @ <TTL> SOA <Primary_NS_Server_Address> <Contact_Email> <Serial_Number> <Refresh_Time> <Retry_Time> <Expire_Time> <Minimum_TTL> @ represents the current domain itself, do not change it. TTL: The TTL (Time To Live) value for this SOA record. Primary NS Server Address: The address of the primary authoritative NS server for this domain. This can be a resolution within the domain. For example, my primary NS server is 172.20.234.225, and I plan to use ns1.yori.dn42. pointing to this address, so here I can fill in ns1.yori.dn42.. Contact Email: The email address, with @ replaced by .. For example, my email is [email protected], so here I can fill in i.iyoroy.cn. Serial Number: A 10-digit number following RFC 1912, representing the version of the zone file. Other DNS servers will refetch the records if they detect an increase in the serial number when querying the SOA. It's commonly encoded using the date + a sequence number, so this value should be incremented after each modification. Refresh Time:: The interval for AXFR slave nodes to pull the zone. Retry Time: The retry interval for AXFR slave nodes after a failed pull. Expire Time: The maximum time an AXFR slave node can continue serving with the last successfully pulled records after a failure, after which it stops responding. Minimum TTL: The minimum TTL value for the entire domain, the minimum refresh time for all records. Records won't be refreshed before at least this much time has passed. {collapse} {collapse-item label="Examp;e"} ; SOA @ 3600 SOA ns1.yori.dn42. i.iyoroy.cn. 2025072705 60 60 1800 60 {/collapse-item} {/collapse} NS Records @ <TTL> NS <NS_Server_1> @ <TTL> NS <NS_Server_2> @ <TTL> NS <NS_Server_3> Fill this in according to your actual situation; add as many records as you have servers. {collapse} {collapse-item label="Example"} ; NS @ 3600 NS ns1.yori.dn42. @ 3600 NS ns2.yori.dn42. @ 3600 NS ns3.yori.dn42. {/collapse-item} {/collapse} A, AAAA, CNAME, etc. Records Fill them in according to the following format: <Hostname> <TTL> <Type> <Record_Value> If your NS server values point to hosts within your own DN42 domain, be sure to add A or AAAA resolution records for them. {collapse} {collapse-item label="Example"} ; A ns1 600 A 172.20.234.225 ns2 600 A 172.20.234.227 ns3 600 A 172.20.234.229 hkg-cn.node 600 A 172.20.234.225 nkg-cn.node 600 A 172.20.234.226 tyo-jp.node 600 A 172.20.234.227 hfe-cn.node 600 A 172.20.234.228 lax-us.node 600 A 172.20.234.229 ; AAAA ns1 600 AAAA fd18:3e15:61d0::1 ns2 600 AAAA fd18:3e15:61d0::3 ns3 600 AAAA fd18:3e15:61d0::5 hkg-cn.node 600 AAAA fd18:3e15:61d0::1 nkg-cn.node 600 AAAA fd18:3e15:61d0::2 tyo-jp.node 600 AAAA fd18:3e15:61d0::3 hfe-cn.node 600 AAAA fd18:3e15:61d0::4 lax-us.node 600 AAAA fd18:3e15:61d0::5 {/collapse-item} {collapse-item label="Complete Example"} /var/lib/knot/yori.dn42.zone ; SOA @ 3600 SOA ns1.yori.dn42. i.iyoroy.cn. 2025072705 60 60 1800 60 ; NS @ 3600 NS ns1.yori.dn42. @ 3600 NS ns2.yori.dn42. @ 3600 NS ns3.yori.dn42. ; A ns1 600 A 172.20.234.225 ns2 600 A 172.20.234.227 ns3 600 A 172.20.234.229 hkg-cn.node 600 A 172.20.234.225 nkg-cn.node 600 A 172.20.234.226 tyo-jp.node 600 A 172.20.234.227 hfe-cn.node 600 A 172.20.234.228 lax-us.node 600 A 172.20.234.229 ; AAAA ns1 600 AAAA fd18:3e15:61d0::1 ns2 600 AAAA fd18:3e15:61d0::3 ns3 600 AAAA fd18:3e15:61d0::5 hkg-cn.node 600 AAAA fd18:3e15:61d0::1 nkg-cn.node 600 AAAA fd18:3e15:61d0::2 tyo-jp.node 600 AAAA fd18:3e15:61d0::3 hfe-cn.node 600 AAAA fd18:3e15:61d0::4 lax-us.node 600 AAAA fd18:3e15:61d0::5 {/collapse-item} {/collapse} IPv4 Reverse Lookup Domain Create a file in /var/lib/knot named <IPv4_Reverse_Lookup_Domain>.zone, replacing / with _. For example, my IPv4 block is 172.20.234.224/28, and my IPv4 reverse lookup domain is 224/28.234.20.172.in-addr.arpa, so the filename here would be 224_28.234.20.172.in-addr.arpa.zone. Fill in the resolution records: ; SOA @ <TTL> SOA <Primary_NS_Server_Address> <Contact_Email> <Serial_Number> <Refresh_Time> <Retry_Time> <Expire_Time> <Minimum_TTL> ; NS @ <TTL> NS <NS_Server_1> @ <TTL> NS <NS_Server_2> @ <TTL> NS <NS_Server_3> ; PTR <Last_IPv4_Octet> <TTL> PTR <Reverse_DNS_Value> <Last_IPv4_Octet> <TTL> PTR <Reverse_DNS_Value> <Last_IPv4_Octet> <TTL> PTR <Reverse_DNS_Value> ... The SOA and NS records are the same as above. Last IPv4 Octet: The last octet of the DN42 IPv4 address you assigned to the device. For example, my HK node is assigned 172.20.234.225, so here I would put 225. {collapse} {collapse-item label="Example"} 224_28.234.20.172.in-addr.arpa.zone ; SOA @ 3600 SOA ns1.yori.dn42. i.iyoroy.cn. 2025072802 60 60 1800 60 ; NS @ 3600 NS ns1.yori.dn42. @ 3600 NS ns2.yori.dn42. @ 3600 NS ns3.yori.dn42. ; PTR 225 600 PTR hkg-cn.node.yori.dn42. 226 600 PTR nkg-cn.node.yori.dn42. 227 600 PTR tyo-jp.node.yori.dn42. 228 600 PTR hfe-cn.node.yori.dn42. 229 600 PTR lax-us.node.yori.dn42. {/collapse-item} {/collapse} You might wonder why the CIDR mask is needed, which differs from the common Clearnet format of reversed octets (e.g., 234.20.172.in-addr.arpa). Also, if you test locally, you might find that reverse lookups for your own IP addresses fail directly. The reason lies in DN42's distributed registry mechanism: a single zone file cannot cover all reverse query entry points for your address block (i.e., the .in-addr.arpa name for each specific IP address). To solve this, after your PR is merged, the official DN42 DNS will add CNAME redirects for your address block on its authoritative servers, pointing individual IP PTR queries to your CIDR-formatted zone, as shown below: ~$ dig PTR 225.234.20.172.in-addr.arpa +short 225.224/28.234.20.172.in-addr.arpa. # <-- CNAME added by Registry (redirect) hkg-cn.node.yori.dn42. # <-- Final PTR record returned by your DNS When an external resolver queries the reverse record for a specific IP (e.g., 172.20.234.225) (querying 225.234.20.172.in-addr.arpa), the official DN42 DNS returns a CNAME record pointing it to the specific record under the CIDR zone name (225.224/28.234.20.172.in-addr.arpa). Ultimately, the PTR record is provided by your configured authoritative DNS server. IPv6 Reverse Lookup Domain Create a file in /var/lib/knot named <IPv6_Reverse_Lookup_Domain>.zone. For example, my IPv6 block is fd18:3e15:61d0::/48, and my IPv6 reverse lookup domain is 0.d.1.6.5.1.e.3.8.1.d.f.ip6.arpa, so the filename here would be 0.d.1.6.5.1.e.3.8.1.d.f.ip6.arpa.zone. Fill in the resolution records: ; SOA @ <TTL> SOA <Primary_NS_Server_Address> <Contact_Email> <Serial_Number> <Refresh_Time> <Retry_Time> <Expire_Time> <Minimum_TTL> ; NS @ <TTL> NS <NS_Server_1> @ <TTL> NS <NS_Server_2> @ <TTL> NS <NS_Server_3> ; PTR <Reversed_Last_20_Nibbles> <TTL> PTR <Reverse_DNS_Value> <Reversed_Last_20_Nibbles> <TTL> PTR <Reverse_DNS_Value> <Reversed_Last_20_Nibbles> <TTL> PTR <Reverse_DNS_Value> ... Handle SOA and NS records as above. For the PTR hostname, you need to take the last 80 bits of the host's IPv6 address (after removing the /48 prefix), expand them into 20 hexadecimal characters, and reverse the order of these characters, separating them with dots. For example, my Hong Kong node's IPv6 is fd18:3e15:61d0::1. Expanded, this is fd18:3e15:61d0:0000:0000:0000:0000:0001. The hostname here would be 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0. {collapse} {collapse-item label="Example"} 0.d.1.6.5.1.e.3.8.1.d.f.ip6.arpa.zone ; SOA @ 3600 SOA ns1.yori.dn42. i.iyoroy.cn. 2025072802 60 60 1800 60 ; NS @ 3600 NS ns1.yori.dn42. @ 3600 NS ns2.yori.dn42. @ 3600 NS ns3.yori.dn42. ; PTR 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 600 PTR hkg-cn.node.yori.dn42. 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 600 PTR nkg-cn.node.yori.dn42. 3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 600 PTR tyo-jp.node.yori.dn42. 4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 600 PTR hfe-cn.node.yori.dn42. 5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 600 PTR lax-us.node.yori.dn42. {/collapse-item} {/collapse} Verifying the Setup After saving everything, run knot reload on each DNS server. If all goes well, you should see the slave nodes synchronizing the zone files from the master node. You can then use dig or nslookup specifying the server to query the resolution records. Registration Domain Clone the DN42 Registry, navigate to data/dns, create a new file named <your_desired_domain>, and fill in the following content: domain: <your_desired_domain> admin-c: <Admin_NIC_Handle> tech-c: <Tech_NIC_Handle> mnt-by: <Maintainer> nserver: <NS1_Server_Domain> <NS1_Server_IP> nserver: <NS2_Server_Domain> <NS2_Server_IP> nserver: <NS3_Server_Domain> <NS3_Server_IP> ... source: DN42 Refer to DN42 - Ep.1 Joining the DN42 Network for admin-c, tech-c, and mnt-by. {collapse} {collapse-item label="Example"} data/dns/yori.dn42 domain: yori.dn42 admin-c: IYOROY-DN42 tech-c: IYOROY-DN42 mnt-by: IYOROY-MNT nserver: ns1.yori.dn42 172.20.234.225 nserver: ns1.yori.dn42 fd18:3e15:61d0::1 nserver: ns2.yori.dn42 172.20.234.227 nserver: ns2.yori.dn42 fd18:3e15:61d0::3 nserver: ns3.yori.dn42 172.20.234.229 nserver: ns3.yori.dn42 fd18:3e15:61d0::5 source: DN42 {/collapse-item} {/collapse} IPv4 Reverse Lookup Domain Navigate to data/inetnum, find the file for your registered address block, and add nserver fields pointing to your own DNS servers: nserver: <your_DNS_server_address> nserver: <your_DNS_server_address> ... ... {collapse} {collapse-item label="Example"} diff --git a/data/inetnum/172.20.234.224_28 b/data/inetnum/172.20.234.224_28 index 50c800945..5ad60e23d 100644 --- a/data/inetnum/172.20.234.224_28 +++ b/data/inetnum/172.20.234.224_28 @@ -8,3 +8,6 @@ tech-c: IYOROY-DN42 mnt-by: IYOROY-MNT status: ASSIGNED source: DN42 +nserver: ns1.yori.dn42 +nserver: ns2.yori.dn42 +nserver: ns3.yori.dn42 {/collapse-item} {/collapse} IPv6 Reverse Lookup Domain Navigate to data/inet6num, find the file for your registered address block, and add nserver fields pointing to your own DNS servers: nserver: <your_DNS_server_address> nserver: <your_DNS_server_address> ... {collapse} {collapse-item label="Example"} diff --git a/data/inet6num/fd18:3e15:61d0::_48 b/data/inet6num/fd18:3e15:61d0::_48 index 53f0de06d..1ae067b00 100644 --- a/data/inet6num/fd18:3e15:61d0::_48 +++ b/data/inet6num/fd18:3e15:61d0::_48 @@ -8,3 +8,6 @@ tech-c: IYOROY-DN42 mnt-by: IYOROY-MNT status: ASSIGNED source: DN42 +nserver: ns1.yori.dn42 +nserver: ns2.yori.dn42 +nserver: ns3.yori.dn42 {/collapse-item} {/collapse} Submit a PR and Wait for Merge After filling everything out, push your changes and submit a Pull Request. Because anyone in DN42 can run recursive DNS, it might take up to a week for the DNS configuration to fully propagate, although I found that the public DNS (172.20.0.53) could query my records within half a day after merging. Special thanks to たのしい for clarifying the differences between IPv4 reverse lookup in DN42 and the public internet. Reference Articles: https://www.haiyun.me/archives/1398.html https://www.jianshu.com/p/7d69ec2976c7 https://www.potat0.cc/posts/20220726/Register_DN42_Domain/ https://bbs.csdn.net/topics/393775423 https://blog.snorlax.blue/knot-reverse-dns-kickstart/ http://www.kkdlabs.jp/dns/automatic-dnssec-signing-by-knot-dns/ https://lantian.pub/article/modify-website/register-own-domain-in-dn42.lantian/ https://datatracker.ietf.org/doc/html/rfc2317 https://datatracker.ietf.org/doc/html/rfc3152 https://datatracker.ietf.org/doc/html/rfc1912#section-2.2

DN42 - Ep.2 Building Internal Network with OSPF and Enabling iBGP Foreword I am a novice in BGP. This article may contain imprecise content/naive understandings/elementary mistakes. I kindly ask the experts to be lenient. If you find any issues, you are welcome to contact me via email, and I will correct them as soon as possible. If you find this unacceptable, it is recommended to close this article now. Article Update Log {timeline} {timeline-item color="#50BFFF"} July 22, 2025: First edition published, using VXLAN over WireGuard tunnel. {/timeline-item} {timeline-item color="#50BFFF"} July 25, 2025: Updated tunneling solution, using type ptp; to support OSPF traffic via WireGuard (Special thanks to Nuro Trance for the guidance!). {/timeline-item} {timeline-item color="#50BFFF"} August 8, 2025: Added explanation and configuration for iBGP. {/timeline-item} {timeline-item color="#4F9E28"} August 27, 2025: Updated node topology diagram. {/timeline-item} {/timeline} Why Do We Need Internal Routing? As the number of nodes increases, we need a proper way to handle internal routing within our AS (Autonomous System). BGP only handles routing to different ASes, which causes a problem: if nodes A and B are both peering with external networks, a request from node A may have its response routed to node B, even though they are part of the same AS. Without internal routing, node A will not receive the reply. To solve this, we need to ensure that all devices within our AS can communicate with each other. The common solutions are: Using network tools like ZeroTier: Simple to set up, just install the client on each node for P2P connectivity. Using P2P tools like WireGuard to manually create $\frac{n(n-1)}{2}$ tunnels, which works like the first solution but becomes cumbersome as nodes grow. Using WireGuard to establish $\frac{n(n-1)}{2}$ tunnels, then using an internal routing protocol like OSPF or Babel to manage the routing. This is more flexible and easier to scale, but it can be risky and could break the DN42 network due to misconfigurations. Thus, I decided to take the risk. Node Topology graph LR A[HKG<br>172.20.234.225<br>fd18:3e15:61d0::1] B[NKG<br>172.20.234.226<br>fd18:3e15:61d0::2] C[TYO<br>172.20.234.227<br>fd18:3e15:61d0::3] D[FRA<br>172.20.234.228<br>fd18:3e15:61d0::4] E[LAX<br>172.20.234.229<br>fd18:3e15:61d0::5] B <--> A C <--> A A <--> E A <--> D C <--> D C <--> E D <--> E Update Bird2 to v2.16 or Above To use IPv6 Link-Local addresses to transmit IPv4 OSPF data, Bird v2.16 or later is required. Here are the steps to update: sudo apt update && sudo apt -y install apt-transport-https ca-certificates wget lsb-release sudo wget -O /usr/share/keyrings/cznic-labs-pkg.gpg https://pkg.labs.nic.cz/gpg echo "deb [signed-by=/usr/share/keyrings/cznic-labs-pkg.gpg] https://pkg.labs.nic.cz/bird2 $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/cznic-labs-bird2.list sudo apt update && sudo apt install bird2 -y Tunnel Configuration [Interface] PrivateKey = <Local WireGuard Private Key> ListenPort = <Listen Port> Table = off Address = <IPv6 LLA>/64 PostUp = sysctl -w net.ipv6.conf.%i.autoconf=0 [Peer] PublicKey = <Peer Public Key> Endpoint = <Peer Public Endpoint> AllowedIPs = 10.0.0.0/8, 172.20.0.0/14, 172.31.0.0/16, fd00::/8, fe00::/8, ff02::5 ff02::5is the OSPFv3 router-specific link-local multicast address and should be included in AllowedIPs. If you're using Bird versions earlier than v2.16, you'll need to add an IPv4 address for the tunnel as well. See the example below: {collapse} {collapse-item label="WireGuard Configuration Example with IPv4"} [Interface] PrivateKey = <Local WireGuard Private Key> ListenPort = <Listen Port> Table = off Address = <IPv6 LLA>/64 PostUp = ip addr add 100.64.0.225/32 peer 100.64.0.226/32 dev %i PostUp = sysctl -w net.ipv6.conf.%i.autoconf=0 [Peer] PublicKey = <Peer Public Key> Endpoint = <Peer Public Endpoint> AllowedIPs = 10.0.0.0/8, 172.20.0.0/14, 100.64.0.0/16, 172.31.0.0/16, fd00::/8, fe00::/8, ff02::5 Please replace 100.64.0.225 and 100.64.0.226 with your local and peer IPv4 addresses, and remember to add AllowedIPs. {/collapse-item} {/collapse} Enable OSPF You should have already configured basic Bird settings as described in the previous article. Create a new file called ospf.conf under /etc/bird and add the following: protocol ospf v3 <name> { ipv4 { import where is_self_net() && source != RTS_BGP; export where is_self_net() && source != RTS_BGP; }; include "/etc/bird/ospf/*"; }; protocol ospf v3 <name> { ipv6 { import where is_self_net_v6() && source != RTS_BGP; export where is_self_net_v6() && source != RTS_BGP; }; include "/etc/bird/ospf/*"; }; Theoretically, OSPF v2 should be used for handling IPv4, but since we need to communicate IPv4 using IPv6 Link-Local addresses, we are using OSPF v3 for IPv4 in this case as well. The filter rules ensure that only routes within the local network segment are allowed to propagate through OSPF, and routes from external BGP protocols are filtered out. Never use import all; export all; indiscriminately, as this could lead to route hijacking and affect the entire DN42 network. OSPF should only handle internal network routes. {collapse} {collapse-item label="Example"} /etc/bird/ospf.conf protocol ospf v3 dn42_iyoroynet_ospf { ipv4 { import where is_self_net() && source != RTS_BGP; export where is_self_net() && source != RTS_BGP; }; include "/etc/bird/ospf/*"; }; protocol ospf v3 dn42_iyoroynet_ospf6 { ipv6 { import where is_self_net_v6() && source != RTS_BGP; export where is_self_net_v6() && source != RTS_BGP; }; include "/etc/bird/ospf/*"; }; {/collapse-item} {/collapse} Next, create the /etc/bird/ospf folder and then create an area configuration file (e.g., /etc/bird/ospf/backbone.conf) with the following content: area 0.0.0.0 { interface "<DN42 dummy interface>" { stub; }; interface "<wg0 interface>" { cost 80; # Modify according to your network situation type ptp; }; interface "<wg1 interface>" { cost 100; # Modify according to your network situation type ptp; }; # Continue for other interfaces }; The 0.0.0.0 area represents the backbone network. he dummy interface here refers to the DN42 virtual interface mentioned in the previous article The cost value is typically used for cost calculation but in DN42's case, where bandwidth is less critical but latency is more important, you can directly assign the latency value. OSPF will automatically choose the route with the lowest cost (sum of the cost values). {collapse} {collapse-item label="Example"} /etc/bird/ospf/backbone.conf area 0.0.0.0 { interface "dn42" { stub; }; interface "dn42_hkg" { cost 80; type ptp; }; interface "dn42_hfe" { cost 150; type ptp; }; interface "dn42_lax"{ cost 100; type ptp; }; }; {/collapse-item} {/collapse} Finally, open /etc/bird/bird.conf and add the following to include the OSPF configuration file at the end: include "ospf.conf"; Run birdc configure, and then birdc show protocols should show the OSPF status as Running. If not, check the configuration steps for errors. At this point, you should be able to ping between two non-directly connected machines: Enable iBGP Before establishing multiple peer connections, each of your nodes must first have complete knowledge of the internal AS topology. This involves configuring another key component: internal BGP (iBGP). Necessity of iBGP iBGP ensures that all routers within the AS have complete knowledge of external destination routes. It ensures that: Internal routers can select the best exit path. Traffic is correctly routed to the boundary routers responsible for specific external networks. Even if there are multiple boundary routers connected to the same external network, internal routers can choose the best exit based on policies. Compared to using a default route pointing to the border router within the AS, iBGP provides precise external route information, allowing internal routers to make more intelligent forwarding decisions. Disadvantages and Solutions To prevent uncontrolled propagation of routing information within the AS, which could cause loops, an iBGP router will not readvertise routes learned from one iBGP neighbor to other iBGP neighbors. This necessitates that traditional iBGP requires a full mesh of iBGP neighbor relationships between all iBGP-running routers within the same AS. (You still need to establish $\frac{n(n+1)}{2}$ connections , there's no way around it. But configuring iBGP is still easier than configuring tunnels after OSPF is set up ). Solutions include: Using a Route Reflector (RR): An RR router manages all routing information within the entire AS. The disadvantage is that if the RR router fails, the entire network can be paralyzed (which is not very Decentralized). Using BGP Confederation: This involves virtually dividing the routers within the AS into sub-ASes, treating the connections between routers as eBGP, and finally stripping the internal AS path information when advertising routes externally. I haven't tried the latter two solutions. Here are some potentially useful reference articles. This article focuses on the configuration of iBGP. DN42 Experimental Network: Intro and Registration (Updated 2022-12) - Lan Tian @ Blog Configure BGP Confederation & Fake Confederation in Bird (Updated 2020-06-07) - Lan Tian @ Blog Writing the iBGP Configuration File Create a new file ibgp.conf in /etc/bird and fill it with the following content: template bgp ibgpeers { local as OWNAS; ipv4 { import where source = RTS_BGP && is_valid_network() && !is_self_net(); export where source = RTS_BGP && is_valid_network() && !is_self_net(); next hop self; extended next hop; }; ipv6 { import where source = RTS_BGP && is_valid_network_v6() && !is_self_net_v6(); export where source = RTS_BGP && is_valid_network_v6() && !is_self_net_v6(); next hop self; }; }; include "ibgp/*"; The import and export filters ensure that iBGP only processes routes learned via the BGP protocol and filters out IGP routes to prevent loops. next hop self is required. It instructs BIRD to rewrite the next hop to the border router's own IP address (instead of the original external next hop) when exporting routes to iBGP neighbors. This is because internal routers cannot directly access the external neighbor's address; without rewriting, the address would be considered unreachable. After rewriting, internal routers only need to send traffic to the border router via IGP routing, and the border router handles the final external forwarding. Because I want to use IPv6 addresses to establish MP-BGP and route IPv4 over IPv6, extended next hop is enabled for IPv4. Next, create the /etc/bird/ibgp directory. Inside, create an iBGP Peer configuration file for each node: protocol bgp 'dn42_ibgp_<Node Name>' from ibgpeers{ neighbor <Corresponding Node's IPv6 ULA Address> as OWNAS; }; {collapse} {collapse-item label="Example"} /etc/bird/ibgp/hkg.conf: protocol bgp 'dn42_ibgp_HKG' from ibgpeers{ neighbor fd18:3e15:61d0::1 as OWNAS; }; {/collapse-item} {/collapse} Note: Each node needs to establish (n-1) iBGP connections, ensuring connectivity with all other machines within the AS. This is why ULA addresses are used. Using ULA addresses ensures that even if the WireGuard connection between two nodes goes down, iBGP can still establish connections via the internal routing established by OSPF. Otherwise, it could lead to the collapse of the entire internal network. Finally, add the inclusion of ibgp.conf in /etc/bird/bird.conf: include "ibgp.conf"; And run birdc configure to apply the configuration. References: BIRD 与 BGP 的新手开场 - 海上的宫殿 萌新入坑 DN42 之 —— 基于 tailscale + vxlan + OSPF 的组网 – 米露小窝 使用 Bird2 配置 WireGuard + OSPF 实现网络的高可用 | bs' realm DN42 实验网络介绍及注册教程（2022-12 更新） - Lan Tian @ Blog 如何引爆 DN42 网络（2023-05-12 更新） - Lan Tian @ Blog Bird 配置 BGP Confederation，及模拟 Confederation（2020-06-07 更新） - Lan Tian @ Blog 深入解析OSPF路径开销、优先级和计时器 - 51CTO New release 2.16 | BIRD Internet Routing Daemon 第一章·第二节 如何在 Linux 上安装最新版本的 BIRD？ | BIRD 中文文档 [DN42] 使用 OSPF ptp 搭建内网与IBGP配置 – Xe_iu's Blog | Xe_iu的杂物间 [译] dn42 多服务器环境中的 iBGP 与 IGP 配置 | liuzhen932 的小窝

DN42 - Ep.1 Joining the DN42 Network Foreword I am a novice in BGP. This article may contain imprecise content/naive understandings/elementary mistakes. I kindly ask the experts to be lenient. If you find any issues, you are welcome to contact me via email, and I will correct them as soon as possible. If you find this unacceptable, it is recommended to close this article now. Welcome to peer with me! For details, please visit: iYoRoy DN42 Network I wanted to study BGP, but renting an ASN and IP block is too expensive, and I was afraid of taking down half the internet due to a configuration error. So, I decided to look into DN42, a virtual network. DN42 is a large decentralized network that uses the BGP protocol for routing, making its structure very similar to today's internet. This makes it suitable for learning networking technologies like BGP. In DN42, everyone plays the role of an ISP (Internet Service Provider), peering with other users to join and participate in building the entire DN42 network. DN42 operates on 172.20.0.0/14 and fd00::/8, both of which are private address ranges, so it won't affect the clearnet. Registration You need to know basic git commands, GPG, and Linux. It's also best to sign your commits with GPG. If you have basic Git knowledge, you can refer to my commit: Add AS4242422024 · d1f9046ecb - registry - dn42 git Fork and Clone the DN42 Registry Git Repository Register an account on dn42 git and Fork the dn42/registry repository. Clone your forked repository and enter it. Register a Contact Create a file named <Nickname>-DN42 under data/person and fill in the following content: person: <Nickname> e-mail: <Email Address> pgp-fingerprint: <GPG Key Fingerprint> nic-hdl: <NIC Handle> mnt-by: <Maintainer> source: DN42 person: Nickname. e-mail: Email address. pgp-fingerprint: GPG key fingerprint, used for some authentication services. nic-hdl: NIC handle, points to the file itself, just use the current filename. mnt-by: Maintained by, points to the maintainer information from the Register Maintainer section below. source: Source, keep it as DN42. www: Optional, your website URL. {collapse} {collapse-item label="Example"} data/person/IYOROY-DN42 @ dn42/registry@master person: Kagura iYoRoy e-mail: [email protected] www: https://www.iyoroy.cn pgp-fingerprint: 3ECCFFDEC2CB4CB8DA8089BE9AF2F2E03CE8FD67 nic-hdl: IYOROY-DN42 mnt-by: IYOROY-MNT source: DN42 {/collapse-item} {/collapse} Register a Maintainer Create a file data/mntner/<Nickname>-MNT and fill in the following content: mntner: <Nickname>-MNT admin-c: <Contact> tech-c: <Contact> auth: <Authentication Method> mnt-by: <Maintainer> source: DN42 mntner: Maintainer name, generally the same as the filename. admin-c: Administrator contact information, points to a file in the person folder, use the filename from the Register Contact section above. tech-c: Technical contact information, points to a file in the person folder, use the filename from the Register Contact section above. auth: Authentication method, supports pgp or ssh-key. mnt-by: Maintained by, generally points to the filename itself. source: Source, keep it as DN42. {collapse} {collapse-item label="Example"} data/mntner/IYOROY-MNT @ dn42/registry@master mntner: IYOROY-MNT admin-c: IYOROY-DN42 tech-c: IYOROY-DN42 auth: pgp-fingerprint 3ECCFFDEC2CB4CB8DA8089BE9AF2F2E03CE8FD67 mnt-by: IYOROY-MNT source: DN42 {/collapse-item} {/collapse} Register an ASN On the clearnet, 4200000000 - 4294967294 is the reserved range for ASNs. DN42 uses 4242420000 - 4242429999, and currently, 4242420000 - 4242423999 is open for registration.The official recommendation is not to manually find an available ASN but to use Burble's DN42 Free ASN Explorer to select an available ASN for registration. After choosing your desired ASN, create a file <ASN, including AS letters> in data/aut-num and fill in the following content: aut-num: <ASN> as-name: <Autonomous System Name> descr: <Autonomous System Description> admin-c: <Administrator NIC Handle> tech-c: <Technical Contact NIC Handle> mnt-by: <Maintainer> source: DN42 aut-num: Your chosen ASN, including the AS prefix. It should be in the format AS424242xxxx. as-name: Autonomous System Name. descr: Autonomous System Description, can contain spaces. admin-c: Administrator contact information, points to a file in the person folder, use the filename from the Register Contact section above. tech-c: Technical contact information, points to a file in the person folder, use the filename from the Register Contact section above. mnt-by: Maintained by, points to the filename from the Create Maintainer section above. source: Source, keep it as DN42. {collapse} {collapse-item label="示例"} data/aut-num/AS4242422024 @ dn42/registry@master aut-num: AS4242422024 as-name: IYOROYNET-AS-DN42 descr: iYoRoy DN42 Network admin-c: IYOROY-DN42 tech-c: IYOROY-DN42 mnt-by: IYOROY-MNT source: DN42 {/collapse-item} {/collapse} Register an IPv4 Block and Add Route You can skip this section if you don't want to register IPv4 The official provides a tool for finding available address blocks: DN42 Free IPv4 Explorer. It is also not recommended to manually specify but to use the available blocks found through the search tool. DN42 also faces IPv4 address shortages, so please register according to your needs. Generally, a /27 block containing 30 usable IPv4 addresses is sufficient. For smaller networks, you can apply for /28 (14 usable addresses) and /29 (6 usable addresses). The largest block that can be directly applied for is /26, which is 62 addresses. Applying for /25, /24 requires submitting an application and waiting for review. For details, refer to: DN42 Experimental Network: Intro and Registration (Updated 2022-12) - Lan Tian @ Blog After selecting your IPv4 block, create a file in data/inetnum named after the CIDR format of the IPv4 block, using _ instead of / (e.g., if the applied IPv4 block is 172.20.234.224/28, the filename is 172.20.234.224_28), and fill in the content: inetnum: <First IPv4 Address in Block> - <Last IPv4 Address in Block> cidr: <IPv4 Block in CIDR Format> netname: <IPv4 Block Name> descr: <IPv4 Block Description> country: <Country Code for IPv4 Block> admin-c: <Administrator NIC Handle> tech-c: <Technical Contact NIC Handle> mnt-by: <Maintainer> status: ASSIGNED source: DN42 inetnum: IPv4 address range, from the first address to the last address, connected with -. cidr: IPv4 block in CIDR format, do not replace / with _. netname: IPv4 block name, fill in as desired, no special requirements. descr: IPv4 block description, can contain spaces. country: Two-character country code from ISO 3166, for China, fill in CN. admin-c: Administrator contact information, points to a file in the person folder, use the filename from the Register Contact section above. tech-c: Technical contact information, points to a file in the person folder, use the filename from the Register Contact section above. mnt-by: Maintained by, points to the filename from the Create Maintainer section above. status: Status, keep it as ASSIGNED. source: Source, keep it as DN42. {collapse} {collapse-item label="Example"} data/inetnum/172.20.234.224_28 @ dn42/registry@master inetnum: 172.20.234.224 - 172.20.234.239 cidr: 172.20.234.224/28 netname: IYOROYNET-DN42-V4 descr: iYoRoy DN42 Network IPv4 Block country: CN admin-c: IYOROY-DN42 tech-c: IYOROY-DN42 mnt-by: IYOROY-MNT status: ASSIGNED source: DN42 {/collapse-item} {/collapse} Next, under data/route, create a file also named after the IPv4 block's CIDR format, using _ instead of /, and fill in the content: route: <IPv4 Block in CIDR Format> origin: <ASN> max-length: <IPv4 Prefix Length> mnt-by: <Maintainer> source: DN42 route: IPv4 block, fill in CIDR format, do not convert /. origin: ASN, needs to include AS prefix. max-lenth: Prefix Length, i.e., the number after / in the CIDR format. mnt-by: Maintained by, points to the filename from the Create Maintainer section above. source: Source, keep it as DN42. {collapse} {collapse-item label="Example"} data/route/172.20.234.224_28 @ dn42/registry@master route: 172.20.234.224/28 origin: AS4242422024 max-length: 28 mnt-by: IYOROY-MNT source: DN42 {/collapse-item} {/collapse} Register an IPv6 Block and Add Route You can skip this section if you don't want to register IPv6 Similarly, use the official tool to find available IPv6: DN42 Free IPv6 Explorer 。 After selecting the address block, create a file under data/inet6num named after the IPv6 block's CIDR format, using _ instead of / (e.g., if the IPv6 block is fd18:3e15:61d0::/48, the filename is fd18:3e15:61d0::_48), and fill in the content: inet6num: <First IPv6 Address in Block> - <Last IPv6 Address in Block> cidr: <IPv6 Block in CIDR Format> netname: <IPv6 Block Name> descr: <IPv6 Block Description> country: <Country Code for IPv6 Block> admin-c: <Administrator NIC Handle> tech-c: <Technical Contact NIC Handle> mnt-by: <Maintainer> status: ASSIGNED source: DN42 inet6num: IPv6 address range, from the first address to the last address, cannot use :: shorthand, connected with -. For example, if my block is fd18:3e15:61d0::/48, I need to fill in fd18:3e15:61d0:0000:0000:0000:0000:0000 - fd18:3e15:61d0:ffff:ffff:ffff:ffff:ffff. cidr: IPv6 block in CIDR format, do not replace / with _. netname: IPv6 block name, fill in as desired, no special requirements descr: IPv6 block description, can contain spaces country: Two-character country code from ISO 3166, for China, fill in CN. admin-c: Administrator contact information, points to a file in the person folder, use the filename from the Register Contact section above. tech-c: Technical contact information, points to a file in the person folder, use the filename from the Register Contact section above. mnt-by: Maintained by, points to the filename from the Create Maintainer section above. status: Status, keep it as ASSIGNED. source: Source, keep it as DN42. {collapse} {collapse-item label="Example"} data/inet6num/fd18:3e15:61d0::_48 @ dn42/registry@master inet6num: fd18:3e15:61d0:0000:0000:0000:0000:0000 - fd18:3e15:61d0:ffff:ffff:ffff:ffff:ffff cidr: fd18:3e15:61d0::/48 netname: IYOROYNET-DN42-V6 descr: iYoRoy DN42 Network IPv6 Block country: CN admin-c: IYOROY-DN42 tech-c: IYOROY-DN42 mnt-by: IYOROY-MNT status: ASSIGNED source: DN42 {/collapse-item} {/collapse} Next, under data/route6, create a file also named after the IPv6 block's CIDR format, using _ instead of /, and fill in the content: route6: <IPv6 Block in CIDR Format> origin: <ASN> max-length: <IPv6 Prefix Length> mnt-by: <Maintainer> source: DN42 route6: IPv6 block, fill in CIDR format, do not convert /. origin: ASN, needs to include AS prefix. max-lenth: Prefix Length, i.e., the number after / in the CIDR format. mnt-by: Maintained by, points to the filename from the Create Maintainer section above. source: Source, keep it as DN42. {collapse} {collapse-item label="Example"} data/route6/fd18:3e15:61d0::_48 @ dn42/registry@master route6: fd18:3e15:61d0::/48 origin: AS4242422024 max-length: 48 mnt-by: IYOROY-MNT source: DN42 {/collapse-item} {/collapse} Create and Push Commit, Submit PR It's best to sign your commits with GPG and upload your public key to dn42 git. After filling in the above information, return to the root directory of the repository and run the script ./fmt-my-stuff <Maintainer> to automatically format the configuration files. Note: Here <Maintainer> is the value of mntner from the Register Maintainer chapter. Then follow the normal git commit process: git add data/, git commit -S -m "<commit-msg>" to create the commit, git push origin master to push. Then, go to the dn42 git web interface, open your forked repository, and submit a Pull Request. If there are configuration issues, the automated review bot and administrators will inform you. Please patiently modify according to the requirements and merge into the original commit, do not create a new commit. It is recommended to use git commit --amend after git add. After modification, force push directly (git push origin master --force). The working language of the DN42 Registry is English. Please use English for the entire process to avoid unnecessary trouble. Configuring Bird First, install bird. Using Ubuntu 22.04 as an example: apt install bird2 -y If you also want to install WireGuard for later use, add the wireguard and wireguard-tools packages: apt install bird2 wireguard wireguard-tools -y Create Configuration Files bird.conf Modify /etc/bird/bird.conf： define OWNAS = <AS Number>; define OWNIP = <DN42 IPv4 Address>; define OWNIPv6 = <DN42 IPv6 Address>; define OWNNET = <DN42 IPv4 Block, CIDR Format>; define OWNNETv6 = <DN42 IPv6 Block, CIDR Format>; define OWNNETSET = [ <DN42 IPv4 Block, CIDR Format>+ ]; define OWNNETSETv6 = [ <DN42 IPv6 Block, CIDR Format>+ ]; router id OWNIP; protocol device { scan time 10; } function is_self_net() { return net ~ OWNNETSET; } function is_self_net_v6() { return net ~ OWNNETSETv6; } function is_valid_network() { return net ~ [ 172.20.0.0/14{21,29}, # dn42 172.20.0.0/24{28,32}, # dn42 Anycast 172.21.0.0/24{28,32}, # dn42 Anycast 172.22.0.0/24{28,32}, # dn42 Anycast 172.23.0.0/24{28,32}, # dn42 Anycast 172.31.0.0/16+, # ChaosVPN 10.100.0.0/14+, # ChaosVPN 10.127.0.0/16{16,32}, # neonetwork 10.0.0.0/8{15,24} # Freifunk.net ]; } function is_valid_network_v6() { return net ~ [ fd00::/8{44,64} # ULA address space as per RFC 4193 ]; } protocol kernel { scan time 20; ipv6 { import none; export filter { if source = RTS_STATIC then reject; krt_prefsrc = OWNIPv6; accept; }; }; }; protocol kernel { scan time 20; ipv4 { import none; export filter { if source = RTS_STATIC then reject; krt_prefsrc = OWNIP; accept; }; }; } protocol static { route OWNNET reject; ipv4 { import all; export none; }; } protocol static { route OWNNETv6 reject; ipv6 { import all; export none; }; } include "rpki.conf"; include "ebgp.conf"; Here, the OWNIP and OWNIPV6 parameters refer to the DN42 IPv4 and IPv6 addresses assigned to this machine, not the address of the block. For example, if I obtained the address segment 172.20.234.224/28 and assigned 172.20.234.225 to machine A, then OWNIP is 172.20.234.225. The same applies to IPv6. rpki.conf You might have seen other tutorials using cron jobs + reloading Bird to update ROAs. Configuring RPKI here is another way to configure ROAs. Create /etc/bird/rpki.conf and fill in the following content: roa4 table dn42_roa; roa6 table dn42_roa_v6; protocol rpki dn42_rpki_akix { roa4 { table dn42_roa; }; roa6 { table dn42_roa_v6; }; remote "<rpki server address>" port 8082; # change it refresh 30; retry 5; expire 600; } For the RPKI server, you can use the service provided by my friend's AkaereIX: rpki.akae.re. {collapse} {collapse-item label="Example"} roa4 table dn42_roa; roa6 table dn42_roa_v6; protocol rpki dn42_rpki_akix { roa4 { table dn42_roa; }; roa6 { table dn42_roa_v6; }; remote "rpki.akae.re" port 8082; refresh 30; retry 5; expire 600; } {/collapse-item} {/collapse} ebgp.conf Create /etc/bird/ebgp.conf and fill in the following content: template bgp dnpeers { local as OWNAS; path metric 1; ipv4 { import filter { if is_valid_network() && !is_self_net() then { if (roa_check(dn42_roa, net, bgp_path.last) != ROA_VALID) then { print "[dn42] ROA check failed for ", net, " ASN ", bgp_path.last; reject; } accept; } reject; }; export filter { if is_valid_network() && source ~ [RTS_STATIC, RTS_BGP] then accept; reject; }; import limit 1000 action block; }; ipv6 { import filter { if is_valid_network_v6() && !is_self_net_v6() then { if (roa_check(dn42_roa_v6, net, bgp_path.last) != ROA_VALID) then { print "[dn42] ROA check failed for ", net, " ASN ", bgp_path.last; reject; } accept; } reject; }; export filter { if is_valid_network_v6() && source ~ [RTS_STATIC, RTS_BGP] then accept; reject; }; import limit 1000 action block; }; } include "peers/*"; This configuration defines a template for peering within DN42 and references all configuration files under /etc/bird/peers. Later, when we peer, we only need to create configuration files here according to the template and write them. Create the /etc/bird/peers folder for subsequent peering. System Configuration Kernel Because each node may act as a router for other nodes, Linux kernel packet forwarding needs to be enabled. Also, because WireGuard is used, which doesn't forward through physical network cards, the rp_filter strict mode needs to be disabled. echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf echo "net.ipv6.conf.default.forwarding=1" >> /etc/sysctl.conf echo "net.ipv6.conf.all.forwarding=1" >> /etc/sysctl.conf echo "net.ipv4.conf.default.rp_filter=0" >> /etc/sysctl.conf echo "net.ipv4.conf.all.rp_filter=0" >> /etc/sysctl.conf sysctl -p DN42 Virtual Network Interface Because MP-BGP typically uses LLA addresses to establish BGP sessions, we need to set up a dummy network interface in the system and bind the DN42 IP we assigned to this machine. Run the following commands: ip link add dn42 type dummy ip addr add <DN42 IPv4 assigned to this machine> dev dn42 ip addr add <DN42 IPv6 assigned to this machine> dev dn42 If persistent configuration is needed, you can refer to the following three methods: {tabs} {tabs-pane label="systemd-networkd"} tee /etc/systemd/network/10-dn42.netdev > /dev/null <<EOF [NetDev] Name=dn42 Kind=dummy EOF tee /etc/systemd/network/20-dn42.network > /dev/null <<EOF [Match] Name=dn42 [Network] Address=<DN42 IPv4 assigned to this machine>/32 Address=<DN42 IPv6 assigned to this machine>/128 EOF systemctl enable systemd-networkd systemctl restart systemd-networkd {/tabs-pane} {tabs-pane label="netplan"} tee /etc/netplan/99-dn42.yaml > /dev/null <<EOF network: version: 2 renderer: networkd ethernets: dn42: match: name: dn42 addresses: - <DN42 IPv4 assigned to this machine>/32 - "<DN42 IPv6 assigned to this machine>/128" accept-ra: no EOF netplan apply {/tabs-pane} {tabs-pane label="/etc/network/interfaces"} tee -a /etc/network/interfaces > /dev/null <<EOF auto dn42 iface dn42 inet static address <DN42 IPv4 assigned to this machine> netmask 255.255.255.255 iface dn42 inet6 static address <DN42 IPv6 assigned to this machine>/128 EOF ifup dn42 {/tabs-pane} {/tabs} Peering with Other Members A user-friendly option for beginners is Potat0's self-service peering service. For details, refer to his DN42 Network page. Follow the instructions to find his Automatic Peering Bot, register your account with the bot by providing your DN42 ASN, the email recorded in the Maintainer during registration above (this is why it's best to fill in the email during registration, as many verification services use it), and receive the verification code with that email. Then, follow the bot's requirements to establish the peer. Install WireGuard apt install wireguard wireguard-tools -y Note: Modern package managers usually automatically install wireguard-tools when installing wireguard to use the wg-quick command. Generate Key Pair wg genkey | tee privatekey | wg pubkey > publickey Note down the contents of privatekey and publickey, representing the private and public keys respectively. Establishing a Peer Generally, there are two modes for establishing a peer: using MP-BGP (Multiprotocol BGP) and not using MP-BGP. Personally, I find MP-BGP more common because its configuration is relatively simple. The configurations are slightly different, so please refer according to your needs. Using MP-BGP Exchanging Information with the Peer You need to provide the other party with the following information, and you also need to know the other party's corresponding information: Public Key Public IP Address (non-DN42 address) Public WireGuard Port, usually listening on the last 5 digits of the other party's ASN DN42 ASN LLA (Link-Local Address), generally fe80::<last 4 digits of peer's ASN> Whether ENH (Extended Next Hop) is supported. Note: If using v6 to exchange routes without enabling ENH, v4 routes cannot be exchanged. Sometimes the public IP address and public WG port are combined and called the Endpoint. Configuring WireGuard Create a configuration file under /etc/wireguard. The name is arbitrary, but my naming convention is dn42-<last 4 digits of peer's ASN>.conf, where dn42-xxxx is the tunnel name. Fill the file with the following content: [Interface] PrivateKey = <Private key generated in the "Generate Key Pair" section above> ListenPort = <Public WireGuard Listen Port> Table = off Address = <Your LLA Address>/64 PostUp = sysctl -w net.ipv6.conf.%i.autoconf=0 [Peer] PublicKey = <Peer's Public Key> Endpoint = <Peer's Endpoint, i.e., IP:Port> AllowedIPs = 10.0.0.0/8, 172.20.0.0/14, 172.31.0.0/16, fd00::/8, fe00::/8 After editing and saving, run: wg-quick up <Tunnel Name> This will start the WG tunnel. Use wg show <Tunnel Name> to check the connection status. Running wg directly shows the status of all tunnels. If you want the tunnel to start automatically on boot, run: systemctl enable wg-quick@<Tunnel Name> Configuring the Bird2 Peer Section Create a new file <Name>.conf under /etc/bird/peers and fill in the following content: protocol bgp <BGP Session Name> from dnpeers{ neighbor <Peer's LLA Address> % '<WireGuard Tunnel Name>' as <Peer's ASN, without AS prefix>; }; If Extended Next Hop is used (as negotiated during information exchange above), configure: protocol bgp <BGP Session Name> from dnpeers{ neighbor <Peer's LLA Address> % '<WireGuard Tunnel Name>' as <Peer's ASN, without AS prefix>; ipv4{ extended next hop; }; }; Applying Configuration Run birdc configure (or birdc c, equivalent) to reload the Bird configuration, then run birdc show protocols (or birdc s p, equivalent) to view the currently established BGP connections. root@hkg2-202501092021514df2f0:~# birdc show protocols BIRD 2.0.12 ready. Name Proto Table State Since Info device1 Device --- up 07:24:14.255 static1 Static dn42_roa up 07:24:14.255 static2 Static dn42_roa_v6 up 07:24:14.255 kernel1 Kernel master6 up 07:24:14.255 kernel2 Kernel master4 up 07:24:14.255 static3 Static master4 up 07:24:14.255 static4 Static master6 up 07:24:14.255 dn42-0298 BGP --- up 08:03:13.347 Established dn42-1816 BGP --- up 07:53:05.028 Established Not Using MP-BGP Exchanging Information with the Peer You need to provide the other party with the following information, and you also need to know the other party's corresponding information: Public Key Public IP Address (non-DN42 address) Public WireGuard Port, usually listening on the last 5 digits of the other party's ASN DN42 ASN DN42 IP, if exchanging IPv4 routes, an IPv4 address is needed; if exchanging IPv6 routes, an IPv6 address is needed. Sometimes the public IP address and public WG port are combined and called the Endpoint. Configuring WireGuard Create a configuration file under /etc/wireguard. The name is arbitrary, but my naming convention is dn42-<last 4 digits of peer's ASN>.conf, where dn42-xxxx is the tunnel name. Fill the file with the following content: [Interface] PrivateKey = <Private key generated in the "Generate Key Pair" section above> ListenPort = <Public WireGuard Listen Port> Table = off PostUp = ip addr add <LLA>/64 dev %i PostUp = ip addr add <Local DN42 IPv6> dev %i PostUp = ip addr add <Local DN42 IPv4> peer <Peer's DN42 IPv4> dev %i PostUp = sysctl -w net.ipv6.conf.%i.autoconf=0 [Peer] PublicKey = <Peer's Public Key> Endpoint = <Peer's Endpoint, i.e., IP:Port> AllowedIPs = 10.0.0.0/8, 172.20.0.0/14, 172.31.0.0/16, fd00::/8, fe00::/8 After editing and saving, run: wg-quick up <Tunnel Name> This will start the WG tunnel. Use wg show <Tunnel Name> to check the connection status. Running wg directly shows the status of all tunnels. If you want the tunnel to start automatically on boot, run: systemctl enable wg-quick@<Tunnel Name> Configuring the Bird2 Peer Section Create a new file <Name>.conf under /etc/bird/peers and fill in the following content: protocol bgp <v4 BGP Session Name> from dnpeers{ neighbor <Peer's DN42 IPv4 Address> as <Peer's ASN, without AS prefix>; direct; ipv6{ import none; export none; }; }; protocol bgp <v6 BGP Session Name> from dnpeers{ neighbor <Peer's DN42 IPv6 Address> % '<WireGuard Tunnel Name>' as <Peer's ASN, without AS prefix>; direct; ipv4{ import none; export none; }; }; Applying Configuration Run birdc configure (or birdc c, equivalent) to reload the Bird configuration, then run birdc show protocols (or birdc s p, equivalent) to view the currently established BGP connections. At this point, we have successfully joined the DN42 network. To make the network more stable, we can peer with more users, establishing multiple BGP lines to prevent disconnection if some nodes fail. You can join the DN42 Unofficial Telegram Group for more information. If BGP is Established but you cannot Ping internal DN42 IPs, check if the IP set in bird.conf matches the IP assigned to the dummy interface or the local IP in WireGuard. Configuring DNS DN42 has its own public DNS with the anycast address 172.20.0.53, which can also resolve normal internet domains. To access internal domains ending with .dn42, you need to put this address at the top of resolv.conf: nameserver 172.20.0.53 nameserver 223.5.5.5 # Below are normal DNS server configurations After this, you can resolve DN42 internal domain names. Also, commands like ping, traceroute, and mtr will show rDNS resolution results when querying internal IPs. Welcome to peer with me! For details, please visit: iYoRoy DN42 Network References: https://blog.baoshuo.ren/post/dn42-network/ https://dn42.dev/howto/Bird2#example-configuration https://dn42.eu/howto/wireguard https://blog.udon.eu.org/archives/dbf21067.html https://blog.byteloid.one/2025/06/02/babeld-over-wireguard/ https://blog.wcysite.com/2021/%E8%B8%A9%E5%9D%91DN42-p2-peer/ https://blog.chs.pub/p/23-14-joindn42/ https://www.cnblogs.com/FengZeng666/p/15583434.html

Cross-Platform Service Programming Diary Ep.2 - Inter-Process Communication (IPC) Previously The previous article implemented unified log management. This article implements inter-process message communication, i.e., IPC. Analysis Windows On Windows, inter-process communication is primarily achieved through Pipes. Pipes are further divided into Named Pipes and Anonymous Pipes. Anonymous pipes are unidirectional and are typically used for communication between a parent and child process[2]. Named pipes, however, can be unidirectional or duplex and support one-to-many communication[3]. As the name implies, the only way to identify a named pipe is by its name, so two processes can communicate as long as they connect to the named pipe with the same name. We need to achieve bidirectional communication between processes, so we use named pipes. The general idea is: a process starts in server mode (receiver), creates a thread, creates a named pipe, and listens for messages within the pipe. When the pipe is connected, it reads data from it; when a process starts as a sender, it attempts to connect to a pipe with the same name and writes the message content. Linux On Linux, sockets are typically used for inter-process communication. However, unlike listening on a port, IPC usually involves listening on a sock file[5]. Common service applications like the Docker daemon and MySQL use this method. Thus, the general idea is as follows: a process started in server mode creates a socket listener and waits to receive messages from it; the sender connects to the socket and sends a message. Similar to the name of the named pipe mentioned above, the socket maps to a unique .sock file. The sender just needs to open this file to send the message. (In practice, it's not opened in the conventional file manner but using socket-specific methods[5].) Code Implementation Initialization To use a common main codebase, I used the same approach as the previous article, differentiating system types via macro definitions, placing the Windows and Linux code in the header files service-windows.h and service-linux.h respectively: #ifdef _WIN32 #include "service-windows.h" #elif defined(__linux__) #include "service-linux.h" #endif When the receiver process starts, it creates a thread to handle message reception (using std::thread as the multithreading library): thread_bind = std::thread(bind_thread_main); Listener Section Windows On Windows, we simply attempt to read data from a named pipe with a specified name. Because the pipe is set to blocking mode (i.e., PIPE_WAIT is set in the DWORD dwPipeMode parameter of CreateNamedPipe below), ConnectNamedPipe will be blocking, so there's no need to worry about performance loss from constant looping. void bind_thread_main() { while (!exit_requested.load()) { HANDLE hPipe = CreateNamedPipe( PIPE_NAME, PIPE_ACCESS_DUPLEX, PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE | PIPE_WAIT, PIPE_UNLIMITED_INSTANCES, 1024, // Output buffer size 1024, // Input buffer size 0, // Default timeout NULL); if (hPipe == INVALID_HANDLE_VALUE) { service_log.push(LEVEL_WARN, "Failed to create pipe: %d", GetLastError()); continue; } if (ConnectNamedPipe(hPipe, NULL) || GetLastError() == ERROR_PIPE_CONNECTED) { char buffer[1024]; DWORD bytesRead; if (ReadFile(hPipe, buffer, sizeof(buffer) - 1, &bytesRead, NULL)) { buffer[bytesRead] = '\0'; m_queueMsg.push(buffer); service_log.push(LEVEL_VERBOSE, "Message received: %s", buffer); } FlushFileBuffers(hPipe); DisconnectNamedPipe(hPipe); CloseHandle(hPipe); } else { CloseHandle(hPipe); } } } Linux To prevent creation failure, the code attempts to delete any leftover sock file that wasn't cleaned up before creation, i.e., unlink(SOCKET_PATH) in the code. SOCKET_PATH is a global variable defining the path to the socket file. When creating the socket, the family is specified as AF_UNIX, indicating a UNIX socket (the .sock file type; for network sockets it would be AF_INET). The timeval code sets a timeout limit. If the accept function waits longer than the set SOCKET_TIMEOUT (in seconds), it will automatically stop blocking and return an error. After creating the socket, proceed with the normal setup for binding and listening. void bind_thread_main() { unlink(SOCKET_PATH); int server_fd = socket(AF_UNIX, SOCK_STREAM, 0); if (server_fd == -1) { service_log.push(LEVEL_FATAL, "Failed to create socket"); exit_requested.store(true); return; } struct timeval tv; tv.tv_sec = SOCKET_TIMEOUT; tv.tv_usec = 0; setsockopt(server_fd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv)); sockaddr_un addr{}; addr.sun_family = AF_UNIX; strncpy(addr.sun_path, SOCKET_PATH, sizeof(addr.sun_path) - 1); if (bind(server_fd, (sockaddr*)&addr, sizeof(addr)) == -1) { service_log.push(LEVEL_FATAL, "Bind failed"); close(server_fd); exit_requested.store(true); return; } if (listen(server_fd, 5) == -1) { service_log.push(LEVEL_FATAL, "Listen failed"); close(server_fd); exit_requested.store(true); return; } while (!exit_requested.load()) { int client_fd = accept(server_fd, nullptr, nullptr); if (client_fd != -1) { char buffer[1024]; int bytes_read = read(client_fd, buffer, sizeof(buffer) - 1); if (bytes_read > 0) { buffer[bytes_read] = '\0'; m_queueMsg.push(buffer); service_log.push(LEVEL_VERBOSE, "Message received: %s", buffer); } close(client_fd); } else { if (errno == EWOULDBLOCK || errno == EAGAIN) { continue; } service_log.push(LEVEL_WARN, "Failed to accept socket connection"); } } } After reading a message, both code versions save the message to the blocking queue m_queueMsg. Sender Section Windows Open the specified pipe and write the message content: bool send_message(const std::string& msg) { if (!WaitNamedPipe(PIPE_NAME, NMPWAIT_WAIT_FOREVER)) { service_log.push(LEVEL_ERROR, "Failed to find valid pipe: %d", GetLastError()); return false; } HANDLE hPipe = CreateFile( PIPE_NAME, GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL); if (hPipe == INVALID_HANDLE_VALUE) { service_log.push(LEVEL_ERROR, "Failed to connect: %d", GetLastError()); return false; } DWORD bytesWritten; if (WriteFile(hPipe, msg.c_str(), (DWORD)msg.size(), &bytesWritten, NULL)) { service_log.push(LEVEL_VERBOSE, "Message sent: %s", msg.c_str()); CloseHandle(hPipe); return true; } else { service_log.push(LEVEL_ERROR, "Message (%s) send failed: %d", msg.c_str(),GetLastError()); CloseHandle(hPipe); return false; } } Linux Similarly, connect to the socket and send the data: bool send_message(const std::string& msg) { int sock = socket(AF_UNIX, SOCK_STREAM, 0); if (sock == -1) { service_log.push(LEVEL_ERROR, "Failed to create socket"); return false; } sockaddr_un addr{}; addr.sun_family = AF_UNIX; strncpy(addr.sun_path, SOCKET_PATH, sizeof(addr.sun_path) - 1); if (connect(sock, (sockaddr*)&addr, sizeof(addr)) == -1) { service_log.push(LEVEL_ERROR, "Connect failed"); close(sock); return false; } if (write(sock, msg.c_str(), msg.size()) == -1) { service_log.push(LEVEL_ERROR, "Message send failed: %s", msg.c_str()); close(sock); return false; } else { service_log.push(LEVEL_VERBOSE, "Message sent success: %s", msg.c_str()); close(sock); return true; } } Cleanup There's little to clean up on Windows, but on Linux, the socket file needs to be deleted: unlink(SOCKET_PATH); Demo Screenshots Windows Linux Sample code download: IPCTest.zip References: https://learn.microsoft.com/zh-cn/windows/win32/ipc/pipes https://learn.microsoft.com/zh-cn/windows/win32/ipc/anonymous-pipes https://learn.microsoft.com/zh-cn/windows/win32/ipc/named-pipes https://www.cnblogs.com/alantu2018/p/8493809.html https://blog.csdn.net/dog250/article/details/100998838

Enabling Cloudflare SaaS Integration for International Traffic Routing on Your Blog While Cloudflare CDN's performance within mainland China leaves much to be desired, it remains highly capable for serving content to international audiences. However, Cloudflare phased out the traditional CNAME setup method some time ago. This article focuses on achieving a similar outcome using SaaS (SSL for SaaS) integration, which requires a credit card for activation. Prerequisites A valid credit card (with card number, security code) or a linked PayPal account. Note: You will not be charged if you stay under the 100 custom hostname limit. A Fallback Origin Domain – this must be different from your primary domain that visitors use to access your site (a requirement for Cloudflare setup). Your Primary Domain (the domain your visitors use). To implement separate DNS resolution for mainland China and other regions, the primary domain used for normal access should not be added to Cloudflare directly via the usual "Add a Site" method. In this guide, the primary domain is: www.iyoroy.cn, and the fallback domain is: nekonya.cloud. Process Adding the Fallback Domain to Cloudflare Register a Cloudflare account and follow the standard procedure to change your domain's nameservers to Cloudflare's: Select the Free plan: Update your domain's nameservers at your registrar as instructed: Wait for the nameserver changes to propagate. You can then manage the fallback domain's DNS through Cloudflare. Adding Payment Method & Enabling SaaS Inside the Cloudflare dashboard for your fallback domain, navigate to SSL/TLS -> Custom Hostnames. Click Enable Cloudflare for SaaS: Enter your credit card information and save it. Then, proceed to activate the SaaS plan: Creating DNS Record for Fallback Origin & Setting up Custom Hostnames Go to DNS -> Records in your fallback domain's dashboard. Create a new record pointing to your origin server: Here, my fallback origin is cname.nekonya.cloud, using a CNAME record (A or AAAA records are also perfectly valid). Ensure the orange-cloud proxy is enabled to utilize Cloudflare's CDN. Next, go back to SSL/TLS -> Custom Hostnames. In the Fallback Origin field, enter the record you just created (e.g., cname.nekonya.cloud): Click Add Custom Hostname and enter your primary domain that visitors will use: The TXT record method is recommended for Domain Control Validation (DCV), as it allows for DCV Delegation (see the next section). You will now need to verify ownership by adding the provided TXT record(s) to your primary domain's DNS (this example shows a test record for demonstration, as the actual one was already configured): Because we will use DCV delegation for ongoing certificate validation in the next step, do not add the specific certificate validation records here yet. If you were not using DCV delegation, you would add those records now. {alert type="warning"} Note: When adding certificate validation records, avoid refreshing the entire page, as the record contents might change. Use the refresh button within the options panel if needed. {/alert} Once the hostname status changes to Active, you can safely remove the temporary TXT (and potentially CNAME) record(s) you added for the initial verification. Setting up DCV Delegation Locate the DCV Delegation for Custom Hostnamessection further down the same page. Copy the provided CNAME value. Go to your primary domain's DNS management console and add a new CNAME record. Hostname: _acme-challenge.www(This depends on your primary domain. For www.iyoroy.cn, it's _acme-challenge.www. For test.iyoroy.cn, it would be _acme-challenge.test). Value: The value provided by Cloudflare, prefixed with your hostname (e.g., www.iyoroy.cn.xxxxxxxx.dcv.cloudflare.com). Configuring CNAME Record for Traffic Routing In your primary domain's DNS management console, add a CNAME record for the subdomain you are using (e.g., www). Configure your DNS provider's Geolocation or Split DNS features to ensure that: Traffic from outside mainland China resolves to the Fallback Origin you set in Cloudflare (e.g., cname.nekonya.cloud). If everything is configured correctly, you should see both the Certificate Status and Hostname Status as Active in the Custom Hostnames section: Testing confirms that traffic from outside China is now routed through Cloudflare: The DNS management system used in this article is netcccyun/dnsmgr