Today, May 5 will be a good day to make sure your network is ready for DNSSEC. The last of the Internet’s 13 root servers will transition to DNSSEC. It could pose a problem for network administrators and users working with older DNS servers, routers, firewalls, and modems.

So, What is it for?

DNSSEC (Domain Name System Security Extensions) is a suite of specifications which implement record signing to ensure the integrity of certain types of transactions.  It uses both asymmetric and symmetric cryptography for RR (Resource Record) or zone transfer transactions, respectively. To ensure the authenticity of information received by a resolver. Securing DNS with DNSSEC begins with establishing a chain of trust. Resolvers use ‘anchor keys’ to verify parent domains, beginning with the trust anchor. DNSSEC will increase DNS traffic with more requests and larger responses. Domains with high volume traffic should prepare for increased bandwidth needs.

What it means to you?

One of the problems the DNS system has is that there are various techniques which are hard to explain but which are pretty well understood in certain nefarious quarters which can be used to trick a computer into believing a forged answer when its resolver asks a question.

When DNSSEC is fully deployed, it’ll provide a method your computer can use to thwart that kind of attack. DNS responses will be “signed”, and your computer’s resolver will be able to check the signatures to make sure they match. So when you type www.yourbank.com.cn and get a forged answer, your computer will know it’s forged.

DNSSEC deployment is a world-wide change to one of the systems that holds the Internet together, and is not something instigated or under the control of Internode as such. However, trying to ensure that in the unlikely event that it causes you a hassle, you will understand it and be able to do something about it.

Sounds good, why are the articles doom-saying about it?

To answer that, you need to know a bit of DNS history: Until relatively recently, DNS responses have usually been limited to 512 bytes, and have mostly been carried by an Internet protocol called “UDP”. So various bits of infrastructure such as firewalls and home ADSL routers have been designed on the assumption that all DNS responses are 512 bytes or less, transported by UDP.

The problem is that the digital signatures required by DNSSEC tend to push the size of DNS responses past the 512 byte point. This shouldn’t present a huge challenge, because the DNS protocol has a mechanism for transporting larger responses by sending them over TCP instead of UDP. But the mechanism has been so rarely needed that many vendors haven’t implemented it. Indeed, large DNS responses have been so rare that some firewall vendors and some companies’ security managers have actively blocked them on the assumption that the only possible reason they’d exist would be as part of an attack!

For people using systems which don’t work correctly with large DNS responses, Wednesday 5th May 2010 will represent a bit of a flag-day. On that day, the Internet’s root DNS servers will start emitting the digital signatures needed to authenticate their responses, and there’s a reasonable expectation that people who aren’t correctly processing large DNS responses will suffer connectivity problems to random bits of the Internet. Most systems should be fine, but older firewalls and ADSL modems might suffer problems.

What you should do?

Making sure your network and end users are ready for DNSSEC. Few Tips provided here may help you:

1. If you haven’t done so already, make sure your DNS servers, routers, and firewalls, can handle DNS requests with packet sizes larger than 512 bytes. Upgrade software and firmware if necessary.
2. Configure your firewall to allow DNS over RCP/53 and make sure “fragmented DNS responses over UDP or TCP aren’t blocked.”
3. If you support users’ home equipment, make sure it is also compatible with DNSSEC, especially if the device has a built-in DNS server. Install new firmware if necessary.

No one seems to be predicting that the May 5 DNSSEC changes will cause a significant Internet disruption, but it never hurts to make sure your network and your users are prepared. If you’re not sure, you can use the instructions at DNS-OARC to test if  your current DNS resolver can handle DNSSEC.

DNSSEC is undergoing a phased rollout and it won’t be ready for full use for a couple of years, but when the work is complete the security of the Internet infrastructure will be vastly improved. You can note that timeline on http://www.root-dnssec.org for other pertinent information about the deployment of DNSSEC for the root zone.

Log-in to your Gmail / Google Account and associate a phone number. You’ll then receive an SMS text message whenever someone tries to recover your Google password.

Create a new email address (on say Yahoo! Mail or Gmail itself) and set this as the secondary email address for your existing Gmail and Google Accounts. Check for emails on this new account manually or through a desktop client via POP3 / IMAP but do not enable auto-forward for the new email address as the original purpose will be defeated.

Take a paper and write down the following information about your Google Account. You will need this to verify your identify to Google in case someone else takes over your Google Account and the secondary email address associated with your account.

• The month and year when your created your Gmail / Google Account. You can look at the last page of your Gmail Inbox (or go to Sent Items) to get an approximate idea of the date when you created the account.
• If you created a Gmail account by invitation, write the email address of the person who first sent you that invite for Gmail. Use a search query like “in:all has invited you to open a free Gmail account” to find that invitation email.
• The email addresses of your most frequently emailed contacts (the top 5).
• The names of any custom labels that you may have created in your Gmail account.
• The day/month/year when you started using various other Google services (like AdSense, Orkut, Blogger, etc.) that are associated with the Google account that you are trying to recover. If you’re not certain about some of the dates, provide your closest estimate.

Do a test run. Log-out of all your Gmail / Google Accounts and initiate the password recovery process for each one of them using this form. This will help you make sure that your SMS settings and secondary email addresses are configured correctly.

Once in a while, do refer to that little line in the footer section of your Gmail Inbox that shows the different IP addresses from where your account is being accessed. If you find an unknown IP address, change your Google password immediately.

- Thanks Amit ,very useful. I'm glad that you got your account back.

The password of my Wordpress admin account was not valid when I tried to login today. I first thought it was a problem with the LastPass password manager and tried to see if I was still logged into the service. When I checked my email inbox I noticed that I have received a new password for the account. That was strange since I did not request a new password. It was not that much of a concern to me as I thought that someone might have used the password reset functionality to reset the password which meant that physical access to the new password was not possible. - Martin

A new post appeared on the Wordpress discussion list today revealing more details about the process. Everyone is apparently able to reset a Wordpress password if the email address of the Wordpress user is known. All that needs to be done is to point the web browser at http://www.domain.com/wp-login.php?action=lostpassword to reset the password. The email address of the account holder has to be supplied in the form. Wordpress usually will send a confirmation email first asking the email account owner if the password should be reset. The vulnerability manipulates the query to skip this step.

It is not possible to exploit this vulnerability further which means attackers cannot get access to the user account. It can however be theoretically be used to reset the password regularly to lock the user or admin out of the Wordpress blog.

A temporary fix for the remote admin password reset vulnerability was posted. Wordpress administrators need to change one line of code in the wp-login.php file of the Wordpress installation to protect their blog from the attack.

Replace

if ( empty( $key ) )

With

if ( empty( $key ) || is_array( $key ) )

It is advised to apply the temporary fix as soon as possible to Wordpress installations.

Update: The Wordpress team has nevertheless released Wordpress 2.8.4. as a response to the security vulnerability. The new release patches this vulnerability and is a recommended update for every Wordpress installation. Wordpress admins should head over to the Wordpress website to download the new version as of now.