dns1.zoneedit.com not responding

ownthegame

New Member
Hi,

I just added a new zone, austexresources.com.
I haven't delegated it to zoneedit yet as I want to test the zoneedit DNS first.

The interface says my nameservers should be:
dns1.zoneedit.com
dns2.zoneedit.com

When I try to test my zone at these nameservers using nslookup, I get the following response:

> server dns1.zoneedit.com
Default Server: dns1.zoneedit.com
Addresses: 2a03:b0c0:1:e0::1623:2001
165.22.116.248

> austexresources.com
Server: dns1.zoneedit.com
Addresses: 2a03:b0c0:1:e0::1623:2001
165.22.116.248

*** dns1.zoneedit.com can't find austexresources.com: No response from server

I get the same from dns2.zoneedit.com. Why are neither of these nameservers responsing to requests?

Thanks in advance
Martin
 
Hi there, how long ago did you add the zone file?

its there at present:

dig @dns1.zoneedit.com a austexresources.com

; <<>> DiG 9.10.6 <<>> @dns1.zoneedit.com a austexresources.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36702
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;austexresources.com. IN A

;; ANSWER SECTION:
austexresources.com. 3600 IN A 15.197.133.181


_________________

dig @dns2.zoneedit.com a austexresources.com

; <<>> DiG 9.10.6 <<>> @dns2.zoneedit.com a austexresources.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50340
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;austexresources.com. IN A

;; ANSWER SECTION:
austexresources.com. 3600 IN A 15.197.133.181


regards
 
Thanks for your response Sandy.

I just checked again and now I was at least getting a connection to the server, but it was timing out with every request.

Then I tried turning off my VPN and it suddenly works! I use ExpressVPN.

Does that mean Zoneedit DNS blocks traffic from VPN servers? I noticed a while ago that I can't log in to zoneedit when I'm connecting through a VPN, which I believe is a deliberate security policy. But if the DNS itself also blocks VPN traffic, does that mean no-one will be able to access my website if they are connected to VPN?! Is that also deliberate or is that something that needs to be reported and fixed?
 
If the VPN is looking up IPv6 that that would be problematic... for both record lookups and logins.

regards
 
Lookup .. google... IPv4 vs IPv6 and then check on your VPN documentation how to set it appropriately. on your lookups :

Default Server: dns1.zoneedit.com
Addresses: 2a03:b0c0:1:e0::1623:2001


2a03:b0c0:1:e0::1623:2001 is an IPv6 IP address so that might be whats causing you the errors.. its looking at IPv6 instead of IPv4 (165.22.116.248)

regards
 
I asked ChatGPT and got a reasonable answer:
https://chatgpt.com/share/6851815a-fd10-800c-b09c-fd7476b9ed05

Seems I just have to disable the VPN when I'm testing the zoneedit DNS directly, but it should work as normal if other users are accessing my site through ExpressVPN.

Thanks for your time Sandy!

What’s happening​

  1. ExpressVPN forces all DNS traffic to use its own resolvers
    When you connect, the client injects routes and ip-tables rules so that every packet on UDP/TCP 53 is either (a) redirected to, or (b) dropped unless it is destined for the private, in-tunnel DNS addresses that ExpressVPN hands out (usually 10.x.x.x). This is part of their “private DNS on every server” feature that is designed to eliminate DNS leaks. expressvpn.comexpressvpn.com
  2. As a side-effect, queries you deliberately aim at third-party name-servers never leave the tunnel.
    From the operating system’s point-of-view you are talking to dns1.zoneedit.com, but the VPN’s firewall either NULL-routes those packets or rewrites them to the in-house resolver. The result is a silent timeout.
  3. Some exit nodes are also black-holed by ZoneEdit themselves.
    ZoneEdit publishes that they block IP ranges that generate abusive DNS traffic. Public-VPN exit ranges—ExpressVPN’s in particular—regularly end up on those ACLs, so even if the packet reaches ZoneEdit it may be discarded. forum.zoneedit.com
  4. Occasional MTU / fragmentation problems add to the confusion.
    Large DNSSEC-signed replies from ZoneEdit can exceed the IPv4 path-MTU once the VPN headers are added. If fragments are filtered on the way back, you again see a timeout. ExpressVPN’s own blog describes why this still happens even with their “dynamic-MTU” logic. expressvpn.com
  5. OpenVPN/LW or OS firewalls can simply block outbound :53 after the tunnel is up.
    Users on the OpenVPN forums report that port 53 becomes unreachable to any outside host immediately after a tunnel is established. forums.openvpn.net
 
Back
Top