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.
Let's start with the DNS resolvers (the DNS name servers the router itself uses when it needs to change a name into an IP address or vice versa):
- You can configure the DNS resolvers with the ip name-server global configuration command or the domain name-server configuration command within the ip dns view default.
- Both lists are merged and combined with the IP addresses acquired from the DHCP reply messages to get the final list of the DNS resolvers. You can inspect the final list with the show ip dns view default command.
- The DNS name servers from the DHCP replies never appear in the router configuration.
- If the same IP address is specified with the ip name-server and domain name-server command, only the global (ip name-server) command will appear in the router configuration.
The rules for DNS forwarders (the DNS servers the router uses to answer incoming DNS queries) are a bit different:
- The DNS view the current DNS query should use is determined based on view-list assigned to incoming interface (with the ip dns view-group interface configuration command) or the global view-list (specified with the ip dns server view-group global configuration command).
- The incoming query is (sequentially) sent to the IP addresses configured as dns forwarders in the selected view. No other DNS servers are used.
- If the selected view has no dns forwarders, but contains domain name-servers, they are used as forwarders.
- If the selected view has no dns forwarders or domain name-servers, the query is forwarded as IP broadcast ... unless the selected view is the default view, in which case the first DNS server computed according to the the previous bullet list is used (only one DNS server is used in this case, even if you have configured multiple DNS servers with the ip name-server configuration command).