DNS
DNSSec
- Before starting your DNSSEC deployment, check with your parent zone administrators to make sure they support DNSSEC. This may or may not be the same entity as your registrar.
- DNSSEC is enabled on a zone-by-zone basis. When a zone is DNSSEC-enabled, it is also known as “signed.”
- the trustworthiness of each zone is guaranteed by its parent zone, all the way back to the root zone.
- To convert a traditional (insecure) DNS zone to a secure one, we need to create some additional records (DNSKEY, RRSIG, and NSEC or NSEC3), and upload verifiable information (such as a DS record) to the parent zone to complete the chain of trust.
- RFC 8624 recommends using algorithm 13 (ECDSA Curve P-256 with SHA-256) alongside algorithm 8 (RSA/SHA-256)
- From version 9.16, policies for key management and zone signing can be specified in the configuration file named.conf. The software will then automatically ensure that signatures (RRSIG records) and ZSK/KSK pairs are always up-to-date. As a result, scripts and cron jobs are no longer necessary to keep signed zones updated.
- Auto-DNSSEC ('auto-dnssec maintain') is deprecated in favour of DNSSEC Policy.
- auto-dnssec has been removed since the 9.19.16 development release, and the upcoming 9.20.0 release.
- dnssec-policy requires either the zone to be dynamic (allowing dynamic updates), or inline-signing to be enabled
- DNSSEC is backwards-compatible to “standard” DNS.
- Once zone is signed, contact your parent zone administrator upload to your parent zone, with the DNSKEY and DS records:
- DNSKEY and DS key is in file: /etc/bind/Kexample.com.+013+10376.key
- Without the DS record(s) in your parent zone, other validating resolvers treat your zone as an insecure (traditional) zone, and no actual verification is carried out. To the rest of the world, your zone still appears to be insecure, and it will continue to be insecure until your parent zone can host the DS record(s) for you and tell the rest of the world that your zone is signed.
- If your parent zone supports polling for CDS/CDNSKEY records, they are uploaded and the DS record published in the parent automatically.
- When the parent notices the presence of the CDS and/or CDNSKEY record(s) in the child zone - the parent zone’s DS RRset for the child zone is changed to correspond to the CDS (or CDNSKEY) records.
- CDS/CDNSKEY records automatically generated by BIND
- For security reasons, a parent zone that supports CDS/CDNSKEY may require the DS record to be manually uploaded when we first sign the zone. Until our zone is signed, the parent cannot be sure that a CDS or CDNSKEY record it finds by querying our zone really comes from our zone
- If your parent zone doesn’t support CDS/CDNSKEY, you will have to supply the DNSKEY or DS record to the parent zone manually when a new KSK appears in your zone
- Whenever you update your zone, BIND automatically re-signs your zone with new RRSIG and NSEC/NSEC3 records, and even increments the serial number for you.
- The public keys are synchronized from primary to secondary server(s) as part of the zone transfer.
- The private keys are not, and should not be, stored anywhere other than secured on the primary server.
# /etc/bind/named.conf
zone "example.fr" {
type master;
file "/var/lib/bind/masters/example.fr";
allow-update {
key "xmlrpc-key";
key "xmlrpc-key-sha512";
};
allow-transfer {
trusted-dns;
};
allow-query {
any;
};
inline-signing yes;
dnssec-policy "default";
};
Check DNSSec https://dnssec-debugger.verisignlabs.com/example.fr
Reload config: rndc reconfig
Zone status: rndc zonestatus example.fr IN public
DNSSec status: rndc dnssec -status example.fr IN public
Signing status: rndc signing -list example.fr IN public
Check config: named-checkconf /etc/bind/named.conf
Check zone: named-checkzone example.fr /var/lib/bind/masters/example.fr
Query DNS: dig @127.0.0.1 example.fr +dnssec +multiline
Get DS RR for parent zone of signed zone: (d=example.fr; dig +norecurse "$d". DNSKEY | dnssec-dsfromkey -f - "$d")
Get DNSKEY for signed zone: dig example.fr DNSKEY +multiline
DNS slave replication
- Primary (Master) DNS Server holds the read-write copy of the zone files.
-
Secondary (Slave) DNS Server obtains the zone data from the primary server and holds a read-only copy.
-
NOTIFY: When a zone is updated on the primary DNS server, it sends a NOTIFY message to the secondary DNS servers to inform them of the update.
- AXFR: The secondary DNS servers, upon receiving a NOTIFY, initiate a zone transfer (AXFR) to fetch the updated zone data from the primary server.
SOA Serial Number: Ensure the SOA record's serial number in the zone file is incremented with each update so that secondary servers recognize the changes.
Zone transfers to all Slave Name Servers may be passive (the Slave will periodically poll the Master) or Active (the Master will send a NOTIFY to its configured Slave(s)). The (very common) way to deal with delays from slave-initiated zone transfers is to combine NOTIFY + AXFR If the SOA serial number remains the same, then the zone is unchanged. Zone transfers are always initiated by the secondary server (that is, they are 'requested' or 'pulled'). While there are mechanisms in place to alert secondaries that they should check to see if a zone transfer is needed, the transfer itself is always started by the secondary. The Slave always intitiates a zone transfer operation (using AXFR or IXFR) using TCP on Port 53 (this can be configured using the transfer-source statement). The original DNS specifications (RFC 1034 & RFC 1035) envisaged that Slave (or secondary) Name Servers would 'poll' the Domain (or zone) Master. The time between such 'polling' is determined by the refresh value on the domain's SOA Resource Record The polling process is accomplished by the Slave sending a query to the Master requesting its current SOA resource record (RR). If the serial number of this RR is higher than the current one maintained by the Slave, a zone transfer (AXFR) is requested. This is why it is vital to be very disciplined about updating the SOA serial number every time anything changes in ANY of the zone records. If a valid notify is received where the notify carries a serial number larger than the one in the SOA currently served by the slave then the secondary zone will again schedule a zone refresh. RFC 1996 introduced a scheme whereby the Master will send a NOTIFY message to the Slave Name Server(s) that a change MAY have occurred in the domain records. The Slave(s) on receipt of the NOTIFY will request the latest SOA Resource Record and if the serial number of the SOA RR is greater than its current value it will initiate a zone transfer using either a Full Zone Transfer (AXFR) or an Incremental Zone Transfer (IXFR). NOTIFY behaviour in BIND is controlled by notify, also-notify and notify-source parameters in the zone or options statements of the named.conf file.
Primary (Master) DNS Server Configuration
- Named Configuration (/etc/named.conf):
options { directory "/var/named"; // Default directory for zone files allow-transfer { 192.0.2.2; }; // Allow zone transfers to the secondary server also-notify { 192.0.2.2; }; // Notify the secondary server of zone changes notify yes; // Enable notifications version none; // Hide the BIND version }; zone "example.com" { type master; file "example.com.db"; allow-transfer { 192.0.2.2; }; // Allow transfers to the specified secondary server }; - Zone File (/var/named/example.com.db):
$TTL 86400 @ IN SOA ns1.example.com. admin.example.com. ( 2023101501 ; Serial number 3600 ; Refresh 1800 ; Retry 1209600 ; Expire 86400 ) ; Minimum TTL IN NS ns1.example.com. IN NS ns2.example.com. ns1 IN A 192.0.2.1 ns2 IN A 192.0.2.2
Secondary (Slave) DNS Server Configuration
- Named Configuration (/etc/named.conf):
options { directory "/var/named"; // Default directory for zone files recursion no; // Ensure the server is authoritative only version none; // Hide the BIND version }; zone "example.com" { type slave; file "slaves/example.com.db"; masters { 192.0.2.1; }; // IP address of the primary DNS server };