Check out the Windows Server 2008 R2 DNSSEC Deployment Guide here:

http://www.microsoft.com/downloads/details.aspx?FamilyID=7a005a14-f740-4689-8c43-9952b5c3d36f&DisplayLang=en

Please note that this is a Beta guide.  Your feedback is most welcome!

DNSSEC also features in the "What's New in DNS in Windows 2008 R2 page": http://technet.microsoft.com/en-us/library/dd378952.aspx

Folks, there's an important issue that I'd like to draw your attention to.  This has to do with Windows 2008 RTM DNS server.  Here's a quick blurb on what the issue is:

If you're hosting a secondary DNS server with hevay traffic, what you may see is that all the records in the secondary DNS server get deleted.  This is because of a bug, which causes the secondary server to treat the zone as "expired".  The fix is available, and we want to make sure that you're aware of it and know how to fix it.

The directory services team has written a much more extensive blog post about this in their blog http://blogs.technet.com/askds/.  Check out Craig Landis' blog post here:  http://blogs.technet.com/askds/archive/2009/02/12/headache-prevention-install-hotfix-953317-to-prevent-dns-records-from-disappearing.aspx.

KB 953317 (http://support.microsoft.com/kb/953317) has the link to the hotfix that will fix this issue.

Yeah…it’s about time we talk about this, isn’t it?

As part of mitigating the threat posed by the Kaminsky vulnerability, which Dan explains in detail in a blog post he published a while ago, Microsoft released patches to the Windows DNS servers that included a feature called “socket pool”.  This was released as Microsoft Security Bulletin MS 08-037.

In Windows 7, there is another additional feature that adds another layer of security called “cache locking”.  I’ll talk a bit about both these features now.

The Socket Pool is the way Windows DNS achieves source port randomization.  Instead of using a predicable source port when issuing queries, the DNS server will now randomly pick a source port from a pool of sockets that it opens when the service starts.  Depending on the OS version, the socket pool is opened either in the 49k to 64k range or the 10k to 49k range.  An attacker will have to guess this source port in addition to the random transaction ID to be able to successfully execute the cache poisoning attack. 

The size of the socket pool is stored in the registry under HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters\SocketPoolSize.  If you open regedit and don’t see this key present, then that means that the DNS server is using a default of 2,500 ports. The registry key only gets created when you attempt to modify this value.

When the DNS service starts up, it reads the value of the socket pool size from this registry location.  It then calls the TCP/IP stack and begins to open up these sockets.  Once they’re all open, the DNS server randomly picks a socket for each query it sends.

By default, the socket pool size is 2,500.  Note that this means 2,500 ports for IPv4 and 2,500 ports for IPv6.  The max value for the socket pool is 10,000.

How do you control the value of this setting? 

Ø  Dnscmd /Info /SocketPoolSize will tell you the current size of the socket pool

Ø  Dnscmd /Config /SocketPoolSize <val> sets the socket pool size to #val

Ø  Once you reset the size, you must restart the DNS service.  Use net stop dns to stop the service, and net start dns to restart the service.  Once the service has restarted, the new socket pool will come into effect.

Now some customers experienced loss of Internet connectivity after installing this patch on computers that had certain versions of ZoneAlarm installed.  ZoneAlarm released a bulletin to address this issue.

Last week NetworkWorld.com published an article that said that one in four DNS servers are still vulnerable to Kaminsky flaw.  If you’re running Windows DNS and haven’t patched yet, do so!  Do it now.  Remember, this mainly affects recursive DNS servers, so if you have no recursive DNS servers, you can panic less.

In Windows Server 2008 R2 DNS server, we’ve made an additional tweak to the socket pool.  The patch released only allows you to turn on/off the socket pool and specify a socket pool size.  However in R2, you can now specify an exclusion list – i.e. a list of ports/port ranges that the DNS server should not bind to.  Therefore, if you have another application on your DNS server that you know binds to a specific port in the 49k – 65k range, then you can add that port to the exclusion list.  DNS server will not bind to that port (or ports) and leave them free for the other application to use.

To set up this exclusion list (available only on Windows Server 2008 R2), use:

Ø  Dnscmd /Config /SocketPoolPortExclusionList

Now Windows Server 2008 R2 DNS server (aka Windows 7 server) contains an additional layer of security with a feature called cache locking.  Understanding TTLs is key to understanding this feature.

Each DNS resource record comes with a Time-To-Live (TTL) value.  This tells another caching server/resolver how long to keep the record in the cache before deleting it.  Accordingly, until the TTL expires, the server will retain the record in the cache.  However there is nothing preventing the server from overwriting the entry in the cache before the TTL expires if it receives updated information about that name.

One of the most dangerous aspects of the Kaminsky attack is that it allows an attacker to overwrite a pre-existing cached delegation. A reasonably valid assumption is that for any domain that is worth attacking, all DNS servers that are serving a typical set of clients will have a valid cached delegation in memory in the steady state. As soon as the valid cached delegation expires, another client is likely to fairly quickly submit a query for a name in the zone, causing the delegation to be re-cached.

Cache locking is measured as a % value.  For example, if the cache locking value is set to 50%, then the DNS server will not overwrite a cached entry for 50% of its TTL.  So, if the DNS server has a cached entry for www.contoso.com with a TTL of 60 minutes, for the first 30 minutes after creating the cache entry, the DNS server will not overwrite the entry even if it receives different data about www.contoso.com.

How does this protect against the Kaminsky vulnerability?  Think about what the attacker is doing – he is running the race over and over again, by querying for 1.contoso.com, 2.contoso.com, 3.contoso.com and bombarding a reply that essentially says “Don’t know where n.contoso.com is, but ask www.contoso.com, who by the way is at <attacker’s IP>.”  And, to successfully complete the attack, he’s counting on the fact that if/when he does win the race, his IP address gets cached against www.contoso.com, overwriting what already may be there.

By default, the cache locking percent value is 100.  This means that cached entries will not be overwritten for the entire duration of the TTL.

The value is stored in this registry location: HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters\CacheLockingPercent.  As with the socket pool, if you look at the registry and don’t see this registry key, then the DNS server will assume a default of 100.  The registry key only gets created when you attempt to modify the value.

Here’s the magic that makes it work (available only on Windows Server 2008 R2):

Ø  Dnscmd /Info /CacheLockingPercent will tell you what the current value of the cache locking percent is.

Ø  Dnscmd /Config /CacheLockingPercent <val> will set the cache locking percentage to #val.

Ø  Once you reset the size, you must restart the DNS service.  Use net stop dns to stop the service, and net start dns to restart the service.  Once the service has restarted, the new socket pool will come into effect.

Wow, the response to Windows 7 so far has been fantastic!  PDC and WinHEC are over, the world has had a chance to finally get a preview of what we’ve been working on for over a year, and it is immensely satisfying to see such positive feedback.

Now let’s start talking about the different pieces of DNSSEC in Windows 7.  Let’s begin with the DNS client since I think it would be easier to digest to start off with.

So in my last blog post, I used a rather gory term to describe the DNS client in Windows 7.  I said it is a “non-validating security-aware stub-resolver”. It may sound scary, but if you look at it carefully, it is rather self-explanatory.  Still, let me help you understand this a bit better.

In a nutshell, what this means is that the DNS client will not perform DNSSEC validation on its own.  The client relies on its configured DNS server to perform validation on its behalf.  One positive side-effect of this is that Trust Anchors do not need to be configured on the clients, thus saving a big chunk of the deployment burden.  It is however security-aware, so it will expect the configured DNS server to indicate results of the validation when returning the response.  This is done so by setting the “AD” bit in the response.  If the DNS server failed to validate successfully (indicated by the AD bit not being set in the response), the DNS client will fail the query.  

The security-aware behavior of the client is not a binary on/off.  It is a policy based mechanism whereby the “Name Resolution Policy Table” will tell the client on which domains it is to expect DNSSEC.  Only for those domains will the DNS client set the DO bit in the query and expect the AD bit in the response.  The Name Resolution Policy Table (or NRPT for short) is a table of settings and configuration which defines the DNS client’s behavior when sending out queries and tells it what to do when receiving responses.  The NRPT contains settings that pertain to DNSSEC as well as another new Windows 7 technology known as Direct Access.  I won’t go into Direct Access here though.

Let’s look at an example of the NRPT.  Below are a couple of rules in the table.  Note that I have simplified the table contents a little for illustration purposes.

So, rule 1 (*.example.com) applies to the example.com domain and all its subdomains.  If an application passes in a query such as www.example.com to the DNS client, that query will match this rule in the NRPT.  The rule then says that the DNS client must set the DO bit when issuing the query and check for the AD bit in the response.  The rule also says it must use IPsec when issuing this query to the DNS server.  And that’s exactly what the DNS client will do in this case.

Rule 2 is what we’d call an “exception”.  If you look at the namespaces for rule 1 and rule 2, foo.example.com is a subdomain of example.com, hence the rule for example.com would apply to queries for foo.example.com as well.  However, because a more specific rule is present in the table, any query under *.foo.example.com will match rule 2 and not rule 1.  Rule 2 says no DNSSEC, hence the DNS client won’t set the DO bit, won’t look for the AD bit in the response and won’t use IPsec either.  (Note that the above is what you’d do when you have a signed-to-unsigned delegation). 

And there you have it…that in a nutshell is the DNS client’s behavior with respect to IPsec. 

A week went by very quickly!  Cairo was fabulous.  I certainly want to go back to the city at some point of time.

To be honest, I didn’t quite know what to expect going in.  Of course, I had seen pictures of Cairo the city and even some YouTube videos, but that can only tell you so much.  I tried to draw an image of Cairo in my head, and that turned out to be more difficult than I imagined.  Still, I left New York with a hybrid image of what I thought Cairo would be like.  What surprised me the most was that when I actually got there was that it wasn’t at all like how I had imagined. 

Several thoughts crossed my mind in the week before I left and even on the 12 hour flight from JFK to Cairo.  It’s Cairo, Egypt.  Egypt!  Pyramids, Pharaohs, mummies, mystical pagan worshippers… But wait.  Egypt is also in Africa!  And you know what that means – Elephants, safari, forests.  No, actually, Egypt is very much covered by the Sahara desert.  Ah, the desert – sand everywhere (including inside my shoes), scorching heat and camels!  The Nile…river, water, oasis?  And then I spoke to my father who reassured me that Egypt is more an extension of the Middle East and would resemble Dubai or Doha more than it would any African city.  So I added skyscrapers, the Cornish and men in white robes to the melting pot in my head as well.  By the time I landed in Cairo, I was expecting a city full of elephants and camels side by side, with the sun beating down while Brendon Frasier guarded the three great Pyramids of Giza, while I roamed the city in a fancy Mitsubishi SUV on American-style disciplined roads lined with palm and date trees.

When I finally got to Cairo, I took a taxi and left the airport complex.  I was just about absorbing all the Arabic and the statue of Ramses when it hit me – wait a second…did I somehow end up in India?  Now having spent almost a week there, in my opinion the best way to describe Cairo would be to take any large Indian city including the traffic indiscipline, the honking, the crowds and the pedestrians and merge it with Arabic signboards, some sand on the side of the streets and a lot of sunshine.  That, my friends, is Cairo.  Cairo, where the amount you pay to a taxi driver depends on…what he feels like.  Cairo, where telling someone that you’re an Indian immediately draws a smile on their face and prompts a reference to Amitabh Bachchan.  Cairo, where people seriously speak Arabic at a breakneck pace.  Cairo, where there are absolutely no traffic lights or roundabouts (seriously, I saw one traffic light in Nasr City near Anwar Sadat’s memorial, and that too was blinking orange).

Fantastic. 

The 33rd ICANN meeting is underway in Cairo, Egypt. On Wednesday, Nov 5th, I will be talking about Windows DNSSEC at the DNSSEC workshop. Check out the agenda for the session here: http://cai.icann.org/en/node/1649.

Check out Jonathan Hassell's article on computerworld. 

http://www.computerworld.com/action/article.do?command=printArticleBasic&taxonomyName=NOSes+and+Server+Software&articleId=9118322&taxonomyId=156 

I'm excited that I finally get to talk about what the DNS team has been working on for over a year.  That's right - DNSSEC.  It's in Windows, and it's on its way.

DNSSEC is a suite of security extensions to the DNS which provide origin authority, data intergity and authenticated denial of existance. Putting that in plain English, DNSSEC allows for a DNS zone to be cryptographically signed (which produces digital signatures), and provides a mechanism for validating the authenticity of the data received using these digital signatures.  Validating resolvers and servers must be pre-configured with a Trust Anchor, using which a "chain of trust" will be established to the signed zone. Data from this signed zone can then be validated.

The new and improved DNSSEC RFCs were published in 2005, and since then DNSSEC has seen a steady growth in attention.  However this year, things took a much more dramatic turn mainly because of the vulnerabilities that were revealed at BlackHat by researcher Dan Kaminsky.  More and more people are showing interest in DNSSEC as a good solution to lock down their DNS infrastructures.

Well, the timing is just perfect.  Windows Server 2008 R2 DNS server will offer support for DNSSEC as per these new RFCs.  The DNS server is now capable of generating keys and signing DNS zones using a sign-tool that we are providing with the product.  The server will also be able to host these signed zones either as a primary or secondary zone, or as an Active Directory-integrated zone.  Once configured with a Trust Anchor, the server will be able to perform full validation of data obtained from other signed zones.

On the DNS client, we have implemented a non-validating security-aware stub resolver.  Doesn't roll off the tongue very easily, does it [:)]?  Breaking it down, all this means is that the DNS client relies on its local DNS server to perform DNSSEC validation and will check to make sure that the server has indeed done so. 

Pre-Beta builds of Windows are already available to those who attened the Professional Developers's Conference in LA that ended today.  I would strongly encourage those of you who do have Windows 7 to test out DNSSEC and tell us what you think about it.

Over the next few days, I will blog more about what is and isn't in the product, so stay tuned!

TechNet has a plethora of information on Windows DNS and Active Directory.  Check out http://www.microsoft.com/dns.  This is your first stop to anything-Windows DNS.  You'll find great links to content on DNS for Windows 2000, Windows 2003 and Windows 2008. 

Hello folks!  I'm Shyam Seshadri, the Program Manager for the Windows Domain Name System (DNS) server and client.  DNS is the Internet's phonebook, which is responsible for converting a human readable name such as www.microsoft.com into a computer readable IP address.  Computers use IP addresses to connect to other computers, but DNS allows you to access resources over the Internet or over a private network without having to remember these IP addresses and use names that are easy to remember.

Windows DNS server is one of the most commonly deployed Windows Server roles and is an integral part of an Active Directory deployment.  Every computer is a DNS client that allows applications such as web browsers to convert names to IP addresses.  In my role at Microsoft, I am responsible for both the DNS server that ships with the Windows Server operating systems as well as the DNS Client which ships with all Windows operating systems (server and client). 

I plan on blogging about best practices around DNS deployment, new features in DNS in upcoming releases of Windows as well as a little bit about the DNS team here at Microsoft.  But more importantly, I want to use this blog as a forum to reach out to the users and administrators of DNS and to hear your thoughts and comments on Windows DNS.

All postings on this weblog are provided "AS IS" with no warranties, and confer no rights.