8 ms·

DNS: The Good Parts

123 points by zrail 13y ago

citricsquid 13y ago
> Almost always you'll want to redirect a bare domain like iskettlemanstillopen.com to www.iskettlemanstillopen.com. Registrars like Namecheap and DNSimple call this a URL Redirect. In Namecheap you would set up a URL Redirect like this: Coincidentally yesterday I snapped and decided that no longer was I happy using a URL forwarding service that requires configuration or running a web server that redirects old domains, so I built http://cnamer.com/ http://cnamer.com/. subdomain.source.com. CNAME google.com.cnamer.com. That will redirect source.com to google.com. cnamer.samryan.co.uk. CNAME minotar.net-opts-query.true-querystring.avatar-querystring.citricsquid.cnamer.com. That redirects http://cnamer.samryan.co.uk http://cnamer.samryan.co.uk to minotar.net/avatar/citricsquid The code powering it sucks at the moment and I intend on adding the ability to use TXT records to set the redirect but it /works/ for now.
- agwa 13y ago
  That looks like an extremely useful service (good work!), but your examples (source.com.) don't work, since the zone apex can't be a CNAME (this is addressed in the article under "Why CNAME is Messed Up"). So this can be used with www.source.com. but not source.com.
  - citricsquid 13y ago
    Fixed! Not sure how I missed that, thanks! :-)
    - diminish 13y ago
      great idea :-) i m curious how many queries per day could the linode server handle, even if they are non mission critical...
      - citricsquid 13y ago
        The version live right now is just a proof of concept more than anything, once I've got a few hours spare (hopefully sometime this week) I'm going to rebuild it to operate in a sane manner and will benchmark the load it can support, the Linode itself shouldn't have problems supporting millions of requests a day, it'll be cnamer itself that causes a bottleneck if there is one. Worst case if it turns out there's too much usage for the Linode to support (unlikely...) I'll upgrade the server / move it elsewhere. I was hoping to rebuild + benchmark it before mentioning it anywhere but this blog post seem super relevant heh.
mcmatterson 13y ago
Minor error in this post: 'IN' doesn't refer to the answer's inclusion in the given DNS type -- it's a short form of Internet, and is meant to denote the address family being returned (the field is called 'CLASS' in DNS-speak). Other options include Hesiod and Chaos (as well as a number of reserved / private values) https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-2 https://www.iana.org/assignments/dns-parameters/dns-paramete...
- colmmacc 13y ago
  Another very forgivable error is a mis-understanding about how recursive queries work. The article says "dig randomly picked one of the root server responses, in this case f.root-servers.net., and asked it for the next part of the domain name in question, info. The info section of the hierarchy is run by a company that operates their own set of servers. dig asks one of these servers for the NS records for bugsplat.info and then finally asks one of those servers for the A record for empoknor.bugsplat.info.." but in actuality every server in the hierarchy is queried for the full name; "empoknor.bugsplat.info". Technically even the root servers may be authoritative for that name, there's no way to know in advance where the zone-cuts are.
  - axaxs 13y ago
    Correct, and very common misconception. While I applaud the author's attempts to simplify DNS, it's somewhat evident they've not looked at the very clearly written RFCs which cover both mistakes.
    - zrail 13y ago
      Thanks for the corrections! I'll fix the article when I get back to a computer.
    - zrail 13y ago
      Fixed both errors. Thanks guys!
      - 13y ago
breck 13y ago
The architecture of DNS is pretty solid, but the encodings are unnecessarily complex. That complexity has a huge, hidden opportunity cost. If anyone wants to help, I'm pretty confident a Space based encoding would greatly improve DNS: https://github.com/nudgepad/space/issues/54 https://github.com/nudgepad/space/issues/54
- duskwuff 13y ago
  I'm not sure you actually understand what's going on here. The zone file that you're looking at is only used internally by the DNS server - it is never sent across the wire, so the verbosity of the format is largely irrelevant.
  - breck 13y ago
    You're right, I don't have a complete working knowledge of DNS, BIND, Zone, et cetera. Hence, the details of my DSL are going to be off. But I'm very confident in my hypothesis that the status quo is unnecessarily complex, all encodings could be reduced to Space DSLs, and doing so would lead to drastic unforeseen benefits. All it takes is someone with knowledge of the details to implement it. I'd do it myself, but am currently doing the same in other domains (right now on HTML, HTTP, CSS).
    - vidarh 13y ago
      Zone files is a side show. Many other DNS servers use entirely different formats, including formats that are more space efficient than what you suggest on your Github page, and some of which are not serialized to text files at all (all data stored in databases). These formats are not standardized at all. Note that your Bind zone file example is also quite verbose compared to what it needs to be. E.g. here's a more compact version: $ORIGIN brekyunits.com. $TTL 3600 @ IN SOA NS53.DOMAINCONTROL.com. dns.jomax.net. (2013041502 28800 7200 604800 3600 ) @ A 107.21.225.189 @ MX 0 smtp.secureserver.net. @ MX 10 mailstore1.secureserver.net. @ NS NS53.DOMAINCONTROL.com. @ NS ns54.DOMAINCONTROL.com. In comparison to that, yours doesn't seem to provide any real benefits that I can see. When it comes to the over the wire format, the over the wire format is designed to be much more compact, because if the request and response fits in a single UDP datagram, the request will be handled much faster - if the reply is too long, then the server might have to tell the client to retry over TCP, for example, which means two wasted packets to establish that, then about half a dozen packets or more for the request/reply over TCP. Your format would not help there. If you want to improve DNS, read the RFC's first.
