Public DNS Servers

Domain Name Resolution (DNS) is one of the services we take for granted every day. It works behind the scenes to resolve name-to-IP addresses. It works so well that we can accept the defaults without clearly understanding how it works. Most ‘computer guys’ or even IT Professionals really don’t have a good grasp on this topic. Simply ask someone to define root-hints and it will clearly demonstrate the knowledge of a technician.

The biggest reason it is overlooked is that it simply works — until it doesn’t. But beyond that, the question exists — can it work better?

This article is about public DNS name resolution — that is, for things outside of your local environment. We’ll save local domain resolution for another day — such as your Active Directory domain name resolution.

So let’s take a quick look at when you type a website name into a browser — perhaps the easiest example of this. What actually happens? Your local computer uses the following method to resolve names, going down the list until it finds a match. At each step its looking for a hit, which is typically a caches result.

  1. Your local computer first checks a local file called the hosts file to see if there is a static IP configured.
  2. Then it checks it’s local DNS cache — so it doesn’t constantly have to ask another source.
  3. It then uses the DNS name configured for your network interface. Which could be your DNS server for your local network (AD server), or perhaps just your home wireless router… (In some very rare cases it is skipping this and using your ISP’s DNS server.) But sticking with the local DNS server it will also check it’s cache first before going out to its upstream server, which is likely your ISP’s DNS server.
  4. Your local ISP is also checking its cache which if that fails, it will likely either source another upstream server, or hopefully, it will use root-hints.
    1. Root hints are the sort of master directory of authoritative servers, which will tell your server who to ask for authoritative information for the TLD, such as .com or .net.
    2. Once it gets the root zone, then it will query those servers to see specifically which DNS servers are authoritative for the next level such as microsoft.com
    3.  Then it will query that server for the actual DNS hostname, such as http://www.microsoft.com

As you can see once you hit step 4, you’re involving talking to a lot more servers, at a distance and latency for each step — which is why we have DNS caching. Each hop along this line introduces latency… Now there is a lot of things which can be said here. But I want to talk about a few things:

  1. Cache is essential for timely name resolution, however, this comes at a cost of stale records. This is especially important for IT Professionals to know because there is inherent latency involved with any DNS change. While local network DNS changes can propagate quickly, especially for AD Integrated AD changes when you’re talking about the public internet, it can take 24-72 hours for a simple hostname change to propagate because each cache location is going to hold on to that data for a certain length of time, often stated as TTL or Time-To-Live.
  2. Public DNS Servers have extremely diverse quality… from the amount of data in their cache to response time. DNS service is really a required afterthought for most internet service providers. As long as it works, they don’t care. As a result, response times can be significant if you need to query your ISP’s DNS information. Additionally, many of the times your ISP doesn’t use a geographically near DNS server so you might be having to traverse the internet to the other side of the continent to get your simple DNS response. Regional ISPs might not have a very good cache of DNS names causing them to reach into the Root Hints, which is time consuming, to build their cache.

There can be a huge performance improvement by migrating away from your ISP’s DNS servers. I have been experiementing with many different options over the decades.

  • Many years ago Verizon had some public DNS servers at 4.4.4.4 that was extremely popular, fast and reliable. However, they became flooded with a bunch of IT professionals directing their networks to 4.4.4.4 which impacted performance, so they closed it to just Verizon customers. It was such an easy IP address number to remember it was often used over ISP DNS servers just because it was easy to remember.
  • In 2009 Google released their set of public DNS servers at 8.8.8.8 and 8.8.4.4 which quickly became a popular replacement for the Verizon servers. As of this writing they’re still publically available.
  • Around the same time, I became introduced to OpenDNS which was recently acquired by Cisco for being awesome at DNS Resolution. Beyond just being a very fast, reliable, responsive DNS server, they also provided very basic DNS filtering. This helped IT professionals by keeping the really, really bad stuff from properly resolving. It also provides options for DNS based content filtering as well, which permitted businesses to get basic content filtering for objectionable content for low cost.
  • Starting in 2018, another company which are experts at DNS resolution, CloudFlare entered the public DNS space with their DNS servers at 1.1.1.1 and 1.0.0.1. They are ANYCAST addresses and you’ll automatically be routed to the geographically closes DNS servers to you. Benchmark testings show that the 1.1.1.1 servers are significantly faster than anything else within North America. Not only for caches records but also for non-caches results.

Today when choosing a public DNS server for my clients, it comes down to either CloudFlare or OpenDNS. In environments where we have no other source of content filtering, then I prefer to use OpenDNS but if the client has some form of content filtering on their firewall then the answer is the CloudFlare 1.1.1.1 network.

One important thing to note is that after ClouldFlare started using the 1.1.1.1 address, it exposed that some hardware vendors were improperly using 1.1.1.1 as a local address, against RFC standard. So in some isolated cases 1.1.1.1 doesn’t work for some clients — but this is because the systems they’re using are actually violating the RFC standards. So this isn’t CloudFlare’s causing but rather vendors disregarding RFC standards when they built their systems to use this unregistered space for their own purposes.

As far as how I personally use this as an individual, at home we use OpenDNS with content filtering to keep a bunch of bad stuff off of our home network, it even helps by filtering ‘objectionable ads’ from popping up often.

