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#

August 3, 2025: First edition published.
March 15, 2026: Update typos. Thanks to @Auride.

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#

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.

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:

1
systemctl stop systemd-resolved
2
systemctl disable systemd-resolved
3
unlink /etc/resolv.conf
4
echo "nameserver 8.8.8.8" > /etc/resolv.conf

I am using Debian 12, so I’ll use APT for installation:

1
apt install knot knot-dnsutils -y

Set KnotDNS to start automatically:

1
systemctl enable knot

Configuring KnotDNS#

Creating a Key#

First, create a key for synchronization:

1
keymgr -t key_knsupdate

Copy the output:

1
# hmac-sha256:key_knsupdate:<your secret>
2
key:
3
  - id: key_knsupdate
4
    algorithm: hmac-sha256
5
    secret: <your secret>

Editing the Configuration File#

Master Node#

Edit /etc/knot/knot.conf and fill in the following content:

1
server:
2
    rundir: "/run/knot"
3
    user: knot:knot
4
    automatic-acl: on
5
    listen: [ <listen_address1>@53, <listen_address2>@53, ... ]
6

7
log:
8
  - target: syslog
9
    any: info
10

11
database:
12
    storage: "/var/lib/knot"
13

14
### Paste the Key generated in the previous step here
15
# hmac-sha256:key_knsupdate:<your secret>
16
key:
17
  - id: key_knsupdate
18
    algorithm: hmac-sha256
19
    secret: <your secret>
20

21
remote:
22
  - id: <DNS_Node_1_ID>
23
    address: <DNS_Node_1_IP>@53
24

25
  - id: <DNS_Node_2_ID>
26
    address: <DNS_Node_2_IP>@53
27

28
  - id: <DNS_Node_3_ID>
29
    address: <DNS_Node_3_IP>@53
30

31
acl:
32
  - id: acl_slave
33
    key: key_knsupdate
34
    action: transfer
35

36
  - id: acl_master
37
    key: key_knsupdate
38
    action: notify
39

40
  - id: acl_knsupdate
41
    key: key_knsupdate
42
    action: update
43

44
template:
45
  - id: default
46
    storage: "/var/lib/knot"
47
    file: "%s.zone"
48

49
zone:
50
  - domain: <DN42 Domain>
51
    notify: [ <Slave_Node_1_ID>, <Slave_Node_2_ID> ]
52
    acl: [ acl_slave, acl_knsupdate ]
53
  - domain: <IPv4 Reverse Lookup Domain>
54
    notify: [ <Slave_Node_1_ID>, <Slave_Node_2_ID> ]
55
    acl: [ acl_slave, acl_knsupdate ]
56
  - domain: <IPv6 Reverse Lookup Domain>
57
    notify: [ <Slave_Node_1_ID>, <Slave_Node_2_ID> ]
58
    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.

Example

1
server:
2
    rundir: "/run/knot"
3
    user: knot:knot
4
    automatic-acl: on
5
    listen: [ 172.20.234.225@53, fd18:3e15:61d0::1@53, localhost@53, 127.0.0.1@53 ]
6

7
log:
8
  - target: syslog
9
    any: info
10

11
database:
12
    storage: "/var/lib/knot"
13

14
# hmac-sha256:key_knsupdate:<key>
15
key:
16
  - id: key_knsupdate
17
    algorithm: hmac-sha256
18
    secret: <key>
19

20
remote:
21
  - id: 225 # Master Node
22
    address: 172.20.234.225@53
23

24
  - id: 227 # Slave Node
25
    address: 172.20.234.227@53
26

27
  - id: 229 # Slave Node
28
    address: 172.20.234.229@53
29

30
acl:
31
  - id: acl_slave
32
    key: key_knsupdate
33
    action: transfer
34

35
  - id: acl_master
36
    key: key_knsupdate
37
    action: notify
38

39
  - id: acl_knsupdate
40
    key: key_knsupdate
41
    action: update
42

43
template:
44
  - id: default
45
    storage: "/var/lib/knot"
46
    file: "%s.zone"
47

48
zone:
49
  - domain: yori.dn42