subsection1h 13y ago
Almost always you'll want to redirect a bare domain like iskettlemanstillopen.com to www.iskettlemanstillopen.com. Registrars like Namecheap and DNSimple call this a URL Redirect. I won't redirect a root domain using a URL redirect because DNSimple's URL redirects can't redirect over SSL.[1] I use an ALIAS record[2] to point the root domain to the subdomain and I use Rack Canonical Host[3] for redirects. [1] http://support.dnsimple.com/articles/url-redirect-ssl http://support.dnsimple.com/articles/url-redirect-ssl [2] http://support.dnsimple.com/articles/alias-record http://support.dnsimple.com/articles/alias-record [3] https://github.com/tylerhunt/rack-canonical-host https://github.com/tylerhunt/rack-canonical-host
eikenberry 13y ago
> Almost always you'll want to redirect a bare domain like iskettlemanstillopen.com to www.iskettlemanstillopen.com. I've always read the opposite. That using the www. subdomain was bad form. That it was an anachronism and meant people would need to remember extra chars that had nothing to do with your branding.
- zrail 13y ago
  It almost certainly doesn't matter for branding. Normal people look past the www because it's so common. Putting your site on a subdomain gives you the distinct advantage of being able to CNAME to whatever you want, since CNAMEs don't work well on a bare domain. Putting a redirect in place means that your branding and marketing can just have "example.com" and it'll just automatically work.
general_failure 13y ago
Can someone tell me who operates the root servers? Organizations? Companies? Governments? I was just thinking that aren't these prime targets for hackers? I mean if one root server is compromised, that would be a royal breach.
- zrail 13y ago
  http://www.root-servers.org http://www.root-servers.org The organizations across the top of that page run the root servers. As you can see on the map, there are quite a few physical servers for those 13 separate root domains, 359 to be exact. The root servers don't actually replicate amongst themselves and they don't actually hold all that much data. They all serve the same set of zones, all from one text file that is updated infrequently, specifically the DNS Root Zone file on this page: http://www.iana.org/about/popular-links http://www.iana.org/about/popular-links
deleted 13y ago
[deleted]
zuselegacy 13y ago
newbie question: I understand that by delegating dns resolution for domains (and subdomains) to their zones, dns scales well. However, isn't there a huge load on the global top level domains. I imagine most sites use .com and all dns requests for www.xxx.com , the queries for . and .com may be heavily cached, but if xxx isn't very popular , would that not put a huge number of requests against the .com nameservers to resolve to the xxx.com domain?If we had a huge number of low popularity xxx domains in the com domain, won't all dns queries have to hit the top level .com nameservers?
- zrail 13y ago
  Yes. There are currently 13 virtual nodes that handle .com and, just like for the root servers, each one of those virtual nodes is actually a group of machines all bound to the same IP address via Anycast. There are hundreds of physical machines spread around the world handling the TLDs. The NS records that these servers return are readily cached with long lifetimes, though, so if you use any relatively popular DNS server, either your ISPs or Google's public server, the resolution process will be really short even for uncommon names.
rspeer 13y ago
Does the "+trace" example work for other people? For me, after it lists the 13 root servers, it pauses for a while and says ";; connection timed out; no servers could be reached". So is someone between me and these servers blocking tracing, or is DNS more unpredictable and weird than the author claims, or both?
js2 13y ago
This is why you can't have a CNAME on a root domain like petekeen.net, because you generally have to have other records for that domain like MX. The issue isn't with an MX record which is optional, it's with the SOA record which is required. BIND also requires at least one NS record.

