• Skip to primary navigation
  • Skip to main content
  • Skip to footer

Cisco Umbrella

Enterprise network security

  • Free Trial
  • Contact us
  • Blog
  • Login
    • Umbrella Login
    • Cloudlock Login
  • Products
    • Product
      • Cisco Umbrella Cloud Security Service
      • Cisco Umbrella Investigate
      • Product Packages
      • Support Packages
    • Functionality
      • DNS-Layer Security
      • Secure Web Gateway
      • Cloud Access Security Broker (CASB)
      • Interactive Intelligence
      • Cloud-Delivered Firewall
    •  
    • Webinar signup
  • Solutions
    • By Need
      • Protect Mobile Users
      • Fast Incident Response
      • Web Content Filtering
      • Shadow IT Discovery & App Blocking
      • Unified Threat Enforcement
      • Reduce Security Infections
      • Secure Direct Internet Access
      • Securing Remote and Roaming Users
    • By Network
      • Protect Guest Wi-Fi
      • SD-WAN Security
      • Off-Network Endpoint Security
    • By Industry
      • Higher Education Security
      • K-12 Schools Security
      • Healthcare, Retail and Hospitality Security
      • Enterprise Cloud Security
      • Small Business Cybersecurity
      • Our Customers
      • Customer Stories
    • Ransomware Defense for Dummies book
  • Why Us
    • Fast Reliable Cloud
      • Cloud Security Infrastructure
      • Cloud Network Status
      • Cloud Network Activity
      • Recursive DNS Services
      • Top Reasons to Trial
      • Getting Started
    • Unmatched Intelligence
      • Cyber Attack Prevention
      • Interactive Intelligence
    • Extensive Integrations
      • IT Security Integrations
      • Hardware Integrations
      • Meraki Integration
      • Cisco SD-WAN
    • Navigation-dropdown-promo-free-trial_102820
  • Resources
    • Content Library
      • Top Resources
      • Analyst Reports
      • Case Studies
      • Customer Videos
      • Datasheets
      • eBooks
      • Infographics
      • Solution Briefs
    • International Documents
      • Deutsch/German
      • Español/Spanish
      • Français/French
      • Italiano/Italian
      • 日本語/Japanese
    • Cisco Umbrella Blog
      • Latest Posts
      • Security Posts
      • Research Posts
      • Threats Posts
      • Product Posts
      • Spotlight
    • For Customers
      • Support
      • Customer Success Hub
      • Umbrella Deployment Hub
      • Customer Success Webinars
      • What’s New
      • Cisco Umbrella Studio
  • Trends & Threats
    • Market Trends
      • Rise of Remote Workers
      • Secure Internet Gateway (SIG)
      • Secure Access Service Edge (SASE)
    • Security Threats
      • Ransomware
      • Cryptomining Malware Protection
      • Cybersecurity Threat Landscape
    •  
    • 2020 Cybersecurity trends
  • Partners
    • Channel Partners
      • Partner Program
      • Become a Partner
    • Service Providers
      • Secure Connectivity
      • Managed Security for MSSPs
      • Managed IT for MSPs
    •  
    • Become a partner
  • Free Trial Signup
  • Umbrella Login
  • Cloudlock Login
  • Contact Us
Security

DNS redirection, Dual-stacked hosts, and Donut shops

By Lucas Siba
Posted on August 12, 2014
Updated on April 7, 2020

Share

Facebook0Tweet0LinkedIn0

TL;DR – Any recursive DNS resolver that responds to all requests, instead of returning NXDOMAIN, NODATA or SERVFAIL when an authoritative server gives these responses, is most likely going to cause issues for any dual-stacked host.

At OpenDNS we think a fast and reliable internet experience starts with a high-quality recursive DNS provider, so any time we find issues in common industry practices, we want everyone to know about it. In this post I’ll be showing a few issue that arise for dual-stacked hosts (meaning the host has both IPv4 and IPv6 addresses) when they’re using a DNS provider that redirects NXDOMAIN, NODATA and SERVFAIL responses. If you need a quick refresh on NXDOMAIN vs NODATA, see my previous post.

DNS redirection is the act of a recursive resolver intercepting NXDOMAIN, NODATA and SERVFAIL responses from an authoritative server and serving up an alternative IP address. This effectively tricks the requesting application into thinking there is an actual host at that name. This technique is commonly used by ISPs or DNS providers as a means of serving assisted search pages for mistyped domains, redirecting clients to advertising pages/resources, or for collecting statistics (see DNS Hijacking for more details). For the most part, on a typical IPv4 enabled host, DNS redirection isn’t a problem (although it may complicate some special DNS applications), but a real issue begins to arise when dual-stack (both IPv4 and IPv6 enabled) clients encounter DNS redirection.

