Azure Infrastructure pre-con ahead of #SQLSatCleveland

Microsoft Azure logoSQL Saturday in Cleveland, Ohio is next week, on February 3rd. If you’re in the area or can easily make it there, I hope that you can come out for a great day of free SQL Server training. I enjoy presenting at SQL Saturdays; they’re fun and educational days for speakers and attendees, alike. Last time we were in Cleveland it had snowed overnight when it was time to leave town on Sunday morning. I’ve lived even longer in the south now, so if that happens again, it’ll be even more fun this time.

In addition to my session on Saturday, where I will talk about using database projects in SSDT/Visual Studio, I’ll also be presenting an all-day session Friday on Azure Infrastructure. Planning and designing your infrastructure is just as important in the cloud as it is when building new systems on-premises. As Azure continues to grow and expand around the world, more companies will be choosing to migrate (or deploy new) services to the public cloud. Understanding the underlying components is imperative to maximum-performance and highly-successful Azure deployments and hybrid migrations. In this session, we’ll cover infrastructure fundamentals with a bit of a focus on deploying and running SQL Server in Azure; however, there will be plenty of general background discussion that can be used for any workload.

Registration for this precon is available here, on EventBrite:, with information about the overall SQL Saturday event available here:

Saturday is free, but tickets for the full-day precon are $150.

I hope to see you next weekend!

Help, Comcast’s DNS is sucking again!

This past Sunday, if you lived in parts of the Midwest (I know IN & IL were on the list, but I don’t remember who all else) and have Crapcast Comcast as your ISP, you might have had problems surfing the tubes, because they were having trouble with their DNS servers again. News of this spread through Twitter (at least that’s how I heard about it since I wasn’t affected directly), in a bizarre twist of news-spreading similar to people sending email at work letting people know that the mail server is down… Obviously with smartphones & such this is still a good way to spread such information, but it still strikes me as a bit funny 😉

(I’m not going to go into what DNS is here. I assume most people reading this are already going to know what it is, what it’s for, and why it’s important, so I’m going to skip this whole part.)

The main way to take care of this is to set your machine to use other DNS servers. The usual suspects recommended during times like this are Google’s two public servers, aptly named google-public-dns-a and (-c resolves to a server, but its IP isn’t as easy to just remember (more on that in a sec). Or, it’s a Google honeypot for smarty pants 😀 ). There’s also OpenDNS servers, which apparently do a bunch of other stuff like redirecting you to the right place when you misspell something. I don’t really know how well this actually works or anything; this is just what their Wikipedia page says.

Google’s own page explaining how to set these up is a good reference for what to do if you don’t know. They’re pretty good instructions, so knock yourself out there. These servers’ IPs are and, which are fairly easy to remember (and type), making it easy to set up on machines on-the-fly, which is important if you’re looking to set this up while DNS is down and you can’t get to…

Here’s what I prefer to do

Google’s instructions are fine to set up a machine or two, but what if you’ve got half a dozen boxes in your house and/or you want a bit of a more robust solution? Glad you asked!

Most likely, the machines on your home network are serviced by your router’s built-in DHCP server. At the same time it provides the machines with IP addresses to use, it also provides them with one or two DNS servers. It should be getting these addresses from your ISP in basically the same way—it’s a DHCP client instead of a server on its external-facing port.

Obviously, under normal circumstances, your ISP is going to be providing their own DNS servers for this use, as it allows them to load custom search pages and stuff if they want to. (Did Comcast ever go through with doing that?) If your router supports it, however, you can override these settings, and that is where the more robust solution to this DNS problem comes in.

Somewhere in your router’s settings is probably a section called “Basic Setup”, “Basic Settings”, or something similar. This section will include things like the router’s name, authentication settings in case your ISP requires that, and possibly more advanced things like MAC address spoofing. What you’re looking for here is a section that refers to “Static” or “Manual” DNS servers like these:

WRT54G Settings

Old Linksys Settings screen

Netgear Settings Screen

Netgear Settings Screen

These are a couple of the routers that I have available to look at. The first one is an old Linksys WRT54G (if you aren’t actively using one of these at home…well…you have my sympathy) and the second one is our travel router, some random Netgear thing. These are the general settings areas that you’re looking for.

The main idea here is to put Google’s DNS servers’ IPs into those manual configuration boxes. You could forego your ISP servers altogether and just put in both of Google’s server and call it a day. However, for some reason, this strikes me as something that isn’t the best idea. I don’t have a real good reason for it, it’s just one of those things that doesn’t feel right. What I would do is to get one of your ISP’s DNS servers and put that in as your primary, then one of Google’s servers as the secondary (or tertiary, if you have an option for 3). That strikes me as a safer option, but there is one thing to keep in mind: If your ISP ever changes their DNS servers, since your settings are manually configured, that change won’t be made automatically like it otherwise would. Obviously if you’ve got one of Google’s servers in there, things will still work, but name resolution may be a bit slower if your machine picks the now-broken IP first and you have to wait for that to time out before it hits the second machine. This is just something to weigh; I don’t know that there’s a good reason to not just put Google’s DNS servers in there and go on with life, other than it’s almost definitely an “unsupported” configuration in your ISP’s eyes.

The reason I advocate this method of setup is simple: When you do this, these addresses will be passed on to your workstations when they get IPs to use from the router. This will happen for every machine that connects to your network, so you only need to set this up once to use these other servers.

While you’re in here messing around, it is important to leave the router set to get its external IP via DHCP or whatever else your ISP has told you it needs to be set to. If you do this, then things will work OK for now, but at some time in the near future, it’s probable that things will stop working altogether. If you can’t manually set your DNS servers without leaving the IP address on Automatic/DHCP, then you won’t be able to set DNS up this way, and you’ll need to use Google’s instructions to set each of your machines individually.

Nutjob solution

Or, forget all this, run your own DNS server, point it at the Root Hint servers, and thumb your nose at Comcast’s inability to do simple things like keep some DNS servers happy.

I have no idea who would do such crazy things, though <.< >.>