Monthly Archives: February 2015

Why You Should Always Use Root Hint Lookups (and avoid DNS Forwarding)

I’ve had this on my mind a while, but never fully published this until now. I’ve been called out a number of times to various customers who have internet connection issues… and found bad DNS setups the culprit, oftentimes DNS Forwarding. I’ve also argued over more than a few beers about using them.

I also want to mention: I know IT people like to pontificate. I’m talking about companies with 10-2,000 users in a typical Active Directory environment. I’m not talking about companies with 2,500,000 users and external-facing infrastructures or service providers who offer DNS as a service. Those companies are likely to use advanced technologies way outside the scope of your typical Microsoft DNS Server setup and the people who implement those technologies aren’t likely to be reading my blog to understand far simpler setups.

Why You Should Not Use DNS Forwarders:

  • DNS Servers Change
    … and they change well after you’ve forgotten about your customer. If you’re even aware of the changes, will you remember every customer you’ve set forwarding up for using that IP?
  • DNS Servers Go Down
    Here in Rochester NY, we’ve had a few circumstances where our area’s primary DNS servers have been down. Granted, it’s 15-20 minutes at most, but that’s enough to anger people. Meanwhile, your internal DNS Server needs to be up using Root Hints or Forwarding anyway, so why have the added dependency?
  • You Marry Your ISP
    If I had a dollar for each time someone has changed ISPs and then “went offline” I’d … well, I’d be worth about $15. Regardless of how you value your money, you will have a server you forgot about lose DNS when you change your ISP and your forwarders no longer work.
  • WAN Failover Breaks
    A half-dozen times or more, I’ve assisted engineers with WAN Failover setups that didn’t work when the primary connection went down. Why? Because the DNS Forwarding was configured using the Primary ISP’s DNS server and when they failed over, those DNS Servers stopped answering queries. Worse, people then just slap Google’s 8.8.8.8 in there to “fix” it.
  • Problems Are Twice As Complex
    I had a school district who couldn’t load specific websites. After some packet-level analysis, I figured out why: the Windows DNS Server and their ISP weren’t playing nicely when using DNSSEC, which the specific sites had configured. The fix was either disable DNSSEC on the Windows DNS Server or use Root Hints. Luckily, they’d recently set up WAN Failover so I could give them my lecture on why it was a bad idea.
  • It’s More Secure
    ISP DNS Servers are going to be the first targets of hackers trying to redirect your banking traffic, vendor logins or other DNS queries to their malicious servers. Your DNS Server is secured nicely behind a firewall and hackers are much more likely to go after the machines in your ISP’s DNS pool.
  • You’ll Never Get Answers from Servers That Aren’t There
    I had a customer continuously receive certificate errors whenever they opened Outlook. After investigation, I discovered that the autodiscover.domain.com record was receiving replies – when it shouldn’t have been. Why? Because the ISP’s DNS server was redirecting traffic from the non-existent domain to their helpful pain-in-the-ass search website, which was responding on HTTPS with an invalid certificate. Sure, there was some fault in the Exchange setup but this side-effect shouldn’t have happened at all. It’s also happened when someone loads http://domain.com and the record doesn’t exist, and in other situations. Using Root Hints means you’re going to get a real, honest DNS lookup.
  • You Get Live Data
    When you query against the Root DNS Servers, you get the most recent information possible. I’ve had nameserver records change for domains that required 72 hours for an end-user to properly resolve because their ISP has (likely inappropriate) levels of caching and returned the wrong values when forwarded.
  • It’s Idiot Proof
    Seriously, direct lookups have been working flawlessly since … well, the mid-1980s. There’s no compelling reason to go the more complicated route with forwarders. This is pretty simple and very reliable technology, there’s no reason to rely on your ISP to get it right when you can.
  • You Probably Set It Up Wrong
    I’d like to ask Microsoft why, in their wisdom, they left the default timeout for DNS Forwards at 3 seconds. Most DNS resolvers time out after 2 seconds, so the second or third DNS server you’re forwarding to is never going to really service the end user on a lookup unless you drop this to 1 second. Also, have you looked at caching and other considerations? While not really complex, there are some considerations I never see accounted for when forwarding is set up. Again, let the DNS Server do its job.

