Blame
Date:
Sun Jan 29 05:00:28 2023 UTC
Message:
Daily backup
01
2023-01-22
jrmu
version=pmwiki-2.2.130 ordered=1 urlencoded=1
02
2023-01-22
jrmu
agent=w3m/0.5.3+git20210102
03
2023-01-22
jrmu
author=jrmu
04
2023-01-22
jrmu
charset=UTF-8
05
2023-01-22
jrmu
csum=
06
2023-01-22
jrmu
ctime=1612258964
07
2023-01-22
jrmu
host=38.87.162.154
08
2023-01-22
jrmu
name=Nsd.Masterslave
09
2023-01-22
jrmu
rev=6
10
2023-01-22
jrmu
targets=Openbsd.FQDN,Openbsd.Base64
11
2023-01-22
jrmu
text=!! Master/Slave Servers%0a%0aInternet RFCs require that each DNS zone have at least two name servers%0ato provide redundancy in case one server goes offline. These two%0aname servers will serve the resource records and need to be kept in%0async. To do this, we can set up a master/slave configuration of%0aour name servers.%0a%0aOne server is chosen to be the master name server, which is the authority%0afor all resource records in the zone file. The other server is chosen to%0abe the slave server, which will mirror the resource records of the%0amaster. The zone master will get its resource records locally, whereas%0athe slave will get its resource records by copying from the master.%0aBoth master and slave are then able to serve records to clients%0athat request name resolution.%0a%0aIn order to replicate the resource records, the master server needs%0ato periodically transfer its resource records to the slave.%0aWhenever there are changes made to the master server's local records,%0ait can issue a '''NOTIFY''' message to slave servers to immediately%0apropagate changes.%0a%0a!! Configure nsd.conf%0a%0aSuppose for a moment we have two servers, ns1.example.com (master with IP 192.168.0.1)%0aand ns2.example.com (slave with IP 172.16.0.1).%0a%0aHere is what you'll need to edit for [[https://man.openbsd.org/nsd.conf|/var/nsd/etc/nsd.conf]] in @@ns1.example.com@@:%0a%0a[@%0a# tsig key example%0akey:%0a name: "tsig1.example.com."%0a algorithm: hmac-sha256%0a secret: "bWVrbWl0YXNkaWdvYXQ="%0a%0azone:%0a name: "example.com"%0a zonefile: "master/example.com"%0a notify: 172.16.0.1 tsig1.example.com.%0a provide-xfr: 172.16.0.1 tsig1.example.com.%0a@]%0a%0aYou will want to replace all appearances of @@example.com@@ with your own zone name, and replace @@192.168.0.1@@ and @@172.16.0.1@@ with your actual IP addresses.%0a%0aFirst, we need to create a tsig key. It's recommended that the key is the same as your domain, with a final period at the end to show that it is a [[openbsd/FQDN|fully qualified domain name]]. For the secret, you must put in the [[openbsd/base64|base64 encoding]] of a random string. Make it longer for more security. When you have a master/slave configuration, a secure transfer of records is necessary, and the tsig key provides that.%0a%0aTo generate a unique secret, run the following command in your shell:%0a%0a[@%0a$ perl -MMIME::Base64 -e 'print encode_base64("YOURSTRINGHERE");'%0a@]%0a%0aReplace YOURSTRINGHERE with your own string to get a base64 encoded string.%0a%0aIf you have not done so already, make sure to create a zone file in /var/nsd/zones/master/example.com. (Note: nsd runs inside a chroot)%0a%0aNext, you'll need to [[https://man.openbsd.org/nsd.conf|/var/nsd/etc/nsd.conf]] for @@ns2.example.com@@ as well:%0a%0a[@%0a# tsig key example%0akey:%0a name: "tsig1.example.com."%0a algorithm: hmac-sha256%0a secret: "bWVrbWl0YXNkaWdvYXQ="%0a%0azone:%0a name: "example.com"%0a zonefile: "slave/example.com"%0a allow-notify: 172.16.0.1 tsig1.example.com.%0a request-xfr: 172.16.0.1 tsig1.example.com.%0a@]%0a%0aThe tsig key block is identical.%0a%0aIn the zone block, @@master@@ is replaced with @@slave@@ for the location of the zonefile, @@notify@@ is replaced with @@allow-notify@@, and @@provide-xfr@@ replaced with @@request-xfr@@.%0a%0aGo ahead now and restart both nameservers if they are not already running:%0a%0a[@%0a$ doas rcctl restart nsd%0a@]%0a%0aYou will want to check /var/log/nsd.log to see if replication succeeded.%0a
12
2023-01-22
jrmu
time=1655620453
13
2023-01-22
jrmu
author:1655620453=jrmu
14
2023-01-22
jrmu
diff:1655620453:1655619495:=46,47c46,47%0a%3c First, we need to create a tsig key. It's recommended that the key is the same as your domain, with a final period at the end to show that it is a [[openbsd/FQDN|fully qualified domain name]]. For the secret, you must put in the [[openbsd/base64|base64 encoding]] of a random string. Make it longer for more security. When you have a master/slave configuration, a secure transfer of records is necessary, and the tsig key provides that.%0a%3c %0a---%0a> First, we need to create a tsig key. When you have a master/slave configuration, a secure transfer of records is necessary, and the tsig key provides that. The secret is a base64 encoded string.%0a> %0a84a85,87%0a> %0a> %0a> It's a good idea to name the key after your domain, with a final period at the end to show that it is a [[openbsd/FQDN|fully qualified domain name]]. For the secret, you must put in the [[openbsd/base64|base64 encoding]] of a random string. Make it longer for more security.%0a
15
2023-01-22
jrmu
host:1655620453=38.87.162.154
16
2023-01-22
jrmu
author:1655619495=jrmu
17
2023-01-22
jrmu
diff:1655619495:1655619230:=56,59c56,57%0a%3c If you have not done so already, make sure to create a zone file in /var/nsd/zones/master/example.com. (Note: nsd runs inside a chroot)%0a%3c %0a%3c Next, you'll need to [[https://man.openbsd.org/nsd.conf|/var/nsd/etc/nsd.conf]] for @@ns2.example.com@@ as well:%0a%3c %0a---%0a> Create a new block in the secondary server config file, as in the example:%0a> %0a61,66d58%0a%3c # tsig key example%0a%3c key:%0a%3c name: "tsig1.example.com."%0a%3c algorithm: hmac-sha256%0a%3c secret: "bWVrbWl0YXNkaWdvYXQ="%0a%3c %0a68,71c60,63%0a%3c name: "example.com"%0a%3c zonefile: "slave/example.com"%0a%3c allow-notify: 172.16.0.1 tsig1.example.com.%0a%3c request-xfr: 172.16.0.1 tsig1.example.com.%0a---%0a> name: "example.net"%0a> zonefile: "slave/example.net"%0a> allow-notify: 10.10.10.10 NOKEY%0a> request-xfr: 10.10.10.10 NOKEY%0a74,79c66,71%0a%3c The tsig key block is identical.%0a%3c %0a%3c In the zone block, @@master@@ is replaced with @@slave@@ for the location of the zonefile, @@notify@@ is replaced with @@allow-notify@@, and @@provide-xfr@@ replaced with @@request-xfr@@.%0a%3c %0a%3c Go ahead now and restart both nameservers if they are not already running:%0a%3c %0a---%0a> you need a secondary server to host the zone, you can do this as follows. Add to the block that describes your master zone, records about the secondary zone as in the example:%0a> %0a> %0a> %0a> Example configuration files for a slave DNS are provided.%0a> %0a81c73,78%0a%3c $ doas rcctl restart nsd%0a---%0a> ## slave zone example%0a> #zone:%0a> # name: "example.net"%0a> # zonefile: "slave/example.net"%0a> # allow-notify: 192.0.2.2 tsig1.example.com.%0a> # request-xfr: 192.0.2.2 tsig1.example.com.%0a84,86c81,88%0a%3c You will want to check /var/log/nsd.log to see if replication succeeded.%0a%3c %0a%3c %0a---%0a> [@%0a> ## tsig key example%0a> key:%0a> name: "example.ircnow.org"%0a> algorithm: hmac-sha256%0a> secret: "bXBjY3B3alVhaDJrYTBSRENtc01RUmNlYmlj"%0a> @]%0a> %0a87a90,118%0a> %0a> %0a> !! Primary and secondary server%0a> !! The zone file for NSD%0a> %0a> The next step is to write the zone files for NSD. First the forward lookup zone example.net:%0a> %0a> [@%0a> ; Domain file from My project%0a> %0a> example.net. 3600 SOA ns.example.net. admin.example.net. (%0a> 2020070701 ; serial YYYYMMDDnn%0a> 10800 ; refresh%0a> 3600 ; retry%0a> 604800 ; expire%0a> 86400 ) ; minimum TTL%0a> %0a> example.net. NS ns.example.net.%0a> example.net. NS ns.secondary.net.%0a> ns A 10.10.10.10%0a> example.net. A 10.10.10.10%0a> www A 10.10.10.10%0a> irc A 10.10.10.10%0a> imap A 10.10.10.10%0a> smtp A 10.10.10.10%0a> example.net. mx 10 smtp.example.net.%0a> @]%0a> %0a> Save this zone file as /var/nsd/zones/master/example.net%0a
18
2023-01-22
jrmu
host:1655619495=38.87.162.154
19
2023-01-22
jrmu
author:1655619230=jrmu
20
2023-01-22
jrmu
diff:1655619230:1655619036:=48c48%0a%3c To generate a unique secret, run the following command in your shell:%0a---%0a> To generate a unique secret, run the following code:%0a
21
2023-01-22
jrmu
host:1655619230=38.87.162.154
22
2023-01-22
jrmu
author:1655619036=jrmu
23
2023-01-22
jrmu
diff:1655619036:1655618385:=23,29c23,24%0a%3c !! Configure nsd.conf%0a%3c %0a%3c Suppose for a moment we have two servers, ns1.example.com (master with IP 192.168.0.1)%0a%3c and ns2.example.com (slave with IP 172.16.0.1).%0a%3c %0a%3c Here is what you'll need to edit for [[https://man.openbsd.org/nsd.conf|/var/nsd/etc/nsd.conf]] in @@ns1.example.com@@:%0a%3c %0a---%0a> Example configuration files for a slave DNS are provided.%0a> %0a31c26,35%0a%3c # tsig key example%0a---%0a> ## slave zone example%0a> #zone:%0a> # name: "example.net"%0a> # zonefile: "slave/example.net"%0a> # allow-notify: 192.0.2.2 tsig1.example.com.%0a> # request-xfr: 192.0.2.2 tsig1.example.com.%0a> @]%0a> %0a> [@%0a> ## tsig key example%0a33,41c37,39%0a%3c name: "tsig1.example.com."%0a%3c algorithm: hmac-sha256%0a%3c secret: "bWVrbWl0YXNkaWdvYXQ="%0a%3c %0a%3c zone:%0a%3c name: "example.com"%0a%3c zonefile: "master/example.com"%0a%3c notify: 172.16.0.1 tsig1.example.com.%0a%3c provide-xfr: 172.16.0.1 tsig1.example.com.%0a---%0a> name: "example.ircnow.org"%0a> algorithm: hmac-sha256%0a> secret: "bXBjY3B3alVhaDJrYTBSRENtc01RUmNlYmlj"%0a44,49c42,48%0a%3c You will want to replace all appearances of @@example.com@@ with your own zone name, and replace @@192.168.0.1@@ and @@172.16.0.1@@ with your actual IP addresses.%0a%3c %0a%3c First, we need to create a tsig key. When you have a master/slave configuration, a secure transfer of records is necessary, and the tsig key provides that. The secret is a base64 encoded string.%0a%3c %0a%3c To generate a unique secret, run the following code:%0a%3c %0a---%0a> It's a good idea to name the key after your domain, with a final period at the end to show that it is a [[openbsd/FQDN|fully qualified domain name]]. For the secret, you must put in the [[openbsd/base64|base64 encoding]] of a random string. Make it longer for more security.%0a> %0a> %0a> !! Primary and secondary server%0a> %0a> If you need a secondary server to host the zone, you can do this as follows. Add to the block that describes your master zone, records about the secondary zone as in the example:%0a> %0a51c50,54%0a%3c $ perl -MMIME::Base64 -e 'print encode_base64("YOURSTRINGHERE");'%0a---%0a> zone:%0a> name: "example.net"%0a> zonefile: "master/example.net"%0a> notify: 20.20.20.20 NOKEY%0a> provide-xfr: 20.20.20.20 NOKEY%0a54,55d56%0a%3c Replace YOURSTRINGHERE with your own string to get a base64 encoded string.%0a%3c %0a66,92d66%0a%3c you need a secondary server to host the zone, you can do this as follows. Add to the block that describes your master zone, records about the secondary zone as in the example:%0a%3c %0a%3c %0a%3c %0a%3c Example configuration files for a slave DNS are provided.%0a%3c %0a%3c [@%0a%3c ## slave zone example%0a%3c #zone:%0a%3c # name: "example.net"%0a%3c # zonefile: "slave/example.net"%0a%3c # allow-notify: 192.0.2.2 tsig1.example.com.%0a%3c # request-xfr: 192.0.2.2 tsig1.example.com.%0a%3c @]%0a%3c %0a%3c [@%0a%3c ## tsig key example%0a%3c key:%0a%3c name: "example.ircnow.org"%0a%3c algorithm: hmac-sha256%0a%3c secret: "bXBjY3B3alVhaDJrYTBSRENtc01RUmNlYmlj"%0a%3c @]%0a%3c %0a%3c It's a good idea to name the key after your domain, with a final period at the end to show that it is a [[openbsd/FQDN|fully qualified domain name]]. For the secret, you must put in the [[openbsd/base64|base64 encoding]] of a random string. Make it longer for more security.%0a%3c %0a%3c %0a%3c !! Primary and secondary server%0a
24
2023-01-22
jrmu
host:1655619036=38.87.162.154
25
2023-01-22
jrmu
author:1655618385=jrmu
26
2023-01-22
jrmu
diff:1655618385:1612258964:=0a1%0a> %0a2,23d2%0a%3c %0a%3c Internet RFCs require that each DNS zone have at least two name servers%0a%3c to provide redundancy in case one server goes offline. These two%0a%3c name servers will serve the resource records and need to be kept in%0a%3c sync. To do this, we can set up a master/slave configuration of%0a%3c our name servers.%0a%3c %0a%3c One server is chosen to be the master name server, which is the authority%0a%3c for all resource records in the zone file. The other server is chosen to%0a%3c be the slave server, which will mirror the resource records of the%0a%3c master. The zone master will get its resource records locally, whereas%0a%3c the slave will get its resource records by copying from the master.%0a%3c Both master and slave are then able to serve records to clients%0a%3c that request name resolution.%0a%3c %0a%3c In order to replicate the resource records, the master server needs%0a%3c to periodically transfer its resource records to the slave.%0a%3c Whenever there are changes made to the master server's local records,%0a%3c it can issue a '''NOTIFY''' message to slave servers to immediately%0a%3c propagate changes.%0a%3c %0a%3c Example configuration files for a slave DNS are provided.%0a
27
2023-01-22
jrmu
host:1655618385=38.87.162.154
28
2023-01-22
jrmu
author:1612258964=jrmu
29
2023-01-22
jrmu
diff:1612258964:1612258964:=1,71d0%0a%3c %0a%3c !! Master/Slave Servers%0a%3c %0a%3c [@%0a%3c ## slave zone example%0a%3c #zone:%0a%3c # name: "example.net"%0a%3c # zonefile: "slave/example.net"%0a%3c # allow-notify: 192.0.2.2 tsig1.example.com.%0a%3c # request-xfr: 192.0.2.2 tsig1.example.com.%0a%3c @]%0a%3c %0a%3c [@%0a%3c ## tsig key example%0a%3c key:%0a%3c name: "example.ircnow.org"%0a%3c algorithm: hmac-sha256%0a%3c secret: "bXBjY3B3alVhaDJrYTBSRENtc01RUmNlYmlj"%0a%3c @]%0a%3c %0a%3c It's a good idea to name the key after your domain, with a final period at the end to show that it is a [[openbsd/FQDN|fully qualified domain name]]. For the secret, you must put in the [[openbsd/base64|base64 encoding]] of a random string. Make it longer for more security.%0a%3c %0a%3c %0a%3c !! Primary and secondary server%0a%3c %0a%3c If you need a secondary server to host the zone, you can do this as follows. Add to the block that describes your master zone, records about the secondary zone as in the example:%0a%3c %0a%3c [@%0a%3c zone:%0a%3c name: "example.net"%0a%3c zonefile: "master/example.net"%0a%3c notify: 20.20.20.20 NOKEY%0a%3c provide-xfr: 20.20.20.20 NOKEY%0a%3c @]%0a%3c %0a%3c Create a new block in the secondary server config file, as in the example:%0a%3c %0a%3c [@%0a%3c zone:%0a%3c name: "example.net"%0a%3c zonefile: "slave/example.net"%0a%3c allow-notify: 10.10.10.10 NOKEY%0a%3c request-xfr: 10.10.10.10 NOKEY%0a%3c @]%0a%3c %0a%3c !! The zone file for NSD%0a%3c %0a%3c The next step is to write the zone files for NSD. First the forward lookup zone example.net:%0a%3c %0a%3c [@%0a%3c ; Domain file from My project%0a%3c %0a%3c example.net. 3600 SOA ns.example.net. admin.example.net. (%0a%3c 2020070701 ; serial YYYYMMDDnn%0a%3c 10800 ; refresh%0a%3c 3600 ; retry%0a%3c 604800 ; expire%0a%3c 86400 ) ; minimum TTL%0a%3c %0a%3c example.net. NS ns.example.net.%0a%3c example.net. NS ns.secondary.net.%0a%3c ns A 10.10.10.10%0a%3c example.net. A 10.10.10.10%0a%3c www A 10.10.10.10%0a%3c irc A 10.10.10.10%0a%3c imap A 10.10.10.10%0a%3c smtp A 10.10.10.10%0a%3c example.net. mx 10 smtp.example.net.%0a%3c @]%0a%3c %0a%3c Save this zone file as /var/nsd/zones/master/example.net%0a
30
2023-01-22
jrmu
host:1612258964=198.251.81.119
IRCNow