50
    notify: [ 227, 229 ]
51
    acl: [ acl_slave, acl_knsupdate ]
52
  - domain: 224/28.234.20.172.in-addr.arpa
53
    notify: [ 227, 229 ]
54
    acl: [ acl_slave, acl_knsupdate ]
55
  - domain: 0.d.1.6.5.1.e.3.8.1.d.f.ip6.arpa
56
    notify: [ 227, 229 ]
57
    acl: [ acl_slave, acl_knsupdate ]

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:

1
--- a/knot.conf
2
+++ b/knot.conf
3
 zone:
4
   - domain: <DN42 Domain>
5
-    notify: [ <Slave_Node_1_ID>, <Slave_Node_2_ID> ]
6
-    acl: [ acl_slave, acl_knsupdate ]
7
+    master: <Master_Node_ID>
8
+    zonefile-load: whole
9
+    acl: acl_master
10
   - domain: <IPv4 Reverse Lookup Domain>
11
-    notify: [ <Slave_Node_1_ID>, <Slave_Node_2_ID> ]
12
-    acl: [ acl_slave, acl_knsupdate ]
13
+    master: <Master_Node_ID>
14
+    zonefile-load: whole
15
+    acl: acl_master
16
   - domain: <IPv6 Reverse Lookup Domain>
17
-    notify: [ <Slave_Node_1_ID>, <Slave_Node_2_ID> ]
18
-    acl: [ acl_slave, acl_knsupdate ]
19
+    master: <Master_Node_ID>
20
+    zonefile-load: whole
21
+    acl: acl_master

The Master Node ID is the ID set in the remote section for the server you designated as the master node.

Examp;e

1
server:
2
    rundir: "/run/knot"
3
    user: knot:knot
4
    automatic-acl: on
5
    listen: [ 172.20.234.227@53, fd18:3e15:61d0::3@53, localhost@53, 127.0.0.1@53 ]
6

7
log:
8
  - target: syslog
9
    any: info
10

11
database:
12
    storage: "/var/lib/knot"
13

14
# hmac-sha256:key_knsupdate:<key>
15
key:
16
  - id: key_knsupdate
17
    algorithm: hmac-sha256
18
    secret: <key>
19

20
remote:
21
  - id: 225
22
    address: 172.20.234.225@53
23

24
  - id: 227
25
    address: 172.20.234.227@53
26

27
  - id: 229
28
    address: 172.20.234.229@53
29

30
acl:
31
  - id: acl_slave
32
    key: key_knsupdate
33
    action: transfer
34

35
  - id: acl_master
36
    key: key_knsupdate
37
    action: notify
38

39
  - id: acl_knsupdate
40
    key: key_knsupdate
41
    action: update
42

43
template:
44
  - id: default
45
    storage: "/var/lib/knot"
46
    file: "%s.zone"
47

48
zone:
49
  - domain: yori.dn42
50
    master: 225
51
    zonefile-load: whole
52
    acl: acl_master
53
  - domain: 224/28.234.20.172.in-addr.arpa
54
    master: 225
55
    zonefile-load: whole
56
    acl: acl_master
57
  - domain: 0.d.1.6.5.1.e.3.8.1.d.f.ip6.arpa
58
    master: 225
59
    zonefile-load: whole
60
    acl: acl_master

After writing the configuration file, run the following command to restart KnotDNS:

1
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:

1
@ <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 i@iyoroy.cn, 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.

Examp;e

1
; SOA
2
@ 3600 SOA ns1.yori.dn42. i.iyoroy.cn. 2025072705 60 60 1800 60

NS Records#

1
@ <TTL> NS <NS_Server_1>
2
@ <TTL> NS <NS_Server_2>
3
@ <TTL> NS <NS_Server_3>

Fill this in according to your actual situation; add as many records as you have servers.

Example

1
; NS
2
@ 3600 NS ns1.yori.dn42.
3
@ 3600 NS ns2.yori.dn42.
4
@ 3600 NS ns3.yori.dn42.

A, AAAA, CNAME, etc. Records#

Fill them in according to the following format:

1
<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.

Example

