Comment by feelin_googley | Hacker News Reader

Comment by feelin_googley | Hacker News Reader

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

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

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.

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.

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

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?

I think you are asking too much out of this classification. The classification is useful to look at DNS from a "user" perspective, not from a "dns troubleshooter" perspective.

Tools like dig, zonemaster [1], etc. are out of the classification's scope. Oftentimes they can do everything DNS and hence fit none and all of the categories. I would call those "DNS powertools" or something like that.

You seem to be trying to classify DNS clients by what they do mechanically. But that isn't the case. DNS software is classified according to its role and expected capabilities. There's a relationship between role and action, but it's the former that matters much more when it comes to naming of parts.

Rather than looking at Wikipedia I suggest consulting RFC 7719 "DNS Terminology", https://tools.ietf.org/html/rfc7719 where you will find that your program is simply called a "resolver": "A program that extract[s] information from name servers in response to client requests."

That RFC further describes some specific classes of resolver, but dig is most definitely not a "stub resolver" because these are characterised by what they cannot do, whilst dig is a swiss-army knife utility that can do a great deal - which merely happens to include, amongst other things, sending the same queries that a stub resolver might send.

In terms of implementation details, your specific description: "programs that send only non-recursive queries and only send them to authoritative nameservers" describes the principal activity of the resolver side of most implementations of a full-service resolver. However if you read that RFC you'll see that it equivocates about the implementation details of full-service resolvers in general, because in classification the role and outcome matters more than the action.

Reply on news.ycombinator.com