
DNS: Basic Concepts (2013) - rhubarbcustard
https://www.petekeen.net/dns-the-good-parts
======
callmeed
If you want a startup/side-project idea, here it is. I can tell you from 10+
years in website hosting and maintenance that most laypeople, designers,
marketers, and even some technical people will _never_ understand DNS. (and
they shouldn't have to)

A small business wants a website at SquareSpace, cloudflare CDN, email at
Google Apps, landing pages on a subdomain with Unbounce, their blog on yet
another subdomain, and DKIM/SPF records for the email newsletter system.

Setting this up is not easy for most people. Most people aren't even sure
_where_ to do it–let alone _how_ to do it. (is your registrar handling your
DNS? sometimes ...)

If you had a 1 or 2-click tool that setup these for people, maybe wrapped it
around some domain search/affiliate tools, I think you could make some money.

My 2¢

~~~
brandon272
I agree that domain registrars should make it easier for people to simply
specify what services they are signed up for and provide the option of one-
click auto configuration/population of DNS records. Some registrars do this to
the extent that they will fill in Google's MX and other CNAME records if you
specify you are a Google apps user.

I disagree that _technical_ people should not have to understand DNS. DNS
isn't that complicated in most scenarios, and having a basic understanding of
it can help alleviate many of the headaches that are introduced when people
don't understand the relationship between the ownership of their domain, their
domain registrar and DNS records that point to various services, basic
concepts around TTLs and caching, etc.

~~~
developer2
>> I disagree that technical people should not have to understand DNS

I think that any _good_ technical developer/sysadmin has at some point set up
their own BIND server or similar, if only to play with it for a few hours
before uninstalling. This is something that is often missing from developers
who went through a CS program just to get a degree in an industry that pays
well, without really having an interest in the field.

Good developers/sysadmins, who actually have an interest in the work they do,
have an innate curiosity that leads them to try their hand at things like a
DNS server. For no reason other than to learn something new and understand a
topic they didn't knowing anything about before the experimentation.

Of course, you can learn about DNS without actually configuring a DNS server
from scratch - but the real "aha" moments come from working with the server
itself rather than only understanding the difference between A/CNAME/MX et al.
Learning about FQDN syntax, how DNS master syncs to slaves, SOA serial
numbers, etc. - so many interesting things to discover.

~~~
manyxcxi
Although I have repeatedly in my life set up and configured BIND servers, and
manage DNS zones monthly if not weekly, I disagree that a could developer
should have to know these things very well if at all.

As a developer you should know the basics of networking and the protocols you
will be using to communicate, as well as their drawbacks but DNS as far as a
developer is concerned, generally is a means to an end. They just need to know
where to send a message to. I feel like you could be a great developer and not
have a freaking clue how to configure a BIND server or manage a zone file-
they're fairly unrelated to creating, maintaining, or deploying code (unless
you're getting into containers and auto-provisioning).

~~~
daurnimator
> they're fairly unrelated to creating, maintaining, or deploying code

Actually it's _very_ useful to know and understand potential
misconfigurations.

e.g. if your 3rd party integration starts failing, it's useful to know the
signals that imply their sysadmin messed up a zone transfer.

This sort of 'hands-on' knowledge that you only really get from messing around
with the daemons yourself reduces downtime and emergency maintenance from
hours to minutes.

------
aljones
_" Email is so important to the functioning of the Internet that it gets its
own record type."_

Well that is one way of looking at it. Probably the appropriate way if you're
teaching, but if you want to be critical then it reeks of poor design for a
particular service to get special treatment by a fundamental part of the
internet. It isn't that MX records aren't needed. They just shouldn't only be
useful for email.

~~~
darkr
MX records were designed and implemented waay back when it was assumed that
every new service would implement it's own super-specific (and probably
binary) layer 4 protocol rather than just defaulting to JSON over HTTP(S). In
Internet time, SMTP is _ancient_.

~~~
walrus01
SMTP is ancient and we've been piling crap on top of it for 20 years to keep
it working (and all the OSI layer 5, 6 and 7 things that depend on mail
continuing to flow). SPF, DKIM, DMARC, IMAP daemons that present email over
TLS1.2, clamAV and realtime malware scanning/filtering, spamassassin, bayesian
filtering and analysis of mail body contents, email-to-SMS gateway, SMS-to-
email gateways, I could probably make this list 4x as long.

But it doesn't seem to be going away anytime soon.

~~~
emilburzo
I've added a new acronym to my personal mail servers over the weekend: SRS
(fixes SPF when doing basic forwarding to another email address, e.g.: to
gmail).

And now I'm not even sure that was a correct move, since Gmail explicitly
states[1] that you shouldn't change the envelope sender (which SRS does).