1
; A
2
ns1 600 A 172.20.234.225
3
ns2 600 A 172.20.234.227
4
ns3 600 A 172.20.234.229
5
hkg-cn.node 600 A 172.20.234.225
6
nkg-cn.node 600 A 172.20.234.226
7
tyo-jp.node 600 A 172.20.234.227
8
hfe-cn.node 600 A 172.20.234.228
9
lax-us.node 600 A 172.20.234.229
10

11
; AAAA
12
ns1 600 AAAA fd18:3e15:61d0::1
13
ns2 600 AAAA fd18:3e15:61d0::3
14
ns3 600 AAAA fd18:3e15:61d0::5
15
hkg-cn.node 600 AAAA fd18:3e15:61d0::1
16
nkg-cn.node 600 AAAA fd18:3e15:61d0::2
17
tyo-jp.node 600 AAAA fd18:3e15:61d0::3
18
hfe-cn.node 600 AAAA fd18:3e15:61d0::4
19
lax-us.node 600 AAAA fd18:3e15:61d0::5

Complete Example

/var/lib/knot/yori.dn42.zone

1
; SOA
2
@ 3600 SOA ns1.yori.dn42. i.iyoroy.cn. 2025072705 60 60 1800 60
3

4
; NS
5
@ 3600 NS ns1.yori.dn42.
6
@ 3600 NS ns2.yori.dn42.
7
@ 3600 NS ns3.yori.dn42.
8

9
; A
10
ns1 600 A 172.20.234.225
11
ns2 600 A 172.20.234.227
12
ns3 600 A 172.20.234.229
13
hkg-cn.node 600 A 172.20.234.225
14
nkg-cn.node 600 A 172.20.234.226
15
tyo-jp.node 600 A 172.20.234.227
16
hfe-cn.node 600 A 172.20.234.228
17
lax-us.node 600 A 172.20.234.229
18

19
; AAAA
20
ns1 600 AAAA fd18:3e15:61d0::1
21
ns2 600 AAAA fd18:3e15:61d0::3
22
ns3 600 AAAA fd18:3e15:61d0::5
23
hkg-cn.node 600 AAAA fd18:3e15:61d0::1
24
nkg-cn.node 600 AAAA fd18:3e15:61d0::2
25
tyo-jp.node 600 AAAA fd18:3e15:61d0::3
26
hfe-cn.node 600 AAAA fd18:3e15:61d0::4
27
lax-us.node 600 AAAA fd18:3e15:61d0::5

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:

1
; SOA
2
@ <TTL> SOA <Primary_NS_Server_Address> <Contact_Email> <Serial_Number> <Refresh_Time> <Retry_Time> <Expire_Time> <Minimum_TTL>
3

4
; NS
5
@ <TTL> NS <NS_Server_1>
6
@ <TTL> NS <NS_Server_2>
7
@ <TTL> NS <NS_Server_3>
8

9
; PTR
10
<Last_IPv4_Octet> <TTL> PTR <Reverse_DNS_Value>
11
<Last_IPv4_Octet> <TTL> PTR <Reverse_DNS_Value>
12
<Last_IPv4_Octet> <TTL> PTR <Reverse_DNS_Value>
13
...

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.

Example

224_28.234.20.172.in-addr.arpa.zone

1
; SOA
2
@ 3600 SOA ns1.yori.dn42. i.iyoroy.cn. 2025072802 60 60 1800 60
3

4
; NS
5
@ 3600 NS ns1.yori.dn42.
6
@ 3600 NS ns2.yori.dn42.
7
@ 3600 NS ns3.yori.dn42.
8

9
; PTR
10
225 600 PTR hkg-cn.node.yori.dn42.
11
226 600 PTR nkg-cn.node.yori.dn42.
12
227 600 PTR tyo-jp.node.yori.dn42.
13
228 600 PTR hfe-cn.node.yori.dn42.
14
229 600 PTR lax-us.node.yori.dn42.

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:

1
~$ dig PTR 225.234.20.172.in-addr.arpa  +short
2
225.224/28.234.20.172.in-addr.arpa.  # <-- CNAME added by Registry (redirect)
3
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:

