Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The story of a little DNS easter egg

blog.cloudflare.com

Post reply on HN
Print view View original

21–25 of 25 posts

Re: The story of a little DNS easter egg

#21

Post by colmmacc »

makomk wrote: post #8
kevinbowman wrote: post #7

I imagine the switch over to TCP is more because the response is likely to be larger than a UDP packet (which IIRC is why DNS-over-TCP exists) (looks to be the case [1]), as opposed to stopping an amplified reflection attack, but it's a nice side effect. [1] http://serverfault.com/questions/404840/when-do-dns-queries-...

Nope. Normal DNS behaviour is to send the first few records over UDP and set the response truncated flag, which would still allow amplified reflection. They're intentionally sending no records at all in order to protect against this.

Some name servers include partial rrsets in truncated responses, some decide it's best to omit the entire rrset, some decide it's best to omit that entire section. All of those behaviors are valid (RFC2181 section 9 is about as detailed as it gets). I think there's enough variety that really there's no "normal" for this.

Re: The story of a little DNS easter egg

#22

Post by i31415 »

thaumaturgy wrote: post #13
jackalope wrote: post #10

One of the reasons they originally chose PowerDNS was that "it seamlessly allowed us to add new records without rebooting." Can someone explain? What DNS server requires a reboot (or even restart) instead of a simple reload?

(I also chose PowerDNS years ago.) I'm not sure about "rebooting" -- if this was just a language error -- but PowerDNS can run with a MySQL or Postgres backend with instant updates to records. i.e., no reload or other configuration re-read required. With DB replication up and running, you can get a fairly robust domain name server pool going without the usual headaches associated with copying updates to multiple serv…

CF engineer here. The main pain point of pdns and CloudFlare was all the additional logic needed to support CloudFlare's cdn product. For example, for a given record, should this resolve to the origin server's IP or CloudFlare's edge node? In the case of an edge node, what particular set of CloudFlare's IPs should be returned. These are both user settable options, and need to be propagated to all dns servers in real time. Supporting this meant supporting an increasingly hacked up fork of pdns, with logic scattered though the code base. Eventually it became less work to build rrdns as a clean platform.

In terms of dns updates, see the blog post http://blog.cloudflare.com/kyoto_tycoon_with_postgresql for details on how CF does it now.

Re: The story of a little DNS easter egg

#24

Post by gwu78 »

ck2 wrote: post #3

I'm curious if cloudflare will ever just sell its anycast dns as a service. Don't really need the other stuff but from what I can see their dns performance is on par with dnsmadeeasy/dyn/ultra

Wouldn't that obviate the need for third party CDN's?

Re: The story of a little DNS easter egg

#25

Post by anotherevan »

I remember listening to a podcast where Steve Gibson mentioned that he uses a DNS TXT record to publish the current version of SpinRite. That way the program just does a DNS look-up to see if there is a newer version available.

Thought that was a clever trick. Saves a centralised server getting hit all the time (although you then miss out of usage information I guess.)

Post reply on HN