07 Sep

DNSSEC deployment across the ccTLDs

While I am spending time on APNIC’s security workshop here at APNIC 46, I got curious about DNSSEC deployment across ccTLDs. 

For those who may be unaware, DNSSEC adds signature the DNS responses making it possible to cryptographically verify a DNS query response. 

Out of 254 ccTLDs, 125 support DNSSEC with a published DS record (at least that is what I get when I check their zone) and 129 do not support it as yet. So, for now, it is at 49.21%. 

ccTLDStatus
acTRUE
adTRUE
aeFALSE
afTRUE
agTRUE
aiFALSE
alFALSE
amTRUE
anFALSE
aoFALSE
aqFALSE
arTRUE
asFALSE
atTRUE
auTRUE
awTRUE
axTRUE
azTRUE
baFALSE
bbFALSE
bdFALSE
beTRUE
bfFALSE
bgTRUE
bhFALSE
biFALSE
bjFALSE
blFALSE
bmTRUE
bnFALSE
boFALSE
bqFALSE
brTRUE
bsFALSE
btTRUE
bvFALSE
bwTRUE
byTRUE
bzTRUE
caTRUE
ccTRUE
cdFALSE
cfFALSE
cgFALSE
chTRUE
ciFALSE
ckFALSE
clTRUE
cmFALSE
cnTRUE
coTRUE
crTRUE
cuFALSE
cvFALSE
cwFALSE
cxTRUE
cyFALSE
czTRUE
deTRUE
djFALSE
dkTRUE
dmFALSE
doFALSE
dzFALSE
ecFALSE
eeTRUE
egFALSE
ehFALSE
erFALSE
esTRUE
etFALSE
euTRUE
fiTRUE
fjFALSE
fkFALSE
fmFALSE
foTRUE
frTRUE
gaFALSE
gbFALSE
gdTRUE
geFALSE
gfFALSE
ggFALSE
ghFALSE
giTRUE
glTRUE
gmFALSE
gnTRUE
gpFALSE
gqFALSE
grTRUE
gsTRUE
gtFALSE
guFALSE
gwTRUE
gyFALSE
hkTRUE
hmFALSE
hnTRUE
hrTRUE
htFALSE
huTRUE
idTRUE
ieTRUE
ilTRUE
imFALSE
inTRUE
ioTRUE
iqFALSE
irFALSE
isTRUE
itTRUE
jeFALSE
jmFALSE
joFALSE
jpTRUE
keTRUE
kgTRUE
khFALSE
kiTRUE
kmFALSE
knFALSE
kpFALSE
krTRUE
kwFALSE
kyTRUE
kzFALSE
laTRUE
lbTRUE
lcTRUE
liTRUE
lkTRUE
lrTRUE
lsFALSE
ltTRUE
luTRUE
lvTRUE
lyFALSE
maTRUE
mcFALSE
mdFALSE
meTRUE
mfFALSE
mgTRUE
mhFALSE
mkFALSE
mlFALSE
mmTRUE
mnTRUE
moFALSE
mpFALSE
mqFALSE
mrFALSE
msFALSE
mtFALSE
muFALSE
mvFALSE
mwFALSE
mxTRUE
myTRUE
mzFALSE
naTRUE
ncTRUE
neFALSE
nfTRUE
ngFALSE
niFALSE
nlTRUE
noTRUE
npFALSE
nrFALSE
nuTRUE
nzTRUE
omFALSE
paFALSE
peTRUE
pfFALSE
pgFALSE
phFALSE
pkFALSE
plTRUE
pmTRUE
pnFALSE
prTRUE
psFALSE
ptTRUE
pwTRUE
pyFALSE
qaFALSE
reTRUE
roTRUE
rsFALSE
ruTRUE
rwFALSE
saTRUE
sbTRUE
scTRUE
sdFALSE
seTRUE
sgTRUE
shTRUE
siTRUE
sjTRUE
skFALSE
slFALSE
smFALSE
snTRUE
soFALSE
srFALSE
ssFALSE
stFALSE
suTRUE
svFALSE
sxTRUE
syFALSE
szFALSE
tcFALSE
tdFALSE
tfTRUE
tgFALSE
thTRUE
tjFALSE
tkFALSE
tlTRUE
tmTRUE
tnTRUE
toFALSE
tpFALSE
trFALSE
ttTRUE
tvTRUE
twTRUE
tzTRUE
uaTRUE
ugTRUE
ukTRUE
umFALSE
usTRUE
uyTRUE
uzFALSE
vaFALSE
vcTRUE
veFALSE
vgFALSE
viFALSE
vnTRUE
vuTRUE
wfTRUE
wsTRUE
ytTRUE
zaTRUE
zmTRUE
zwFALSE