1
; SOA
2
@ <TTL> SOA <Primary_NS_Server_Address> <Contact_Email> <Serial_Number> <Refresh_Time> <Retry_Time> <Expire_Time> <Minimum_TTL>
3

4
; NS
5
@ <TTL> NS <NS_Server_1>
6
@ <TTL> NS <NS_Server_2>
7
@ <TTL> NS <NS_Server_3>
8

9
; PTR
10
<Reversed_Last_20_Nibbles> <TTL> PTR <Reverse_DNS_Value>
11
<Reversed_Last_20_Nibbles> <TTL> PTR <Reverse_DNS_Value>
12
<Reversed_Last_20_Nibbles> <TTL> PTR <Reverse_DNS_Value>
13
...

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.

Example

0.d.1.6.5.1.e.3.8.1.d.f.ip6.arpa.zone

1
; SOA
2
@ 3600 SOA ns1.yori.dn42. i.iyoroy.cn. 2025072802 60 60 1800 60
3

4
; NS
5
@ 3600 NS ns1.yori.dn42.
6
@ 3600 NS ns2.yori.dn42.
7
@ 3600 NS ns3.yori.dn42.
8

9
; PTR
10
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.
11
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.
12
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.
13
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.
14
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.

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:

1
domain:             <your_desired_domain>
2
admin-c:            <Admin_NIC_Handle>
3
tech-c:             <Tech_NIC_Handle>
4
mnt-by:             <Maintainer>
5
nserver:            <NS1_Server_Domain> <NS1_Server_IP>
6
nserver:            <NS2_Server_Domain> <NS2_Server_IP>
7
nserver:            <NS3_Server_Domain> <NS3_Server_IP>
8
...
9
source:             DN42

Refer to DN42 - Ep.1 Joining the DN42 Network for admin-c, tech-c, and mnt-by.

Example

data/dns/yori.dn42

1
domain:             yori.dn42
2
admin-c:            IYOROY-DN42
3
tech-c:             IYOROY-DN42
4
mnt-by:             IYOROY-MNT
5
nserver:            ns1.yori.dn42 172.20.234.225
6
nserver:            ns1.yori.dn42 fd18:3e15:61d0::1
7
nserver:            ns2.yori.dn42 172.20.234.227
8
nserver:            ns2.yori.dn42 fd18:3e15:61d0::3
9
nserver:            ns3.yori.dn42 172.20.234.229
10
nserver:            ns3.yori.dn42 fd18:3e15:61d0::5
11
source:             DN42

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:

1
nserver:            <your_DNS_server_address>
2
nserver:            <your_DNS_server_address>
3
...
4
...

Example

1
diff --git a/data/inetnum/172.20.234.224_28 b/data/inetnum/172.20.234.224_28
2
index 50c800945..5ad60e23d 100644
3
--- a/data/inetnum/172.20.234.224_28
4
+++ b/data/inetnum/172.20.234.224_28
5
@@ -8,3 +8,6 @@ tech-c:             IYOROY-DN42
6
 mnt-by:             IYOROY-MNT
7
 status:             ASSIGNED
8
 source:             DN42
9
+nserver:            ns1.yori.dn42
10
+nserver:            ns2.yori.dn42
11
+nserver:            ns3.yori.dn42

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:

1
nserver:            <your_DNS_server_address>
2
nserver:            <your_DNS_server_address>
3
...

Example

1
diff --git a/data/inet6num/fd18:3e15:61d0::_48 b/data/inet6num/fd18:3e15:61d0::_48
2
index 53f0de06d..1ae067b00 100644
3
--- a/data/inet6num/fd18:3e15:61d0::_48
4
+++ b/data/inet6num/fd18:3e15:61d0::_48
5
@@ -8,3 +8,6 @@ tech-c:             IYOROY-DN42
6
 mnt-by:             IYOROY-MNT
7
 status:             ASSIGNED
8
 source:             DN42
9
+nserver:            ns1.yori.dn42
10
+nserver:            ns2.yori.dn42
11
+nserver:            ns3.yori.dn42

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: