/64 block in IPv6 router links

I note that some ISPs and organizations are not using /64 block in IPv6 router link or IPv6 peering.

Unlike IPv4 which normally has a subnet mask of /30 in router link for reserving the available IPv4 addresses , there is no need to make the subnet mask as /126 in IPv6. Just use /64 will be good enough and this is the default in a basic network segment. Put it another way, this is not a waste IPv6 addresses but an industry norm.warrenkwok

Can IPv6 resolve cache-poisoning

Lately, I have been thinking about whether IPv6 can help to prevent cache poisoning.

A resolver running IPv4 can have one source IPv4 address to use whereas one riding on IPv6 can have up to 2^64 addresses to use within a basic network segment. Each time, the IPv6-enabled resolver sends out a query, a random IPv6 address within the assigned prefix should be selected. This way, the chance of cache poisoning will be a factor 16 bit transaction ID, 16 bit random port number plus 64 bit source IPv6 address. That says, the chance of poisoning is 1 in 2^96 which is not a problem at all.

However, the reality is that not all authoritative name servers are IPv6-enabled. If the Internet world had implemented IPv6 much earlier, cache poisoning should have been resolved and DNSSEC would not be necessary.

DNSSEC resolvers weakness

I notice there is a weakness in DNSSEC-aware resolvers which is the root public key.  If hackers can disrupt the pre-stored root trust anchor, the resolvers can not resolve any domain due to chain of trust not  established.  But is that a big deal.

No, not at all.  ISPs are required to supply 2 or more resolvers to clients.  Even one resolver breaks down, the other will serve immediately.  The chance of hackers damage two resolvers at the same time is quite limited.

Pre-published rollover of zone signing keys

I have turned to the use of pre-published rollover of zone signing key in order to manage DNSSEC in one of my administered zones. I need to draw a diagram to remind about the timing sequences and what keys to sign and publish. Here it is.

The above process must be done by cron job and shell script for automation.

Root and TLDs shall not sign child's NS glue records

I have been wondering if root zone and TLDs are required to sign the NS glue records for their child zone since these TLDs are required to sign the DS records of their child zones. The answer is negative. Current release of DNSSEC specifications do not require such signing as TLDs are not authoritative for their child zone glue records. Whatever submitted will be accepted and stored without question. Just give a live example. If I get abc.com and the glue reccords say ns1.abc.com is at 1.2.3.4. Verisign, the operator of .com TLD will never ask me to prove this information.

Sounds pretty reasonable. Will there be any risk due to no signing of NS glue records for child zones. Hackers will know after some time.

Start time of RRSIG fall behind 9 hours from the system clock after zone signing

I was wondering why the start time of RRSIG fell behind 9 hours from the system clock when zone signing was completed. On careful lookup of dnssec-signzone, it was stated that RRSIG should have a start time of UTC-1 hour in order to allow clock skew. It also made sense that RRSIG should be time-stamped with UTC. Since the time zone of Hong Kong is UTC +8, after adding one hour for clock skew, all RRSIG generated will be 9 hours behind the system clock.

This triggers me to think about another issue. If you have a nameserver that performs DNSSEC zone signing, it is better to change the clock to UTC instead of the local time. It will help to track RRSIG start and expiry more easily.

Rescue boot process of Windows XP again

What a bad luck.  Within 6 months, I had 2 machines running Windows XP not able to boot up.  Fortunately, during the last failure, I wrote down the rescue method.  This time, the failed machine had Windows XP in F drive while C, D and E hard disks  were just non-OS drives.  The rescue was to boot Windows XP CD to repair mode and then invoke “fixboot f:”.  It might be good to do “bootcfg /rebuild” if fixboot report any errors.

Which TLDs are now having Delegation Signer (DS) signed by root

A question can be asked do you know if which TLDs are DNSSEC-enabled and have been signed by root.  I have a solution using "ldns-walk . | grep DS".  As shown in the screen dump below, they are : .bg, .biz, .br, .cat, .cz, ..dk, edu. .lk, .museum, .na, .org, .tm, .uk. and .us.  Hey, the US Government mandated the use of DNSSEC for .gov, what happens to .gov ?

Only less than 5 % of global IPv4 addresses remain

Bad news.  The remaing IPv4 addresses unallocated are less than 5 %.  This is an alarm.  If your company has not started deploying IPv6, act now.

PCCW can now offer IPv6 services

PCCW, the bigggest ISP in Hong Kong, can now offer IPv6 services by way of dual-stack approach. If you are corporate customers of PCCW, ask PCCW for IPv6 address block and how to seamlessy migrate to IPv6.

In fact, PCCW is the biggest ISP in Honb Kong.   Now that the biggest ISP has embarked on IPv6, other competitors will follow suit.

For my record, IPv6 service providers in HK are NTT Com Asia, CPCNet and PCCW.

Obtaining DNSSEC Logo

DNSSEC Logo is now issued by http://www.dnssec-logo.org/.

Once a domain is submitted, the zone admininistrator mentioned in the SOA record will receive an email on how to proceed.   There are three levels of certification:

Bronze - Zone is properly maintained, i.e. passes classical zone checks, and is correctly signed.

Silver - The KSK of the zone is correctly refered by the parent zone (if signed) or registered at one of the common TARs. During the last six months a ZSK rollover following the procedures of RFC 5011 was observed.

Gold - During the last year a KSK rollover following the procedures of RFC 5011 including the parental delegations was observed. Access is granted to the zone contents for exhaustive RRSIG checks.

I shall apply for DNSSEC logo in order to test my capability of managing DNSSEC.

DNSSEC Signature Expiry

What will happen if the stub resolver of a browser works on DNSSEC only and the signature of a address record of the domain name have expired.  The simple answer is that the browser can not allow access to the site.  My captured picture is attached below (see the red warning key).

Changing the default resolvers assigned by DHCP

One of my Linux machines get IP address from DHCP Server and as a result, the resolvers are pre-assigned in the file /etc/resolv.conf.   I wanted to use my local DNSSEC-aware resolver @127.0.0.1.  My way of doing this is to add the following in /etc/rc.d/rc.local :

cat /dev/null > /etc/resolv.conf
echo "nameserver 127.0.0.1" >> /etc/resolv.conf
service named restart
rndc flush

CPU Thermal Shutdown due to heat generated from display card

One of my desktop PC with Intel motherboard D865PERL experienced frequent thermal shutdown after booting up for several minutes.  The CPU heat sink was not hot at all.  I guessed the motherboard sensors detected excessive heat from devices close to the CPU. Without doubt, this should be the display card.  What I tried to do was to do a CMOS reset and then replace the fan of the display card.  

Things got normal now.

Fedora Core 13 on a USB memory stick

I used Live USB Creator to make Fedora Core running on a 2GB USB stick.  The amount of persistent storage was set to 700 MB.   Guess what, everything is so smooth.  I can boot up the USB to have a working desktop version of Fedora Core 13.  Since there is space for persistent storage, user profiles, file moves and changes can be saved.    It is a thriving experience.

Root trust anchor and DNSSEC Lookaside Validation Registry working side by side

Previously, I had the idea that DLV Registry scheme administered by the Internet System Consortium (ISC) would cease operation after 15 July 2010 when the root zone is signed. Recently, I have come across the config file of a recursive validator running BIND 9.7.1 and found that DLV is supplementing the root trust anchor. This is great since DLV Registry has a large number of domains already deploying DNSSEC but their parent zones (such as .com, .net or .hk etc) have not started DNSSEC operation and provided signing for their child zones.

Without DLV, in the absence of a fully signed path from root to a zone, users wishing to enable DNSSEC-aware resolvers would have to configure and maintain multiple trusted keys into their configuration. Maintaining multiple trusted keys by hand is an unmanageable task. ISC DLV removes this need by serving as a trusted repository of entry points through which those keys can be securely retrieved by the resolver when it needs them.

Here is the named.conf for Bind 9.7 using root trust anchor and DLV:

//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//

options {
// listen-on port 53 { 127.0.0.1; };
 listen-on-v6 port 53 { ::1; };
 directory  "/var/named";
 dump-file  "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
 allow-query     { localhost; 192.168.73.0/24; };
 recursion yes;

 dnssec-enable yes;
 dnssec-validation yes;
 dnssec-lookaside auto;

 /* Path to ISC DLV key */
 bindkeys-file "/etc/named.iscdlv.key";
};
trusted-keys { 
"." 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0="; };
logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
 type hint;
 file "named.ca";
};

include "/etc/named.rfc1912.zones";

// End of config

15 % of all .cz domains are DNSSEC-secured

Congratulations to the Czech Republic (.cz) Government.  There are about 700K “.cz” registered domains but as of today, over 100K are DNSSEC-secured. This is really a world leading position in infrastructure and application security.