123 points by zrail 13y ago

> Almost always you'll want to redirect a bare domain like iskettlemanstillopen.com to www.iskettlemanstillopen.com. Registrars like Namecheap and DNSimple call this a URL Redirect. In Namecheap you would set up a URL Redirect like this: Coincidentally yesterday I snapped and decided that no longer was I happy using a URL forwarding service that requires configuration or running a web server that redirects old domains, so I built http://cnamer.com/ http://cnamer.com/. subdomain.source.com. CNAME google.com.cnamer.com. That will redirect source.com to google.com. cnamer.samryan.co.uk. CNAME minotar.net-opts-query.true-querystring.avatar-querystring.citricsquid.cnamer.com. That redirects http://cnamer.samryan.co.uk http://cnamer.samryan.co.uk to minotar.net/avatar/citricsquid The code powering it sucks at the moment and I intend on adding the ability to use TXT records to set the redirect but it /works/ for now.

agwa 13y ago
That looks like an extremely useful service (good work!), but your examples (source.com.) don't work, since the zone apex can't be a CNAME (this is addressed in the article under "Why CNAME is Messed Up"). So this can be used with www.source.com. but not source.com.
- citricsquid 13y ago
  Fixed! Not sure how I missed that, thanks! :-)
  - diminish 13y ago
    great idea :-) i m curious how many queries per day could the linode server handle, even if they are non mission critical...
    - citricsquid 13y ago
      The version live right now is just a proof of concept more than anything, once I've got a few hours spare (hopefully sometime this week) I'm going to rebuild it to operate in a sane manner and will benchmark the load it can support, the Linode itself shouldn't have problems supporting millions of requests a day, it'll be cnamer itself that causes a bottleneck if there is one. Worst case if it turns out there's too much usage for the Linode to support (unlikely...) I'll upgrade the server / move it elsewhere. I was hoping to rebuild + benchmark it before mentioning it anywhere but this blog post seem super relevant heh.

mcmatterson 13y ago

Minor error in this post: 'IN' doesn't refer to the answer's inclusion in the given DNS type -- it's a short form of Internet, and is meant to denote the address family being returned (the field is called 'CLASS' in DNS-speak). Other options include Hesiod and Chaos (as well as a number of reserved / private values) https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-2 https://www.iana.org/assignments/dns-parameters/dns-paramete...

colmmacc 13y ago
Another very forgivable error is a mis-understanding about how recursive queries work. The article says "dig randomly picked one of the root server responses, in this case f.root-servers.net., and asked it for the next part of the domain name in question, info. The info section of the hierarchy is run by a company that operates their own set of servers. dig asks one of these servers for the NS records for bugsplat.info and then finally asks one of those servers for the A record for empoknor.bugsplat.info.." but in actuality every server in the hierarchy is queried for the full name; "empoknor.bugsplat.info". Technically even the root servers may be authoritative for that name, there's no way to know in advance where the zone-cuts are.
- axaxs 13y ago
  Correct, and very common misconception. While I applaud the author's attempts to simplify DNS, it's somewhat evident they've not looked at the very clearly written RFCs which cover both mistakes.
  - zrail 13y ago
    Thanks for the corrections! I'll fix the article when I get back to a computer.
  - zrail 13y ago
    Fixed both errors. Thanks guys!
    - 13y ago

breck 13y ago

The architecture of DNS is pretty solid, but the encodings are unnecessarily complex. That complexity has a huge, hidden opportunity cost. If anyone wants to help, I'm pretty confident a Space based encoding would greatly improve DNS: https://github.com/nudgepad/space/issues/54 https://github.com/nudgepad/space/issues/54

