DNS
Contents
-
DNS
- Implementations
- Driving own DNS servers
- Public Recursive DNS-Servers
- Top-Level Domains (TLDs)
- EDNS Client Subnet (ECS)
- Check SOA Consitency
- Resource Record Types
- DNS Service Discovery (DNS-SD)
- Domain transfer
- DNSsec
- Webtools
- Tools
- 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
Trouble Shooting DNS problems
The error messages e.g. in zone transfers may not be to obvious "Not an authoritative server/NotAuth".
Use tcpdump and wireshark to track down the problem!
You'll find it.
Some possible reasons for "NotAuth"
- Wrong NAT IP?
- Nofifies are signed with TSIG,
but TSIG is not configured on the slave? -> Wireshark …
Public Recursive DNS-Servers
FQDN |
IP |
Comment |
one.one.one.one. |
1.0.0.1, 1.1 |
|
one.one.one.one. |
1.1.1.1 |
|
dns.google. |
8.8.4.4 |
|
dns.google. |
8.8.8.8 |
|
dns9.quad9.net. |
9.9.9.9 |
|
resolver1-fs.opendns.com. |
208.67.222.123 |
Cisco FamilyShield nameservers |
resolver2-fs.opendns.com. |
208.67.220.123 |
Cisco FamilyShield nameservers |
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:
Check SOA Consitency
1 host -C rockstable.it
2 Nameserver 78.47.38.48:
3 rockstable.it has SOA record ns3.rockstable.org. hostmaster.rockstable.it. 2020101377 86400 3600 2419200 21600
4 Nameserver 195.201.246.253:
5 rockstable.it has SOA record ns3.rockstable.org. hostmaster.rockstable.it. 2020101377 86400 3600 2419200 21600
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
https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-cabrowser-forum
IETF RFC6844 DNS Certification Authority Authorization (CAA) Resource Record
Set CAA-Record in DNS
Three properties are defined:
- issue
- issuewild
- iodef
The Incident Object Description Exchange Format (IODEF) IETF RFC5070 is used to present the incident report in machine-readable form.
Notes on evaluation:
- Subdomains take precedence over domain properties.
- With wildcard domains issuewild takes precedence over the issue property.
- Use of DNSSEC to authenticate CAA RRs is strongly RECOMMENDED but not required.
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. 
Please test if your SRV records can be resolved, there may be an issue with the DNS resolver (e.g. related to DNSsec).
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.
SRV XMPP
Please see ejabberd#SRV-Records
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.
IETF RFC2821 - implicit MX Record
- If no MX records are found, but an A RR is found, the A RR is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.
Example MX records
Deny any mail to this domain.
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
Zone Delegation
NS Records are also used to delegate domains to nameservers.
The following example does not include glue records, which may be important. /etc/bind/zones/db.org.rockstable
/etc/bind/zones/db.it.rockstable
NAPTR RR
The Naming Authority Pointer (NAPTR) DNS Resource Record
Used in DNS lookups of SIP/VOIP systems.
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
Please also take a look at bind9#NextSECure
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:
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.
SSHFP
SSH fingerprint records.
SSHFP structure
⟨Name⟩ [⟨TTL⟩] [⟨Class⟩] SSHFP ⟨Algorithm⟩ ⟨Type⟩ ⟨Fingerprint⟩
- ⟨Name⟩
- The name of the object to which the resource record belongs (optional)
- ⟨TTL⟩
- Time to live (in seconds). Validity of Resource Records (optional)
- ⟨Class⟩
- Protocol group to which the resource record belongs (optional)
- ⟨Algorithm⟩
- SSHFP RR Types for public key algorithms
Value
Description
Reference
0
Reserved
[RFC4255]
1
RSA
[RFC4255]
2
DSA
[RFC4255]
3
ECDSA
[RFC6594]
4
Ed25519
[RFC7479]
5
Unassigned
6
Ed448
[RFC8709]
- ⟨Type⟩
- Algorithm used to hash the public key
SSHFP RR types for fingerprint types
Value
Description
Reference
0
Reserved
[RFC4255]
1
SHA-1
[RFC4255]
2
SHA-256
[RFC6594]
- ⟨Fingerprint⟩
- Hexadecimal representation of the hash result, as text
For the verification please see
ssh#Check SSH-HostKey
Create the text representation of the SSHFP records with
ssh-keygen -r git.rockstable.it
1 git.rockstable.it IN SSHFP 1 1 86f779dc905766f6c97a60d4c04bf420f51e1cdd
2 git.rockstable.it IN SSHFP 1 2 882269abab9ed7604f460a4199d97183a50eceac127358b900255ccda1fe9d34
3 git.rockstable.it IN SSHFP 2 1 0ec59becd75009940e229f01bc0a6c81950e4166
4 git.rockstable.it IN SSHFP 2 2 9f2629246470826e7f89f28faa07a915b3ee15b7db6c1898f122f3f3afcc2345
5 git.rockstable.it IN SSHFP 3 1 c2d7589cd1c10795abe3d58210a894ac3d34d89b
6 git.rockstable.it IN SSHFP 3 2 8bafebfbe1ebd57332063e436f71bf373e9296033e94263bf40abd596d3f1dba
7 git.rockstable.it IN SSHFP 4 1 4f3bf9f499d0ef5f89ced13d9533d615e1fe27d5
8 git.rockstable.it IN SSHFP 4 2 f2a8d8b85c177b16e438fa451391016250f83a186772a4ec82f1b3214a04f622
TLSA - DANE
Links
According to the Bind9 Docs - Supported RFCs there is no support in Bind9, yet.
Please avoid “3 0 1” and “3 0 2” DANE TLSA records with LE certificates
IETF RFC6234 US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)
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).
General structure of the TLSA-RR
Prefixed domain name of a TLSA-RR
The TLSA-records are stored under a prefixed domain name. For the exact construction please see:
RFC6698 Section 3 - Domain Names for TLSA Certificate Associations
Basically it consists of
- The decimal representation of the port number on which a TLS- based service is assumed to exist is prepended with an underscore character ("_") to become the left-most label in the prepared domain name. This number has no leading zeros.
- The protocol name of the transport on which a TLS-based service is assumed to exist is prepended with an underscore character ("_") to become the second left-most label in the prepared domain name. The transport names defined for this protocol are "tcp", "udp", and "sctp".
- The base domain name is appended to the result of step 2 to complete the prepared domain name. The base domain name is the fully qualified DNS domain name [RFC1035] of the TLS server, with the additional restriction that every label MUST meet the rules of [RFC0952]. The latter restriction means that, if the query is for an internationalized domain name, it MUST use the A-label form as defined in [RFC5890].
Value of the TLSA-RR
The TLSA resource record consists four fields.
- Certificate Usage (uint_8)
- Selector (uint_8)
- Matching Type (uint_8)
- Certificate association
Structure
Examples
1 ;;; SHA2-256 FINGERPRINT OF A CA CERTIFICATE
2 ;;; WHICH HAS TO RESIDE AS A LOCAL CA IN CAPATH
3 ;;; PKIX-TA Cert SHA2-256 (RATHER STABLE)
4 _443._tcp.www.example.com. IN TLSA (
5 0 0 1 d2abde240d7cd3ee6b4b28c54df034b9
6 7983a1d16e8a410e4561cb106618e971 )
7
8 ;;; SHA2-512 FINGERPRINT OF A SERVER CERTIFICATE
9 ;;; TO BY VALIDATED AGAINST A LOCAL CA IN CAPATH
10 ;;; PKIX-EE SPKI SHA2-512 (STABLE)
11 _443._tcp.www.example.com. IN TLSA (
12 1 1 2 92003ba34942dc74152e2f2c408d29ec
13 a5a520e7f2e06bb944f4dca346baf63c
14 1b177615d466f6c4b71c216a50292bd5
15 8c9ebdd2f74e38fe51ffd48c43326cbc )
16
17 ;;; FULL CERTIFICATE TO BE TRUSTED (UNSTABLE)
18 ;;; DANE-EE Cert Full (UNSTABLE)
19 _443._tcp.www.example.com. IN TLSA (
20 3 0 0 30820307308201efa003020102020... )
Certificate Usage Field
RFC7218 2.1.1. The Certificate Usage Field
Value |
Acronym |
Short Description |
0 |
PKIX-TA |
CA constraint |
1 |
PKIX-EE |
Service certificate constraint |
2 |
DANE-TA |
Trust anchor assertion |
3 |
DANE-EE |
Domain-issued certificate |
4-254 |
|
Unassigned |
255 |
Reserved for Private Use |
Anything is encoded in ASN.1 distinguished encoding rules (DER) [X.690].
Notes
0 PKIX-TA - Public Key Infrastructure X.509 - Trust Anchor
- Cert
- must validate to specific trust anchor limited by TLSA-RR.
- must validate against trust anchor (in CApath).
- Trust anchor
- may be a certificate or a pubkey of a certificate.
- must be in CApath of the end entity.
1 PKIX-EE - Public Key Infrastructure X.509 - End Entity
- Cert
- must match a specific certificate limited by TLSA-RR.
- must validate against trust anchor (in CApath).
- may be a certificate or a pubkey of a certificate.
- Trust anchor
- must be in CApath of the end entity.
2 DANE-TA - DNS-based Authentication of Named Entities (DANE) - Trust Anchor
- Cert
- must validate to specific trust anchor limited by TLSA-RR.
- must validate against trust anchor.
- Trust anchor
- may be a certificate or a pubkey of a certificate.
- is provided by the server in TLS (and thus is not necessarily found in the CApath of the client).
- Allows running an own CA and thus "insertion" of a CA to the end entity.
- This certificate usage assumes trust of the end entity to the owner of a DNSsec enabled domain, to provide a secure CA. :-/
3 DANE-EE - DNS-based Authentication of Named Entities (DANE) - End Entity
- Cert
- must match a specific certificate limited by TLSA-RR.
- is not validated against CA
- Trust anchor
- none
- Allows running self-signed certificates or ignorance of the issuing CA.
- This certificate usage assumes trust of the end entity to the owner of a DNSsec enabled domain, to provide a secure CA. :-/
The Selector Field
RFC7218 2.1.2. The Selector Field
Value |
Acronym |
Short Description |
0 |
Cert |
Full certificate |
1 |
SPKI |
|
2-254 |
|
Unassigned |
255 |
Reserved for Private Use |
Please also take a look to RFC5280 4.1.2.7. Subject Public Key Info.
The Matching Type Field
RFC7218 2.1.3. The Matching Type Field
Value |
Acronym |
Short Description |
0 |
Full |
No hash used |
1 |
SHA2-256 |
256 bit hash by SHA2 |
2 |
SHA2-512 |
512 bit hash by SHA2 |
3-254 |
|
Unassigned |
255 |
Reserved for Private Use |
If no hashing is used (0) the full certificate is to be included.
If hashed matching, use the same hash as in certificate signature, to aid limited clients.
Hashes can be looked up in RFC6234.
Calculation of the fingerprints
Calculate the full certificate (sha256) fingerprint
1 ### COMMON
2 CERT="/etc/ssl/certs/DST_Root_CA_X3.pem"
3 #CERT="/etc/ssl/custom_ca/custom_ca.crt"
4 #CERT="/etc/letsencrypt/live/mx1.rockstable.it/cert.pem"
5 ### ALT1
6 openssl x509 -noout -fingerprint -sha256 < "$CERT" \
7 |tr -d : \
8 |cut -d= -f2
9 99B5773FDDB0309C65D5507B15E89883E6B9A47C05A567B00F31DEF12EECECE0
10 ### ALT2
11 openssl x509 -outform DER < "$CERT" \
12 |openssl sha256 \
13 |cut -d\ -f2
14 99b5773fddb0309c65d5507b15e89883e6b9a47c05a567b00f31def12eecece0
15 ### ALT3
16 openssl x509 -outform DER < "$CERT" \
17 |openssl dgst -sha256 -binary \
18 |hexdump -ve '/1 "%02x"'
19 99b5773fddb0309c65d5507b15e89883e6b9a47c05a567b00f31def12eecece0#
TLSA-records allow to use the fingerprint of the pubkey instead of the certificates with the Selector set to 1.
Calculate (sha256) fingerprint of the ASN.1 DER encoded SubjectPublicKeyInfo
1 ### COMMON
2 CERT="/etc/letsencrypt/live/mx1.rockstable.it/cert.pem"
3 ### ALT1
4 openssl x509 -noout -pubkey -fingerprint -sha256 < "$CERT" \
5 |tail -n1 \
6 |tr -d : \
7 |cut -d= -f2
8 ### ALT2
9 openssl x509 -noout -pubkey < "$CERT" \
10 |openssl pkey -pubin -outform DER \
11 |openssl dgst -sha256 -binary \
12 |hexdump -ve '/1 "%02x"'
13 094023194bacf2b540ba61a3351bd6b020721fe9b2f940c0c9ec806f56350eb6
TLSA-RR with constant values
There are several constant combinations, that don't require the (rather lazy) admin to change the TLSA records every day.
Stable are
- combinations of CU 0 (PKIX-TA) or CU 2 (DANE-TA), unless the CA certificate changes.
- combinations of
- CU 1 (PKIX-EE) or 3 (DANE-EE)
- selector 1 (SPKI) and
the reusage of the key --reuse-key material.
Therefor a little hint:
Certbot has the ability to reuse the RSA-keypair on renewal. Public and private keys stay the same all the time and the pubkey fingerprint does not change anymore and may be used to publish a stable TLSA-RR.
Thanks to Helge for mailing me to clear this previously messy post up. 
CNAMEs and DNAMEs on TLSA-RR
RFC6698 Provisioning TLSA Records with Aliases
CNAMEs should work on top of TLSA-RRs when the client reolver library is capable and allow to same some effort in keeping track.
1 ; TLSA record for original domain has CNAME to target domain
2 ;
3 sub5.example.com. IN CNAME sub6.example.com.
4 _443._tcp.sub5.example.com. IN CNAME _443._tcp.sub6.example.com.
5 sub6.example.com. IN A 192.0.2.1
6 sub6.example.com. IN AAAA 2001:db8::1
7 _443._tcp.sub6.example.com. IN TLSA 1 1 1 536a570ac49d9ba4...
DNAMEs (for the entire domain subtree) shoud also do threi jobs.
1 ; TLSA record in target domain, visible in original domain via DNAME
2 ;
3 sub5.example.com. IN CNAME sub6.example.com.
4 _tcp.sub5.example.com. IN DNAME _tcp.sub6.example.com.
5 sub6.example.com. IN A 192.0.2.1
6 sub6.example.com. IN AAAA 2001:db8::1
7 _443._tcp.sub6.example.com. IN TLSA 1 1 1 536a570ac49d9ba4...
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.
Walk the reverse DNS
Not elegant but effective. :-D
/usr/local/bin/walk_reverse_dns.sh
walk_reverse_dns.sh 192.168.0.1 192.168.0
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
Example for rockstable.it
Tools
dnstracer
http://www.mavetju.org/unix/dnstracer.php
dnstracer determines where a given Domain Name Server (DNS) gets its information from, and follows the chain of DNS servers back to the servers which know the data.
Install
1 apt install dnstracer
dnsviz
https://github.com/dnsviz/dnsviz
DNSViz is a tool suite for analysis and visualization of Domain Name System (DNS) behavior, including its security extensions (DNSSEC). This tool suite powers the Web-based analysis available at http://dnsviz.net/
Install
1 apt install dnsviz
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 without gui (remommended)
namebench with gui (ignores the arguments supplied on as args (nameservers) and reads only from the GUI form).
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.
Please see
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 ???