Hello, and welcome to DNS

by pjf • 8 years ago

276 42 8 years ago

"When in doubt: authoritative servers 'host' DNS data, 'resolvers' look up things over at authoritative servers and clients run 'stub resolvers' to look things up over at resolvers."

What about programs run by clients that look things up over at authoritative servers? (Programs that do not look things up over at resolvers.)

"Zone files are one way of storing DNS data, but these are not integral to the operation of a nameserver. The zone file format is standardized, but it is highly non-trivial to parse.

...

Of specific note, many people have attempted to write a grammar (parser) for zonefiles and it is almost impossible."

I am guessing this statement is only referring to "BIND" zone file format.

I wonder how that could be a desirable or even acceptable state of affairs: having a "standardized" format that is "almost impossible" to parse.

The author suggests zone files are "not integral" to operation of a nameserver.

If zonefiles are optional does that also leave the programmer the option to use a zonefile format of their own choosing?

IME, parsing a tinydns zonefile is not difficult at all, because the author did not use the "standardized" BIND zonefile format.

yorwba• 8 years ago

I think the zonefile format is the one given in section 5 of https://tools.ietf.org/html/rfc1035

It seems to be a straightforward format for expressing tabular data using whitespace. I'm pretty sure that it was designed to be parsed using hand-written code iterating over an array of characters. Most formats that were defined by their implementation using a hand-written parser tend to be difficult to force into a grammar-based paradigm, because context-sensitivity is much easier to introduce when you write the parser yourself.

C is similarly difficult to parse with a grammar, since pointer declarations like char * ptr and multiplications like x * y are only distinguishable using context about the available types.

guessmyname2• 8 years ago

Of specific note, many people have attempted to write a grammar (parser) for zonefiles and it is almost impossible.

I had to build a DNS zone file parser +3 years ago for the web application firewall that I was building for my employer. I have to agree that I had a lot of problems implementing the different formats but ultimately — implementing the most common ones — succeeded. The project later became the CDN of one of the biggest hosting providers in the US, and as far as I know, there hasn't been any problems with the configuration files.

BIND zone files are (for the most part) very straightforward.

ahubert6• 8 years ago

By all means read up about $GENERATE for example, and multi-line statements etc, or all the fields you can omit or reorder. It is no fun.

inopinatus2• 8 years ago

What about programs run by clients that look things up over at authoritative servers?

Aside from the utilities like dig, I call those “resolvers” too. Doesn’t matter if they’re client-specific. The term still fits, it describes what the code is doing.

feelin_googley5• 8 years ago

Heres Wikipedia:

"Stub resolvers are "minimal DNS resolvers that use recursive query mode to offload most of the work of DNS resolution to a recursive name server."

A stub resolver will simply forward a request to a recursive name server..."

dig can send both recursive and non-recursive queries.

This appears to meet the definition of a "stub resolver" according the definition above.

However I am asking about programs that send only non-recursive queries and only send them to authoritative nameservers.

(FWIW I do not consider caches to be authoritative for any name.)

Is there a well-understood term to describe this type of program?

hliyan• 8 years ago

It's a rarity to see websites where form follows function these days: table of contents, heading, and content. This is what the web should be...

captn3m0• 8 years ago

Looking at the source, it feels like it should work without JS, but it doesn't (Firefox 60 beta, Linux)

Neither of elinks/lynx renders it correctly either.

feelin_googley5• 8 years ago

It does work without JS. For elinks, try pressing the backslash key.

Seirdy• 8 years ago

That's because it uses [markdeep](https://casual-effects.com/markdeep/), which lets you add a <script> and stylesheet tag to your markdown file to have any JS-enabled browser render it as HTML. If you backslash/view source, you can see the original markdown with the <script> and stylesheet tags.

Markdeep is the single best Markdown implementation I have ever used. The generated pages are beautiful and it supports a vast number of features. If I want to save a processed page as plain HTML, I just have to save the page's current state.

jlgaddis2• 8 years ago

Try viewing it with Safari on iPad.

ChrisSD2• 8 years ago

In order to squeeze as much information as possible into the 512 bytes...

