Some DNSSEC / NSEC Experiments Starting at the Root Zone

Introduction

I was recently playing around with DNSSEC and figured out that the root DNS zone . uses NSEC and not NSEC3 to prove the absence of a resource record. This looked interesting to me and triggered some ideas. So I did some experiments and here are the results.

TL;Dr:

The most interesting facts:

The root DNS zone uses NSEC can be therefore be DNSSEC zone walked
There are more than 1500 TLDs
More than 90% of all TLDs haven DNSSEC configured
The most used algorithm for signing DNS zones is RSA/SHA-256
53 TLDs also use NSEC and can therefore also be DNSSEC zone walked

Note: The results may not be exactly accurate because it was not always verified if every query was always successful.

NSEC in the Root Zone

If the DNS root zone . is queried for the nameservers of the top level domain gugus. (something that does not exist), the following NSEC record and the according RRSIG signature record is returned:

$ dig gugus. NS +dnssec @8.8.8.8 +multiline
[...]
guge.			82883 IN NSEC guide. NS DS RRSIG NSEC
guge.			82883 IN RRSIG NSEC 8 1 86400 (
				20200417050000 20200404040000 48903 .
				JQDqlkmru8j9MIMtNTkb+Omq3+p/GeJ28ACMetTVacaO
[...]

This NSEC record tells the DNS client that there is no NS record for a domain between the domain guge. and guide.. So two existing domains are disclosed in this NSEC record. It’s now possible to query the root nameservers for the alphabetically next domain by e.g. adding an a after the previously discovered domain, which is guidea.:

$ dig guidea. NS +dnssec @8.8.8.8 +multiline
[...]
guide.			81771 IN NSEC guitars. NS DS RRSIG NSEC
guide.			81771 IN RRSIG NSEC 8 1 86400 (
				20200417050000 20200404040000 48903 .
				YrYNf4dEOoJIYCWsyIxgdMTfjcJAe/rYjz5xqGg48fQE
[...]

This shows the alphabetically next top level domain guitars. in the NSEC record. Using this technique, it’s possible to enumerate all existing DNS records of a domain. This is called DNSSEC zone walking.

In the concrete example of the DNS root zone, this allows to get a list of all top level domains (TLDs).

A Note on NSEC3

DNSSEC zone walking does not work when NSEC3 is used to prove the absence of a DNS record. If NSEC3 is used, only hashes of domains are returned:

$ dig thisdoesnotexist.ch +dnssec  +multiline @8.8.8.8
[...]
MB26RDU3A4G95SMNVMVS34K1S3E2GIKU.ch. 899 IN NSEC3 1 1 2 CCBADBD6 (
				MB2CRVD2ILBVGL6TMSI5BVUPDTAU0RMS
				NS SOA RRSIG DNSKEY NSEC3PARAM )
MB26RDU3A4G95SMNVMVS34K1S3E2GIKU.ch. 899 IN RRSIG NSEC3 13 2 900 (
				20200424192501 20200325190118 18757 ch.
				EQ8uIrpzntBIcK+0+YLLS5tY2EuVwhM1+BR14CWKKZ/I
				z7Z1Zp3e3mDvS3bdYeZUt0xFVEBbVH+KsM9rcjlkcw== )
QU2HTAQA675DN7T4JO5DT253O7VD45CD.ch. 899 IN NSEC3 1 1 2 CCBADBD6 (
				QU3D92HOP0HSVG6MCV8MM75NVF7719PF
				NS DS RRSIG )
QU2HTAQA675DN7T4JO5DT253O7VD45CD.ch. 899 IN RRSIG NSEC3 13 2 900 (
				20200428150345 20200329150115 18757 ch.
				cNePMn5H59kt5fFfy2qodf7YAL7cCRIW9212G0QKVujD
				m96Q/hKyVd1vbbATa0jAL/AUWEk4Z19TNU7bR8jQRA== )
1TIR9G6M8HKJ2JDURH1C9716DL19SNNL.ch. 899 IN NSEC3 1 1 2 CCBADBD6 (
				1TK0Q5SFB3QFQCCIL6G82QPUD12HOFL1
				NS DS RRSIG )
1TIR9G6M8HKJ2JDURH1C9716DL19SNNL.ch. 899 IN RRSIG NSEC3 13 2 900 (
				20200430025429 20200331020116 18757 ch.
				j5GqfXEcdeHhxrhZMO3E4X6IPnGQM0UG1V26E15kz2ni
				ukloYNjgc6ATiMxPIISbdKHosHN6xKMDJ/0VW/561A== )

These hashes could be cracked using e.g. hashcat and the hash mode 8300. After cracking, the alphabetically next non existing DNS record could be queried and so on in order to get all DNS entries.

DNSSEC Zone Walking in the Root Zone

Of course there are tools that automate the DNSSEC zone walking process, like ldns-walk. So, it’s possible to get all top level domains by walking throught the entire root zone .:

$ ldns-walk . | tee zone_.
.	. NS SOA RRSIG NSEC DNSKEY
aaa. NS DS RRSIG NSEC
aarp. NS DS RRSIG NSEC
abarth. NS DS RRSIG NSEC
abb. NS DS RRSIG NSEC
abbott. NS DS RRSIG NSEC
[...]
guge. NS DS RRSIG NSEC
guide. NS DS RRSIG NSEC
guitars. NS DS RRSIG NSEC
guru. NS DS RRSIG NSEC
gw. NS DS RRSIG NSEC
[...]
zm. NS RRSIG NSEC
zone. NS DS RRSIG NSEC
zuerich. NS DS RRSIG NSEC

In total, there are more than 1'500 top level domains:

$ wc -l zone_.
1513 zone_.

DNSSEC on the Top Level Domains

Now we have a list of all top level domains. Let’s analyze them for some DNSSEC related configuration.

The following script was used to query the TLDs for some infos:

#!/usr/bin/env bash

NAMESERVER="8.8.8.8"
OUTPUTFILE="dnssec-domain-analysis.out"
> "$OUTPUTFILE"

while read domain foo
do
  echo "[*] Domain $domain"
  dig "$domain" DS @"$NAMESERVER"
  dig "$domain" DNSKEY @"$NAMESERVER"
  dig "$domain" SOA +dnssec @"$NAMESERVER"
  NXDOMAIN="$(openssl rand -hex 16)"
  dig "$NXDOMAIN.$domain" +dnssec @"$NAMESERVER"
done < zone_. | tee -a "$OUTPUTFILE"

This script does the following:

Query the DS record to check if DNSSEC is configured (the DS record is configured in the parent zone, which is the root zone in this case)
Query the configured DNSSEC keys (should return at least one KSK and ZSK)
Query the SOA record with the according RRSIG record
Query a non-existing domain to check if NSEC or NSEC3 is used

Analysis: DNSSEC Enabled Domains

Searching for all TLDs that have a DS record configured and are therefore ready for DNSSEC:

$ awk '/^[^;].*IN.*DS[[:space:]][0-9]/{ print $1 }' dnssec-domain-analysis.out \
  | sort -u | tee has_ds_record
aaa.
aarp.
abarth.
abb.
[...]

In total, 1375 domains have a DS record configured:

$ wc -l has_ds_record
1375 has_ds_record

This is ~91% of all top level domains:

$ bc -lq <<< 1375/1514
.90819022457067371202

The following domains do not have DNSSEC configured:

$ grep -v -f has_ds_record zone_.  | cut -d ' ' -f 1 | column
.	.			gg.			pa.
ae.			gh.			pf.
ai.			gm.			pg.
al.			gp.			ph.
ao.			gq.			pk.
aq.			gt.			pn.
as.			gu.			ps.
ba.			hm.			py.
bb.			ht.			qa.
bd.			im.			rw.
bf.			iq.			sd.
bh.			ir.			sl.
bi.			je.			sm.
bj.			jm.			so.
bn.			jo.			sr.
bo.			kh.			st.
bs.			km.			sv.
bv.			kn.			sy.
cd.			kp.			sz.
cf.			kz.			tc.
cg.			ls.			td.
ci.			ly.			tg.
ck.			mg.			tj.
cm.			mh.			tk.
cu.			mk.			to.
cv.			ml.			tr.
cw.			mm.			uz.
cy.			mo.			va.
dj.			mp.			vg.
dm.			mq.			vi.
do.			ms.			xn--80ao21a.
ec.			mt.			xn--d1alf.
eg.			mu.			xn--fzc2c9e2c.
er.			mv.			xn--mgba3a4f16a.
et.			mw.			xn--mgbayh7gpa.
fj.			mz.			xn--mgbcpq6gpa1a.
fk.			ne.			xn--mix891f.
fm.			ng.			xn--ogbpf8fl.
ga.			ni.			xn--wgbl6a.
gb.			np.			xn--xkc2al3hye2a.
ge.			nr.			ye.
gf.			om.			zm.

Testing if every domain with a DS record also has a signed SOA record and write the results into a file:

$ while read domain
  do
    grep -q -E "^$domain.*RRSIG.*SOA" dnssec-domain-analysis.out \
      && echo "$domain yes" \
      || echo "$domain no
  done < has_ds_record | tee is_zone_signed
aaa. yes
aarp. yes
abarth. yes
abb. yes
abbott. yes
abbvie. yes
[...]

There is one zone that has a DS record but no signed SOA record ( xn--mgbai9azgqp6j. is punycode for پاکستان. which is Pakistan):

$ grep "no$" is_zone_signed
xn--mgbai9azgqp6j. no

This domain always returns a SERVFAIL:

$ dig xn--mgbai9azgqp6j. SOA
[...]
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60210 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 [...] $ dig xn--mgbai9azgqp6j. SOA @ns1.ntc.net.pk. [...] ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3008
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
[...]

This means that all other domains that have a DS record configured do also sign it’s zone.

However, some days later, the domain had a signed SOA record:

$ dig xn--mgbai9azgqp6j. SOA +dnssec +short
ns.ntc.net.pk. admin.ntc.net.pk. 2020041960 21600 3600 604800 86400
SOA 7 1 86400 20200518185901 20200418185901 40937 پاکستان. YWI2RCm8U4kT6pKoMCEJvhWwbjtMCXNAnVc+qgcV59qudJr/bUIuMfpp D3R0b24k/5YkRtYzYtKZ7tPCTxfKLHqdL+aPipFI+mZJtaOqhpUr7KEP v1i+mjO+vZW33NMHi2Zs/l/Kqua/ids1rfpaF70Q7onM2GZHgwobMSyf E4XtvvD6PkUKwmJluAyfQ0gR9O9TU9s056998ebyC/RZpTQDmd+HVrkA RTIClL3SxyEzcedqdo3rAQrKRQIYEnvXzw88g0dBXfSnTQJF98FpcKyT IGahq69ErEOaGEX9DHo0o+C/l4qfNhVywM+9JFJSI84Qd9BPEb/dRvtT
xOhC4w==

Analysis: DS Records

It’s possible to have multiple DS records. But most domains have exactly one DS record configured. This shows the number of domains and the number of DS records:

$ awk '/^[^;].*IN.*DS[[:space:]][0-9]/{ print $1 }' dnssec-domain-analysis.out \
  | uniq -c | awk '{ print $1 }' | sort | uniq -c | sort -rn
    533 1
    428 4
    373 2
     32 6
      7 3
      2 5

A DS record looks like this:

guru.	86400	IN	DS	44536 8 1 C0F5EAFD23D5B7839D388545CE577B4BE399D190

DS record details:

The first number after the DS keyword is the key ID which is used to match the DNSKEY in the zone itself.
The 2nd number after the DS keyword is the algorithm which is used by the key for signing the DNS zone (see https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml for the entire list)
- 1 = RSA/MD5
- 2 = Diffie-Hellman
- 3 = DSA/SHA1
- 5 = RSA/SHA1
- 6 = DSA-NSEC3-SHA1
- 7 = RSASHA1-NSEC3-SHA1
- 8 = RSA/SHA-256
- 10 = RSA/SHA-512
- 12 = GOST R 35.10-2001
- 13 = ECDSA-P256/SHA256
- 13 = ECDSA Curve P-256 with SHA-256
- 14 = ECDSA-P384/SHA384
- 15 = ED25519
- 16 = ED448
The 3rd number after the DS keyword is the hashing algorithm used for the DS record
- 1 = SHA-1
- 2 = SHA-256
- 3 = GOST R 34.11-94
- 4 = SHA-384
The 4th number after the DS keyword is the hash of the DNSKEY itself

No domain has multiple DS records configured with different signing algorithms:

$ awk '/^[^;].*IN.*DS[[:space:]][0-9]/{ print $1, $6 }' dnssec-domain-analysis.out \
  | sort -u | cut -d ' ' -f 1 | uniq -c | sort -nr
      1 zuerich.
      1 zone.
      1 zip.
[...]

Most domains have a DS record configured that points to a DNSKEY that uses RSA/SHA-256 to sign the zone. This shows the number of domains and the used signing algorithms:

$ awk '/^[^;].*IN.*DS[[:space:]][0-9]/{ print $6 }' dnssec-domain-analysis.out \
  | sort | uniq -c | sort -nr
   2515 8
    494 7
    158 5
     34 10
     13 13

Most domains only have one key configured (unique key ID). This shows the number of domains and the number of different key IDs:

$ awk '/^[^;].*IN.*DS[[:space:]][0-9]/{ print $1, $5 }' dnssec-domain-analysis.out \
  | sort -u | cut -d ' ' -f 1 | uniq -c | sort -nr | awk '{ print $1 }' | sort \
  | uniq -c | sort -nr
    870 1
    468 2
     37 3

The most popular hashing algorithm in the DS record is SHA2. Only SHA2 and SHA1 are used:

$ awk '/^[^;].*IN.*DS[[:space:]][0-9]/{ print $1, $7 }' dnssec-domain-analysis.out \
  | sort -u | cut -d ' ' -f 2 | sort | uniq -c | sort -rn
   1371 2
    807 1

All domains have a unique DNSKEY hash, so no domain is signed by the same key:

$ awk '/^[^;].*IN.*DS[[:space:]][0-9]/{ print $8 }' dnssec-domain-analysis.out  \
  | sort | uniq -c | sort -nr
      1 FFBAC3E447FD25705104BB50F8652E7CCF6EECBFC956E1E65890C9B9
      1 FFA7F40CCE0F75E63BC85BDF0495C83EB2BB22E12A10099531C37D7F
      1 FF8C0D6BDA26D334D42200737316877D89E2F7AA40FAA67A73D7EAE3
      1 FF6D6BA7638E7D8010867C4334D20EED0D8F0D0D
[...]

Analysis: DNSKEYS

A DNSKEY record looks like this:

ch.	34568	IN	DNSKEY	257 3 13 8Tb8/h/ON8XsvUxjxUJyFLykQUUEyY80LACtat0nN+S0TOjoQ8o5e+hu um6ZOJx1bVh4PaUfoUvNBUS77VWB0Q==

DNSKEY record details:

The 1st number after the DNSKEY keyword is the key type.
- 257 = KSK, Key Signing Key (this hash is in the DS record in the parent zone and used to sign the ZSK)
- 256 = Zone Signing Key, ZSK (this key is used to sign the record in this zone))
The 2nd number after the DNSKEY keyword is the protocol which is always 3 in DNSSEC.
The 3rd number after the DNSKEY keyword is the algorithm that is used for signing
- 1 = RSA/MD5
- 2 = Diffie-Hellman
- 3 = DSA/SHA1
- 5 = RSA/SHA1
- 6 = DSA-NSEC3-SHA1
- 7 = RSASHA1-NSEC3-SHA1
- 8 = RSA/SHA-256
- 10 = RSA/SHA-512
- 12 = GOST R 35.10-2001
- 13 = ECDSA-P256/SHA256
- 13 = ECDSA Curve P-256 with SHA-256
- 14 = ECDSA-P384/SHA384
- 15 = ED25519
- 16 = ED448

Most domains have only one KSK configured. This shows the number of domains and the number of configured KSK keys:

$ awk '/^[^;].*IN.*DNSKEY[[:space:]]+257/{ print $1 }' dnssec-domain-analysis.out \
  | uniq -c | awk '{ print $1 }' | sort | uniq -c | sort -nr
    625 1
    590 2
     65 4
     41 3

Most domains have two ZSKs configured. This shows the number of domains and the number of configured ZSK keys:

$ awk '/^[^;].*IN.*DNSKEY[[:space:]]+256/{ print $1 }' dnssec-domain-analysis.out \
  | uniq -c | awk '{ print $1 }' | sort | uniq -c | sort -nr
    814 2
    402 1
     40 3
     35 5
     29 4
      1 6

The following domains have multiple ZSKs configured with different signing algorithms:

$ awk '/^[^;].*IN.*DNSKEY[[:space:]]+256/{ print $1,$7 }' dnssec-domain-analysis.out \
  | sort -u  | cut -d ' ' -f 1 | uniq -c | grep -E -v "^ +1 "
      2 in.
      2 xn--2scrj9c.
      2 xn--45br5cyl.
      2 xn--45brj9c.
      2 xn--fpcrj9c3d.
      2 xn--gecrj9c.
      2 xn--h2breg3eve.
      2 xn--h2brj9c.
      2 xn--h2brj9c8c.
      2 xn--mgbbh1a.
      2 xn--mgbgu82a.
      2 xn--s9brj9c.
      2 xn--xkc2dl3a5ee0h.

The same domains have also KSKs configured with different signing algorithms:

$ diff -s \
  <(awk '/^[^;].*IN.*DNSKEY[[:space:]]+256/{ print $1,$7 }' dnssec-domain-analysis.out \
      | sort -u  | cut -d ' ' -f 1 | uniq -c | grep -E -v "^ +1 ")\
  <(awk '/^[^;].*IN.*DNSKEY[[:space:]]+257/{ print $1,$7 }' dnssec-domain-analysis.out \
      | sort -u  | cut -d ' ' -f 1 | uniq -c | grep -E -v "^ +1 ") \
Files /dev/fd/63 and /dev/fd/62 are identical

Because the analysis of the DS records before shows that no zone has mulitple signing algorithms configured in the DS record, this shows that there are probbably unused keys configured due to key rotation or similar.

The most used signing algorithm over all keys is RSA/SHA-256. This shows the number of DNSKEYS and the according signature algorithm:

$ awk '/^[^;].*IN.*DNSKEY[[:space:]]+25[67]/{ print $7 }' dnssec-domain-analysis.out \
  | sort | uniq -c | sort -nr
   3528 8
    924 7
     84 5
     68 10
     31 13

These numbers are in a similar ratio like the algorithms used in the DS record but generally higher, because a domain can have multiple DNSKEYS configured.

There are domains that have multiple DNSKEYS configured with different signature algorithms:

$ awk '/^[^;].*IN.*DNSKEY[[:space:]][0-9]/{ print $1,$7 }' dnssec-domain-analysis.out | sort -u | cut -d ' ' -f 1 | uniq -c | sort -nr | grep -E -v "^ +1 "
      2 xn--xkc2dl3a5ee0h.
      2 xn--s9brj9c.
      2 xn--mgbgu82a.
      2 xn--h2brj9c8c.
      2 xn--h2brj9c.
      2 xn--h2breg3eve.
      2 xn--gecrj9c.
      2 xn--fpcrj9c3d.
      2 xn--45brj9c.
      2 xn--45br5cyl.
      2 xn--2scrj9c.
      2 in.

For example, India in. has two DS records that point to DNSKEYS that use RSA/SHA-256 for signing but there are also two other DNSKEYS (a KSK and a ZSK) that uses the RSASHA1-NSEC3-SHA1 alrorithm:

$ dig in. DS +short
54739 8 1 2B5CA455A0E65769FF9DF9E75EC40EE1EC1CDCA9
54739 8 2 9F122CFD6604AE6DEDA0FE09F27BE340A318F06AFAC11714A73409D4 3136472C
$ dig in. DNSKEY +short
257 3 8 AwEAAZuDkhOheGegFGo18ZNCe3BMDFgYQ8tSoJgi1323hSQD+kjcsDDT Y3eQH/umbcJ4YiMg8dFz6DHyHr4TdBPZLjnfwSgflWSEbFfRFng29KzP crq6gszJiy1A0xzDhjBQOpMNUiRG9eLXqvRL1js3Z5wcpGDGeDPCboZZ nk+r2MmLGdEkB6EJuw/36/uBfL91uCyH5ej0modBfuDDtJWB+g1zMWm1 qkPifhDjBngasbWxFfXFv49B6JZL+S+5YnQuEaaMWTdd/BuJfxKuo6HR OAVrXlnuM9YhsY6AlfEG8rKPHsI6X8TlTCkzbRD7GrnNjH4AK/Bf+484 YC/z0mH3lFE=
256 3 8 AwEAAbXHhNS6fpmmvClBi/I5ndXrsNO9N36hPAhkRKP1bOMw+iTGHqti FRIZB2VS0j1KQMp5ATSACMpLGc7IOJLsJgKWFLXStl5SkvJXCXEh8MSS qgQSWi3ZHQM9nI5WzkPA0/Z2h0nsWq0kuMe7whiqe4ngmXsru3pTUqNF g40BtsqhubBbzwW527FoM6OkhTjQMD7sdJKsTnRm25xYSbjaIGU=
256 3 7 AwEAAb/ThDZIxoLtBkUR7QHoSXU35G7VnP19QSvOYzWQdcGgLExA9BrU exZ17aNWyS/9HbGKbPqYoqVxyJUErJEG4eICZ0he/nd6DtKtF/5C1p0i x18ceAvMJ1ahSpK/57S3AhJgiaIZhnS36Jntq0kudBSqODMGfQzT6KiQ VdUP2KzZjItBzMQ+jpk5tI13FD1+imnXQndEmuP6FyqtM95xdls=
257 3 7 AwEAAZulDnq8AXUvU2fYIHW/xWqFkMGAD0C/4ABUsX3ErS0/G3CuAfFb 7lkWM7egPmQ7J6bMG3V4BOIKflSDJuj9uMJ8Ote5v0VR0yPKA5+9zHSG qMYMz66lnnnMlB1ZB1EwU15qzG7ScvwO5SA5iA23nZY1rc4sx5VagHo8 PN1FkL8qvAFoZw+YxZga3o05LCdJZfZSKWD3VJOFCcg9wNxA/HXb5Z89 ujQ3NMZyDBcO6wccuOnj/chs1B5ZR6hyumpjGHj2xAI8rLduBMH9lvtR j2/L3+s0OyScawwiSpGNhO6asAgB8CjYBU6oAnl39j+W3IdoI4BNujIJ SlMX7O3BlhM=

The records are then also signed using both keys (this can be seen on the key IDs 9182 and 65169):

$ dig in. SOA +dnssec +multiline
[...]
in.			900 IN RRSIG SOA 7 1 900 (
				20200519133350 20200419123350 9182 in.
				is62vYiYNkuWcnuIQpyVddFLTLzruyqmP4w14uaZlQBz
				[...])
in.			900 IN RRSIG SOA 8 1 900 (
				20200519133350 20200419123350 65169 in.
				ny6GVhh6MCCowWQnyoaz9ABWVU4YmMxC6GAD4hXsAXzu
				[...])
$ dig in. DNSKEY +multiline
[...]
in.			850 IN DNSKEY 256 3 7 (
				AwEAAb/ThDZIxoLtBkUR7QHoSXU35G7VnP19QSvOYzWQ
				[...]
				) ; ZSK; alg = NSEC3RSASHA1 ; key id = 9182
in.			850 IN DNSKEY 256 3 8 (
				AwEAAbXHhNS6fpmmvClBi/I5ndXrsNO9N36hPAhkRKP1
				[...]
				) ; ZSK; alg = RSASHA256 ; key id = 65169
[...]

Analysis: NSEC/NSEC3

In total, 53 domains use NSEC:

$ awk '/^[^;\.]+\.[[:space:]].*IN[[:space:]]+NSEC[[:space:]]/{ print $1 }' dnssec-domain-analysis.out \
  | sort -u | wc -l
53

This means it’s also possible to DNSSEC zone walk through the following zones:

$ awk '/^[^;\.]+\.[[:space:]].*IN[[:space:]]+NSEC[[:space:]]/{ print $1 }' dnssec-domain-analysis.out \
  | sort -u | column
arpa.			game.			mom.
au.			gift.			na.
audio.			gn.			photo.
auto.			guitars.		pics.
ax.			help.			pr.
bg.			hiphop.			property.
blackfriday.		hosting.		se.
br.			id.			sexy.
bt.			inc.			sl.
car.			jetzt.			tattoo.
cars.			juegos.			tn.
christmas.		kg.			ve.
click.			ky.			wed.
diet.			lb.			xn--fzc2c9e2c.
dz.			link.			xn--l1acc.
ee.			lk.			xn--pgbs0dh.
erni.			lol.			xn--xkc2al3hye2a.
flowers.		lr.

This is for example the entire arpa. zone where the famous in-addr.arpa. and the IPv6 equivalent ip6.arpa. can be seen:

$ ldns-walk arpa.
arpa.	arpa. NS SOA RRSIG NSEC DNSKEY
as112.arpa. NS DS RRSIG NSEC
e164.arpa. NS DS RRSIG NSEC
home.arpa. NS RRSIG NSEC
in-addr.arpa. NS DS RRSIG NSEC
in-addr-servers.arpa. NS DS RRSIG NSEC
ip6.arpa. NS DS RRSIG NSEC
ip6-servers.arpa. NS DS RRSIG NSEC
ipv4only.arpa. NS RRSIG NSEC
iris.arpa. NS DS RRSIG NSEC
uri.arpa. NS DS RRSIG NSEC
urn.arpa. NS DS RRSIG NSEC

It’s also possible to walk through further zones of the arpa zone:

$ ldns-walk in-addr.arpa.
in-addr.arpa.	in-addr.arpa. NS SOA RRSIG NSEC DNSKEY
1.in-addr.arpa. NS DS RRSIG NSEC
10.in-addr.arpa. NS RRSIG NSEC
100.in-addr.arpa. NS DS RRSIG NSEC
101.in-addr.arpa. NS DS RRSIG NSEC
102.in-addr.arpa. NS DS RRSIG NSEC
103.in-addr.arpa. NS DS RRSIG NSEC
104.in-addr.arpa. NS DS RRSIG NSEC
105.in-addr.arpa. NS DS RRSIG NSEC
106.in-addr.arpa. NS DS RRSIG NSEC
[..]
$ ldns-walk ip6.arpa.
ip6.arpa.	ip6.arpa. NS SOA RRSIG NSEC DNSKEY
2.0.1.0.0.2.ip6.arpa. NS DS RRSIG NSEC
3.0.1.0.0.2.ip6.arpa. NS DS RRSIG NSEC
4.0.1.0.0.2.ip6.arpa. NS DS RRSIG NSEC
5.0.1.0.0.2.ip6.arpa. NS DS RRSIG NSEC
6.0.1.0.0.2.ip6.arpa. NS DS RRSIG NSEC
7.0.1.0.0.2.ip6.arpa. NS DS RRSIG NSEC
$ ldns-walk uri.arpa.
uri.arpa.	uri.arpa. NS SOA MX RRSIG NSEC DNSKEY
ftp.uri.arpa. NAPTR RRSIG NSEC
http.uri.arpa. NAPTR RRSIG NSEC
mailto.uri.arpa. NAPTR RRSIG NSEC
urn.uri.arpa. NAPTR RRSIG NSEC

The most TLDs use NSEC3:

$ awk -F. '/^[^;]+\.[[:space:]].*IN[[:space:]]+NSEC3[[:space:]]/{ print $2 }' dnssec-domain-analysis.out \
  | sort -u  | wc -l
1309

The number of NSEC and NSEC3 domains no not match the number of domains that have a DS record configured. This is probbably due to some timeouts during the tests where no response was received. This was not further analyzed. It’s possible that I missed some details because of these timeouts. However, the statistics give still a good overview about the top level domain DNSSEC configuration.

MX Records for TLDs

During the analysis I was wondering if there are TLDs that have an MX record set up. The following have an MX record configured:

$ while read domain foo
  do
    dig "$domain" MX @8.8.8.8
  done < zone_. | grep "^[^;].*MX" | tee has_mx_record
ai.			21599	IN	MX	10 mail.offshore.ai.
arab.			3599	IN	MX	10 your-dns-needs-immediate-attention.arab.
ax.			21599	IN	MX	5 mail.aland.net.
cf.			10799	IN	MX	0 mail.intnet.cf.
cpa.			3599	IN	MX	10 your-dns-needs-immediate-attention.cpa.
dm.			21599	IN	MX	10 mail.nic.dm.
gp.			21599	IN	MX	10 ns1.nic.gp.
gt.			14399	IN	MX	10 aspmx.l.google.com.
gt.			14399	IN	MX	20 alt1.aspmx.l.google.com.
gt.			14399	IN	MX	20 alt2.aspmx.l.google.com.
gt.			14399	IN	MX	30 aspmx2.googlemail.com.
gt.			14399	IN	MX	30 aspmx4.googlemail.com.
gt.			14399	IN	MX	30 aspmx5.googlemail.com.
hr.			14399	IN	MX	5 alpha.carnet.hr.
kh.			10799	IN	MX	10 ns1.dns.net.kh.
km.			3599	IN	MX	100 mail1.comorestelecom.km.
lk.			21599	IN	MX	10 malithi-slt.nic.lk.
lk.			21599	IN	MX	20 malithi-lc.nic.lk.
llp.			3599	IN	MX	10 your-dns-needs-immediate-attention.llp.
mq.			21599	IN	MX	10 mx1-mq.mediaserv.net.
mr.			3599	IN	MX	5 mail.nic.mr.
pa.			21599	IN	MX	5 ns.pa.
politie.		1799	IN	MX	10 your-dns-needs-immediate-attention.politie.
sr.			21599	IN	MX	10 spsbbank.sr.
tt.			21599	IN	MX	1 ASPMX.L.GOOGLE.COM.
tt.			21599	IN	MX	10 ALT1.ASPMX.L.GOOGLE.COM.
ua.			21599	IN	MX	10 mr.kolo.net.
ws.			21599	IN	MX	10 mail.worldsite.ws.
xn--mgbah1a3hjkrd.	21599	IN	MX	5 mail.nic.mr.
xn--mxtq1m.		3599	IN	MX	10 your-dns-needs-immediate-attention.xn--mxtq1m.
xn--ngbrx.		3599	IN	MX	10 your-dns-needs-immediate-attention.xn--ngbrx.

It would be interesting to see if these mailservers would actually accept and deliver mails for these TLDs.

Interesting is also that several domains have your-dns-needs-immediate-attention in it.

These always resolve to 127.0.53.53:

$ dig your-dns-needs-immediate-attention.arab. +short
127.0.53.53

The TXT record gives more information about that:

$ dig your-dns-needs-immediate-attention.arab. TXT +short
"Your DNS configuration needs immediate attention see https://icann.org/namecollision"

This mechanism is used to detect when operating a private domain name (e.g. a non-delegated TLD) results in a query to the public DNS, which should not happen. The IP 127.0.53.53 is is used to be quickly found in logfiles that can be used to alert the administrators.

Quote from this website:

127.0.53.53 is a special IPv4 address that will appear in system logs alerting system administrators that there is potential name collision issue, enabling a quick diagnosis and remediation. The “53” is used as a mnemonic to indicate a DNS-related problem owing to the use of network port 53 for the DNS service.

That’s it

I hope you learned something new about DNSSEC or the Internet :)

Introduction#

TL;Dr:#

NSEC in the Root Zone#

A Note on NSEC3#

DNSSEC Zone Walking in the Root Zone#

DNSSEC on the Top Level Domains#

Analysis: DNSSEC Enabled Domains#

Analysis: DS Records#

Analysis: DNSKEYS#

Analysis: NSEC/NSEC3#

MX Records for TLDs#

That’s it#

Comments