DNS Forwarding Myths:

  • It Reduces Traffic
    This is silly – there’s very little difference in traffic between lookups. Recursive or not, the results are cached for the next lookup – the majority of DNS queries come from the cache after an initial loading period.
  • It Reduces Server Load
    Unless you’re familiar with your DNS Server’s source code, this argument is silly and uninformed. Who is to say that a recursive lookup through an external DNS server is any more or less computationally intensive on a machine than a non-recursive lookup? And unless you’re processing tens of thousands of DNS queries a second, it won’t matter.
  • It Prevents DNS Exposure
    … just wrong, wrong, wrong. Your DNS Server is going to resolve any query for a name it doesn’t know about – whether forwarding or using root hints. If your DNS server is attempting to resolve internal hostnames through your WAN port you have it configured wrong.
  • It’s More Secure
    Some people claim that by going to your ISP’s DNS Server, you’re reducing exposure. Firstly, DNS is a pretty simple (and pretty darned secure) protocol, particularly when it’s behind a firewall and not answering public queries. If a potential hacker has the ability to modify or inject malicious packets into lookups done through a DNS root server, why could they not do the same with your ISP’s DNS server addresses?
  • It Prevents Cache Poisoning
    Since Server 2003, Microsoft’s DNS server has had protections against this by default. But what do you trust more to provide a reliable DNS query/response – your ISP’s DNS servers, or the internet’s heavily fortified root servers? And if the root servers are compromised, would your ISP’s results not also be in question?

I’ll state again – there are plenty of times when you want to use DNS Forwarding. If I had a campus with dozens of buildings or many floors of users, I might have my various internal servers forward external lookups to a DNS setup somewhere else to minimize the WAN traffic of 40 DNS servers (where caching at another level would really benefit things), but those purpose-built servers would be querying the root servers for answers…

The Woes of a Base Cisco ASA License

Though past the end-of-life announcement, the Cisco ASA 5505 is still a common router to see. I feel as though just yesterday I was installing them regularly. Today I’m recommending their replacements. Gosh, I feel old…

Anyway, the ASA5505 came with a base license that was – essentially – a total turd. Sure, it has the awesome ASA feature set, but it came with a limitation of 10 users and 1 LAN (and a DMZ, but you weren’t allowed to route traffic between them openly). But it was cheap and has the Cisco name on it and as such, many users bought them. Later on, they’ll add a printer, a credit-card machine and a little file server and boom – they’re over a long-forgotten limitation of ten hosts.

If you have a number of machines on a LAN that experience intermittent connectivity with the outside world (and one PC you test from never seems to go down), that’s because the Cisco has hit the license limitation for network hosts and is preventing other machines from getting online.

Enable console or buffered logging at (I believe) a debug level and check for messages like this one I stole from another blog:

11:29:05 450001 24.106.9.206 80 Deny traffic for protocol 6 src outside:216.81.128.197/23580 dst inside:24.106.9.206/80, licensed host limit of 10 exceeded

You can also issue a show local-host command to see the host limit and current host count:

someones-asa-5505# show local-host
Detected interface 'outside' as the Internet interface. Host limit applies to all other interfaces.
Current host count: 12, towards licensed host limit of: 50
[...]

There’s also the show activation-key command to see what you’re licensed for:

someones-asa-5505# show activation-key
Serial Number: ABC1234ABCD
Running Activation Key: [Redacted]

Licensed features for this platform:
Maximum Physical Interfaces : 8
VLANs : 20, DMZ Unrestricted
Inside Hosts : 50
Failover : Active/Standby
VPN-DES : Enabled
VPN-3DES-AES : Enabled
SSL VPN Peers : 2
Total VPN Peers : 25
Dual ISPs : Enabled
VLAN Trunk Ports : 8
Shared License : Disabled
AnyConnect for Mobile : Disabled
AnyConnect for Cisco VPN Phone : Disabled
AnyConnect Essentials : Disabled
Advanced Endpoint Assessment : Disabled
UC Phone Proxy Sessions : 2
Total UC Proxy Sessions : 2
Botnet Traffic Filter : Disabled

This platform has an ASA 5505 Security Plus license.

Server 2012R2 Install Issues on Hyper-V using Dynamic Memory

Posting this hoping I can help someone else out. I had a customer who wanted a Server 2012R2 VM built for a new accounting application… so I downloaded the ISO, created a VHD and built the VM using Dynamic Memory with a 512MB . Upon booting, I get as far as clicking “Install Now” when I received a similar error message:

 

Server2012R2ErrorWithDynamicMemory

For Google, it reads: “Windows installation encountered an unexpected error. Verify that the installation sources are accessible, and restart the installation.”

The error in the screenshot is easily searchable and resolvable, but initially I had a different error. The screenshot reads “Error code: 0xE0000100″, but when I first ran into this problem it read “Error code: 0xC0000005“. As I write this post, I wonder why the error code changes after one successful startup of the installation program, but alas …

If you try to install Server 2012R2 as a Hyper-V Guest and you get the “Error code: 0xC0000005″ message using Dynamic Memory – check your Startup RAM value. Despite this TechNet Article stating that 512MB is the minimum needed for Server 2012R2, there must be a RAM Disk or additional software that is utilized during the install process. I was successful with a Startup Memory value of 1024M. However, that was after I spent over an hour checking to make sure the HyperV services had access to the ISO files, re-downloading the ISO twice, checking MD5 hashes of the file against a known-good and making sure the VHD files were not corrupt…