Building network automation solutions

9 module online course

Start now!

Category: DNS

Worth Reading: Anycast DNS in Enterprise Networks

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.

The blog posts written by Tom Bowles should get you there. He started with the idea and described his implementation using Infoblox DNS.

Want to know even more? I covered numerous load balancing mechanisms including anycast in Data Centers Infrastructure for Networking Engineers webinar.

add comment

Moving Complexity to Application Layer?

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.

Of course I pointed out an old blog post ;), and we all know that Happy Eyeballs work this way.

read more see 2 comments

NSONE – Data-Driven DNS on Software Gone Wild

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.

The result: Episode 29 of Software Gone Wild in which we discussed a number of topics including:

read more see 1 comments

Custom-written DNS servers: Learn to love them

A cryptic e-mail message from one of my readers telling me that blog.ioshints.info does not resolve into an IP address (yet again, thank you Igor!) set just the right mood for my Monday morning. As I had about 30 minutes before rushing off to a day-long countryside family event, all I could do was run a few quick tests (of course it worked for me) and take my iPad with me (luckily, it’s a 3G model and the coverage in Slovenia is decent).

During the day, Igor was able to supply more details: the DNS hosting company I was using suddenly decided to return NXDOMAIN error code on every CNAME record unless the query type was CNAME, while providing the results in the response at the same time. Here’s a sample of their bizarre reasoning:

$ dig @ns1.domaindiscover.com xml.ioshints.info
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 14206
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;xml.ioshints.info. IN A

;; ANSWER SECTION:
xml.ioshints.info. 0 IN CNAME ghs.google.com.
read more see 1 comments

DNSSEC ... finally!

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.

Read the rest of the article on his blog.

DNSSEC deployment could cause some firewalls to hiccup. You might have to change your ASA configuration; zone-based firewall on IOS supposedly works just fine.

see 2 comments

Yellow journalism at work: Previously Unknown DNS Attacks

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.
read more see 4 comments

Decent DNS, DHCP and HTTP server on an ISR router

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.

read more see 8 comments

Correction: NAT-translated DNS responses are not cacheable

It looks like the wording in the “NAT-translated DNS responses are not cacheable” post was a bit too vague, as some readers understood the router would mess the TTL field in the DNS response payload when changing the IP addresses in the IP header of the response packet.

That's not the case; the TTL field in the DNS response payload is touched only if the router performs application-layer translation of the DNS response (for example, changing the A record in the DNS response). I've reworded the original post; I can only hope I've made it unambiguous (after all, English is not my native language).
add comment

NAT-translated DNS responses are not cacheable

Slightly reworded on 2008-12-18. Not only is NAT (as implemented in Cisco IOS) very picky about the translation of IP addresses in the payload of DNS responses (it translates only addresses defined in IP-level NAT translations with no additional route-map filters), it also sets the TTL field in the DNS response to zero when translating an IP address in the DNS response payload based on an existing L3 NAT entry making the DNS response completely uncacheable.

The behavior makes some sense, as the L3 NAT entry might change before the DNS response expires, but the implementation is definitely overly aggressive. In my opinion, IOS should use some sensible (configurable?) value for static NAT translations and times comparable to NAT timeouts for dynamic NAT translations. What do you think?

see 4 comments

Network Address Translation of DNS responses

I “always knew” that Cisco IOS supports NAT translations between local and global addresses in DNS replies … until I wanted to use this functionality in one of my sample configurations and discovered it doesn’t work as expected.

A few tests later, I discovered the true story: DNS requests and responses are translated if and only if you define IP-level NAT translations using either the ip nat inside source static or the ip nat inside source list pool configuration command. The translations should not use any additional filters (do not use the route-map keyword) and cannot result in PAT translations (do not use the overload keyword).

You can find more details in the “Network address translation of DNS responses” article in the CT3 wiki.

see 4 comments

Private domain names

I'm positive the IP prefixes reserved for private use by RFC 1918 are well-known to anyone building private IP networks. Likewise, you should be familiar with reserved AS numbers documented in RFC 1930 if you're building private networks running BGP. But if you know there are reserved DNS domains that can be used to write sample configurations and test code, you're smarter than I was a few weeks ago.

I was writing the June IP Corner article and needed to set up DNS servers within the lab. I used example.com as the domain name and decided to check what would happen if you'd visit the actual www.example.com web site (try it out). It politely referenced me to RFC 2606, which documents the reserved domain names you can use.

As a rule, you should 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 the AS numbers are imaginary.

see 3 comments
Sidebar