DNS
Contents
-
DNS
- Implementations
- Driving own DNS servers
- Top-Level Domains (TLDs)
- EDNS Client Subnet (ECS)
- Resource Record Types
- DNS Service Discovery (DNS-SD)
- Domain transfer
- DNSsec
- Webtools
- Benchmarking
- Attacks against DNS
- Client problems
- DNS on Android
This is a view on the protocol.
Implementations
Driving own DNS servers
It's worth it.
Recursive name servers
In my opinion recursors are mandatory to be local.
Pro
- Own recursive caching servers reduce latency in name resolution by some magnitudes of order.
- Every little plastic router has a build in DNS server, that is propagated by DHCP. It's not too complex or demanding.
- Internal systems systems still have name resolution on loss of internet uplink and in front of expiry of TTLs (caching).
- Never configure your internal servers to query the internet directly (Active Directory domain controllers, databases, clients, …)
- May use forwards to upstream ISP name servers
- - subject to filtering
- - loss of privacy, since the ISP can read every DNS query
- + to simplify the setup
- Don't expose internal network-structure to external name servers with unencrypted queries for reverse resolution (0.168.192.in-addr.arpa., …).
- Take responsibility
Contra
- Additional resources (time, money (CPU, RAM, Storage, IO))
- Adds some complexity
- Miss-configured name-servers impose a threat to the internet (DDoS).
- Own responsibility
Authoritative name servers
Yeah, drive your own name servers.
Pro
- Practice the knowledge of this important building block in your company
- Internal systems systems still have name resolution on loss of internet uplink and expiry of TTLs (authority).
- Maximum control
- own DNSsec trust anchors
- freedom of implementation
- Maybe with an API to maximize integration
- Maybe with views and split-horizon
- DNS-over-TLS (DoT) or DNS-over-HTTPs (DoH)
- Secondary services like dyndns2 support possible
- Data-set in is local in the house and may be used
- Take responsibility
Contra
- Additional resources (time, money (CPU, RAM, Storage, IO))
- Adds some complexity
- Own responsibility
Top-Level Domains (TLDs)
Groups of TLDs
- generic TLD (gTLD)
- with three or more characters
managed by Internet Corporation for Assigned Names and Numbers (ICANN)
- restricted generic TLD (grTLD)
- managed under official ICANN accredited registrars
- sponsored TLD (sTLD)
- are proposed and sponsored by private agencies or organizations that establish and enforce rules restricting the eligibility to use the TLD. Use is based on community theme concepts;
- managed under official ICANN accredited registrars.
- unsponsored TLD (uTLD)
- country-code TLD (ccTLD)
- two-letter domains established for countries or territories. With some historical exceptions (e.g. .uk (additionally to .gb), .eu for Europe), the code for any territory is the same as its two-letter ISO 3166 code. Creation and delegation of ccTLDs is described in RFC 1591, corresponding to ISO 3166-1 alpha-2 country codes.
- managed by local (IANA) trusted registries
- internationalized ccTLD (IDN ccTLD)
- ccTLDs in non-Latin character sets (e.g., Arabic, Cyrillic, Hebrew, or Chinese) since November 2009;
- Punycode-translated ASCII domain names.
- test TLD (tTLD)
These domains were installed under .test for testing purposes in the IDN development process
- these domains are not present in the root zone.
- infrastructure TLD (iTLD)
- managed by IANA
.root (never actively used)
.arpa (Address and Routing Parameter Area)
.root (never actively used)
.bitnet (decrecated)
.uucp (decrecated)
Lists
- Official, authoritative list of all Top-Level domains published by Internet Assigned Numbers Authority (IANA)
Reserved domains
RFC 6761 reserves the following four top-level domain names to avoid confusion and conflict. Any such reserved usage of those TLDs should not occur in production networks that utilize the global domain name system:
- example: reserved for use in examples
- invalid: reserved for use in obviously invalid domain names
- localhost: reserved to avoid conflict with the traditional use of localhost as a hostname
- test: reserved for use in tests
RFC 6762 reserves the use of .local for link-local host names that can be resolved via the Multicast DNS name resolution protocol.
RFC 7686 reserves the use of .onion for the self-authenticating names of Tor hidden services. These names can only be resolved by a Tor client because of the use of onion routing to protect the anonymity of users.
EDNS Client Subnet (ECS)
PowerDNS:
Resource Record Types
There are quite a lot
1 A, AAAA, AFSDB, APL, CAA, CDNSKEY, CDS, CERT, CNAME, CSYNC, DHCID,
2 DLV, DNAME, DNSKEY, DS, EUI48, EUI64, HINFO, HIP, IPSECKEY, KEY, KX,
3 LOC, MX, NAPTR, NS, NSEC, NSEC3, NSEC3PARAM, OPENPGPKEY, PTR, RRSIG,
4 RP, SIG, SMIMEA, SOA, SRV, SSHFP, TA, TKEY, TLSA, TSIG, TXT, URI,
5 ZONEMD, SVCB, HTTPS
Start Of Authority (SOA)
SOA Record - from Wikipedia, the free encyclopedia
A Start of Authority record (abbreviated as SOA record) is a type of resource record in the Domain Name System (DNS) containing administrative information about the zone, especially regarding zone transfers. The SOA record format is specified in RFC 1035.
Background
Normally DNS name servers are set up in clusters. The database within each cluster is synchronized through zone transfers. The SOA record for a zone contains data to control the zone transfer. This is the serial number and different timespans.
It also contains the email address of the responsible person for this zone, as well as the name of the primary master name server. Usually the SOA record is located at the top of the zone. A zone without a SOA record does not conform to the standard required by RFC 1035.
Structure
- name
- name of the zone (mostly "@")
- IN
- zone class (usually IN for internet)
- SOA
- abbreviation for Start of Authority
- MNAME
- Primary master name server for this zone UPDATE requests should be forwarded toward the primary master[2] NOTIFY requests propagate outward from the primary master
- RNAME
- Email address of the administrator responsible for this zone. (As usual, the email address is encoded as a name. The part of the email address before the @ becomes the first label of the name; the domain name after the @ becomes the rest of the name.
In zone-file format, dots in labels are escaped with backslashes; thus the email address john.doe@example.com would be represented in a zone file as john\.doe.example.com.)
- SERIAL
- Serial number for this zone. If a secondary name server slaved to this one observes an increase in this number, the slave will assume that the zone has been updated and initiate a zone transfer.
- REFRESH
- number of seconds after which secondary name servers should query the master for the SOA record, to detect zone changes.
- Recommendation for small and stable zones:[4] 86400 seconds (24 hours).
- RETRY
- number of seconds after which secondary name servers should retry to request the serial number from the master if the master does not respond. It must be less than Refresh.
- Recommendation for small and stable zones:[4] 7200 seconds (2 hours).
- EXPIRE
- number of seconds after which secondary name servers should stop answering request for this zone if the master does not respond. This value must be bigger than the sum of Refresh and Retry.
- Recommendation for small and stable zones:[4] 3600000 seconds (1000 hours).
IETF RFC1912 Common DNS Operational and Configuration Errors suggests 2-4 weeks (1209600-2419200)
- TTL, a.k.a. MINIMUM
- Time To Live for purposes of negative caching.
- Recommendation for small and stable zones:[4] 172800 seconds (2 days).
- Originally this field had the meaning of a minimum TTL value for resource records in this zone; it was changed to its current meaning by
Abstracted SOA layout
- Strongly annotated
- Names are taken from upper definitions.
moinmoin: Use #!highlight clojure
1 ;ORIGIN IS APPENDED TO ANY NAME-STRING THAT DOES NOT END ON "."
2 $ORIGIN . ;GET ORIGIN FROM BIND CONFIG (named.conf.local)
3 ;$ORIGIN domain.tld. ;SET ORIGIN
4 $TTL 86400 ;DEFAULT TTL FOR RESOURCE RECORDS
5 name zone_class SOA MNAME RNAME (
6 2018110201 ;Serial (ISO 8601 basic format followed by a two-digit counter)
7 86400 ;Refresh (SOA Query Interval in [s])
8 7200 ;Retry (Query Retry Interval after failed query in [s],
9 ; Retry < Refresh < Expire)
10 604800 ;Expire (delay in [s] from contact loss to stop of response)
11 86400 ;Minimum TTL ([s] actually lifetime for negative caching,
12 ;SEE: [[https://tools.ietf.org/html/rfc2308|RFC 2308]])
13 )
14 ; SOA ALREADY ENDED BUT NS RECORDS ARE OF INTEREST DURING ZONE TRANSFER TO!
15 IN NS MNAME
16 IN NS NS1
17 IN NS NS2.other-domain.tld.
Typical impression of a SOA record in BIND syntax
Cleaned up
Serial number changes
Several methods have been established for updates to the SERIAL field of a zone's SOA record:
- The serial number begins at 1, and is simply incremented at every change.
- The serial number contains the date of the last change (in ISO 8601 basic format) followed by a two-digit counter (e.g. 2017031405 = the fifth change dated March 14, 2017). This method is recommended in RFC 1912.
- The serial number is the time of last modification to the zone's data file expressed as the number of seconds since the UNIX epoch. This method is used by default in the djbdns suite. Although it uses a 32-bit counter, it is not susceptible to the year 2038 problem due to the effect of serial number arithmetic.
HINT: IN VIM TRY CTRL+A or CTRL+Y
DNS Certification Authority Authorization (CAA) Resource Record
Set CAA-Record in DNS
1 @ CAA 128 issue "letsencrypt.org"
DNS SRV Records
Here is the format of the SRV RR, whose DNS type code is 33:
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
SRV Mail
Following DNS resource records within the zone allow automatic discovery of your email-services and auto-configuration of your Mail User Agent (MUA).
Prepare a dynamic bind9 zone
Edit zone file
1 $TTL 86400
2 $ORIGIN rockstable.it.
3
4 ; SOA RECORD WITH INCREMENTED SERIAL OMITTED
5
6 @ MX 10 mx1
7
8 mail CNAME mx1
9 smtp CNAME mx1
10 mx1 A 178.63.149.227
11
12 ;SERVICE TYPE PRIO WEIGHT PORT SERVER
13 _imap._tcp SRV 0 1 143 mx1
14 _imaps._tcp SRV 0 1 993 mx1
15 _pop3._tcp SRV 0 1 110 mx1
16 _pop3s._tcp SRV 0 1 995 mx1
17 _submission._tcp SRV 0 1 587 mx1
18 _sieve._tcp SRV 0 1 4190 mx1
The labels mail and smtp are served for Thunderbird Autoconfiguration. Unfortunaltely Thunderbird has no support to resolve the SRV-Records. 
SRV NTP
Automatic discovery of Network Time Protocol Servers
SRV Kerberos
MIT Kerberos #Hostnames for KDCs
MIT recommends that your KDCs have a predefined set of CNAME records (DNS hostname aliases), such as kerberos for the master KDC and kerberos-1, kerberos-2, … for the replica KDCs. This way, if you need to swap a machine, you only need to change a DNS entry, rather than having to change hostnames.
As of MIT krb5 1.4, clients can locate a realm’s KDCs through DNS using SRV records (RFC 2782), assuming the Kerberos realm name is also a DNS domain name. These records indicate the hostname and port number to contact for that service, optionally with weighting and prioritization. The domain name used in the SRV record name is the realm name. Several different Kerberos-related service names are used:
_kerberos._udp
- This is for contacting any KDC by UDP. This entry will be used the most often. Normally you should list port 88 on each of your KDCs.
_kerberos._tcp
- This is for contacting any KDC by TCP. The MIT KDC by default will not listen on any TCP ports, so unless you’ve changed the configuration or you’re running another KDC implementation, you should leave this unspecified. If you do enable TCP support, normally you should use port 88.
_kerberos-master._udp
- This entry should refer to those KDCs, if any, that will immediately see password changes to the Kerberos database. If a user is logging in and the password appears to be incorrect, the client will retry with the master KDC before failing with an “incorrect password” error given.
- If you have only one KDC, or for whatever reason there is no accessible KDC that would get database changes faster than the others, you do not need to define this entry.
_kerberos-adm._tcp
- This should list port 749 on your master KDC. Support for it is not complete at this time, but it will eventually be used by the kadmin program and related utilities.
For now, you will also need the admin_server variable in krb5.conf.
_kpasswd._udp
- This should list port 464 on your master KDC. It is used when a user changes her password. If this entry is not defined
but a _kerberos-adm._tcp entry is defined, the client will use the _kerberos-adm._tcp entry with the port number changed to 749.
The DNS SRV specification requires that the hostnames listed be the canonical names, not aliases. So, for example, you might include the following records in your (BIND-style) zone file:
1 $ORIGIN foobar.com.
2 _kerberos TXT "FOOBAR.COM"
3 kerberos CNAME daisy
4 kerberos-1 CNAME use-the-force-luke
5 kerberos-2 CNAME bunny-rabbit
6 _kerberos._udp SRV 0 0 88 daisy
7 SRV 0 0 88 use-the-force-luke
8 SRV 0 0 88 bunny-rabbit
9 _kerberos-master._udp SRV 0 0 88 daisy
10 _kerberos-adm._tcp SRV 0 0 749 daisy
11 _kpasswd._udp SRV 0 0 464 daisy
Clients can also be configured with the explicit location of services using the kdc, master_kdc, admin_server, and kpasswd_server variables in the [realms] section of krb5.conf. Even if some clients will be configured with explicit server locations, providing SRV records will still benefit unconfigured clients, and be useful for other sites.
Mail eXchanger (MX)
IETF RFC2821 Simple Mail Transfer Protocol
- obsolete but defines "implicit MX RR" better
IETF RFC5321 - preferences
- MX records contain a preference indication that MUST be used in sorting if more than one such record appears (see below). Lower numbers are more preferred than higher ones. If there are multiple destinations with the same preference and there is no clear reason to favor one (e.g., by recognition of an easily reached address), then the sender-SMTP MUST randomize them to spread the load across multiple mail exchangers for a specific organization.
Deny any mail to this domain, ever.
1 example.com MX 0 .
NameServer (NS)
The NameServer resource record
- A NS-RR in a public zone must never be a private IP. Some mail servers check this …
In that case consider using the private IP in also-notify
- When changing objects in the NICs/Domain Name Registries, always prepare everything in your DNS (NS- or DS-RR). Some NICs like the italian NIC ".it" have very strict policies.
- If the fully qualified domain name of a nameserver is a subdomain of a domain it is authoritative for, a circular dependency exists. To resolve this problem, glue RR of type A/AAAA, which provide the IP4/6 addresses of the nameservers,
are necessary in the parent domain.
Wiki EN: DNS Circular dependencies and glue records
DNSsec RR
DNS Security Extensions (DNSSEC).
The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS.
Some old RFCs all updated in the meantime.
IETF RFC4034 Resource Records for the DNS Security Extensions
IETF RFC4035 Protocol Modifications for the DNS Security Extensions
Resource records:
- public key (DNSKEY)
- delegation signer (DS)
- resource record digital signature (RRSIG)
- authenticated denial of existence (NSEC)
- hashed authenticated denial of existence (NSEC3)
- child delegation signer (CDS)
- child DNSKEY (CDNSKEY)
Delegation signer (DS)
The record used to identify and validate the DNSSEC signing key of a delegated zone.
RFC 4034 Resource Records for the DNS Security Extensions Section 5 The DS Resource Record
The DS Resource Record refers to a DNSKEY RR and is used in the DNS DNSKEY authentication process. A DS RR refers to a DNSKEY RR by storing the key tag, algorithm number, and a digest of the DNSKEY RR. Note that while the digest should be sufficient to identify the public key, storing the key tag and key algorithm helps make the identification process more efficient. By authenticating the DS record, a resolver can authenticate the DNSKEY RR to which the DS record points. The key authentication process is described in IETF RFC4035.
The DS RR and its corresponding DNSKEY RR have the same owner name, but they are stored in different locations. The DS RR appears only on the upper (parental) side of a delegation, and is authoritative data in the parent zone. For example, the DS RR for "example.com" is stored in the "com" zone (the parent zone) rather than in the "example.com" zone (the child zone). The corresponding DNSKEY RR is stored in the "example.com" zone (the child zone). This simplifies DNS zone management and zone signing but introduces special response processing requirements for the DS RR; these are described in IETF RFC4035.
The type number for the DS record is 43.
The DS resource record is class independent.
The DS RR has no special TTL requirements.
DS example
The following example shows a DNSKEY RR and its corresponding DS RR.
1 dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
2 fwJr1AYtsmx3TGkJaNXVbfi/
3 2pHm822aJ5iI9BMzNXxeYCmZ
4 DRD99WYwYqUSdjMmmAphXdvx
5 egXd/M5+X7OrzKBaMbCVdFLU
6 Uh6DhweJBjEVv5f2wwjM9Xzc
7 nOf+EPbtG9DMBmADjFDc2w/r
8 ljwvFw==
9 ) ; key id = 60485
10
11 dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
12 98631FAD1A292118 )
NextSECure (NSEC)
Authenticated denial of existence
The NSEC resource record lists two separate things: the next owner name (in the canonical ordering of the zone) that contains authoritative data or a delegation point NS RRset, and the set of RR types present at the NSEC RR's owner name [RFC3845]. The complete set of NSEC RRs in a zone indicates which authoritative RRsets exist in a zone and also form a chain of authoritative owner names in the zone. This information is used to provide authenticated denial of existence for DNS data, as described in IETF RFC4035.
Because every authoritative name in a zone must be part of the NSEC chain, NSEC RRs must be present for names containing a CNAME RR. This is a change to the traditional DNS specification [RFC1034], which stated that if a CNAME is present for a name, it is the only type allowed at that name. An RRSIG (see Section 3) and NSEC MUST exist for the same name as does a CNAME resource record in a signed zone.
See IETF RFC4035 for discussion of how a zone signer determines precisely which NSEC RRs it has to include in a zone.
The type value for the NSEC RR is 47.
The NSEC RR is class independent.
The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL field. This is in the spirit of negative caching (IETF RFC2308).
NSEC example
These records themselfes are authenticated by their own RRSIG-RR.
The following NSEC RR identifies the RRsets associated with alfa.example.com. and identifies the next authoritative name after alfa.example.com.
So there is no name between alfa.example.com. and host.example.com.
The Next Domain Name Field 'host.example.com' allows to gather information by zone walking. Therefore #NextSECure3 (NSEC3) was indroduced.
NextSECure3 (NSEC3)
Hashed Authenticated Denial of Existence
NSEC3 example
You may calculate a NSEC3 hash with nsec3hash
1 ### Usage: nsec3hash salt algorithm iterations domain
2 # nsec3hash CA12B74ADB90591A 1 15 example-domain-does-not-exist.de
3 BRSD1OSC2HU0G6I5CLH99A8VRC9IJE02 (salt=CA12B74ADB90591A, hash=1, iterations=15)
4 # nsec3hash CA12B74ADB90591A 1 15 de
5 TJLB7QBOJVMLF1S6GDRIRU7VSMS1LG16 (salt=CA12B74ADB90591A, hash=1, iterations=15)
6 # nsec3hash CA12B74ADB90591A 1 15 '*.de'
7 NIHKEQI54QCK38BPFVGGV7RQ5JRRD2VP (salt=CA12B74ADB90591A, hash=1, iterations=15)
Example example-domain-does-not-exist.de
1 dig +dnssec @ns3.rockstable.org example-domain-does-not-exist.de
2 …
3 ;; QUESTION SECTION:
4 ;example-domain-does-not-exist.de. IN A
5
6 ;; AUTHORITY SECTION:
7 de. 6200 IN SOA f.nic.de. its.denic.de. 1596536258 7200 7200 3600000 7200
8 de. 6200 IN RRSIG SOA 8 1 86400 20200818101721 20200804084721 53031 de. ib/6DpoLaoYng35Xx7jcZ6pfW0mDytrJmK3FgorgH0ZMatfBcDsN31lP HgG/CDPXn/KLSCsqA+gwammIkqOHusM2c/TaaeCJQyVDSt6wCWs3j6ox E4sRZYbI+pABqjR3O2YrZDHDrAtvU1UCd5Pw0qI1jxPLju7+Nk+2XX+a JDM=
9
10 ### DOMAIN "example-domain-does-not-exist.de" DOES NOT EXIST
11 brs96vbp1sahe35lpkt3uoogsq5bnah4.de. 6200 IN RRSIG NSEC3 8 2 7200 20200817031534 20200803014534 53031 de. XY2eZDo3fKyDCsUzK0EnP2Z8qSk5lFNu0SUROkvyNQG4BL5L13qp6JVZ 9DsEaPB6TiouK2f7XL6KauAsEUD0jsBJOYxTSY74wLmBQbGXrd21q0UN rsi4/XXSqD8aP6H6cKVb7mzdcqr8iF27DbUTKYZJQmZu/W3cTavlKLIL RQU=
12 brs96vbp1sahe35lpkt3uoogsq5bnah4.de. 6200 IN NSEC3 1 1 15 CA12B74ADB90591A BRSDPAF1BH7JFSTL8A9MAKVIEHE8QJMI NS DS RRSIG
13
14 ### WILDCARD "*.de" DOES NOT EXIST
15 nihitgish70cve28nu73a3segd6r1d4p.de. 6200 IN RRSIG NSEC3 8 2 7200 20200817031534 20200803014534 53031 de. DkwxuXIqGbshC5fOBRUKW1hWkAdWPBQjioSyhPrNbcs325vB26QSIa8R cKImwrtJ3qUAmpCdP8IcO1So6p/KW7YCoORt88a/lj+N3RKF67Val5Ie KgJpq3PKwn8umszbNRYFJPIKkugERE8xWggopE6q9hN9fvh3DIQ4X+Je Rpg=
16 nihitgish70cve28nu73a3segd6r1d4p.de. 6200 IN NSEC3 1 1 15 CA12B74ADB90591A NIHRI169E5SB3FJMDM1I3LTSNURVSITQ NS DS RRSIG
17
18 ### DOMAIN "de" EXISTS
19 tjlb7qbojvmlf1s6gdriru7vsms1lg16.de. 6200 IN RRSIG NSEC3 8 2 7200 20200817015011 20200803002011 53031 de. ZLyo18DvvCZenk+FKcjiYhnESjoOLx8bacE3DQ0E5MtgFBXEJP3Ayxuf vIRiwCMlEuicS/wntH5Jj7sKvJ7I19Wq+IBvVSS5X+W5fWLlhqOxYXnW Kg2t5khcNwupF4716RVUyirh2brCp2vo78WMm/jXNFtFaLoeM9d0tza8 b2k=
20 tjlb7qbojvmlf1s6gdriru7vsms1lg16.de. 6200 IN NSEC3 1 1 15 CA12B74ADB90591A TJLD25EJ1NKGCSHQ3OM1J58DHA96ULK7 NS SOA RRSIG DNSKEY NSEC3PARAM
The answer states that a domain, which hash is in between of BRS96VBP1SAHE35LPKT3UOOGSQ5BNAH4 and BRSDPAF1BH7JFSTL8A9MAKVIEHE8QJMI does not exists. The calculated hash (RSASHA1-NSEC3-SHA1) of example-domain-does-not-exist.de is BRSD1OSC2HU0G6I5CLH99A8VRC9IJE02 in between. The domain does therefore not exist. Wrapping domain 'de' exists. There is no wildcard domain matching. See the calculated hashes above.
Note:<<BR>> When NSEC3 records are not generated dynamically, zone walking may still be performed by attacking the hash functions.
NextSECure3 parameters (NSEC3PARAM)
NSEC3PARAM example
Example for de.
DNSKEY
The public key
DNSSEC uses public key cryptography to sign and authenticate DNS resource record sets (RRsets). The public keys are stored in DNSKEY resource records and are used in the DNSSEC authentication process described in [RFC4035]: A zone signs its authoritative RRsets by using a private key and stores the corresponding public key in a DNSKEY RR. A resolver can then use the public key to validate signatures covering the RRsets in the zone, and thus to authenticate them.
The DNSKEY RR is not intended as a record for storing arbitrary public keys and MUST NOT be used to store certificates or public keys that do not directly relate to the DNS infrastructure.
The Type value for the DNSKEY RR type is 48.
The DNSKEY RR is class independent.
The DNSKEY RR has no special TTL requirements.
DNSKEY example
The following DNSKEY RR stores a DNS zone key for example.com.
Resource record digital signature (RRSIG)
Resource record digital signature
DNSSEC uses public key cryptography to sign and authenticate DNS resource record sets (RRsets). Digital signatures are stored in RRSIG resource records and are used in the DNSSEC authentication process described in [RFC4035]. A validator can use these RRSIG RRs to authenticate RRsets from the zone. The RRSIG RR MUST only be used to carry verification material (digital signatures) used to secure DNS operations.
An RRSIG record contains the signature for an RRset with a particular name, class, and type. The RRSIG RR specifies a validity interval for the signature and uses the Algorithm, the Signer's Name, and the Key Tag to identify the DNSKEY RR containing the public key that a validator can use to verify the signature.
Because every authoritative RRset in a zone must be protected by a digital signature, RRSIG RRs must be present for names containing a CNAME RR. This is a change to the traditional DNS specification [RFC1034], which stated that if a CNAME is present for a name, it is the only type allowed at that name. A RRSIG and NSEC (see Section 4) MUST exist for the same name as a CNAME resource record in a signed zone.
The Type value for the RRSIG RR type is 46.
The RRSIG RR is class independent.
An RRSIG RR MUST have the same class as the RRset it covers.
The TTL value of an RRSIG RR MUST match the TTL value of the RRset it covers. This is an exception to the [RFC2181] rules for TTL values of individual RRs within a RRset: individual RRSIG RRs with the same owner name will have different TTL values if the RRsets they cover have different TTL values.
RRSIG example
The following RRSIG RR stores the signature for the A RRset of host.example.com:
Child DS (CDS) and Child DNSKEY (CDNSKEY)
IETF RFC8078 Managing DS Records from the Parent via CDS/CDNSKEY
- This document specifies two new DNS resource records, CDS and CDNSKEY. These records are used to convey, from one zone to its Parent, the desired contents of the zone's DS resource record set residing in the Parent zone. The CDS and CDNSKEY resource records are published in the Child zone and give the Child control of what is published for it in the parental zone. The Child can publish these manually, or they can be automatically maintained by DNS provisioning tools. The CDS/CDNSKEY RRset expresses what the Child would like the DS RRset to look like after the change; it is a "replace" operation, and it is up to the software that consumes the records to translate that into the appropriate add/delete operations in the provisioning systems (and in the case of CDNSKEY, to generate the DS from the DNSKEY). If neither CDS nor CDNSKEY RRset is present in the Child, this means that no change is needed.
TLSA - DANE
DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC).
Certbot has the ability to reuse the RSA-Keypair on renewal. So the Certificate fingerprint no longer changes.
Calculate certificate fingerprint
1 ### ALT1
2 openssl x509 -noout -fingerprint -sha256 < /etc/letsencrypt/live/mx1.rockstable.it/cert.pem \
3 |tr -d : \
4 |cut -f2 -d=
5 99B5773FDDB0309C65D5507B15E89883E6B9A47C05A567B00F31DEF12EECECE0
6 ### ALT2
7 openssl x509 -outform DER < /etc/letsencrypt/live/mx1.rockstable.it/cert.pem \
8 |openssl sha256 \
9 |cut -f2 -d\
10 99b5773fddb0309c65d5507b15e89883e6b9a47c05a567b00f31def12eecece0
11 ### ALT3
12 openssl x509 -outform DER < /etc/letsencrypt/live/mx1.rockstable.it/cert.pem \
13 |openssl dgst -sha256 -binary \
14 |hexdump -ve '/1 "%02x"'
15 99b5773fddb0309c65d5507b15e89883e6b9a47c05a567b00f31def12eecece0#
16 ### ALT4 DISCOURAGED AND UNTESTED
17 ### PROBABLY WRONG WAY (HASHES PUBKEY INSTEAD OF CERT)
18 #openssl x509 -noout -pubkey < /etc/letsencrypt/live/mx1.rockstable.it/cert.pem \
19 # |openssl pkey -pubin -outform DER \
20 # |openssl dgst -sha256 -binary \
21 # |hexdump -ve '/1 "%02x"'
22 #094023194bacf2b540ba61a3351bd6b020721fe9b2f940c0c9ec806f56350eb6
23
TXT
https://en.wikipedia.org/wiki/TXT_record
A TXT record (short for text record) is a type of resource record in the Domain name system(DNS) used to provide the ability to associate arbitrary text with a host or other name, such as human readable information about a server, network, data center, or other accounting information.
It is also often used in a more structured fashion to record small amounts of machine-readable data into the DNS.
Used for various tasks
postfix#Domain-based Message Authentication, Reporting and Conformance (DMARC)
- SEO site verification
Example
dig TXT rockstable.it +multi
DNS Service Discovery (DNS-SD)
DNS Service Discovery is a way of using standard DNS programming interfaces, servers, and packet formats to browse the network for services.
Domain transfer
Other names:
- change provider (CHPROV)
- Konnektivitäts-Koordination (KK)
ICANN Extensible Provisioning Protocol (EPP) domain status codes
Authinfo
https://en.wikipedia.org/wiki/Domain_name_registrar#Domain_name_transfer
ICANN Extensible Provisioning Protocol (EPP) domain status codes
Domain Management Provider
My requirements for a Domain Management Provider
- Reasonable prices for new domains
Customer support that actually responds in reasonable time (1d < 8h < t)
- Fast website with nice UX
- Secure authentication with 2FA
- at leatst TOTP
- i'd love to see FIDO2
- High degree of automation, minimal grade of manual interaction
- Good documentation (like a wiki)
- Support for DNSsec
- I take this as an indicator that they are willing to try "new" things, which are too difficult for others. They are able to get out of their comfort zone.
- (Optionally) green power.
- German company
This is a list of DNSsec Domain Resellers There are many.
I decided for https://www.domaindiscount24.com by https://www.key-systems.net.
Process
CHILL!1!!
There will be problems! Expect them! Be prepared. Be patient. :-D
Especially with mass migrations and country code TLDs with strict policies.
Timing - it's quite slow
- My ".it"-domain-transfer took one day.
- My ".org"-domain-transfer is estimated to finish after 6 days.
Transfering a domain from one provider to another.
- Adjust your high-availablity scenarios.
- pick a good time, where you don't need to change anything on your domain. It will take a while …
- Save the domain names and IP-addresses of your name servers locally. In case you need it for GLUE Records in the parent domain.
- Decide for a new domain management provider.
- Make sure you have access to both domain management systems (source and destination).
- Configure a payment method on the new provider.
- Release the domains on the old provider.
Wait for the AuthCode to be displayed. This may take 60s up to 24h.
- Enter the domains and their authcode in the formular of the new provider. The exact format depends on your provider (space/colon/…).
- Follow the guidance in the webinterface to avoid trouble (PEBKAC).
- read _all_ the options and make sure you understand them.
e.g. ENTITY-TYPE (nic.it) -> 7:
Allowed values: 1 Italian and foreign natural persons 2 Companies/one man companies (only IT) 3 Freelance workers/professionals (only IT) 4 non-profit organizations(only IT) 5 public organizations (only IT) 6 other subjects (only IT) 7 foreigner companies/organizations who match 2-6 (all other EU member countries)
- complete ownership, company and contact information.
- allow disclosure of personal information
- accept the registry policies
- accept the policies,… of the provider
- confirm
- Whois domain status changes
from Status: ok to Status: pendingTransfer
- Whois domain status changes
- read _all_ the options and make sure you understand them.
Wait patiently
- for the failure
- Contact the provider
- The provider certainly knows how to fix it
- Back to "Wait patiently :-)"
- for success
- for the failure
- Check, double check and correct whois-info !1!!
- nameservers should be congruent to your authoritative zone's NS-RR
- Check if glue records are of the right amount and if they are correct
- contacts owner-, admin-, tech- and billing-contact
- maybe create a whois-set from contacts
- make sure every domain has all 4 contacts set
- think about enabling whois-privacy
- done
If you've had no problems, were prepared really well. Nice.
DNSsec
Reasoning
Pro
- Provides authenticity and integrity
- Protection against techniques that attack DNS (like MITM-Attacks, (Kaminiski) DNS Spoofing/Poisoning)
- Prove of existence and non-existence (no gaps)
- Most TLDs are signed
- Use of DANE to secure self-signed certs
Contra
- Some extra complexity (server and client)
- NSEC zone enumeration possible, but NSEC3 helps
- some extra latency on first resolution of a domain.
- Limited client and server support
- Limited support from domain resellers, which is annoying.
Process of enabling DNSsec
- Make sure you understand DNSsec (RFCs).
- Make sure you understand your implementation of choice (bind9, PowerDNS, …).
- Make sure your domain name registrar supports publishing of Delegation Signer (DS) records
- If you are using 3rd party nameservers make sure they support DNSsec.
- Define a dnssec-policy and rollover strategy.
- Prepare your name server.
- Create Key Signing Key (KSK).
- Create Zone Signing Key (ZSK).
- Prepare your DS RR.
- Sign your zone.
- Adjust nsec3 parameters at will.
- Test your zone and your records!
- Be sure!1!!
- Publish Delegation Signer (DS) RR in parent zone.
- Test it!!1!
- Roll it (from time to time).
- Change NSEC3PARAM salt (from time to time).
Webtools
Benchmarking
By the usage of benchmarking, i was able to identify a configuration problem with the adblocker in my openwrt-router and speed up DNS requests extremely.
dnsdiag
Install
1 apt install dnsdiag
dnseval is a bulk ping utility that sends an arbitrary DNS query to a given list of DNS servers. This script is meant for comparing response time of multiple DNS servers at once.
Create a server.list or configured OS resolver will be used
dnseval
1 % dnseval -C -f server.list rockstable.it
2 server avg(ms) min(ms) max(ms) stddev(ms) lost(%) ttl flags
3 ----------------------------------------------------------------------------------------------------------------
4 ns3.rockstable.org. 27.204 17.369 46.375 11.029 %0 86400 QR AA -- RD RA -- --
5 ns4.rockstable.org. 23.405 17.237 41.271 7.602 %0 86400 QR AA -- RD RA -- --
6 192.168.182.1 135.950 106.881 216.447 36.557 %0 86400 QR AA -- RD RA -- --
7 8.8.8.8 33.768 24.764 67.073 14.191 %0 21585 QR -- -- RD RA -- --
dnsping pings a DNS resolver by sending an arbitrary DNS query for given number of times. It calculates minimum, maximum and average response time as well as jitter (stddev).
dnsping
1 # dnsping rockstable.it
2 dnsping DNS: 192.168.182.1:53, hostname: rockstable.it, rdatatype: A
3 40 bytes from 192.168.182.1: seq=1 time=109.288 ms
4 40 bytes from 192.168.182.1: seq=2 time=140.449 ms
5 40 bytes from 192.168.182.1: seq=3 time=107.434 ms
6 40 bytes from 192.168.182.1: seq=4 time=107.955 ms
7 40 bytes from 192.168.182.1: seq=5 time=107.957 ms
8 ^C
9 --- 192.168.182.1 dnsping statistics ---
10 5 requests transmitted, 5 responses received, 0% lost
11 min=107.434 ms, avg=114.617 ms, max=140.449 ms, stddev=14.457 ms
12 # dnsping -s 8.8.8.8 rockstable.it
13 dnsping DNS: 8.8.8.8:53, hostname: rockstable.it, rdatatype: A
14 40 bytes from 8.8.8.8: seq=1 time=28.992 ms
15 40 bytes from 8.8.8.8: seq=2 time=30.218 ms
16 40 bytes from 8.8.8.8: seq=3 time=26.093 ms
17 40 bytes from 8.8.8.8: seq=4 time=26.565 ms
18 40 bytes from 8.8.8.8: seq=5 time=23.357 ms
19 ^C
20 --- 8.8.8.8 dnsping statistics ---
21 5 requests transmitted, 5 responses received, 0% lost
22 min=23.357 ms, avg=27.045 ms, max=30.218 ms, stddev=2.674 ms
Ohh, my router in the local network seams to be quite slow…
dnstraceroute is a traceroute utility to figure out the path that a DNS request is passing through to get to its destination. Comparing it to a network traceroute can help identify if DNS traffic is routed via any unwanted path.
Trace the path a DNS-request travels along. dnstraceroute
1 # sudo dnstraceroute -Cea -s ns4.rockstable.org rockstable.it
2 dnstraceroute DNS: 78.47.38.48:53, hostname: rockstable.it, rdatatype: A
3 1 quasar.domain.tld (192.168.182.1) 1.812 ms
4 2 ipADDRESS.dynamic.kabel-deutschland.de (IP.ADD.RE.SS) [AS3209 VODANET International IP-Backbone of Vodafone, DE] 13.736 ms
5 3 83-169-181-254-isp.superkabel.de (83.169.181.254) [AS3209 VODANET International IP-Backbone of Vodafone, DE] 13.670 ms
6 4 ip5886c0f1.static.kabel-deutschland.de (88.134.192.241) [AS3209 VODANET International IP-Backbone of Vodafone, DE] 16.776 ms
7 5 145.254.3.68 (145.254.3.68) [AS3209 VODANET International IP-Backbone of Vodafone, DE] 9.191 ms
8 6 145.254.2.179 (145.254.2.179) [AS3209 VODANET International IP-Backbone of Vodafone, DE] 17.176 ms
9 7 145.254.2.179 (145.254.2.179) [AS3209 VODANET International IP-Backbone of Vodafone, DE] 17.767 ms
10 8 decix2-gw.hetzner.com (80.81.193.164) 16.208 ms
11 9 core24.fsn1.hetzner.com (213.239.203.150) [AS24940 HETZNER-AS, DE] 38.136 ms
12 10 spine1.cloud2.fsn1.hetzner.com (213.239.239.126) [AS24940 HETZNER-AS, DE] 25.434 ms
13 11 *
14 12 12420.your-cloud.host (136.243.183.34) [AS24940 HETZNER-AS, DE] 19.371 ms
15 13 *
16 14 ns4.rockstable.org (78.47.38.48) [AS24940 HETZNER-AS, DE] 22.618 ms
namebench
namebench - open-source DNS benchmark utility
https://github.com/google/namebench
namebench searches the fastest DNS servers available for your computer to use. namebench runs a fair and thorough benchmark using your web browser history, tcpdump output, or standardized dataset in order to provide an individualized recommendation.
Install
1 apt install namebench
Defaults are in
/etc/namebench/namebench.cfg
1 # NOTE: Most settings can be overriden on the command line
2 # with the appropriate --option to namebench.py
3
4 [general]
5
6 # Number of tests to run
7 query_count=250
8
9 # number of runs
10 run_count=1
11
12 # Selection algorithm to pick tests with (automatic, weighted, random, chunk)
13 select_mode=automatic
14
15 # If you are on a shared shell-server, you may want to set this to 8.
16 # If you are on Windows, we limit you to no more than 60 automatically.
17 # If you are on other platforms, we limit you to no more than 90 automatically.
18 health_thread_count=40
19
20 # How many threads to use for the benchmark. nb 1.1 defaulted to 1 thread.
21 benchmark_thread_count=2
22
23 # How long should we wait for general queries to complete (seconds)
24 timeout=3.5
25
26 # How long to wait for an initial nameserver ping (seconds)
27 ping_timeout=0.5
28
29 # How long should we wait for secondary health checks to complete (seconds)
30 health_timeout=3.75
31
32 # How many servers should we include in our benchmark test
33 num_servers=11
34
35 # Results sharing. Must be enabled by using -u or from the GUI.
36 site_url=http://namebench.appspot.com/
37 upload_results=0
38 hide_results=0
39
40 # Always include at least one of each anycast service in the benchmarks.
41 [global]
42 8.8.8.8=Google Public DNS
43 8.8.4.4=Google Public DNS-2
44 156.154.70.1=UltraDNS
45 156.154.71.1=UltraDNS-2
46 208.67.220.220=OpenDNS
47 208.67.222.222=OpenDNS-2
48 216.146.35.35=DynGuide
49 216.146.36.36=DynGuide-2
50 2001_470_20__2=Hurricane Electric IPv6
51
52 [regional]
53 # LINES OMITTED
54
55 # These are unlikely to work for most people, but are useful enough to keep
56 [private]
Namebench only extracts IP-Adresses as nameservers, don't provide domain-names.
namebench with gui
namebench without gui
Attacks against DNS
- Kashpureff Attack
- "Man-In-The-Middle" Attacks
- Betrayal of a trusted nameserver
- Attack on Authoritative Data on the Nameserver itself
- (Distributed) Denial of Service (search for BCP 38)
- NSEC Domain Walking
Using the source port with randomization along with the Query ID, raised the bar to performing the Kaminsky Attack. The only real fix to the Kaminsky Attack is DNSsec.
Client problems
When /etc/resolv.conf contains nameserver 127.0.0.53. This is a clue for systemd-resolved. This may for example be the case on Ubuntu 16.04+. If you are stuck without DNS-resolution, just enable the service.
Little script that restores DNS resolution and adds back some control.
Short version
1 sudo bash -c 'systemctl enable systemd-resolved.service; reboot'
DNS on Android
WiFi
It's pretty easy to get and change DNS of your WiFi connection.
Get:
Settings > Network & Internet > WiFi > Choose Active SSID
Set:
Settings > Network & Internet > WiFi > Choose Active SSID (long click) > Change Network > IP Settings > Static > DNS1/2
Mobile data
Get DNS Android DNS servers of mobile data is much harder. Install a terminal emulator (like android-terminal-emulator (, doesn't work in termux?)) and open a shell.
Get
Set ???