I’ve previously written about how different operating systems resolve hostnames when they are dual-stacked here, so for now I’m only going to focus on OSX 10.9 (but know that this problem will affect most OSes). When you have a dual-stacked OSX host, and an application that is using the system resolving libraries (the system call getaddrinfo() specifically), OSX will send out both A (IPv4) and AAAA (IPv6) requests. Here’s an example of my dual-stacked host trying to lookup the local donut shop’s domain:

# tcpdump -n -s 1500 -i en0 udp port 53 & ./getaddrinfo www.timhortons.com
 10.10.10.165.63835 > 208.67.222.222: 18223+ A? www.timhortons.com.
 10.10.10.165.55987 > 208.67.222.222: 9571+ AAAA? www.timhortons.com.
 208.67.222.222 > 10.10.10.165.63835: 18223 1/0/0 A 206.152.12.196
 208.67.222.222 > 10.10.10.165.55987: 9571 0/1/0

From the tcpdump we can see that A and AAAA requests were sent out in parallel. Our A record request received “206.152.12.196” and our AAAA record request recieved a NODATA response. Now let’s imagine we were using a DNS provider that was doing DNS redirection. The AAAA NODATA response from our donut shop’s authoritative DNS server would have been redirected and we would have been served a valid IPv6 address (hopefully with some donut-related advertising). At this point both the A and AAAA records would be given to the calling application and it would be up the applications logic to choose which record to use (but the application has no way of knowing that the AAAA record has been falsified). This can (and will) lead to a very confusing browsing experience, the falsified record may take you to a webpage claiming the domain you’re looking for doesn’t exist!

“Can’t the DNS provider’s recursive resolver just look to see if both records types (the IPv4 and IPv6) are NXDOMAIN, NODATA or SERVFAIL before deciding to redirect an answer?”

At first glance it might look as though recursive DNS providers can work around this problem by checking both record types before responding, but another issues arises for DNS redirection when you include a search domain in your systems resolv.conf. Let’s assume for the purpose of this example you’ve added “dunkindonuts.com” and “opendns.com” to your list of DNS search domains so that you only have to type “system” when looking up “system.opendns.com” (knowing that there is no “system.dunkindonuts.com” host). Now let’s look at what the system’s resolving libraries will do:

# tcpdump -n -s 1500 -i en0 udp port 53 & ./getaddrinfo system
 10.10.10.165.50227 > 208.67.222.222.53: 5591+ A? system.dunkindonuts.com.
 208.67.222.222.53 > 10.10.10.165.50227: 5591 NXDomain 0/1/0
 10.10.10.165.54555 > 208.67.222.222.53: 48108+ A? system.opendns.com.
 208.67.222.222.53 > 10.10.10.165.54555: 48108 1/0/0 A 208.69.38.170

The system resolving libraries have done a lookup for “system.dunkindonuts.com”, waited for the responses (which was an NXDOMAIN), and then tried a lookup of “system.opendns.com”. The result is that we get the correct response for “system.opendns.com”. Now if this query had been done against a server which was doing DNS redirection our initial NXDOMAIN response (meaning there were neither IPv4 or IPv6 records) from the “system.dunkindonuts.com” query would have been redirected and replaced with a falsified record and the OS would have stopped trying to resolve the correct host.

“Doesn’t OpenDNS use DNS redirection to display ads? Isn’t that your entire business model?”

It is true that previously OpenDNS did use DNS redirection for the purpose of giving what we called “a guide page”, but we don’t do that anymore. OpenDNS has transitioned away from advertising-based revenue to focus on our world class enterprise security platform. You can read more about our transition away from ads in our CEO’s blog post “No more ads”.

So now that you know more about the pitfalls of DNS redirection, don’t put up with a recursive DNS server that redirects your traffic, especially not in the coming dual-stacked world.

Previous Post:

Previous Article

Next Post:

Next Article

Follow Us

  • Twitter
  • Facebook
  • LinkedIn
  • YouTube

Footer Sections

What we make

  • Cloud Security Service
  • DNS-Layer Network Security
  • Secure Web Gateway
  • Security Packages

Who we are

  • Cisco Umbrella Blog
  • Cloud Network Status
  • Cloud Network Activity
  • OpenDNS is now Cisco Umbrella

Learn more

  • Events
  • Careers
  • Support
  • Cisco Umbrella Live Demo
  • Contact Sales
Umbrella by Cisco
208.67.222.222+208.67.220.220
2620:119:35::35+2620:119:53::53
Sign up for a Free Trial
  • Cisco Online Privacy Statement
  • Terms of Service
  • Sitemap

© 2021 Cisco Umbrella