-2

Let me start by saying that of course conventions are important, there should be a rule of thumb for some cases that is representing the best action to follow by, in order to prevent mistakes and make stuff more simple.

Now for the topic of the question/discussion.

I am working on a side project of a DNS server written in Go, and have been reading RFC 1034 & RFC 1035.

RFC 1035 describe the Zones master file that stores all the DNS records inside of it, with some other data like TTL, record type and authority who sent it.

RFC 1035 was written in 1987 and I understand why it was using a text file in order to store its data.

While designing my project I was thinking about using a local database like PostgreSQL serving under the localhost.

While looking a bit more into the subject, I found out that big companies who serves DNS servers like Microsoft are using the text file format as well, I guess that its because of keeping the convention "alive", but I just cant find any reason not to kill it and improve the system.

Do you think I should use the text file, or a local database?

Why does companies keep using old methods?

Thank you for any answer, that might point to something i didnt think about.

moti shaku
  • 21
  • 2
  • 5
    There's nothing wrong with doing things the "way it's always been done" when the way it's always been done **works well** – whatsisname Sep 23 '20 at 20:13
  • 1
    `Why does companies keep using old methods that are simple and effective?` FTFY – Dan Wilson Sep 23 '20 at 21:07
  • 10
    I can almost certain guarantee you that almost no parts of a production DNS systems use files, nor RDBMSs. I'll bet my saving that almost all data is looked-up from hyper-optimized, domain-specific in-memory data structures, without the latency of HDDs/SSDs, file system drivers, SQL query processors, etc. The zone file format is just an interface. It can be generated and served upon request, but that doesn't mean that the underlying representation that stores its backing data, and it certainly doesn't mean that the zone file is how look-ups are performed – Alexander Sep 23 '20 at 21:14
  • 2
    @Alexander-ReinstateMonica: Indeed, in the RFC the OP quoted, the very next section after the one talking about the zone file, gives suggestions for how to design the internal database, and it also makes it very clear that those are only suggestions and that every implementor can do whatever they want. – Jörg W Mittag Sep 24 '20 at 00:48
  • Thank you for the answers, i did not think about some of the stuff mentioned here. I should have mentioned im a new developer, self learning, so still got a lot to learn of course. @Alexander-ReinstateMonica – moti shaku Sep 24 '20 at 16:02

5 Answers5

5

The zone file format is a standardized format. Standard are good, because, well, they are standardized. They give a common ground. Why do we still use TCP/IP? Because every device in the world (modulo tiny embedded devices) speaks it. Can we do better? Sure! We can update TCP/IP. We can even try and replace it. But that would mean replacing the entire infrastructure of what is, essentially the basis of almost all modern life.

If you do use local database for configuration, and your server ends up running an important zone, then how am I going to send my zone data to you? As a SQL INSERT INTO statement?

Note that there is nothing in the RFC you quoted that says you must use a zone file. It only defines the format for the zone file in case you use one.

Of course, you will not be using the zone file as the runtime database. It is a configuration file, not a data structure. In fact, the very RFC you quoted has this to say (bold emphasis mine):

6.1.2 Database

While name server implementations are free to use any internal data structures they choose, the suggested structure consists of three major parts:

  • A "catalog" data structure which lists the zones available to this server, and a "pointer" to the zone data structure. The main purpose of this structure is to find the nearest ancestor zone, if any, for arriving standard queries.

  • Separate data structures for each of the zones held by the name server.

  • A data structure for cached data. (or perhaps separate caches for different classes)

Community
  • 1
Jörg W Mittag
  • 101,921
  • 24
  • 218
  • 318
2

Where are you going to find the IP of "localhost" before you can connect to your database?

You are basing the entirety of a very critical service (DNS) on the performance, security and stability of a RDBMS.

You are not gaining any runtime performance benefits to doing it -- any indexing that the RDBMS is going to do is going to be generic, and better indexing can be done on a known file format.

You are not going to gain memory cache benefits doing it -- any caching the RDBMS will do can be done by the OS filesystem cache (just as effectively), or custom data structures matching your known file format (far more effective).

You are adding connection overhead to a system that is supposed to be stupidly blistering fast.

Like @whatisname said, I just don't see the benefits here. There is nothing stopping you from using Postgres to generate the file and signal your daemon to reload the file. That gets you the dynamic building you want, while still remaining RFC compliant and all the benefits mentioned above.

Bryan Boettcher
  • 2,754
  • 4
  • 21
  • 31
  • 1
    The zone file for a DNS server application, and the local resolution of names like `localhost` are completely separate concerns, and there may not even be any network connections needed to talk to a database (besides the fact that `localhost=127.0.01` is probably the worst example of needing a lookup in the first place). There is a grain of truth in this answer, in that a _very task-specific_ in-memory database would be more appropriate than an off-the-shelf RDBMS, but _directly reading a text file_ for every query would be an awful implementation, and I'm sure it's not what the RFC intends. – IMSoP Sep 24 '20 at 16:24
0

This can be framed under the heading legacy. There is a concept called path dependency where decisions that are made in the past limit the decisions that can be made in the future. In other words, it's difficult to reverse decisions made in the past to accommodate new contexts.

From a technological point of view this doesn't quite make sense; just use modern technology right? It might be complicated to replace the old, but it's not impossible. Database instead of a file, from a technical point of view, just seems like common sense right - hence your question - and why not use new technology?

From a cultural point of view it gets messy. The RFC is what everyone is used to. Technical snobbery, it exists and has it's benefits as well as flaws, might influence the decision to improve. For example, if Microsoft had decided to change the RFC file format against the community wishes it could be seen as attempts to lock in the technology and the skills. Also, what's there now is what everyone knows so don't improve it because some people don't want to update their skills and want to remain the experts over others (read, they have the secret knowledge - even if it's a file format). Improvement might take away that knowledge and therefore they're expert power; handing it over to a younger generation. That's food off the table.

From a business point of view it might be costly to change. This is were standards come in. Integration with standards ensures technology plays well together. Changing to a database might be okay for you; but maybe not for someone that integrates or manages dependent systems. It's like changing the rules of the game; creating variation. Python 2 to Python 3 is a great example of the business impact of breaking standards.

Hope that added to the conversation. Happy coding.

null
  • 344
  • 1
  • 5
-3

Because otherwise you create misery.

By convention you give a gift to a person who is having a birthday.

This is inefficient because if you both give each other $20 gifts all you have succeeded on doing is wasting $4 dollars worth of packaging if given in person, much more if you post it.

The same effect can be achieved by just transfering $20 dollars to them and letting them spend as they see fit.

Except the efficiency isn't the point. The point of gift giving is to convey other information, in this case your respect/love/revelry/etc.

The point of using a text format to describe zone information also is not about efficiency. It is that anyone can access/modify that information. By not following this convention you actively cause misery to all the other programs/users who simply cannot comprehend your proprietary solution.

Kain0_0
  • 15,888
  • 16
  • 37
-5

Older companies are more traditional and employ older staff. I worked as a software developer in healthcare and we had C and perl all over, even newer code was written in C, im not talking about legacy, mostly because thats what staff was comfortable with. So in older companies there might be some sentiment in favor of following older standards and paradigms, I work 6 years as programmer and no one mentioned RFCs at all, old or new is moot point.

QOlobOQ
  • 1
  • 2