About all TLDs in the root zone

There are 1540 TLDs right now in the root zone out of which 145 do not support DNSSEC as yet (129 of that is ccTLD alone). 1396 do have DS record at the DNS zone in TLD level. I have published the full list here.

Note: Full DNSSEC support is more than just DS record in the zone. 

01 Mar

Encrypted DNS using DNSCrypt

Writing this post from my hotel room in Kathmandu. I found that many of the servers appear to be DNS resolvers which is unusual.

E.g:

 

This seems unusual and is the result of basically port 53 DNS hijack. Let’s try to verify it using popular “whoami.akamai.net” query.

So clearly something in middle is hijacking DNS queries and no matter whichever DNS resolver I try to use, the queries actually hit authoritative DNS via 202.79.32.164. This belongs to WorldLink Communications (ISP here in Nepal) and I am just 5 hops away from it.

 

So what can be done about these cases? Well, one way is VPN of course but with a setup where VPN server’s IP address is hardcoded in the client and not using DNS. It works and does the task but performance can vary greatly depending on how far is the tunnel server. A better and more modern way out of it is by using encryption in DNS by using a protocol named “DNSCrypt“. DNSCrypt offers to encrypt of DNS queries from clients to the DNS resolvers. (Beyond that resolver still, follow usual non-encrypted root chain to reach authoritative DNS servers).

 

So how does it work?

There’s no integrated support of DNSCrypt in OS’es at this time. There are number of projects like dnscrypt-osxclient available on GitHub which enable this support.  Once configured, the client changes system’s DNS resolver to a local IP which listens for port 53 (regular/non-encrypted) requests.

The client often offers support of various open resolvers like OpenDNS, Quad9 etc.

 

 

Here it shows that DNS resolver in my case happens to be Cisco’s OpenDNS. As soon as the client gets port 53 DNS queries, it encrypts it and sends via UDP port 443 (UDP or TCP depending on provider and client configuration). The encyption is based on trusted root CA’s and associated chain as popularly used in HTTPS. This is also one of reasons why DNSCrypt is also known as DNS over HTTPS.

 

Here’s an example of a DNS query to resolve A record of google.com while running tcpdumps in parallel:

This shows request went in clear text to 127.0.0.54 which is configured on loopback. While in parallel if I watch for traffic towards OpenDNS public IPs, I get:

Thus all that appears here is just an encrypted packet to Cisco OpenDNS over UDP port 443.

I ran another query and saved it in pcap file. Here’s how it looks like in wireshark:

 

 

 

That’s all about it for now. I am going to keep encryption enabled especially when travelling from now onwards. Time to get some sleep. 🙂

 

Useful Links:

  1. dnscrypt-osxclient – https://github.com/alterstep/dnscrypt-osxclient
  2. DNSCrypt Wikipedia – https://en.wikipedia.org/wiki/DNSCrypt
  3. DNS Over HTTPS (Google Public DNS) – https://developers.google.com/speed/public-dns/docs/dns-over-https
  4. DNS over TLS (Quad9) – https://quad9.net/faq/#Does_Quad9_support_DNS_over_TLS