On my mobile devices, I have a VPN Tunnel which I use on any network which will let me use a VPN, like at Starbucks, etc., and you can find more about this config at this Roadwarrior VPN Configuration article. But sometimes I cannot connect to the VPN due to firewall filtering, such as at Holiday Markets or at my kids school guest network, so in those cases, I use the 1.1.1.1 DNS Profile for my iPhone.

One other closing issue — there have been various ISPs in the past which force all DNS resolution through there servers. In fact, there is one which on each subsequent request for a record, it will artificially increase the TTL number on each request. Basically trying to get your system to cache the results. In this case, your pretty stuck if you run into this but I would suggest you complaining to your sales rep for that ISP. Also you can look into using the DNS over TLS or DNS over HTTPS but as of right now Windows doesn’t natively support it without third party software, some very modern routers might support it, and I know that the DD-WRT aftermarket wireless firmware supports it. So you might have a bit more work to do to get it working.

 

Some mail server networking best practices

I was reminded this week about the importance of some good best practices when handling the networking portion of a mail server. While a server or exchange administrator will do a great job handling all of the best practices of configuring the software itself, it is not uncommon for the networking portion to be overlooked. Here is a summary of a couple of networking or firewall related best practices…

  • Your Mail Server should be NAT’ed to an IP address different than your general internet traffic. This ensures that malicious activity taking place on your general internet traffic, or an infected pc, or even a guest system does not impact your ability to send email. If I guest laptop on your wireless network has a virus and is sending out spam, it might result in your IP address being blacklisted, and it will cascade onto your mail server. With a public IP address dedicated to your mail server, you can be assured that if you’re blacklisted, it is because of traffic through your mail server, and not from another source.
  • Block outbound port 25 from everything except your mail server. In general, the only device that should be sending mail outside of your network is your mail server, and if another device needs to send email, such as your MFP or other device, it should relay off your mail server, and not send out directly.
  • If you are using some form of hosted inbound spam or mail filtering, such as MXLogic or Reflexion, you should source IP filter your inbound port 25 traffic, or better yet, consider using an alternate port. If you don’t lock this down, it permits people to bypass your hosted mail hosting, and directly send spam to your mail server.
  • Ensure that your firewall has application aware protection in place for SMTP traffic, however if you have an older Cisco PIX firewall and an Exchange mail server, consider turning FIXUP off for SMTP since there is a long history of documented problems.
  • Be on the lookout for a mail administrator who assigns a public IP address on their mail server directly, thereby bypassing the firewall or other edge protection. If they really want to dual home the mail server, have them place it on a DMZ instead.

Enjoy

 

Microsoft Server 2008 SP-2 Enterprise DCPromo

3d human with big negative symbolYesterday I experienced an interesting problem when attempting to run DCPROMO on a new Server 2008 Enterprise SP-2 to promote a server to become a domain controller in a Server 2000/2003 environment. Every time I ran DCPROMO on the 2008 box, it kept errorring out stating that I first needed to run ADPREP. However, I had already run it on the 2003 AD Server:

To install a domain controller into this Active Directory forest, you must first perpare the forest using “adprep/forestprep”. The Adprep utility is available on the Windows Server 2008 installation media in the Windows\sources\adprep folder

I’ve upgraded many domains from 2000 and 2003 to a 2008 domain, and don’t recall running into this problem before.

As a toubleshooting steps:

  • I knew that you must upgrade all Server 2000 domain controllers to at least SP-2 or apply a specific hotfix. A quick double-check of our 2000 box showed that we were at SP-4 and tha patch was unneeded.
  • I also decided to verify the forst and domain functional levels, which were also set to 2000 native.
  • Since we were still failing, a quick knowledgebase check did not reveal anything, and this new 2008 server was going to be replacing our 2000 server, I decided to simply remove any problem with the 2000 box from the equation. I double checked that it was not holding any FSMO roles, or any other AD integrated services which existed only on that box (DNS, DHCP, IAS, CA, etc)
  • After demoting the 2000 server, I also upgraded the forset and domain functional level to 2003 native, but this also did not resolve the problem.
  • I began to run a series of DSUtil commands to check the DNS and overall domain and everything cameback successfull… except when I ran the utility on the 2008 server. But since the utlity came back fine on the 2003 box, I assumed there must be something wrong onthe 2008 box itself.
  • I double checked that all patches were applied to the 2003 and 2008 boxes
  • I then researched the issue more widely on the internet via Google. A couple of things came up which were misses, but probable causes for other networks, so I’ll list them here:
    • In multi-domain forests, be sure to prep both the forest and domain controllers
    • Make sure you run adprep on the box which contains your Schema Master FSMO
    • Make sure you have proper DNS connectivity both ways on current and additional domain controller (add static entries for forward lookups as needed)
    • Ensure DNS is Active Directory aware (yes, you can install in non-aware environments but have to manually create the DNS entries, which can cause problems with an automated DC promo).
    • Make sure you disable third party firewalls

The last entry caught my eye and while we were not running any firewalls or anti-virus on the server yet, in 2008 SP-2 after installing the server the next automatic step was to enable the Windows Firewall. How you would assume that DCPromo would know about and could create the proper holes in the firewall to permit DCPromo to work, but apparently it does not. At least not in SP-2. So disable Windows Firewall while performing the DCPromo and it completes without problem. Then reable as you see fit. I don’t recall this problem or a need to do this in pre-SP-2 2008 server DCPromo’s, nor is it listed under any Microsoft documentation for performing a DCPromo, so it sounds like another excellent undocumented feature.

Enjoy.

Powered by WordPress.com.

Up ↑