duskwuff 13y ago
I'm not sure you actually understand what's going on here. The zone file that you're looking at is only used internally by the DNS server - it is never sent across the wire, so the verbosity of the format is largely irrelevant.
- breck 13y ago
  You're right, I don't have a complete working knowledge of DNS, BIND, Zone, et cetera. Hence, the details of my DSL are going to be off. But I'm very confident in my hypothesis that the status quo is unnecessarily complex, all encodings could be reduced to Space DSLs, and doing so would lead to drastic unforeseen benefits. All it takes is someone with knowledge of the details to implement it. I'd do it myself, but am currently doing the same in other domains (right now on HTML, HTTP, CSS).
  - vidarh 13y ago
    Zone files is a side show. Many other DNS servers use entirely different formats, including formats that are more space efficient than what you suggest on your Github page, and some of which are not serialized to text files at all (all data stored in databases). These formats are not standardized at all. Note that your Bind zone file example is also quite verbose compared to what it needs to be. E.g. here's a more compact version: $ORIGIN brekyunits.com. $TTL 3600 @ IN SOA NS53.DOMAINCONTROL.com. dns.jomax.net. (2013041502 28800 7200 604800 3600 ) @ A 107.21.225.189 @ MX 0 smtp.secureserver.net. @ MX 10 mailstore1.secureserver.net. @ NS NS53.DOMAINCONTROL.com. @ NS ns54.DOMAINCONTROL.com. In comparison to that, yours doesn't seem to provide any real benefits that I can see. When it comes to the over the wire format, the over the wire format is designed to be much more compact, because if the request and response fits in a single UDP datagram, the request will be handled much faster - if the reply is too long, then the server might have to tell the client to retry over TCP, for example, which means two wasted packets to establish that, then about half a dozen packets or more for the request/reply over TCP. Your format would not help there. If you want to improve DNS, read the RFC's first.

subsection1h 13y ago

Almost always you'll want to redirect a bare domain like iskettlemanstillopen.com to www.iskettlemanstillopen.com. Registrars like Namecheap and DNSimple call this a URL Redirect. I won't redirect a root domain using a URL redirect because DNSimple's URL redirects can't redirect over SSL.[1] I use an ALIAS record[2] to point the root domain to the subdomain and I use Rack Canonical Host[3] for redirects. [1] http://support.dnsimple.com/articles/url-redirect-ssl http://support.dnsimple.com/articles/url-redirect-ssl [2] http://support.dnsimple.com/articles/alias-record http://support.dnsimple.com/articles/alias-record [3] https://github.com/tylerhunt/rack-canonical-host https://github.com/tylerhunt/rack-canonical-host

eikenberry 13y ago

> Almost always you'll want to redirect a bare domain like iskettlemanstillopen.com to www.iskettlemanstillopen.com. I've always read the opposite. That using the www. subdomain was bad form. That it was an anachronism and meant people would need to remember extra chars that had nothing to do with your branding.

zrail 13y ago
It almost certainly doesn't matter for branding. Normal people look past the www because it's so common. Putting your site on a subdomain gives you the distinct advantage of being able to CNAME to whatever you want, since CNAMEs don't work well on a bare domain. Putting a redirect in place means that your branding and marketing can just have "example.com" and it'll just automatically work.

general_failure 13y ago

Can someone tell me who operates the root servers? Organizations? Companies? Governments? I was just thinking that aren't these prime targets for hackers? I mean if one root server is compromised, that would be a royal breach.

zrail 13y ago
http://www.root-servers.org http://www.root-servers.org The organizations across the top of that page run the root servers. As you can see on the map, there are quite a few physical servers for those 13 separate root domains, 359 to be exact. The root servers don't actually replicate amongst themselves and they don't actually hold all that much data. They all serve the same set of zones, all from one text file that is updated infrequently, specifically the DNS Root Zone file on this page: http://www.iana.org/about/popular-links http://www.iana.org/about/popular-links

deleted 13y ago

[deleted]

zuselegacy 13y ago

newbie question: I understand that by delegating dns resolution for domains (and subdomains) to their zones, dns scales well. However, isn't there a huge load on the global top level domains. I imagine most sites use .com and all dns requests for www.xxx.com , the queries for . and .com may be heavily cached, but if xxx isn't very popular , would that not put a huge number of requests against the .com nameservers to resolve to the xxx.com domain?If we had a huge number of low popularity xxx domains in the com domain, won't all dns queries have to hit the top level .com nameservers?

zrail 13y ago
Yes. There are currently 13 virtual nodes that handle .com and, just like for the root servers, each one of those virtual nodes is actually a group of machines all bound to the same IP address via Anycast. There are hundreds of physical machines spread around the world handling the TLDs. The NS records that these servers return are readily cached with long lifetimes, though, so if you use any relatively popular DNS server, either your ISPs or Google's public server, the resolution process will be really short even for uncommon names.

rspeer 13y ago

Does the "+trace" example work for other people? For me, after it lists the 13 root servers, it pauses for a while and says ";; connection timed out; no servers could be reached". So is someone between me and these servers blocking tracing, or is DNS more unpredictable and weird than the author claims, or both?

js2 13y ago

This is why you can't have a CNAME on a root domain like petekeen.net, because you generally have to have other records for that domain like MX. The issue isn't with an MX record which is optional, it's with the SOA record which is required. BIND also requires at least one NS record.