
DNS: The Good Parts - zrail
http://www.petekeen.net/dns-the-good-parts
======
citricsquid
> 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
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
Fixed! Not sure how I missed that, thanks! :-)

~~~
diminish
great idea :-) i m curious how many queries per day could the linode server
handle, even if they are non mission critical...

~~~
citricsquid
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
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-
paramete...](https://www.iana.org/assignments/dns-parameters/dns-
parameters.xhtml#dns-parameters-2)

~~~
colmmacc
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
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
Fixed both errors. Thanks guys!

~~~
axaxs
Sorry if I came off as condescending, it looked that way when I read it again.
The rfcs are 1034 and 35 and are very interesting reads. 5321 is good too. For
example, did you know that you don't need an mx record for email? If none is
present, it will default to the a record. DNSSEC is in 4034, among others.
Also, I think maybe more explanation about the main benefit of CNAMES, a
virtual host based setup where many domains point to the same IP.

~~~
zrail
No worries, you were right on the money. I've linked those RFCs as further
reading in the wrap-up section.

------
subsection1h

        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)

------
breck
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
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
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
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.

~~~
breck
Thanks for the comments. I actually have read a lot of the RFCs.

A Space DSL to replace all this stuff won't materialize out of thin air,
someone will have to take the time to think it through and iterate a couple
times. But I've been in the lucky position over the past while to see Space in
action, and at this point I'm pretty confident that it will disrupt many
areas, including DNS.

I haven't done a good job of making my case. Talk is cheap, more Space code is
coming.

But my point in general is that all of these formats can be described as
premature optimization. Or perhaps, no longer necessary optimization.

The example you provided clearly illustrates that. Dollar signs, at signs,
periods, parentheses and abbreviations galore. In my mind, the current state
of things is ugly code. I can make sense of that. But someone off the street
can't make sense of that. In my mind, that is a problem. That is a _huge_
problem. The common reaction is to "teach people DNS". I'm off the opinion,
"No, these formats suck! No need for all that complexity. The world has
changed. Let's start looking ahead."

To use a word mentioned earlier, I believe code should be trivial, as trivial
as reading a road sign. I believe the Internet is due for a big refactor. I
believe the unreadability of these formats is causing us a __ton __in lost
innovation. Why should only l33t hackers be able to understand the full stack?
There 's no reason in my estimation, other than that the stack is permeated by
ugly, unnecessary complexity. So many things people do nowadays over the
Internet are done on top of 10 levels of abstraction when they could be done
at 2 or 3.

I think there is a real opportunity here for someone to improve upon DNS.

~~~
vidarh
It isn't a problem that someone off the street can't make sense of that, since
it's a format that is an internal detail of a complicated tool. Someone off
the street isn't expected to understand that: There's a plethora of tools that
lets them enter stuff in other formats, and a plethora of web frontends.

What they _do_ need to understand, though, to do anything beyond the extremely
trivial, is the DNS data model, and the Bind style zone files reflects that
data model extremely directly, so almost whatever they end up with doing, they
will sooner or later come across something that may _remind them_ of the zone
files. And I get that is a lot of what causes people to be concerned about
Bind zone files.

As I pointed out, there are lots of DNS servers where you won't see a Bind
style zone file _ever_ , and you don't need to require configuration to be
done via a file at all. Djbdns is one of the former. ldapdns is one of the
latter - that exposes DNS entries pulled out of an LDAP server. But both will
be similar in structure because they map to the same data model.

The only thing you will achieve by devising a format like what you describe on
top of DNS is drive people crazy, because they now need to learn a format that
does not map easily directly to the DNS data model (if it does, it will appear
very similar to zone files and will be pointless).

I've written a DNS server, that was used for a registrar platform (I co-
founded the company that ran ".name"), and I didn't use zone files, but the
data was still mostly the same.

If you want to change that, beyond the extremely superficial (e.g. renaming
"MX" to "mailserver" or similar) that will only confuse people communicating
with those using the original names, you'd need to start lower:

With the DNS data model and wire format. Good luck with that - there are
trillions of dollars hinging on DNS working these days, and a _lot_ of design
decisions in DNS follows directly from real-life constraints that are not
going to change.

They are simple: The data must be small - if records are too large for a
single UDP datagram, it slows things down instantly. A DNS record consists of
a label, an address family (can usually be omitted, as almost everyone just
uses "IN"), a resource type (A,CNAME,MX etc. - you could rename those in your
format), a TTL (which can usually be left out to use the default), and a
resource type specific data field which is usually a string, label or IPv4 or
v6 address (obvious exceptions: MX, which includes the priorty, and SOA).

You could possibly drop the address family, but as I pointed out, "everyone"
just uses IN anyway, and most software will default to that if you leave it
out. You can rename the record types to something "friendly", but you don't
need to change internals of the software for that - just add a mapping to the
UI of various tools - these query types are mapping to byte values internally
in DNS servers anyway.

So what do you think you'd achieve? What can make DNS more understandable
without breaking functionality people depend on?

> To use a word mentioned earlier, I believe code should be trivial, as
> trivial as reading a road sign.

Not going to happen, because code implements real world requirements, and many
real world requirements are far more complicated than reading a road sign.

You can write a DNS server that is simple to understand for a programmer,
though - DNS is not all that complicated. But then you don't need to mess with
the DNS data model - it takes little effort to learn enough of it that zone
files is not the problem. It took me less than a week to write my first fully
functional DNS server without ever having looked at the RFC's before.

If you want to tackle unnecessary complexity, look somewhere else, like IMAP
(or get people to stop using SOAP...) - now there is ridiculous complexity for
no good reason (there are _reasons_ , they just aren't good)

> Why should only l33t hackers be able to understand the full stack?

Sometimes because it often takes a huge amount of basic knowledge about the
domain to even understand what people are talking about.

But you don't need that to understand DNS. Seriously.

Read RFC 1034 and 1035. Equip yourself with "tcpdump", "dig" and or
"nslookup". Write some DNS encoding and decoding routines based on the data in
RFC 1034. Run tcpdump and do capture some queries that you carry out via dig
or nslookup. Test your encoding and decoding routines to see that they match
based on the dig input/output and captured packets until you have them
working.

Then write a simple authoritative resolver based on the rules in the RFC's
(authoritative resolvers are simplest because you are only answering based on
"I know this, it's in my local data set", as opposed to recursive resolvers
that have to know when it is right to cache, when it is right to forward
requests, who it should allow recursion for, and [these days] how to avoid
being part of a DNS amplification attack unwittingly). That isn't much more
complex than: Wait for incoming query; parse query; extract name it is asking
for; if it is a name your server should serve, return the data you have for
that name, otherwise return an error (handling corner cases will make it a bit
more complex, such as handling fallback to TCP).

If you have _any_ prior network programming experience, this should be no more
than a week of coding if you keep things simple. If you're experienced, you
might even have something basic working (the "first 80%") within the day. At
least if you pick something higher level than C to write it in.

There are many areas to improve upon in DNS, but data model complexity is
pretty much bottom of the list. I'd have agreed with your second to last
paragraph if it was better targeted than against DNS.

------
js2
_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.

------
rspeer
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?

------
eikenberry
> 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
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.

------
zuselegacy
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
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.

------
general_failure
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
[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)

