Install, configure OpenDNSSEC 1.3.x and 1.4.1, NSD, FreeBSD 9.2
What is and why OpenDNSSEC is information on the network. Detailed information on this topic a bit and mostly in English. I'll try to fill the gap. I myself am not an expert in this field, it was interesting, wanted, done.
The article was written simultaneously with the installation / configuration of OpenDNSSEC. In total, it took about a month. The procedure was performed twice. First, OpenDNSSEC 1.3 was installed. The zones are signed, the anchor of the domain registrar (RD) is registered, the chain of trust is built, as reported in the personal account of the domain registrar (RD), in general, everything turned out. Six months later, as a result of the next manual update of the ports, the port of OpenDNSSEC 1.3.x was automatically updated to 1.4.1, and there are a lot of other things. But everything, of course, continued to work without any hint of a problem. Discovered by chance when a change was required in the DNS zone. And so it began ...
We assume that the NSD DNS server is configured, it works for several years, everything is in order.
Version 1.4 did not manage to be configured for a long time, keys did not appear, zones did not subscribe. The package was installed with the support of MySql55. On the official site, while listing officially supported OSs for 1.4, FreeBSD 9.0 was announced. It was unlikely that there was a reason (the reason was not the case), but it was updated on every basis from FreeBSD 8.2 to 9.1. From ignorance of the nuances I even suggested that the already built chain of trust was interfering. Therefore, in the personal account of RD broke the chain of trust. And set up NSD to work with unsigned zones. Trying to convert an existing SQLite2 database into SQLite3 did not. It was decided to re-do everything and use MySql55, as recommended.
')
In general, the picture most likely looks like this: NSD both served the zones and served them. NSD and Opendnssec are in no way connected with each other. Opendnssec is a handy gadget for automating the zone signing process. Opendnssec takes existing, unsigned NSD server zone files and signs / re-signing them at specified intervals. After automatic re-signing, Opendnssec restarts NSD. Further NSD uses already signed zone files. And DNSSEC in NSD is included automatically. NSD itself recognizes signed zone files. One moment is not clear: in the personal account of the RD (domain registrar) you need to register some keys, the so-called anchors. Will it be necessary to edit them manually later when the zones are automatically re-signed with new keys? I will assume of course that there will be no problems.
Looking ahead: c MySql OpenDNSSEC could not be configured. Exactly found out that the problem is connected with the database, or with the interaction between the database and OpenDNSSEC. OpenDNSSEC can work with both SQLite and MySql. Returned to SQLite3 everything went right there and no questions asked. On the official website, SQLite3 is recommended only for test applications. I will assume that MySql is recommended if there are many, thousands of files and records in them. For the case of a test server decided to use SQLite. Thus, all of the following, related to MySql, is not used. But for just this information left. Below is a schematic picture describing what is happening. The picture is taken from the official OpenDNSSEC documentation site.
Secondary DNS servers do not require any action on themselves, however, you need to make sure that the secondary server also supports DNSSEC. The RD, which was ordered to have two secondary DNS at one time, is all supported.
There are 2 pairs of keys:
The first pair - ZSK is used to sign the zone file.
The second pair, KSK, is used to sign the ZSK key and generate DS records that are transmitted to the administrator of the parent zone (in the current case of the PD). It is recommended to change KSK once a year, ZSK up to once a month.
The installation of both 1.3 and 1.4 versions of OpenDNSSEC overlaps. When using SQLite2 and 3 databases there were no problems. With MySql55 setup failed. After everything worked with SQLite3, the search for the reasons why there were problems with MySql was postponed until the next time. Again, SQLite is recommended for testing only.
I cite everything as it was, so at first it is desirable to see how it ended, and then repeat. Yes, if you install only OpenDNSSEC 1.4.1, the article would be two times shorter. But I think that redundancy of information will better help to understand if there are any nuances. As they say, a gift to rewriters. If you automatically had an OpenDNSSEC update from the old version to 1.4.1, then it is advisable to transfer OpenDNSSEC to a backup folder and reinstall it. Configuration files will be different. And the old ones, for obvious reasons, are not overwritten.
When installing the opendnssec port, we do not do make clean, some files will be needed for configuration.
# cd / usr / ports / dns / opendnssec
# make
===> opendnssec-1.3.13 is marked as broken: does not work with ruby ​​1.9.
*** Error code 1
Install the port / usr / ports / lang / ruby18, because Since 1.9, the opendnssec port has compatibility problems, namely, an error occurs when the AUDITOR flag is on.
In general, install / reinstall the ruby18 port.
Next, look at the file / usr / ports / UPDATING, which says what about ruby1.8 and 1.9. In general, to use version 1.8, you need to add the following lines to the /etc/make.conf file:
#
# Keep ruby ​​1.8 as default version.
#
RUBY_DEFAULT_VER = 1.8
Reboot and then retry the installation:
# cd / usr / ports / dns / opendnssec
# make config - make sure all flags are checked
# make && make install && make clean
[x] AUDITOR Build with Auditor
[] MYSQL MySQL database support
[x] SOFTHSM Build / update SOFTHSM as well
In OpenDNSSEC 1.4.1, this problem does not occur, there is no longer used by AUDITOR, which used ruby. Ruby is not used at all. Of the 2 options offered during installation, one MySql was selected. I repeat that it didn’t start with MySql, for OpenDNSSEC 1.4.1 we’ll select the second of the two checkboxes, respectively.
In the file /usr/local/etc/nsd/nsd.conf, we change:
zonesdir: “/ usr / local / var / opendnssec / signed”
and all zonefile entries:
zonefile: "/usr/local/var/opendnssec/signed/zone1.ru"
zonefile: "/usr/local/var/opendnssec/signed/zone2.ru"
...
zonefile: "/usr/local/var/opendnssec/signed/zoneN.ru"
Create links:
# cd / usr / local / etc / nsd
# ln -s / usr / local / var / opendnssec / unsigned.
# ln -s / usr / local / var / opendnssec / signed.
Copy existing, working, unsigned NSD server zone files from / usr / local / etc / nsd / zones / master to / usr / local / etc / nsd / ~ unsigned.
# chown -R opendnssec: opendnssec / usr / local / var / opendnssec / unsigned
Initializing SoftHSM database with the label “OpenDNSSEC” using the SO PIN <pin code> and USER PIN <the same pin code>
If there is no / usr / local / var / lib / softhsm folder for any reason, then install / reinstall the port:
# cd / usr / ports / security / softhsm
# make && make install && make clean
Set permissions on the softhsm folder, by default they are 700:
# chmod 0755 / usr / local / var / lib / softhsm
We invent / enter / remember 2 PIN codes. Let it be the same:
# softhsm --init-token --slot 0 --label "OpenDNSSEC"
The PIN PIN must have a length between 4 and 255 characters.
Enter SO PIN:
The PIN must be a length between 4 and 255 characters.
Enter user PIN:
The token has been initialized.
In the /usr/local/etc/opendnssec/conf.xml file, delete the line
Pin code will be entered manually. Or leave, the PIN code will be substituted automatically.
It should turn out like this:
For 1.4.1 Install MySql55 server and client. SQLite3 is recommended for testing purposes only.
After installing MySql55, it is necessary, depending on the expected load on the server, to select one of the configuration files located in / usr / local / share / mysql, and copy it to / var / db / mysql. And accordingly in /etc/rc.conf should be:
nsd_enable = "YES"
opendnssec_enable = "YES"
mysql_enable = "YES"
To automatically create the necessary database structure, use the file:
/usr/ports/dns/opendnssec/work/opendnssec-1.4.1/enforcer/utils/database_create.mysql
# mysql
> create database kasp;
> CREATE USER 'ksuser' @ 'localhost' IDENTIFIED BY 'password';
> GRANT ALL PRIVILEGES ON kasp. * TO 'ksuser' @ 'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION;
> flush privileges;
> quit
If after flush privileges; there will be a mistake
ERROR 1146 (42S02): Table 'mysql.servers' does not exist
We try this way here with the password:
# mysqlcheck --check-upgrade --all-databases - auto-repair -p
Enter password:
And then
# mysql_upgrade --force -p
Enter password:
At one time it helped.
We adjusted the created database.
# mysql kasp </usr/ports/dns/opendnssec/work/opendnssec-1.4.1/enforcer/utils/database_create.mysql
# mysql
> USE kasp;
> SHOW TABLES;
+ ----------------------------- +
| Tables_in_kasp |
+ ----------------------------- +
| INT_KEYALLOC_VIEW_FOR_MYSQL |
| KEYALLOC_VIEW |
| KEYDATA_VIEW |
| PARAMETER_LIST |
| PARAMETER_VIEW |
| categories |
| dbadmin |
| dnsseckeys |
| keypairs |
| parameters |
| parameters_policies |
| policies |
| securitymodules |
| serialmodes |
| zones |
+ ----------------------------- +
15 rows in set (0.01 sec)
> quit
In / usr / local / etc / opendnssec there will be default configuration files created during installation.
In /usr/local/etc/opendnssec/conf.xml we correct:
<Host is the name of the system where the database is installed. The parameter is optional; if not specified, the database is associated with the system where OpenDNSSEC is installed. Port it is clear what. The parameter is optional, the default is 3306.
<Database Database.
<Username Database user.
<Password Respectively password.
In /usr/local/etc/opendnssec/conf.xml should be:
We check for it like this:
For sekurnosti pin code is not registered here. It will be entered manually, although it is easier to leave it in place.
Pay attention to the record:
Enter the data of the configuration files in the database
# ods-ksmutil setup
* WARNING * This will erase all data in the database; are you sure? [y / n] y
zonelist filename set to /usr/local/etc/opendnssec/zonelist.xml.
kasp filename set to /usr/local/etc/opendnssec/kasp.xml.
Repository SoftHSM found
Capacity set to 1024.
RequireBackup set.
INFO: The XML in /usr/local/etc/opendnssec/conf.xml is valid
INFO: The XML in /usr/local/etc/opendnssec/zonelist.xml is valid
INFO: The XML in /usr/local/etc/opendnssec/kasp.xml is valid
Before launching OpenDNSSEC, you must enter the previously set PIN code (if it was deleted), the one that was entered when the softhsm command - init-token was requested.
...
Zone files have not yet been added.
Enter the pin code:
# ods-hsmutil login
Enter PIN for token SoftHSM:
The tokens are now logged in.
In /usr/local/etc/opendnssec/conf.xml, the line with the default pin code 1234 should be removed. If you make any changes to the configuration files, then apparently you need to run # ods-ksmutil update all.
OpenDNSSEC consists of two demons, ods-signerd and ods-enforcerd, run:
# ods-control start
Starting enforcer ...
OpenDNSSEC ods-enforcerd started (version 1.4.1), pid 39528
Starting signer engine ...
OpenDNSSEC signer engine version 1.4.1
Engine running.
Everything is working.
# ods-control stop
Add zones:
# ods-ksmutil zone add --zone zone1.com
# ods-ksmutil zone add --zone zone2.com
Apparently, all that this command does is add textual information about the paths to the location of the zone files in the /usr/local/etc/opendnssec/zonelist.xml file. The zone name entered must match the name of the zone file that will be copied to / usr / local / var / opendnssec / unsigned. In general, not to edit your hands zonelist.xml
# ods-ksmutil update all
Everything related to the policy of working with zones can be found in the official documentation. Used the default policy. With zones finished.
Form the keys:
Actually form the keys:
# ods-ksmutil key generate --policy default --interval 1Y
Key sharing is Off
Info: converting 1Y to seconds; M interpreted as 31 days, Y interpreted as 365 days
HSM opened successfully.
* WARNING * This will create 4 KSKs (2048 bits) and 16 ZSKs (1024 bits)
Are you sure? [y / n] y
Created KSK size: 2048, alg: 8 with id: ... in repository: SoftHSM and database.
Created KSK size: 2048, alg: 8 with id: ... in repository: SoftHSM and database.
Created KSK size: 2048, alg: 8 with id: ... in repository: SoftHSM and database.
Created KSK size: 2048, alg: 8 with id: ... in repository: SoftHSM and database.
Created ZSK size: 1024, alg: 8 with id: ... in repository: SoftHSM and database.
Created ZSK size: 1024, alg: 8 with id: ... in repository: SoftHSM and database.
Created ZSK size: 1024, alg: 8 with id: ... in repository: SoftHSM and database.
Created ZSK size: 1024, alg: 8 with id: ... in repository: SoftHSM and database.
...
Created ZSK size: 1024, alg: 8 with id: ... in repository: SoftHSM and database.
NOTE: keys generated in repository SoftHSM will not be active until you have been backed up
all done! hsm_close result: 0
# ods-hsmutil info
Repository: SoftHSM
Module: /usr/local/lib/softhsm/libsofthsm.so
Slot: 0
Token Label: OpenDNSSEC
Manufacturer: SoftHSM
Model: SoftHSM
Serial: 1
# ods-hsmutil list SoftHSM
Listing keys in repository: SoftHSM
20 keys found.
Repository ID Type
- - - SoftHSM ... RSA / 1024
SoftHSM ... RSA / 1024
...
SoftHSM ... RSA / 1024
SoftHSM ... RSA / 2048
SoftHSM ... RSA / 2048
SoftHSM ... RSA / 2048
SoftHSM ... RSA / 2048
Back up keys can be done only when OpenDNSSEC is stopped. Otherwise, there is a possibility of generating a new key during the execution of the back up operation. Keys are marked as bsck up. For now, I have removed the <RequireBackup option from /usr/local/etc/opendnssec/conf.xml
Run:
# ods-control start
Starting enforcer ...
OpenDNSSEC ods-enforcerd started (version 1.4.1), pid 51678
Starting signer engine ...
OpenDNSSEC signer engine version 1.4.1
Engine running.
# ods-ksmutil key list --verbose
MySQL database schema set to: somedatabase
MySQL database user set to: user
MySQL database password set
Keys:
Zone: Keytype: State: Date of next transition (to): Size: Algorithm: CKA_ID: Repository: Keytag:
And we see no keys. Poorly.
# ods-signer sign --all
With MySql I did not see the keys.
In general, it was not possible to configure with MySql55. Reinstall OpenDNSSEC:
[] MYSQL MySQL database support
[x] SOFTHSM SoftHSM cryptographic store for PKCS # 11 interface
Reinstalled, after backing up everything connected with OpenDNSSEC to another folder.
Here in / usr / local / etc / opendnssec there will be default configuration files created during installation. In general, the folder should contain the files: conf.xml, kasp.xml, zonefetch.xml, zonelist.xml. If not, then you need to rename the files with the sample extension in the same directory.
Now initialize the OpenDNSSEC database:
Import conf.xml, kasp.xml and zonelist.xml to the database. Delete current settings, including any previously installed keys.
# ods-ksmutil setup
* WARNING * This will erase all data in the database; are you sure? [y / n] y
Error: database in config file doesn’t match libksm
If we see this, then we need it in the /usr/local/etc/opendnssec/conf.xml file. To correct the path:
When installing OpenDNSSEC with MySql, the path is already fixed.
# ods-ksmutil setup
* WARNING * This will erase all data in the database; are you sure? [y / n] y
fixing permissions on file /usr/local/var/opendnssec/kasp.db
zonelist filename set to /usr/local/etc/opendnssec/zonelist.xml.
kasp filename set to /usr/local/etc/opendnssec/kasp.xml.
Repository SoftHSM found
No Maximum Capacity set.
RequireBackup NOT set; please make sure that you can use the keys.
/usr/local/etc/opendnssec/conf.xml validates
/usr/local/etc/opendnssec/kasp.xml validates
Policy default found
Info: converting P1Y to seconds; M interpreted as 31 days, Y interpreted as 365 days
The /usr/local/var/opendnssec/kasp.db file appears.
Check configuration files:
# ods-kaspcheck
/usr/local/etc/opendnssec/conf.xml validates
/usr/local/etc/opendnssec/kasp.xml validates
In / etc / rc.conf add opendnssec_enable = "YES"
We do not pay attention to version 1.3.13, you will have 1.4.1
# ods-control start
Starting enforcer ...
OpenDNSSEC ods-enforcerd started (version 1.3.13), pid 55019
Starting signer engine ...
OpenDNSSEC signer engine version 1.3.13
Engine running.
# ods-ksmutil zone add --zone zone1.com
zonelist filename set to /usr/local/etc/opendnssec/zonelist.xml.
Imported zone: zone1.com
# ods-ksmutil zone add - zonezone2.ru
zonelist filename set to /usr/local/etc/opendnssec/zonelist.xml.
Imported zone: zone2.ru
Etc. add all your zone files.
# ods-ksmutil update zonelist
zonelist filename set to /usr/local/etc/opendnssec/zonelist.xml.
kasp filename set to /usr/local/etc/opendnssec/kasp.xml.
Zone zone2.ru found
Policy set to default.
Zone zone1.com found
Policy set to default.
Notifying enforcer of new database ...
For everyone:
# ods-ksmutil update all
Checking that everything is in order; a list of keys should be displayed:
# ods-ksmutil key list --verbose
SQLite database set to: /usr/local/var/opendnssec/kasp.db
Keys:
Zone: Keytype: State: Date of next transition: CKA_ID: Repository: Keytag:
zone2.ru KSK publish 2013-06-02 13:29:18 4962a716093d3973bc2cbcd0312a2e90 SoftHSM 41863
zone2.ru ZSK active 2013-07-01 23:29:18 0696ec624c7baba98062d4fc32064b46 SoftHSM 5817
zone1.com KSK publish 2013-06-02 13:29:18 f73f605125a7e59e3f3108680255d84e SoftHSM 6918
zone1.com ZSK active 2013-07-01 23:29:18 31e08389f3a59397dce1f22fa67df8a8 SoftHSM 2180
If we see such a conclusion, then everything is set up correctly.
SQLite database: /usr/local/var/opendnssec/kasp.db
Let's try to check the DNSSEC request:
# dig + norec dig xx.yy.zz.ss -t ANY zone2.ru
; << >> DiG 9.6.-ESV-R3 << >> + norec dig xx.yy.zz.ss -t ANY zone2.ru
;; global options: + cmd
;; Got answer:
;; - >> HEADER << - opcode: QUERY, status: NOERROR, id: 53654
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 13
;; QUESTION SECTION:
; dig. IN A
;; AUTHORITY SECTION:
. 2574 IN NS d.root-servers.net.
. 2574 IN NS a.root-servers.net.
. 2574 IN NS g.root-servers.net.
. 2574 IN NS h.root-servers.net.
. 2574 IN NS c.root-servers.net.
. 2574 IN NS i.root-servers.net.
. 2574 IN NS b.root-servers.net.
. 2574 IN NS f.root-servers.net.
. 2574 IN NS j.root-servers.net.
. 2574 IN NS k.root-servers.net.
. 2574 IN NS l.root-servers.net.
. 2574 IN NS e.root-servers.net.
. 2574 IN NS m.root-servers.net.
;; ADDITIONAL SECTION:
a.root-servers.net. 2574 IN A 198.41.0.4
a.root-servers.net. 1398 IN AAAA 2001: 503: ba3e :: 2: 30
b.root-servers.net. 60 IN A 192.228.79.201
c.root-servers.net. 3425 IN A 192.33.4.12
d.root-servers.net. 2482 IN A 199.7.91.13
d.root-servers.net. 92 IN AAAA 2001: 500: 2d :: d
e.root-servers.net. 2482 IN A 192.203.230.10
f.root-servers.net. 2482 IN A 192.5.5.241
f.root-servers.net. 2574 IN AAAA 2001: 500: 2f :: f
g.root-servers.net. 2482 IN A 192.112.36.4
h.root-servers.net. 2482 IN A 128.63.2.53
h.root-servers.net. 2574 IN AAAA 2001: 500: 1 :: 803f: 235
i.root-servers.net. 2482 IN A 192.36.148.17
;; Query time: 1 msec
;; SERVER: 192.168.45.64 # 53 (192.168.45.64)
;; WHEN: Sun Jun 2 00:50:27 2013
;; MSG SIZE rcvd: 488
;; Got answer:
;; - >> HEADER << - opcode: QUERY, status: NXDOMAIN, id: 23363
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
; xx.yy.zz.ss. IN ANY
;; AUTHORITY SECTION:
. 3274 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2013060101 1800 900 604800 86400
;; Query time: 1 msec
;; SERVER: 192.168.45.64 # 53 (192.168.45.64)
;; WHEN: Sun Jun 2 00:50:27 2013
;; MSG SIZE rcvd: 107
;; Got answer:
;; - >> HEADER << - opcode: QUERY, status: NOERROR, id: 5213
;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
; zone2.ru. IN A
;; ANSWER SECTION:
zone2.ru. 3135 IN A xx.yy.zz.ss
;; AUTHORITY SECTION:
zone2.ru. 579 IN NS ns8-l2.xxx.ru.
zone2.ru. 579 IN NS ns4-l2.xxx.ru.
zone2.ru. 579 IN NS ns1.zone2.ru.
;; ADDITIONAL SECTION:
ns1.zone2.ru. 579 IN A xx.yy.zz.ss
ns4-l2.xxx.ru. 2596 IN A abcd1
ns8-l2.xxx.ru. 2596 IN A abcd2
;; Query time: 1 msec
;; SERVER: 192.168.45.64 # 53 (192.168.45.64)
;; WHEN: Sun Jun 2 00:50:27 2013
;; MSG SIZE rcvd: 154
Everything is good. DNS is still, and after a while it works. But DNSSEC is not functioning yet, there are no lines with keys in the output.
You need to export open KSK keys for each of the zones. You can export only KSK in the ready state.
The following commands for exporting keys are not yet executed:
ods-ksmutil key export --zone example.com [--keystate READY]
ods-ksmutil key export --zone example.com --ds [--keystate READY]
The first pair is the ZSK for signing the zone file.
The second pair is the KSK for signing the ZSK key and generating DS records that are transmitted to the administrator of the parent zone.
We find out the DNSKEY and DS records from the KSK:
# ods-ksmutil key list --verbose
SQLite database set to: /usr/local/var/opendnssec/kasp.db
Keys:
Zone: Keytype: State: Date of next transition: CKA_ID: Repository: Keytag:
zone2.ru KSK publish 2013-06-02 13:29:18 4962a716093d3973bc2cbcd0312a2e90 SoftHSM 41863
zone2.ru ZSK active 2013-07-01 23:29:18 0696ec624c7baba98062d4fc32064b46 SoftHSM 5817
zone1.com KSK publish 2013-06-02 13:29:18 f73f605125a7e59e3f3108680255d84e SoftHSM 6918
zone1.com ZSK active 2013-07-01 23:29:18 31e08389f3a59397dce1f22fa67df8a8 SoftHSM 2180
# ods-ksmutil key ds-seen -z zone1.com -x 6918
Found key with CKA_ID f73f605125a7e59e3f3108680255d84e
Key f73f605125a7e59e3f3108680255d84e made active
Notifying enforcer of new database ...
# ods-ksmutil key ds-seen -z zone2.ru -x 41863
Found key with CKA_ID 4962a716093d3973bcc2cbcd0312a2e90
Key 4962a716093d3973bc2cbcd0312a2e90 made active
Notifying enforcer of new database ...
KSK status has changed from publish to active:
# ods-ksmutil key list --verbose
SQLite database set to: /usr/local/var/opendnssec/kasp.db
Keys:
Zone: Keytype: State: Date of next transition: CKA_ID: Repository: Keytag:
zone2.ru KSK active 2013-06-02 13:29:18 4962a716093d3973bc2cbcd0312a2e90 SoftHSM 41863
zone2.ru ZSK active 2013-07-01 23:29:18 0696ec624c7baba98062d4fc32064b46 SoftHSM 5817
zone1.com KSK active 2013-06-02 13:29:18 f73f605125a7e59e3f3108680255d84e SoftHSM 6918
zone1.com ZSK active 2013-07-01 23:29:18 31e08389f3a59397dce1f22fa67df8a8 SoftHSM 2180
Now you need to inform the provider about your public key and DS records for each of the zones. The provider on the site in your account has / should be filled out form with an example. My was.
When exporting after the –e key, you need to set the current state of the KSK key publish, active ...
# ods-ksmutil key export -z zone2.ru -e active -x 41863
; publish KSK DNSKEY record:
zone2.ru. 3600 IN DNSKEY 257 3 8 Aw ... dk2 =; {id = xxxx (ksk), size = 2048b}
to place the DNSKEY in the RD, directly everything received through the ods-ksmutil key export is copied into the text entry field on the website in your account, after some time the entered data will be automatically corrected to look like in the example. This refers to an example of filling in on the web page of a personal account of the PD. Those. all that is after; publish KSK DNSKEY record: register in the DNS Key field: in your personal account of PD.
Now we find out DS records for the domain:
# ods-ksmutil key export -z zone2.ru -e active -x 41863 --ds
; publish KSK DS record (SHA1):
zone2.ru. 3600 IN DS 57062 8 1 2a… 34df
; publish KSK DS record (SHA256):
zone2.ru. 3600 IN DS 57062 8 2 e3fa ... d492
Accordingly, we copy the received DS records into the corresponding input field in the personal account xxx. Perform the appropriate operation for all domains.
And the final touch is the automatic restart of the NSD server during key regeneration:
In the /usr/local/etc/opendnssec/conf.xml file, you need to comment or add a line to
In / usr / local / bin / create an opendnssec-nsd-reload file with the following contents:
{
#! / bin / sh - # @ (#) (CAcert) $ Id: reload-nsd, v 1.1 2013/06/02 23:49:50 root Exp $
# reload-nsd - script invoked by opendnssec to reload zonefiles
# logging
# echo $ 0 $ *
# ignore% zone and% zonefile since nsd can't use them ...
/ usr / local / sbin / nsdc rebuild
/ usr / local / sbin / nsdc reload
}
# chmod 0555 / usr / local / bin / opendnssec-nsd-reload
Or we copy the corresponding file from the OpenDNSSEC installation folder.
You can use the command to stop opendnssec.
# ods-control stop
If changes were made to kasp.xml, then you need to run the command:
# ods-ksmutil update kasp
If changes are made in the unsigned zones –– original zones copied from the / usr / local / etc / nsd / zones / master to the / usr / local / var / opendnssec / unsigned directory, then you need to run the command:
# ods-signer sign example.com for each zone in which changes were made.
Restart NSD to read the signed zone files:
# nsdc rebuild
# nsdc reload
# nsdc notify
Verification: you should end up with the following:
Displays the standard DNS server response without dnssec.
# dig site.com
; << >> DiG 9.6.-ESV-R3 << >> site.com
;; global options: + cmd
;; Got answer:
;; - >> HEADER << - opcode: QUERY, status: NOERROR, id: 43618
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
; site.com. IN A
;; ANSWER SECTION:
site.com. 1111 IN A xxx.yyy.zzz.aaa
;; AUTHORITY SECTION:
site.com. 1111 IN NS ns4-l2.xxx.ru.
site.com. 1111 IN NS ns8-l2.xxx.ru.
;; ADDITIONAL SECTION:
ns4-l2.xxx.ru. 1276 IN A abcd1
ns8-l2.xxx.ru. 1276 IN A abcd2
;; Query time: 1 msec
;; SERVER: xx1.yy1.zz1.aa1 # 53 (xx1.yy1.zz1.aa1)
;; WHEN: Mon Jun 3 18:00:40 2013
;; MSG SIZE rcvd: 123
We display the dnssec response from the DNS server:
# dig xxx.yyy.zzz.aaa site.com + retry = 1 + dnssec + multiline
; << >> DiG 9.6.-ESV-R3 << >> xxx.yyy.zzz.aaa site.com + retry = 1 + dnssec + multiline
;; global options: + cmd
;; Got answer:
;; - >> HEADER << - opcode: QUERY, status: NXDOMAIN, id: 12671
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
; xxx.yyy.zzz.aaa. IN A
;; AUTHORITY SECTION:
. 2235 IN SOA a.root-servers.net. nstld.verisign-grs.com. (
2013060300; serial
1800; refresh (30 minutes)
900; retry (15 minutes)
604800; expire (1 week)
86400; minimum (1 day)
)
;; Query time: 1 msec
;; SERVER: xx1.yy1.zz1.aa1 # 53 (xx1.yy1.zz1.aa1)
;; WHEN: Mon Jun 3 18:52:31 2013
;; MSG SIZE rcvd: 107
;; Got answer:
;; - >> HEADER << - opcode: QUERY, status: NOERROR, id: 53116
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
; site.com. IN A
;; ANSWER SECTION:
site.com. 1835 IN A xxx.yyy.zzz.aaa
site.com. 1835 IN RRSIG A 8 2 3600 20130609232905 (
20130602143424 39964 site.com.
IM + aCUZHZekNnQhjxngyIXUrBUkgCjAxc8o4UuoqvMUu
F1W3L7ge4HVHdWkfmEf / Gk + o8hu7B2MGgP1P9L89 / l3c
gCyVYvIrpR3viVFP7uNtbaoiVdo3bRgtHyFH6QmlTCCW
NrmBHY5sKh / NItAqp1bagQCMYqy71o07oNsNeOU =)
;; AUTHORITY SECTION:
site.com. 1835 IN NS ns4-l2.xxx.ru.
site.com. 1835 IN NS ns8-l2.xxx.ru.
site.com. 1835 IN RRSIG NS 8 2 3600 20130610191139 (
20130603121736 39964 site.com.
ceIOophlVR8zLydk0hVWdtIx / OSLO + kdqQg0opthF5pF
O4NRYgKfkl2tSLGHozzQq0CqzZ0s9rGiE2hnq7M2jJby
Mg9wm1BmHVnmogSat463kpG29Di2U1Yj + AAY8WJ0Gtvv
iYG / atnToDAsLoXgaLfbaYvRCRirCym7LoXjn3Q =)
;; ADDITIONAL SECTION:
ns4-l2.xxx.ru. 1866 IN A abcd1
ns8-l2.xxx.ru. 1866 IN A abcd2
;; Query time: 1 msec
;; SERVER: xx1.yy1.zz1.aa1 # 53 (xx1.yy1.zz1.aa1)
;; WHEN: Mon Jun 3 18:52:31 2013
;; MSG SIZE rcvd: 472
In the above output we see the presence of keys.
And the last check, since everything was done for the xxx registrar, go to your personal account, and perform online DNS testing.
Everything is in order, it remains to make sure that after the expiration of the established validity of the keys, the zones will be re-signed automatically. We see the record in the personal account of the RD “A chain of trust is built”.
If someone points out the possible nuances of customization with MySql, I will test and correct the article.
A lot of information is on the official site.
The article is planned to be corrected to edit the settings related to MySql.
The article was written simultaneously with the installation / configuration of OpenDNSSEC. In total, it took about a month. The procedure was performed twice. First, OpenDNSSEC 1.3 was installed. The zones are signed, the anchor of the domain registrar (RD) is registered, the chain of trust is built, as reported in the personal account of the domain registrar (RD), in general, everything turned out. Six months later, as a result of the next manual update of the ports, the port of OpenDNSSEC 1.3.x was automatically updated to 1.4.1, and there are a lot of other things. But everything, of course, continued to work without any hint of a problem. Discovered by chance when a change was required in the DNS zone. And so it began ...
We assume that the NSD DNS server is configured, it works for several years, everything is in order.
Version 1.4 did not manage to be configured for a long time, keys did not appear, zones did not subscribe. The package was installed with the support of MySql55. On the official site, while listing officially supported OSs for 1.4, FreeBSD 9.0 was announced. It was unlikely that there was a reason (the reason was not the case), but it was updated on every basis from FreeBSD 8.2 to 9.1. From ignorance of the nuances I even suggested that the already built chain of trust was interfering. Therefore, in the personal account of RD broke the chain of trust. And set up NSD to work with unsigned zones. Trying to convert an existing SQLite2 database into SQLite3 did not. It was decided to re-do everything and use MySql55, as recommended.
')
In general, the picture most likely looks like this: NSD both served the zones and served them. NSD and Opendnssec are in no way connected with each other. Opendnssec is a handy gadget for automating the zone signing process. Opendnssec takes existing, unsigned NSD server zone files and signs / re-signing them at specified intervals. After automatic re-signing, Opendnssec restarts NSD. Further NSD uses already signed zone files. And DNSSEC in NSD is included automatically. NSD itself recognizes signed zone files. One moment is not clear: in the personal account of the RD (domain registrar) you need to register some keys, the so-called anchors. Will it be necessary to edit them manually later when the zones are automatically re-signed with new keys? I will assume of course that there will be no problems.
Looking ahead: c MySql OpenDNSSEC could not be configured. Exactly found out that the problem is connected with the database, or with the interaction between the database and OpenDNSSEC. OpenDNSSEC can work with both SQLite and MySql. Returned to SQLite3 everything went right there and no questions asked. On the official website, SQLite3 is recommended only for test applications. I will assume that MySql is recommended if there are many, thousands of files and records in them. For the case of a test server decided to use SQLite. Thus, all of the following, related to MySql, is not used. But for just this information left. Below is a schematic picture describing what is happening. The picture is taken from the official OpenDNSSEC documentation site.
Secondary DNS servers do not require any action on themselves, however, you need to make sure that the secondary server also supports DNSSEC. The RD, which was ordered to have two secondary DNS at one time, is all supported.
There are 2 pairs of keys:
The first pair - ZSK is used to sign the zone file.
The second pair, KSK, is used to sign the ZSK key and generate DS records that are transmitted to the administrator of the parent zone (in the current case of the PD). It is recommended to change KSK once a year, ZSK up to once a month.
The installation of both 1.3 and 1.4 versions of OpenDNSSEC overlaps. When using SQLite2 and 3 databases there were no problems. With MySql55 setup failed. After everything worked with SQLite3, the search for the reasons why there were problems with MySql was postponed until the next time. Again, SQLite is recommended for testing only.
I cite everything as it was, so at first it is desirable to see how it ended, and then repeat. Yes, if you install only OpenDNSSEC 1.4.1, the article would be two times shorter. But I think that redundancy of information will better help to understand if there are any nuances. As they say, a gift to rewriters. If you automatically had an OpenDNSSEC update from the old version to 1.4.1, then it is advisable to transfer OpenDNSSEC to a backup folder and reinstall it. Configuration files will be different. And the old ones, for obvious reasons, are not overwritten.
When installing the opendnssec port, we do not do make clean, some files will be needed for configuration.
# cd / usr / ports / dns / opendnssec
# make
===> opendnssec-1.3.13 is marked as broken: does not work with ruby ​​1.9.
*** Error code 1
Install the port / usr / ports / lang / ruby18, because Since 1.9, the opendnssec port has compatibility problems, namely, an error occurs when the AUDITOR flag is on.
In general, install / reinstall the ruby18 port.
Next, look at the file / usr / ports / UPDATING, which says what about ruby1.8 and 1.9. In general, to use version 1.8, you need to add the following lines to the /etc/make.conf file:
#
# Keep ruby ​​1.8 as default version.
#
RUBY_DEFAULT_VER = 1.8
Reboot and then retry the installation:
# cd / usr / ports / dns / opendnssec
# make config - make sure all flags are checked
# make && make install && make clean
[x] AUDITOR Build with Auditor
[] MYSQL MySQL database support
[x] SOFTHSM Build / update SOFTHSM as well
In OpenDNSSEC 1.4.1, this problem does not occur, there is no longer used by AUDITOR, which used ruby. Ruby is not used at all. Of the 2 options offered during installation, one MySql was selected. I repeat that it didn’t start with MySql, for OpenDNSSEC 1.4.1 we’ll select the second of the two checkboxes, respectively.
In the file /usr/local/etc/nsd/nsd.conf, we change:
zonesdir: “/ usr / local / var / opendnssec / signed”
and all zonefile entries:
zonefile: "/usr/local/var/opendnssec/signed/zone1.ru"
zonefile: "/usr/local/var/opendnssec/signed/zone2.ru"
...
zonefile: "/usr/local/var/opendnssec/signed/zoneN.ru"
Create links:
# cd / usr / local / etc / nsd
# ln -s / usr / local / var / opendnssec / unsigned.
# ln -s / usr / local / var / opendnssec / signed.
Copy existing, working, unsigned NSD server zone files from / usr / local / etc / nsd / zones / master to / usr / local / etc / nsd / ~ unsigned.
# chown -R opendnssec: opendnssec / usr / local / var / opendnssec / unsigned
Initializing SoftHSM database with the label “OpenDNSSEC” using the SO PIN <pin code> and USER PIN <the same pin code>
If there is no / usr / local / var / lib / softhsm folder for any reason, then install / reinstall the port:
# cd / usr / ports / security / softhsm
# make && make install && make clean
Set permissions on the softhsm folder, by default they are 700:
# chmod 0755 / usr / local / var / lib / softhsm
We invent / enter / remember 2 PIN codes. Let it be the same:
# softhsm --init-token --slot 0 --label "OpenDNSSEC"
The PIN PIN must have a length between 4 and 255 characters.
Enter SO PIN:
The PIN must be a length between 4 and 255 characters.
Enter user PIN:
The token has been initialized.
In the /usr/local/etc/opendnssec/conf.xml file, delete the line
<PIN>1234</PIN> Pin code will be entered manually. Or leave, the PIN code will be substituted automatically.
It should turn out like this:
For 1.4.1 Install MySql55 server and client. SQLite3 is recommended for testing purposes only.
After installing MySql55, it is necessary, depending on the expected load on the server, to select one of the configuration files located in / usr / local / share / mysql, and copy it to / var / db / mysql. And accordingly in /etc/rc.conf should be:
nsd_enable = "YES"
opendnssec_enable = "YES"
mysql_enable = "YES"
To automatically create the necessary database structure, use the file:
/usr/ports/dns/opendnssec/work/opendnssec-1.4.1/enforcer/utils/database_create.mysql
# mysql
> create database kasp;
> CREATE USER 'ksuser' @ 'localhost' IDENTIFIED BY 'password';
> GRANT ALL PRIVILEGES ON kasp. * TO 'ksuser' @ 'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION;
> flush privileges;
> quit
If after flush privileges; there will be a mistake
ERROR 1146 (42S02): Table 'mysql.servers' does not exist
We try this way here with the password:
# mysqlcheck --check-upgrade --all-databases - auto-repair -p
Enter password:
And then
# mysql_upgrade --force -p
Enter password:
At one time it helped.
We adjusted the created database.
# mysql kasp </usr/ports/dns/opendnssec/work/opendnssec-1.4.1/enforcer/utils/database_create.mysql
# mysql
> USE kasp;
> SHOW TABLES;
+ ----------------------------- +
| Tables_in_kasp |
+ ----------------------------- +
| INT_KEYALLOC_VIEW_FOR_MYSQL |
| KEYALLOC_VIEW |
| KEYDATA_VIEW |
| PARAMETER_LIST |
| PARAMETER_VIEW |
| categories |
| dbadmin |
| dnsseckeys |
| keypairs |
| parameters |
| parameters_policies |
| policies |
| securitymodules |
| serialmodes |
| zones |
+ ----------------------------- +
15 rows in set (0.01 sec)
> quit
In / usr / local / etc / opendnssec there will be default configuration files created during installation.
In /usr/local/etc/opendnssec/conf.xml we correct:
<Datastore> <MySQL> <!-- <Host port="1213">dnssec-db</Host> --> <Database>database</Database> <Username>kaspuser</Username> <Password>mysqlpassword</Password> </MySQL> </Datastore> <Host is the name of the system where the database is installed. The parameter is optional; if not specified, the database is associated with the system where OpenDNSSEC is installed. Port it is clear what. The parameter is optional, the default is 3306.
<Database Database.
<Username Database user.
<Password Respectively password.
In /usr/local/etc/opendnssec/conf.xml should be:
<Repository name="SoftHSM"> <Module>/usr/local/lib/softhsm/libsofthsm.so</Module> <TokenLabel>OpenDNSSEC</TokenLabel> <Capacity>1024</Capacity> <RequireBackup/> <SkipPublicKey/> </Repository> We check for it like this:
<Signer> <NotifyCommand>/usr/local/bin/opendnssec-nsd-reload</NotifyCommand> For sekurnosti pin code is not registered here. It will be entered manually, although it is easier to leave it in place.
Pay attention to the record:
<Module>/usr/local/lib/softhsm/libsofthsm.so</Module> Enter the data of the configuration files in the database
# ods-ksmutil setup
* WARNING * This will erase all data in the database; are you sure? [y / n] y
zonelist filename set to /usr/local/etc/opendnssec/zonelist.xml.
kasp filename set to /usr/local/etc/opendnssec/kasp.xml.
Repository SoftHSM found
Capacity set to 1024.
RequireBackup set.
INFO: The XML in /usr/local/etc/opendnssec/conf.xml is valid
INFO: The XML in /usr/local/etc/opendnssec/zonelist.xml is valid
INFO: The XML in /usr/local/etc/opendnssec/kasp.xml is valid
Before launching OpenDNSSEC, you must enter the previously set PIN code (if it was deleted), the one that was entered when the softhsm command - init-token was requested.
...
Zone files have not yet been added.
Enter the pin code:
# ods-hsmutil login
Enter PIN for token SoftHSM:
The tokens are now logged in.
In /usr/local/etc/opendnssec/conf.xml, the line with the default pin code 1234 should be removed. If you make any changes to the configuration files, then apparently you need to run # ods-ksmutil update all.
OpenDNSSEC consists of two demons, ods-signerd and ods-enforcerd, run:
# ods-control start
Starting enforcer ...
OpenDNSSEC ods-enforcerd started (version 1.4.1), pid 39528
Starting signer engine ...
OpenDNSSEC signer engine version 1.4.1
Engine running.
Everything is working.
# ods-control stop
Add zones:
# ods-ksmutil zone add --zone zone1.com
# ods-ksmutil zone add --zone zone2.com
Apparently, all that this command does is add textual information about the paths to the location of the zone files in the /usr/local/etc/opendnssec/zonelist.xml file. The zone name entered must match the name of the zone file that will be copied to / usr / local / var / opendnssec / unsigned. In general, not to edit your hands zonelist.xml
# ods-ksmutil update all
Everything related to the policy of working with zones can be found in the official documentation. Used the default policy. With zones finished.
Form the keys:
/usr/local/etc/opendnssec/kasp.xml policy: default <Policy name="default"> <Keys> <KSK> <Lifetime>P3M</Lifetime> 3 . –interval , . , , . 1M , <ZSK> <Lifetime>P1M</Lifetime> <KSK> <Lifetime>P3M</Lifetime> 2 2 KSK 2 ZSK. --interval 1Y 2 , 6 KSKs (2048 bits) and 20 ZSKs (1024 bits). Actually form the keys:
# ods-ksmutil key generate --policy default --interval 1Y
Key sharing is Off
Info: converting 1Y to seconds; M interpreted as 31 days, Y interpreted as 365 days
HSM opened successfully.
* WARNING * This will create 4 KSKs (2048 bits) and 16 ZSKs (1024 bits)
Are you sure? [y / n] y
Created KSK size: 2048, alg: 8 with id: ... in repository: SoftHSM and database.
Created KSK size: 2048, alg: 8 with id: ... in repository: SoftHSM and database.
Created KSK size: 2048, alg: 8 with id: ... in repository: SoftHSM and database.
Created KSK size: 2048, alg: 8 with id: ... in repository: SoftHSM and database.
Created ZSK size: 1024, alg: 8 with id: ... in repository: SoftHSM and database.
Created ZSK size: 1024, alg: 8 with id: ... in repository: SoftHSM and database.
Created ZSK size: 1024, alg: 8 with id: ... in repository: SoftHSM and database.
Created ZSK size: 1024, alg: 8 with id: ... in repository: SoftHSM and database.
...
Created ZSK size: 1024, alg: 8 with id: ... in repository: SoftHSM and database.
NOTE: keys generated in repository SoftHSM will not be active until you have been backed up
all done! hsm_close result: 0
# ods-hsmutil info
Repository: SoftHSM
Module: /usr/local/lib/softhsm/libsofthsm.so
Slot: 0
Token Label: OpenDNSSEC
Manufacturer: SoftHSM
Model: SoftHSM
Serial: 1
# ods-hsmutil list SoftHSM
Listing keys in repository: SoftHSM
20 keys found.
Repository ID Type
- - - SoftHSM ... RSA / 1024
SoftHSM ... RSA / 1024
...
SoftHSM ... RSA / 1024
SoftHSM ... RSA / 2048
SoftHSM ... RSA / 2048
SoftHSM ... RSA / 2048
SoftHSM ... RSA / 2048
Back up keys can be done only when OpenDNSSEC is stopped. Otherwise, there is a possibility of generating a new key during the execution of the back up operation. Keys are marked as bsck up. For now, I have removed the <RequireBackup option from /usr/local/etc/opendnssec/conf.xml
Run:
# ods-control start
Starting enforcer ...
OpenDNSSEC ods-enforcerd started (version 1.4.1), pid 51678
Starting signer engine ...
OpenDNSSEC signer engine version 1.4.1
Engine running.
# ods-ksmutil key list --verbose
MySQL database schema set to: somedatabase
MySQL database user set to: user
MySQL database password set
Keys:
Zone: Keytype: State: Date of next transition (to): Size: Algorithm: CKA_ID: Repository: Keytag:
And we see no keys. Poorly.
# ods-signer sign --all
With MySql I did not see the keys.
In general, it was not possible to configure with MySql55. Reinstall OpenDNSSEC:
[] MYSQL MySQL database support
[x] SOFTHSM SoftHSM cryptographic store for PKCS # 11 interface
Reinstalled, after backing up everything connected with OpenDNSSEC to another folder.
Here in / usr / local / etc / opendnssec there will be default configuration files created during installation. In general, the folder should contain the files: conf.xml, kasp.xml, zonefetch.xml, zonelist.xml. If not, then you need to rename the files with the sample extension in the same directory.
Now initialize the OpenDNSSEC database:
Import conf.xml, kasp.xml and zonelist.xml to the database. Delete current settings, including any previously installed keys.
# ods-ksmutil setup
* WARNING * This will erase all data in the database; are you sure? [y / n] y
Error: database in config file doesn’t match libksm
If we see this, then we need it in the /usr/local/etc/opendnssec/conf.xml file. To correct the path:
<Module>/usr/local/lib/softhsm/libsofthsm.so</Module> When installing OpenDNSSEC with MySql, the path is already fixed.
# ods-ksmutil setup
* WARNING * This will erase all data in the database; are you sure? [y / n] y
fixing permissions on file /usr/local/var/opendnssec/kasp.db
zonelist filename set to /usr/local/etc/opendnssec/zonelist.xml.
kasp filename set to /usr/local/etc/opendnssec/kasp.xml.
Repository SoftHSM found
No Maximum Capacity set.
RequireBackup NOT set; please make sure that you can use the keys.
/usr/local/etc/opendnssec/conf.xml validates
/usr/local/etc/opendnssec/kasp.xml validates
Policy default found
Info: converting P1Y to seconds; M interpreted as 31 days, Y interpreted as 365 days
The /usr/local/var/opendnssec/kasp.db file appears.
Check configuration files:
# ods-kaspcheck
/usr/local/etc/opendnssec/conf.xml validates
/usr/local/etc/opendnssec/kasp.xml validates
In / etc / rc.conf add opendnssec_enable = "YES"
We do not pay attention to version 1.3.13, you will have 1.4.1
# ods-control start
Starting enforcer ...
OpenDNSSEC ods-enforcerd started (version 1.3.13), pid 55019
Starting signer engine ...
OpenDNSSEC signer engine version 1.3.13
Engine running.
# ods-ksmutil zone add --zone zone1.com
zonelist filename set to /usr/local/etc/opendnssec/zonelist.xml.
Imported zone: zone1.com
# ods-ksmutil zone add - zonezone2.ru
zonelist filename set to /usr/local/etc/opendnssec/zonelist.xml.
Imported zone: zone2.ru
Etc. add all your zone files.
# ods-ksmutil update zonelist
zonelist filename set to /usr/local/etc/opendnssec/zonelist.xml.
kasp filename set to /usr/local/etc/opendnssec/kasp.xml.
Zone zone2.ru found
Policy set to default.
Zone zone1.com found
Policy set to default.
Notifying enforcer of new database ...
For everyone:
# ods-ksmutil update all
Checking that everything is in order; a list of keys should be displayed:
# ods-ksmutil key list --verbose
SQLite database set to: /usr/local/var/opendnssec/kasp.db
Keys:
Zone: Keytype: State: Date of next transition: CKA_ID: Repository: Keytag:
zone2.ru KSK publish 2013-06-02 13:29:18 4962a716093d3973bc2cbcd0312a2e90 SoftHSM 41863
zone2.ru ZSK active 2013-07-01 23:29:18 0696ec624c7baba98062d4fc32064b46 SoftHSM 5817
zone1.com KSK publish 2013-06-02 13:29:18 f73f605125a7e59e3f3108680255d84e SoftHSM 6918
zone1.com ZSK active 2013-07-01 23:29:18 31e08389f3a59397dce1f22fa67df8a8 SoftHSM 2180
If we see such a conclusion, then everything is set up correctly.
SQLite database: /usr/local/var/opendnssec/kasp.db
Let's try to check the DNSSEC request:
# dig + norec dig xx.yy.zz.ss -t ANY zone2.ru
; << >> DiG 9.6.-ESV-R3 << >> + norec dig xx.yy.zz.ss -t ANY zone2.ru
;; global options: + cmd
;; Got answer:
;; - >> HEADER << - opcode: QUERY, status: NOERROR, id: 53654
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 13
;; QUESTION SECTION:
; dig. IN A
;; AUTHORITY SECTION:
. 2574 IN NS d.root-servers.net.
. 2574 IN NS a.root-servers.net.
. 2574 IN NS g.root-servers.net.
. 2574 IN NS h.root-servers.net.
. 2574 IN NS c.root-servers.net.
. 2574 IN NS i.root-servers.net.
. 2574 IN NS b.root-servers.net.
. 2574 IN NS f.root-servers.net.
. 2574 IN NS j.root-servers.net.
. 2574 IN NS k.root-servers.net.
. 2574 IN NS l.root-servers.net.
. 2574 IN NS e.root-servers.net.
. 2574 IN NS m.root-servers.net.
;; ADDITIONAL SECTION:
a.root-servers.net. 2574 IN A 198.41.0.4
a.root-servers.net. 1398 IN AAAA 2001: 503: ba3e :: 2: 30
b.root-servers.net. 60 IN A 192.228.79.201
c.root-servers.net. 3425 IN A 192.33.4.12
d.root-servers.net. 2482 IN A 199.7.91.13
d.root-servers.net. 92 IN AAAA 2001: 500: 2d :: d
e.root-servers.net. 2482 IN A 192.203.230.10
f.root-servers.net. 2482 IN A 192.5.5.241
f.root-servers.net. 2574 IN AAAA 2001: 500: 2f :: f
g.root-servers.net. 2482 IN A 192.112.36.4
h.root-servers.net. 2482 IN A 128.63.2.53
h.root-servers.net. 2574 IN AAAA 2001: 500: 1 :: 803f: 235
i.root-servers.net. 2482 IN A 192.36.148.17
;; Query time: 1 msec
;; SERVER: 192.168.45.64 # 53 (192.168.45.64)
;; WHEN: Sun Jun 2 00:50:27 2013
;; MSG SIZE rcvd: 488
;; Got answer:
;; - >> HEADER << - opcode: QUERY, status: NXDOMAIN, id: 23363
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
; xx.yy.zz.ss. IN ANY
;; AUTHORITY SECTION:
. 3274 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2013060101 1800 900 604800 86400
;; Query time: 1 msec
;; SERVER: 192.168.45.64 # 53 (192.168.45.64)
;; WHEN: Sun Jun 2 00:50:27 2013
;; MSG SIZE rcvd: 107
;; Got answer:
;; - >> HEADER << - opcode: QUERY, status: NOERROR, id: 5213
;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
; zone2.ru. IN A
;; ANSWER SECTION:
zone2.ru. 3135 IN A xx.yy.zz.ss
;; AUTHORITY SECTION:
zone2.ru. 579 IN NS ns8-l2.xxx.ru.
zone2.ru. 579 IN NS ns4-l2.xxx.ru.
zone2.ru. 579 IN NS ns1.zone2.ru.
;; ADDITIONAL SECTION:
ns1.zone2.ru. 579 IN A xx.yy.zz.ss
ns4-l2.xxx.ru. 2596 IN A abcd1
ns8-l2.xxx.ru. 2596 IN A abcd2
;; Query time: 1 msec
;; SERVER: 192.168.45.64 # 53 (192.168.45.64)
;; WHEN: Sun Jun 2 00:50:27 2013
;; MSG SIZE rcvd: 154
Everything is good. DNS is still, and after a while it works. But DNSSEC is not functioning yet, there are no lines with keys in the output.
You need to export open KSK keys for each of the zones. You can export only KSK in the ready state.
The following commands for exporting keys are not yet executed:
ods-ksmutil key export --zone example.com [--keystate READY]
ods-ksmutil key export --zone example.com --ds [--keystate READY]
The first pair is the ZSK for signing the zone file.
The second pair is the KSK for signing the ZSK key and generating DS records that are transmitted to the administrator of the parent zone.
We find out the DNSKEY and DS records from the KSK:
# ods-ksmutil key list --verbose
SQLite database set to: /usr/local/var/opendnssec/kasp.db
Keys:
Zone: Keytype: State: Date of next transition: CKA_ID: Repository: Keytag:
zone2.ru KSK publish 2013-06-02 13:29:18 4962a716093d3973bc2cbcd0312a2e90 SoftHSM 41863
zone2.ru ZSK active 2013-07-01 23:29:18 0696ec624c7baba98062d4fc32064b46 SoftHSM 5817
zone1.com KSK publish 2013-06-02 13:29:18 f73f605125a7e59e3f3108680255d84e SoftHSM 6918
zone1.com ZSK active 2013-07-01 23:29:18 31e08389f3a59397dce1f22fa67df8a8 SoftHSM 2180
# ods-ksmutil key ds-seen -z zone1.com -x 6918
Found key with CKA_ID f73f605125a7e59e3f3108680255d84e
Key f73f605125a7e59e3f3108680255d84e made active
Notifying enforcer of new database ...
# ods-ksmutil key ds-seen -z zone2.ru -x 41863
Found key with CKA_ID 4962a716093d3973bcc2cbcd0312a2e90
Key 4962a716093d3973bc2cbcd0312a2e90 made active
Notifying enforcer of new database ...
KSK status has changed from publish to active:
# ods-ksmutil key list --verbose
SQLite database set to: /usr/local/var/opendnssec/kasp.db
Keys:
Zone: Keytype: State: Date of next transition: CKA_ID: Repository: Keytag:
zone2.ru KSK active 2013-06-02 13:29:18 4962a716093d3973bc2cbcd0312a2e90 SoftHSM 41863
zone2.ru ZSK active 2013-07-01 23:29:18 0696ec624c7baba98062d4fc32064b46 SoftHSM 5817
zone1.com KSK active 2013-06-02 13:29:18 f73f605125a7e59e3f3108680255d84e SoftHSM 6918
zone1.com ZSK active 2013-07-01 23:29:18 31e08389f3a59397dce1f22fa67df8a8 SoftHSM 2180
Now you need to inform the provider about your public key and DS records for each of the zones. The provider on the site in your account has / should be filled out form with an example. My was.
When exporting after the –e key, you need to set the current state of the KSK key publish, active ...
# ods-ksmutil key export -z zone2.ru -e active -x 41863
; publish KSK DNSKEY record:
zone2.ru. 3600 IN DNSKEY 257 3 8 Aw ... dk2 =; {id = xxxx (ksk), size = 2048b}
to place the DNSKEY in the RD, directly everything received through the ods-ksmutil key export is copied into the text entry field on the website in your account, after some time the entered data will be automatically corrected to look like in the example. This refers to an example of filling in on the web page of a personal account of the PD. Those. all that is after; publish KSK DNSKEY record: register in the DNS Key field: in your personal account of PD.
Now we find out DS records for the domain:
# ods-ksmutil key export -z zone2.ru -e active -x 41863 --ds
; publish KSK DS record (SHA1):
zone2.ru. 3600 IN DS 57062 8 1 2a… 34df
; publish KSK DS record (SHA256):
zone2.ru. 3600 IN DS 57062 8 2 e3fa ... d492
Accordingly, we copy the received DS records into the corresponding input field in the personal account xxx. Perform the appropriate operation for all domains.
And the final touch is the automatic restart of the NSD server during key regeneration:
In the /usr/local/etc/opendnssec/conf.xml file, you need to comment or add a line to
<Signer>…</Signer>: <NotifyCommand>/usr/local/bin/opendnssec-nsd-reload</NotifyCommand> In / usr / local / bin / create an opendnssec-nsd-reload file with the following contents:
{
#! / bin / sh - # @ (#) (CAcert) $ Id: reload-nsd, v 1.1 2013/06/02 23:49:50 root Exp $
# reload-nsd - script invoked by opendnssec to reload zonefiles
# logging
# echo $ 0 $ *
# ignore% zone and% zonefile since nsd can't use them ...
/ usr / local / sbin / nsdc rebuild
/ usr / local / sbin / nsdc reload
}
# chmod 0555 / usr / local / bin / opendnssec-nsd-reload
Or we copy the corresponding file from the OpenDNSSEC installation folder.
You can use the command to stop opendnssec.
# ods-control stop
If changes were made to kasp.xml, then you need to run the command:
# ods-ksmutil update kasp
If changes are made in the unsigned zones –– original zones copied from the / usr / local / etc / nsd / zones / master to the / usr / local / var / opendnssec / unsigned directory, then you need to run the command:
# ods-signer sign example.com for each zone in which changes were made.
Restart NSD to read the signed zone files:
# nsdc rebuild
# nsdc reload
# nsdc notify
Verification: you should end up with the following:
Displays the standard DNS server response without dnssec.
# dig site.com
; << >> DiG 9.6.-ESV-R3 << >> site.com
;; global options: + cmd
;; Got answer:
;; - >> HEADER << - opcode: QUERY, status: NOERROR, id: 43618
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
; site.com. IN A
;; ANSWER SECTION:
site.com. 1111 IN A xxx.yyy.zzz.aaa
;; AUTHORITY SECTION:
site.com. 1111 IN NS ns4-l2.xxx.ru.
site.com. 1111 IN NS ns8-l2.xxx.ru.
;; ADDITIONAL SECTION:
ns4-l2.xxx.ru. 1276 IN A abcd1
ns8-l2.xxx.ru. 1276 IN A abcd2
;; Query time: 1 msec
;; SERVER: xx1.yy1.zz1.aa1 # 53 (xx1.yy1.zz1.aa1)
;; WHEN: Mon Jun 3 18:00:40 2013
;; MSG SIZE rcvd: 123
We display the dnssec response from the DNS server:
# dig xxx.yyy.zzz.aaa site.com + retry = 1 + dnssec + multiline
; << >> DiG 9.6.-ESV-R3 << >> xxx.yyy.zzz.aaa site.com + retry = 1 + dnssec + multiline
;; global options: + cmd
;; Got answer:
;; - >> HEADER << - opcode: QUERY, status: NXDOMAIN, id: 12671
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
; xxx.yyy.zzz.aaa. IN A
;; AUTHORITY SECTION:
. 2235 IN SOA a.root-servers.net. nstld.verisign-grs.com. (
2013060300; serial
1800; refresh (30 minutes)
900; retry (15 minutes)
604800; expire (1 week)
86400; minimum (1 day)
)
;; Query time: 1 msec
;; SERVER: xx1.yy1.zz1.aa1 # 53 (xx1.yy1.zz1.aa1)
;; WHEN: Mon Jun 3 18:52:31 2013
;; MSG SIZE rcvd: 107
;; Got answer:
;; - >> HEADER << - opcode: QUERY, status: NOERROR, id: 53116
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
; site.com. IN A
;; ANSWER SECTION:
site.com. 1835 IN A xxx.yyy.zzz.aaa
site.com. 1835 IN RRSIG A 8 2 3600 20130609232905 (
20130602143424 39964 site.com.
IM + aCUZHZekNnQhjxngyIXUrBUkgCjAxc8o4UuoqvMUu
F1W3L7ge4HVHdWkfmEf / Gk + o8hu7B2MGgP1P9L89 / l3c
gCyVYvIrpR3viVFP7uNtbaoiVdo3bRgtHyFH6QmlTCCW
NrmBHY5sKh / NItAqp1bagQCMYqy71o07oNsNeOU =)
;; AUTHORITY SECTION:
site.com. 1835 IN NS ns4-l2.xxx.ru.
site.com. 1835 IN NS ns8-l2.xxx.ru.
site.com. 1835 IN RRSIG NS 8 2 3600 20130610191139 (
20130603121736 39964 site.com.
ceIOophlVR8zLydk0hVWdtIx / OSLO + kdqQg0opthF5pF
O4NRYgKfkl2tSLGHozzQq0CqzZ0s9rGiE2hnq7M2jJby
Mg9wm1BmHVnmogSat463kpG29Di2U1Yj + AAY8WJ0Gtvv
iYG / atnToDAsLoXgaLfbaYvRCRirCym7LoXjn3Q =)
;; ADDITIONAL SECTION:
ns4-l2.xxx.ru. 1866 IN A abcd1
ns8-l2.xxx.ru. 1866 IN A abcd2
;; Query time: 1 msec
;; SERVER: xx1.yy1.zz1.aa1 # 53 (xx1.yy1.zz1.aa1)
;; WHEN: Mon Jun 3 18:52:31 2013
;; MSG SIZE rcvd: 472
In the above output we see the presence of keys.
And the last check, since everything was done for the xxx registrar, go to your personal account, and perform online DNS testing.
Everything is in order, it remains to make sure that after the expiration of the established validity of the keys, the zones will be re-signed automatically. We see the record in the personal account of the RD “A chain of trust is built”.
If someone points out the possible nuances of customization with MySql, I will test and correct the article.
A lot of information is on the official site.
The article is planned to be corrected to edit the settings related to MySql.
Source: https://habr.com/ru/post/188848/
All Articles