My domains, MyDNS (Linux.com) [LWN.net]

My domains, MyDNS (Linux.com)

Posted Feb 23, 2006 23:26 UTC (Thu) by proski (subscriber, #104) [Link]

What's exactly so "moronic" in this article? In my opinion, the article gives a good idea of what the software does, how good it is at what it does, and how easy it is to use. If I need to use a DNS server, the article gives me a general idea whether to this software would be good for me.

I think bad articles are those that concentrate just one one aspect (e.g. speed or ease of use) and ignore others. This is not one of them.

By the way, did you read the article at all? It says that PostgreSQL is supported as backend in addition to MySQL. Or maybe you wanted to say that supporting MySQL is a terrible sin that cannot be expiated by supporting other databases? Or maybe you are against any database backends?

My domains, MyDNS (Linux.com)

Posted Feb 24, 2006 8:34 UTC (Fri) by HenrikH (guest, #31152) [Link]

I think that jwb are opposed to the idea of storing your DNS records in a SQL database, and in this I agree completely with him since that is somewhat insane.

My domains, MyDNS (Linux.com)

Posted Feb 24, 2006 9:17 UTC (Fri) by farnz (guest, #17727) [Link]

So what about DNS records in LDAP? If I understand the big objections to SQL databases properly, the trouble is that DNS is hierarchical, and SQL isn't; LDAP is also hierarchical, and things like PowerDNS LDAP backend let you keep your DNS records in there.

If not, what database-like alternatives do people recommend to text files?

My domains, MyDNS (Linux.com)

Posted Feb 24, 2006 12:59 UTC (Fri) by HenrikH (guest, #31152) [Link]

Using a SQL or LDAP as a replacement for the configuration files is one thing, using them as the database for the DNS server is another (and is the one that I am against).

A DNS is a database on it's own and in my world it should be treated as a kind of soft-realtime service, while SQL and LDAP is far from that in my mind.

My domains, MyDNS (Linux.com)

Posted Feb 24, 2006 14:11 UTC (Fri) by farnz (guest, #17727) [Link]

Why is it dangerous? Even OpenLDAP supports online read-only replication, so each DNS server has its own copy of the database, and is allowed to access other copies if the local copy is down.

If the DNS server has to maintain a local copy of the database (when the master is in the LDAP database), it ends up replicating the database itself, and being forced to monitor for changes. This adds complexity to the DNS server for no gain (whether the replication and monitoring is done via extra code within the DNS server, or by an external program that writes out a text configuration and reloads the DNS server).

Further, if the DNS server queries the authoritative database itself, I'm guaranteed not to poison DNS caches with known wrong data; if the DNS server uses an internal database, there's the risk that it goes wrong or gets out of sync with LDAP, and silently corrupts caches, or worse, that the problem goes undiagnosed until I change LDAP and wonder why my DNS is now inconsistent between my servers. Instead, if I have a breakdown between a DNS server and all LDAP servers, I have a nice, easy to diagnose and detect failure of a DNS server.

Finally, for my network, there are no services running that don't depend in some way on LDAP being up (either for e-mail routing data, or authentication/authorization). In that scenario (not uncommon if you don't have public services other than receiving SMTP e-mail), a failure of all LDAP servers means that a DNS failure is the least of your worries; none of the services that could be contacted via DNS entries are functioning.

My domains, MyDNS (Linux.com)

Posted Feb 24, 2006 14:28 UTC (Fri) by HenrikH (guest, #31152) [Link]

Who said that it would be dangerous?

> there are no services running that don't depend in some way on LDAP being up
perhaps not on your net but on mine where we are handling realtime trading in shares we have nothing critical that is dependant upon LDAP (or SQL for that matter).

My domains, MyDNS (Linux.com)

Posted Feb 26, 2006 10:50 UTC (Sun) by job (subscriber, #670) [Link]

You still want to shave off every millisecond you can from a DNS reply. A good tradeoff should be for the DNS to mirror the LDAP data in memory. Most zones are so small anyways (even for large companies) that using any sort of disk storage is stupid.

My domains, MyDNS (Linux.com)

Posted Feb 27, 2006 8:40 UTC (Mon) by Wol (guest, #4433) [Link]

If DNS is hierarchical, use a hierarchical database.

The trouble with Relational, is it is SLOW (and it's broken :-) It treats all data as EQUAL and it seeks to EQUALISE access times. Firstly not all data is equal (if there's a hierarchy, it can't be :-), and secondly by equalising access times it has to equalise to the worst case!

Then, of course, SQL is a broken implementation of the broken Relational Model :-)

Cheers,
Wol

My domains, MyDNS (Linux.com)

Posted Feb 24, 2006 16:27 UTC (Fri) by proski (subscriber, #104) [Link]

This doesn't make the article "moronic".

My domains, MyDNS (Linux.com)

Posted Feb 26, 2006 10:50 UTC (Sun) by job (subscriber, #670) [Link]

Well, it wasn't informative. I still know nothing about MyDNS except the fact that it can store data in SQL which would be a very silly thing to begin with.

My domains, MyDNS (Linux.com)

Posted Mar 2, 2006 3:04 UTC (Thu) by Baylink (guest, #755) [Link]

> a very silly thing

You don't have to manage 75,000 zones.

Now, I don't either, but we both know there are people who *do*, and filesystem/text tools don't scale well to that.

Perhaps, from an implementation standpoint, the best compromise is to render the zones into traditional zone files, and run them on a 'standard' DNS server, but the bare idea of maintaining zones in a DBMS isn't inherently stupid.

My domains, MyDNS (Linux.com)

Posted Mar 4, 2006 19:32 UTC (Sat) by job (subscriber, #670) [Link]

Neither do I, but the people who do tend to not bring in relational databases to the mix. The RIPE DNS server (yes, I know it isn't, I just forgot it's name) has some interesting stories to tell about its development and what king of data structures scales to those numbers.

Myself, if I designed a server, would aim to keep data live all the time. 75k zones isn't that hard, even if you store 1k data per zone, you'd still fit in 75MB which hardly costs money these days. Disk storage should be regarded as backing up data to read back again when restarting and should be kept as simple as possible. No matter which way I look at it, SQL seems to be a really bad fit.

Actually...

Posted Mar 4, 2006 19:49 UTC (Sat) by Baylink (guest, #755) [Link]

the people who do *do* use SQL underneath.

At least Todd Lewis et al did, at Mindspring, in 1999. The Usenix paper is here. It was actually someone else who was implementing the MySQL backend, but Lewis asserts that he thinks SQL underpinnings are a Pretty Neat Idea, several places in the paper.

It would be interesting to know what he thinks at this remove; anyone know where he went? Todd; you reading this? :-)

Actually...

Posted Mar 25, 2006 11:37 UTC (Sat) by job (subscriber, #670) [Link]

I don't believe "they" do, unless more than one come forward and say so.
And the Dents server is dead so that may not be the best example. But I'm
also very interested to learn more about the results, please post
something if you learn more.

My domains, MyDNS (Linux.com)

Posted Feb 24, 2006 3:39 UTC (Fri) by ajf (subscriber, #10844) [Link]

well-tested, robust, secure, and scalable

I thought we were talking about bind.

My domains, MyDNS (Linux.com)

Posted Feb 27, 2006 18:01 UTC (Mon) by carcassonne (guest, #31569) [Link]

Could very well be that alongside more people moving from Windows to Linux, or at least using more Linux than before, we also get all these 'freeware' and 'shareware' developers with it. That's to be expected.

This said, I'm not pointing at the concerned article since I do not know the author.