I appreciate that this is a work in progress but this section is misleading. As all too briefly mentioned elsewhere on the page, EDNS allows extending this. In practice most of the resolvers I connect to do support EDNS and a buffer of 4096. So yes 512 may be needed as a fallback (depending on what you're doing) but you'll almost certainly have more room to breathe than that. IPv6 and DNSSEC practically make the extra space a necessity.

DNS names can (and often MUST) be compressed.

I don't think I've ever seen label compression in actual use? RFC 6891 (https://tools.ietf.org/html/rfc6891) seems to suggest they're obsolete.

That critique aside, it seems like this will become a good tutorial. And if you're looking for a reference I'd point to the IANA's page on DNS parameters (https://www.iana.org/assignments/dns-parameters/dns-paramete...) it lists and organises most of the relevant RFCs. RFC 6895 (https://tools.ietf.org/html/rfc6895) is a particularly useful resource for best practices.

colmmacc• 8 years ago

Label compression is pretty common, I think all of the big name server implementations do it by default. Amazon Route 53 definitely does it - I wrote the code! But my favorite thing about DNS label compression is probably this quote from DJB's code where he implemented it ...

https://github.com/abh/djbdns/blob/0715ca5de14ad5eae2c779c53...

ChrisSD2• 8 years ago

Thanks! I've only been hacking around with dns as an amateur so i appreciate the correction.

bluejekyll• 8 years ago

Yeah, label compression is very much in use. It is annoying though, it’s one of the slower pieces during serialization.

muks• 8 years ago

I appreciate that this is a work in progress but this section is misleading. As all too briefly mentioned elsewhere on the page, EDNS allows extending this. In practice most of the resolvers I connect to do support EDNS and a buffer of 4096. So yes 512 may be needed as a fallback (depending on what you're doing) but you'll almost certainly have more room to breathe than that. IPv6 and DNSSEC practically make the extra space a necessity.

EDNS is fundamental DNS knowledge that any DNS server implementer knows and Bert is one. He's talking about "when DNS was created" in that context, i.e., the current DNS's RFC 1034/1035 times.

ahubert6• 8 years ago

Hi Muks! The rest of the content is still appearing, but https://powerdns.org/hello-dns/optional.md.html now talks about EDNS.

jedisct1• 8 years ago

This needs an update, but here is a study I made a while back on EDNS support and payload sizes: http://msync.c9x.org/PubDNS/

Annatar4• 8 years ago

Ahhh, PowerDNS! At the time I determined that BIND was completely unscalable to perform configuration management on (no include directives in those days, circa 2007), I determined that I needed a DNS server which supported ordinary SQL and a relational database on the backend.

PowerDNS was the only DNS server at the time to use a relational database, and they supported several, including Oracle, which is what won me over. I embarked on an epic journey to make PowerDNS a first class citizen on Solaris 10. It took me five years, but boy did it pay off with massive dividends in stability and scalability!

PowerDNS isn't a perfect piece of software though: it has two major weaknesses, first that it is written in C++ as opposed to C and that made it a bitch to port to Solaris, and second that it depends on Boost, which is also a massive, bloated C++ monster which is a nightmare to get to build on any platform, let alone Solaris.

However, the software itself is a damn good DNS server, resistant to most attacks and constantly improving having had loving care from its user community, some which could be core PowerDNS developers in their own right. Finally it bears writing that the owners of PowerDNS are some of the kindest, sweetest guys one ever had the pleasure of working with, and they are open to considering suggestions and accepting contributions in patches and features. They were an absolute blast to work with over the years and could serve as poster children on how open source collaboration could work and make money off of at the same time.

ahubert6• 8 years ago

blush - the PowerDNS team :-)

Annatar4• 8 years ago

Fancy meeting you here, but I'm glad that I did! Didn't know you have a "HackerNews" account B.!

yipbub• 8 years ago

How did they make money?

ahubert6• 8 years ago

I did a talk on that at OHM2013 but sadly the recordings got lost. Will blog it up one day. You can be a "good" open source company and still make money! It does require a lot of planning though.

Annatar4• 8 years ago

They sell commercial support contracts, and because the software is so good, they have several very large customers, to write the least... PowerDNS powers a lot of top level domains by now.

dingaling• 8 years ago

I needed a DNS server which supported ordinary SQL and a relational database on the backend.

The one aspect that concerns me about that is the bootstrap step of resolving the database server name. How is that done? hosts file?

Annatar4• 8 years ago

Database name has nothing to do with normal host name resolution; they are two separate worlds. Oracle uses her own name resolution: "sqlnet.ora" is the equivalent of nsswitch.conf(4), and "tnsnames.ora" defines the TNS listener's service name(s), protocol, port, and connection type.

Database name, user and password are then configured in powerdns.conf(4). When linked with Oracle client libraries, pdns(1M) Oracle backend module makes the database connection over "OCI", the Oracle client interface.

Other database backends, like for example SQLite run on the same server so pdns(1M) "gsqlite" backend module opens the database file directly.

DanielDent• 8 years ago

It looks like RFC 7873 (May 2016) came up with a very different meaning for "DNS cookies" than I did in 2015.

It's an unfortunate naming collision.

My meaning: http://dnscookie.com/ RFC 7873 meaning: https://tools.ietf.org/html/rfc7873

DyslexicAtheist• 8 years ago

"The original RFCs remain the authoritative source of normative text, but this document tries to make this venerable protocol more accessible, while maintaining full alignment with all relevant and useful RFCs"

so if anyone has lost their mind looking for a complete list of DNS RFC's and their relationship / timeline, ... knock yourselves out: https://emaillab.jp/dns/dns-rfc/

ahubert6• 8 years ago

Another viewer is https://powerdns.org/dns-camel - where you can select obsoleted, informational, experimental, historic, and standards (track) RFCs. And drafts!

jlgaddis2• 8 years ago

FWIW, this is completely unusable on an iPad.

ahubert6• 8 years ago

Hi! Author of that page here. Let me know your thoughts, or express your feelings in a pull request! https://github.com/ahupowerdns/hello-dns/ - you might also appreciate the DNS RFC viewer on https://powerdns.org/dns-camel . Finally, this all started based on this IETF presentation: https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-ri...

bogomipz• 8 years ago

This is great! I look forward to reading more in this series. Cheers.

justaj• 8 years ago

Is there any particular reason why Javascript has to be enabled just to view this page? Or even have a minified JS file in the first place?

guessmyname2• 8 years ago

The author is using Markdeep [1] to render the plain text content of that page as HTML.

Disabling JavaScript will leave the entire page in plain text again, which should still work.

[1] http://casual-effects.com/markdeep/

arca_vorago• 8 years ago

I've implemented powerdns in prod a few times and really like it. There are some quirks but it has good documentation and a huge point for me is it is gpl (or gpl compat, I can't remember which)

koffiezet• 8 years ago

Same, I use it as the central authoritative DNS server for our internal domains, backed by a simple sqlite datbase which seems to be able to handle it without a single issue. Local Bind9 instances are configured on all our sites to ASFR all zones, and handle the client-facing traffic. All this is managed using Ansible, and works like a charm.

Hello, and welcome to DNS

Related Stories