[sf-lug] EveryDNS.net (and some of its plus sides and downsides)

Rick Moen rick at linuxmafia.com
Sun Aug 24 02:41:26 PDT 2008

Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):


> ; For EveryDNS.net, NOTE AT LEAST THE FOLLOWING (at least as of
> ; 2007-05-26):
> ;
> ; Cannot be set up and function as slave(s) until one or more of
> ; their nameservers have been delegated as an NS via a chain of
> ; authority from the root nameservers.
> ;

I cherish the irony of my rising to the defence of DJB's tinydns.

(In 1999, after administering qmail professionally for a while, I
posted on my personal Web pages the reasons why I don't enjoy
administering the man's software, because I was tired of repeating those
reasons.  My doing so lead to Prof. Bernstein sending me what was
tantamount to a lawsuit threat, my being maligned by name in the
gentleman's qmail pages, and my becoming the semi-official devil figure
of DJB groupies everywhere.)

tinydns _should_ be able to handle all RR types, because there is a
generic data type that should accomodate any arbitrary RRs, including
those not officially supported.  My rundown on all DNS servers for
Linux, including djbdns (which includes tinydns) is here:

Of course, if you say it can't, I do believe that your experience
at least suggests that limitation -- and there might be something about
the EveryDNS implementation that creates that problem even though it
should not be present in tinydns per se.

I would not personally run tinydns in its present state (unmaintained
for seven years running, with a large number of third-party patches
available that may or may not be compatible and meet one's needs).


That is a serious sin.  

Notice that, also, ISP nameservers are notorious for overruling domains'
TTL (time to live) values for no better reason than slightly reducing
ISPs' bandwith cost on (usually necessary, useful) DNS zone updates.
That always struck me as a sufficient reason to not use ISP nameservers
or _any other_ nameservers that cannot be bothered to do the job
correctly -- and overriding TTL values is just not a good sign.

> ; FAILs TO ACCEPT TCP CONNECTIONS on ns[123].everydns.net.  

Heh.  Oh boy.  That is a classic symptom of running DJB's tinydns
software.  (Just to be clear on this, a separate DJB daemon called
axfrdns _does_ support TCP-type queries, and, no, not just for AXFR
zonefile transfer requests.  Maybe everydns.net elect not to run it?

> ; DOES WORK (including answering queries) with TCP on:
> ; ns4.everydns.net.

Might be that they run the axfrdns daemon only there.

> ; Accepts but ignores notify

Classic tinydns behaviour.  Again, please see my rundown page.

> ; Will pick up zone updates at most once per hour (and presumably
> ; only if SOA serial number indicates there's been an update).

Again, classic djbdns failing.  (There are optional, third-party scripts
that they could elect to run, to fix this problem.)

I honestly cannot understand anyone being willing to outsource
authoritative DNS to people who screw it up, that way.  (Again, I think
that David Ulevich's "OpenDNS" people, who run Everydns.net, are being 
quite generous, and are very competent.  There are merely built-in
compromises in what they're willing to do for people.)  The sensible
alternative is to set up one's own authoritative DNS on one's own static
IP address, and then do secondary DNS for others in the same situation,
with them returning the favour.  Works for Me.<tm>

More information about the sf-lug mailing list