Recommendations for third-party DNS?


#1

For years, I had dreamhost hosting the www.master.gen.in.us and www.ilove.lancaster.pa.us domains, but I have recently started experiencing trouble with both domains.

The support staff (William) indicates that Dreamhost’s DNS has problems providing domain name service for domains that aren’t directly under a top-level domain.

Does anyone have any experience with third-party DNS providers I can use as canonical domain name servers, since Dreamhost’s servers seem not up to the job?

deke


#2

You’re misquoting me a bit - I said that sometimes the code that recognizes what domains are domains and which are subdomains doesn’t work properly.
It’s not an issue of our servers being up to the job or not - the backend just needs to be configured to generate DNS for it. I’ve gone ahead and done that for you (for ilove.lancaster.pa.us).

jazz% dig ilove.lancaster.pa.us. @ns.newdream.net.

; <<>> DiG 9.3.0s20020703 <<>> ilove.lancaster.pa.us. @ns.newdream.net.
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55480
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;ilove.lancaster.pa.us. IN A

;; ANSWER SECTION:
ilove.lancaster.pa.us. 7200 IN A 66.33.196.236

;; AUTHORITY SECTION:
ilove.lancaster.pa.us. 7200 IN NS ns3.newdream.net.
ilove.lancaster.pa.us. 7200 IN NS ns.newdream.net.
ilove.lancaster.pa.us. 7200 IN NS ns2.newdream.net.

;; ADDITIONAL SECTION:
ns.newdream.net. 7200 IN A 66.33.206.6
ns2.newdream.net. 7200 IN A 216.240.131.131
ns3.newdream.net. 7200 IN A 64.70.42.11

;; Query time: 129 msec
;; SERVER: 66.33.206.6#53(ns.newdream.net.)
;; WHEN: Mon Jul 15 12:41:43 2002
;; MSG SIZE rcvd: 168

For master.gen.in.us, there are two extra nameservers that aren’t responding at all, however it does appear to be setup properly with us, and it should still be working (although you should get rid of the lame delegation). Are you actually having problems with this one? It should be working fine as far as I can tell.

jazz% dig master.gen.in.us @ns1.oar.net. ns

; <<>> DiG 9.3.0s20020703 <<>> master.gen.in.us @ns1.oar.net. ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45713
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 3

;; QUESTION SECTION:
;master.gen.in.us. IN NS

;; ANSWER SECTION:
master.gen.in.us. 86400 IN NS ns2.dreamhost.net.
master.gen.in.us. 86400 IN NS fwi.com.
master.gen.in.us. 86400 IN NS ns.idt.net.
master.gen.in.us. 86400 IN NS ns.newdream.net.

The only thing I can see is that there may be some kind of problem with some of the servers that are authoritative for the top level domain ‘us.’ (right now, only one of them is responding for me, and there’s a missing glue record for b.gtld.biz).

I would not suggest switching to using a third party provider for DNS, because this will create a fairly good risk of something breaking down the road.


#3

When I was testing a stat analysis program called Sawmill, it required me to identify the dns resolver. So I used my isp. It worked fine. As I understand it, if the named dns resolver doesn’t know the canonical name, it sends out a request to the next higher level, and so on, until the name is resolved.

Patty


#4

Oops, Will replied to this thread as I was, and boy was I out of bounds responding. You guys are talking about something entirely different than I thought.

Patty


#5

That’s basically correct (assuming the server you’re using to resolve domain names allows recursion).

DNS is a hierarchical, distributed database, and so caching is a big part of what makes it work so efficiently (there are 13 “root” servers, which are authoritative for ‘.’ – these root servers delegate everything under ‘.’).

An authoritative server can define a ‘TTL’ (time to live) for each record which states how long other servers can cache a response for.


#6

[quote]You’re misquoting me a bit - I said that sometimes
the code that recognizes what domains are domains
and which are subdomains doesn’t work properly.

It’s not an issue of our servers being up to the job
or not - the backend just needs to be configured
to generate DNS for it. I’ve gone ahead and done
that for you (for ilove.lancaster.pa.us).

[/quote]

Sorry about misquoting you. What you said was
"Our system doesn’t always recognize domains that aren’t directly under a TLD, and thus won’t always generate
DNS for them properly.

"I have to doublecheck the setting to force DNS generation; I should have this fixed for you by tomorrow at the latest.

“In the meantime, you may wish to get this delegated to you from the servers for lancaster.pa.us (unless, of course,they require it to be setup on our side first).”

How is having the domain delegated to me different than registering it? I did that three years ago for the lanca site, and Dreamhost has been hosting both sites since then. I didn’t start having any trouble with these two domains until June.

In any case, I still have a problem. You indicate Dreamhost doesn’t reliably recognize non-second-level domains, and you indicate the solution I came up with - third-party DNS - is the road to perdition. What is the answer for reliable hosting of these domains?


#7

[quote]“In the meantime, you may wish to get this delegated to you from the
servers for lancaster.pa.us (unless, of course,they require it to be setup
on our side first).”

[/quote]

That one was my fault – I didn’t specify a non-recursive lookup in my initial query, and since our system wasn’t generating NS records for the zone. The servers for lancaster.pa.us are, in fact, reponding properly for ilove.lancaster.pa.us

[quote]I did that three years ago for the lanca site, and Dreamhost has been
hosting both sites since then. I didn’t start having any trouble with these
two domains until June.

[/quote]

I don’t see why you would be having trouble with the other domain, but if you are, I’d guess the problems are mostly or partially caused by problems with the servers that are authoritative for the us. TLD. Again, I would suggest changing the registration information for master.gen.in.us from:

ns.idt.net.
ns.newdream.net.
ns2.dreamhost.net.
fwi.com.

to:
ns.newdream.net
ns2.newdream.net
ns3.newdream.net

What surprises me more is that the ilove.lancaster.pa.us. domain was working at all until now. In any event, now that it’s fixed, it’s not going to break again.

[quote]You indicate Dreamhost doesn’t reliably recognize non-second-level
domains, and you indicate the solution I came up with - third-party DNS -
is the road to perdition. What is the answer for reliable hosting of these
domains?

[/quote]

At the moment, the best solution is to contact support when adding such a domain, and have them set the parameter ‘force_dns’ for your domain’s DNS service. I will talk to our developers and see if we can work out a more robust solution to this problem (I believe we have many of the common domains that might be problematic such as .co.uk or .co.jp set to be considered as a TLD in our system, so this problem affects very few customers).

Also, if you continue to experience problems, it would be helpful if you could include any DNS debugging information possible (from your perspective), and the exact error messages you’re getting.