Bailiwick in DNS requests

So a month or two ago Dan Kaminsky discovered one of the most severe flaws from the last recent years, perhaps even since the internet boom.
With the flaw, hackers can redirect internet traffic by answering maliciously to your DNS requests.
Dan has written a nice article on his blog.
More details and patches you can find on the Microsoft sites.

Since I realised I knew nothing about how this exploit actually functioned, I read up on it last week, in a spare minute and came across something I never heard of before: bailiwick.

So I decided to spend a little more time on this and did some research on the "bailiwick" thing.
This is what I found out:

There are two important precepts to remember about content DNS server bailiwick:

1. Bailiwick is in the eye of the beholder.
Bailiwick is not inherent in the content DNS servers themselves. Content DNS servers don't know anything about their bailiwicks. The bailiwick of a content DNS server cannot be obtained from the server itself. The DNS protocol does not provide it with any way of knowing who issues the referrals that cause resolving proxy DNS servers to come to it, or what those referrals are.

It is only the resolving proxy DNS servers following that referral that know what the referrals are. It is the resolving proxy DNS servers that track the bailiwicks of the content DNS servers that they send queries to, and apply them as they process the responses.

2. Bailiwick applies only fleetingly, and multiple bailiwicks can apply to a single content DNS server.
The bailiwick of a content DNS server applies only to the query resolution at hand. A content DNS server can have many bailiwicks because it is referred to for information on names in several different domains. If multiple queries are being resolved for names in these different domains, it can indeed have those bailiwicks simultaneously.

For example: If the content DNS servers listening on IP addresses 207.228.252.101 and 209.81.71.60 serve up information on names in both the "scitechsoft.com." and the "openwatcom.com." domains, because they are owned by people who own both of those domains, then they will have the bailiwick "scitechsoft.com." when the "com." servers refer resolving proxy DNS servers to them for information on names in "scitechsoft.com.", and the bailiwick "openwatcom.com." when the "com." servers refer resolving proxy DNS servers to them for information on names in "openwatcom.com.".
For another example: The Verisign/Network Solutions content DNS servers serve up information on names in "com." and "net.". Their bailiwick is "com." or "net.", depending from the query being resolved at the time, and hence from what domain the "." content DNS servers actually issued the referral pointing at them in the first place.

The complete article on it, you can find here.

Very interesting stuff, if I can say so myself ... :)

Microsoft offers cooperative technical support on Validated Virtualized Environments!

What's the biggest concern when virtualizing your environment? No, not performance, not scalability, not management, not costs, ...
Instead, it's the fact that when you have a serious problem, not linked to the fact that the servers are virtualized, you are not covered by the Microsoft support program.

Now, thank to the SVVP (Server Virtualization Validation Program) program you don't have to worry about that anymore. ESX 3.5 U2 is the first VMware hypervisor being covered by the program. Providing VMware customers who run Windows Server and Microsoft applications with access to cooperative support from Microsoft and VMware.

Thus, eliminating one of the biggest factors why enterprises were reluctant to virtualize mission critical servers.

Message from VMware:
Microsoft’s Server Virtualization Validation Program enables VMware and other software providers to test and validate their virtualization software to run Windows Server 2008 and previous versions of Windows Server. Under this program, Microsoft offers cooperative technical support to customers running Windows Server on validated, non-Microsoft server virtualization software, such as VMware ESX 3.5 update 2.

The rest of the article you can read here.

Extracting the details from a CSR certificate request

I'm sure that those of you that have already created, configured and implemented certificates before know the importance of filling in the correct details when creating the certificate request.

The other day I had to create one to secure a website for a customer. But there were a few issues. They had a root certificate authority in place (somewhere in the states), but the site where I was at (Belgium) didn't have any information for me on what I needed to fill in. Viewing the time difference, I couldn't just pick up the phone and call ...

Instead I found this great site that allows you to paste an existing CSR into a tool they created and it extracts all the information you need:
1. Common name
2. Organisation
3. OU
4. City
5. State/Country
6. Country

Very, very cool and handy.

The website you can find here: Check your CSR

Enjoy!