Every network engineer should be familiar with the DNS basics – after all, all network failures are caused by DNS… unless it’s BGP.
The May 2022 ISP Column by Geoff Huston is an excellent place to brush up on your DNS basics and learn about new ideas, including a clever one to push DNS entries that will be needed in the future to a web client through a DNS-over-HTTPS session.
One of the publicly observable artifacts of the October 2021 Facebook outage was an intricate interaction between BGP routing and their DNS servers needed to support optimal anycast configuration. Not surprisingly, it was all networking engineers' fault according to some opinions1
There’s no need for anycast2/BGP advertisement for DNS servers. DNS is already highly available by design. Only network people never understand that, which leads to overengineering.
Anycast (advertising the same IP address from multiple servers/locations) has long been used to implement scale-out public DNS services (the whole root DNS system runs on massive anycast), but it’s not as common in enterprise networks.
Want to know even more? I covered numerous load balancing mechanisms including anycast in Data Centers Infrastructure for Networking Engineers webinar.
One of my readers sent me this question:
One thing that I notice is you mentioned moving the complexity to the upper layer. I was wondering why browsers don't support multiple IP addresses for a single site – when a browser receives more than one IP address in a DNS response, it could try to perform TCP SYN to the first address, and if it fails it will move to the other address. This way we don't need an anycast solution for DR site.
Another great blog post by Russ White: DNS is part of the TCP/IP stack, get used to it.
You might also want to tell application developers hard-coding IP addresses or anyone else believing in using /etc/hosts files instead of DNS that those things stopped being sexy around 1980.
If you’re a host running on an IPv6-only network, you might want to detect the IPv6 prefix used for NAT64 (for example, to transform IPv4 literals a clueless idiot embedded into a URL into IPv6 addresses).
DNS is a crucial component in modern scale-out application architectures, so when Alex Vayl and Kris Beevers from NSONE contacted me just as I was starting to work on my Active-Active Data Centers presentation, I was more than interested to hear what their solution can do.
It looks like the signed DNS root zone might finally get deployed on July 15th and Geoff Huston celebrates the fact with a lengthy article on DNSSEC. Just in case you’re not aware what DNSSEC is all about, he’s providing this nifty summary:
A succinct summary of the problem that DNSSEC is intended to address is that DNSSEC is intended to protect DNS clients from believing forged DNS data.
When I’ve stumbled across the headline Porn site feud spawns new DNS attack on NetworkWorld’s web site, the urge to read the article was simply irresistible. The article starts with the following paragraph (emphasis mine):
A scrap between two pornographic Web sites turned nasty when one figured out how to take down the other by exploiting a previously unknown quirk in the Internet's DNS.
The link in the paragraph points to another article documenting a completely different DNS attack. The next paragraph contradicts the first one (emphasis yet again mine):
The attack is known as DNS Amplification. It has been used sporadically since December, but it started getting talked about last month when ISPrime, a small New York ISP, started getting hit hard with what's known as a distributed denial of service (DDoS) attack.
Readers of my blog have probably noticed that I’m occasionally documenting the shortcomings of DNS and DHCP servers built into Cisco IOS (I will not even mention the HTTP server, this one gets constantly degraded). On the other hand, although you could centralize all these services, the centralization makes the branch offices completely dependent on the availability of WAN uplinks; without a working uplink, a branch office stops completely.
Working on an implementation of a split DNS design, I encountered an interesting bug in Cisco IOS: the ip dns view-group command works only on interfaces, but not on subinterfaces. As it’s a pure IP feature, there obviously no reason why it shouldn’t work on anything that has an IP address; obviously someone forgot to insert the correct entry in the parser tables.
Keep in mind: Use private IP addresses, AS numbers and domain names in all technical documentation you're producing (unless, of course, you're describing an actual network). If you're forced to use public addresses or AS numbers (for example, to illustrate how the neighbor remote-private-as command works), you should clearly state that they are imaginary.
You can safely use:
After I've fixed the default routing in my home office, I've stumbled across another problem: the two ISPs I'm using for my primary and backup link have DNS servers that reply solely to the DNS requests sent from their own IP address range:
When the traffic is switched from the primary to the backup ISP, I therefore also need to switch the DNS servers. Fortunately, this is quite easy to do on a router; you just need to configure ppp ipcp dns request on the dialer interface and the router starts asking for the DNS server address as part of the IPCP negotiation.