Server failure?

ebarzilay

New Member
Good morning,

I have a legacy account, and for years I had ns8 and ns14 as secondary slave servers for the main server which I managed. At some point I wanted to switch and have zoneedit as primary servers, and I did some changes, but I don't remember exactly what they were. My own server is down now, so I looked up the settings on zoneedit.

When I click the "name servers" thing on the Domain Administration page, it tells me that I should use ns9 and ns17. But I don't get any replies with any of these (including ns8 and ns14). Is there anything wrong? -- I don't see anything that indicates that it's a slave now (and I don't see any option to set up slaves either). My domain is barzilay.org.
 

ebarzilay

New Member
Ping?

I've been trying it since the above, and I get nothing from the ZE servers. Even things like:

$ dig @23.27.48.61 ns19.zoneedit.com
; <<>> DiG 9.8.1-P1 <<>> @23.27.48.61 ns19.zoneedit.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
 

sandy

Administrator
Staff member
hi there.

the domain is delegated to:
Name Server:NS9.ZONEEDIT.COM
Name Server:NS17.ZONEEDIT.COM
Name Server:pLTMDNS.CCS.NEU.EDU

and:
dig @ns9.zoneedit.com a barzilay.org

; <<>> DiG 9.3.4 <<>> @ns9.zoneedit.com a barzilay.org
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16318
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;barzilay.org. IN A

;; ANSWER SECTION:
barzilay.org. 3600 IN A 129.10.115.115


-----

dig @ns17.zoneedit.com a barzilay.org

; <<>> DiG 9.3.4 <<>> @ns17.zoneedit.com a barzilay.org
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19602
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;barzilay.org. IN A

;; ANSWER SECTION:
barzilay.org. 3600 IN A 129.10.115.115

the other server has no record and should be either fixed or removed from the delegation at the registrar:

dig @PLTMDNS.CCS.NEU.EDU a barzilay.org


; <<>> DiG 9.3.4 <<>> @PLTMDNS.CCS.NEU.EDU a barzilay.org
; (1 server found)
;; global options: printcmd
;; connection timed out; no servers could be reached


I hope this helps

thanks
sandy
 

ebarzilay

New Member
Hmm -- I see that now when I'm trying from a different machine. In fact, I also get a good reply from other ns*.zoneedit.com servers (which I'm guessing is something that can disappear and should not be used).

But I still get nothing but errors when I'm using that machine that the domain points to (which is 129.10.115.115). Is there anything that could make it refuse serving that particular machine? That's the only thing I can think of, since:
  • Pinging and tracerouting the zoneedit servers works fine, so I can reach them
  • Trying dig/host using the google dns servers (8.8.8.8 and 8.8.4.4) works fine too
The dig/host tools on the machine are the standard ones that are included with Fedora 20, and I've never heard about any issues with them.

(And yes, I know that the last name on the delegation list is not responding now, that's what made me look into verifying that the ZE servers are working...)
 

sandy

Administrator
Staff member
Hi again.

if 129.10.115.115 is set as a nameserver then it would most likely be configuration errors on that server or that server not having any zone file information
for the domain name. It would have to be fixed from within that servers environment.

thanks
sandy
 

ebarzilay

New Member
It's not supposed to be a nameserver -- but now that I think about it, it's likely that I played with this and maybe left it with some misconfigured local caching ns. But shouldn't "dig @foo blah" or "host blah foo" ignore local stuff and just query foo for answers?

(And thanks for the quick reply!)
 

ebarzilay

New Member
*sigh* After lots of digging around, it turns out that the university network that the machine is in has a firewall blocking outgoing dns queries for some paranoia reasons...

Apologies for the noise, and thanks again for looking into it!
 
Top