[1] -
[https://support.google.com/mail/answer/175365?hl=en](https://support.google.com/mail/answer/175365?hl=en)

~~~
walrus01
Anything that breaks DKIM so the signature coming from your SMTPd is no longer
valid, not matching the public key published in your DNS records, will make
your mail MUCH more likely to be flagged as spam.

~~~
emilburzo
SRS[1] doesn't break DKIM, because the sender rewrite happens on my server,
before DKIM.

That's the thing, in theory I went from:

    
    
      spf:  fail
      dkim: pass
    

for forwarded mails, before SRS, to:

    
    
      spf:  pass
      dkim: pass
    

so it should be better, right?

But as I said, they explicitly mention NOT changing the envelope sender (maybe
they have an exception for SRS cases, but it's not documented anywhere).

Oh yeah, and now I'm also responsible for any real spam forwarded to Gmail,
since the From is @mydomain.

[1] - [http://www.openspf.org/SRS](http://www.openspf.org/SRS)

------
axaxs
'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'

While in theory that's common, the primary reason is because of the SOA record
that must exist.

~~~
wink
Also, you can (sometimes/mostly) have a CNAME on a root domain and it even
works (sometimes/mostly)

~~~
devnull42
It goes against RFCs and you shouldn’t but non-compliant resolvers will do it.

rfc1034 is vague but rfc2181 clears it up.
[https://tools.ietf.org/html/rfc1034](https://tools.ietf.org/html/rfc1034)
[https://tools.ietf.org/html/rfc2181](https://tools.ietf.org/html/rfc2181)

------
nine_k
A very short, beginner-level intro to DNS.

~~~
xufi
yeah exactly what I need. I need a refresher on DNS.

------
dominotw
Learning networking/tcp/dns has been a pain for me for years. I can never wrap
my head around it properly despite many attempts.

I blame it on not having easy access to throwaway playgrounds.

I recently found this project [http://mininet.org/](http://mininet.org/) which
promises throwaway network playgrounds. Hopefully it will help me finally
learn networks for good.

~~~
NetStrikeForce
Although I appreciate that you're sharing something interesting, I can't
believe you when you say the problem to tinker with networking, TCP and DNS
was the lack of playgrounds.

Any home LAN is a playground. Internet is a playground. GNS3 for Cisco stuff.
Linux itself is a playground (I have been playing today with StrongSwan,
Quagga and SoftEther!). If you just want a network simulator, there's Packet
Tracer. Of course you could also just fire up tcpdump and/or Wireshark and
have a look. Many of the things I've mentioned are free :-)

~~~
mancerayder
Absolutely. Within that playground you can have a distributed wonderland,
running VirtualBox, KVM or XEN where you spin up Linux hosts rapidly. Now your
playground can start to imitate real life.

It sounds like the poster you're replying to need to solidify the
fundamentals, before the playground under his/her feet can be experienced.
TCP/IP Illustrated, one of many introductory guides to DNS, etc. can be read
through. TCP/IP Illustrated Vol 1 is great because of how simple it makes
networking feel, and it does so while showing you packet captures (another
skill to pick up).

Add to that GNS3, which I've seen people use to design and sketch out company
networks (just need a Cisco account to download the IOS images).

We could go on. The point is that your (free) playground is right under your
nose.

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

I prefer my domains to be naked (as opposed to www.), but I typically redirect
all www-traffic in my web server (NGINX). Is this the wrong approach?

~~~
snuxoll
I prefer naked domains, but the problem I always have is that you can only use
A records which makes using them with a bunch of things a pain in the butt. I
host my personal website as just a tumblr blog (yes, go ahead and laugh, but I
find it less of a chore to deal with than wordpress) so I need a CNAME to make
that work, so I just have a very basic redirect on the naked domain to my blog
subdomain.

~~~
bschwindHN
Cloudflare offers something called CNAME flattening which will let you define
a CNAME record for the naked domain.

[https://blog.cloudflare.com/introducing-cname-flattening-
rfc...](https://blog.cloudflare.com/introducing-cname-flattening-rfc-
compliant-cnames-at-a-domains-root/)

------
known
OpenNIC is a user controlled Network Information Center offering a democratic
and non-national alternative to the traditional Top-Level Domain registries.
[http://wiki.opennicproject.org/HomePage](http://wiki.opennicproject.org/HomePage)

~~~
tombrossman
I used OpenNIC for a while and it mostly worked. I started to notice some
problems resolving .today URLs and had to ask for help in their IRC, and the
response was not reassuring. At least one operator do not regularly update or
even monitor their servers - I saw down time lasting weeks for one server
(fortunately I had configured my router to use two and the second kept working
throughout). The .today TLD had existed for several years but had not been
added to the DNS servers I used. This isn't a complaint, just an observation
after a year of regular use.

I like the idea behind the project, but from personal experience I decided
that I had to switch to another provider that had more robust infrastructure
and regularly patched their machines. DNS is too critical and I felt the risk
of having my DNS requests hijacked by a compromised machine was too great.

 _(Also, who down-voted the parent comment? Bizarre, maybe that was
accidental?)_

------
jasonbenne
This is also a nice overview from the dnsimple guys:

[https://howdns.works/ep1/](https://howdns.works/ep1/)

------
wineisfine
Anyone tried the "new" namecheap custom dns settings? Like glueing
nameservers?

Its one of the poorest interfaces ever created in the history of mankind.

------
gist
Anyone old enough to remember movie.edu and the grasshopper O'Reilly 1st
Edition DNS&Bind book?

~~~
peatfreak
What a great book! I wish they'd publish a new edition (the latest was ten
years ago).

Has anything as good been released since? What is the current "standard
reference" on DNS and BIND?

~~~
gist
I haven't needed that type of reference since I read that in the mid 90's. And
now with simply doing a search don't really need to buy books at all.

------
_RPM
I thought they were going to get into the binary protocol.

~~~
zrail
The binary protocol is a good part? :)

~~~
cmhamill
I actually think the DNS binary protocol is a rather well-designed one, but
others might disagree.

~~~
X-Istence
DNS result "compression" is crap though...

------
riobard
So, which are the good parts?

~~~
dang
We replaced that with the phrase "basic concepts" from the intro, in the title
above.

~~~
zrail
Why? Nobody changed the title the first time this was on HN and subsequently
made it into Hacker Weekly.

[https://news.ycombinator.com/item?id=6075330](https://news.ycombinator.com/item?id=6075330)

~~~
dang
Because "the good parts" is (a little) misleading and baity, to judge by the
response it evoked in this thread. Please see
[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html).

You're never going to get perfect consistency of moderation here because it's
impossible for us to see every post, and also because we're human.

