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. 

10 Jul

Calculating IPv6 subnets outside the nibble boundary

Often this comes into the subnetting discussion by my friends who are deploying IPv6 for the first time. How do you calculate subnets outside the 4-bit nibble boundary? This also happens to be one of starting points of APNIC IPv6 routing workshop where I occasionally instruct as community trainer.

So what is a Nibble boundary?

In IPv6 context, it refers to 4 bit and any change in multiple of 4 bits is easy to calculate. Here’s how: Let’s say we have a allocation: 2001:db8::/32. Now taking slices from this pool within 4 bit boundry is quite easy.

/36 slices (1 x 4 bits)
2001:db8:0000::/36
2001:db8:1000::/36
2001:db8:2000::/36
and so on…

/40 slices (2 x 4 bits)
2001:db8:0000::/40
2001:db8:0100::/40
2001:db8:0200::/40

/44 slices (3 x 4 bits)
2001:db8:0000::/44
2001:db8:0010::/44
2001:db8:0020::/44

/48 slices (4 x 4 bits)
2001:db8:0000::/48
2001:db8:0001::/48
2001:db8:0002::/48

Clearly, it seems much simple and that is one of the reasons we often strongly recommend subnetting within the nibble boundary and not outside for all practical use cases. However understanding why it’s easy this way, as well as things like how to subnet outside nibble boundary for cases, say if you are running a very large network and have a /29 allocation from RIR.

Going back to fundamentals

IPv6 address consists of 128 bit addressing and is represented in hexadecimal.
IPv6 address:  _ _ _ _: _ _ _ _ :_ _ _ _ :_ _ _ _ :_ _ _ _ :_ _ _ _ :_ _ _ _ :_ _ _ _ 

Each dash here represents is written in hexadecimal and represents 4 bits, thus 4+4+4+4 = 16 bits in each block and 16 x 8 = 128 bit addressing. This brings that magical 4-bit nibble boundary.

So if we expand 4 bits into binary, we can have following combinations for each “dash” in above representation:

Here I have simply represented 4 bits from lowest to highest. Remember just like in the decimal system with base 10 (which we all are familiar with), we follow same logic in binary system where we start from lowest (0 0 0 0) and go to next digital (0 0 0 1) and now since it’s base 2, we go to next logical number which is (0 0 1 0) and so on. Now when we modify these 4 bits together, we do not have to worry about the decimal part but as soon as we try to go inside the 4-bit zone, we have to deal with the decimal counting.
So let’s take a real-world case of American Cable & broadband provider Comcast. They have an allocation 2001:558::/31:

What exactly /31 means here?

Going back by CIDR fundamentals /31 means 31 bits are reserved and remaining (128-31 i.e 97 bits) are available. How can they generate /32 or say /36 out of this allocation?

2001:558::/31
Writing in expanded form:

2001:0558::/31
(16 bits + 15 bits)

In above, first 16 bits are reserved for 2001 but for next part “0558” only 15 bits are reserved. Let’s expand the 2nd block further:

0 5 5 8 – 15 bits reserved

Here “0” gives 4 bits (and in binary is 0 0 0 0)
5 gives 4 bits (and in binary is 0 1 0 1)
Next 5 also reserves 4 bits
So far we are at (4 + 4 + 4) 12 bit count. Now that 15 bits are reserved, basically from “8” 3 bits are reserved and rest 1 bit is available for modification.

Let’s expand 8:

8 in hexadecimal = 1 0 0 0 in binary. Here 1 0 0  is reserved (each representing one binary bit and hence the three bits) and 4th bit can vary.
Hence possible combinations in binary are:
1 0 0 0
1 0 0 1

The remaining first three bits (1 0 0 ) cannot be altered as they are part of network mask. Now 1 0 0 0 in binary gives us “8” in hexadecimal and 1 0 0 1 gives us “9”. Thus possible /32s out of this /31 allocation are:

2001:558::/31 = 2001:558::/32  and 2001:559::/32

Similarly to calculate /36 slices from it, we can basically vary this 1 bit (as we just did) as well as next 4 bits altogether (5-bit variation). Hence possible /36 slices are:

2001:558:0000::/36
2001:558:1000::/36
2001:558:2000::/36
2001:558:3000::/36

and so on until 2001:558:f000::/36 (16 pools here)
and next,
2001:559:0000::/36
2001:559:1000::/36
2001:559:2000::/36
2001:559:3000::/36

and so on until 2001:559:f000::/36 (16 pools here). Thus we get these 32 /36 blocks out of /31 allocations.

That’s all about IPv6 subnetting. Once you understand this part, you should be just fine with subnetting in the future. 🙂