DNS record outdated

[Jason000]

Hi,

I am using dynamic DNS for my domain, the DNS records is updated using API. Currently I am facing a problem that even though the records are updated successfully, any DNS request to my domain still pointing to old records, until I login to the web control panel, and do update manually, the web shows correct IP.

My domain, absmail.biz

Please check and fix as soon as possible.

Thanks.

 

[sandy]

May i suggest that you modify the dynamic records to only include the root domain... the @ sign and a wildcard updater... the * sign and let me know if that fixes the issue.

thanks
sandy

 

[Tobias Müller]

Same here.
I have two domains to be updated, the root (troplin.ch) and a subdomain (mail.troplin.ch).
Both are pointing to the same IP and I'm using exactly the same mechanism to update both.

The update reports success for both, and the web interface shows the new IP for both domains.
But the zone file is only updated for the subdomain (mail.troplin.ch) and not for the root domain (troplin.ch).

That means my update script (https://encodable.com/eponym/) detects that the IPs do not match and regularly tries to update it again.
This is what I get for report:

Redundant update: troplin.ch to 176.127.156.114​

85.4.59.200 is the current IP of troplin.ch.
176.127.156.114 is your current IP.
The last update was 20160414-2015.
About to update troplin.ch by asking dynamic.zoneedit.com for
auth/dynamic.html?host=troplin.ch

server-response: <SUCCESS CODE="201" TEXT="no update required for troplin.ch to 176.127.156.114" ZONE="troplin.ch">

Note: this message is not an indication of a problem unless it happens frequently.

[Sent by Eponym v2.72]​

I know it's a free service and I'm grateful to use it, but this should really be fixed.

 

[sandy]

Hi Tobias,

can you also try to update ghe root @ and a wild card *.. what may be happening is if we are updating the @ record and the zone is reloading with that new ip.. and while the zone is reloading
another dynamic update comes for mail then that mail dynamic update may be skipped..... as it reached us during a zone reload... as well the TTL must be 600 seconds at the very least and if you scatter them if yo keep the root and mail by ten minutes each that helps as well.

thanks
sandy

 

[Tobias Müller]

Hi Sandy,
I'm not sure what you mean exactly by "try to update the root @ and a wild card *".
Do you mean I should..
... change the update script to update "*.troplin.ch" and "troplin.ch" or ...
... change my settings in the web interface or ...
... do a one-time update for "*.troplin.ch" and see if it fixes the problem ...

Unfortunately, the eponym script cannot be configured such that it scatters the updates.

Suggestion: If the update service doesn't work reliably during a zone reload, couldn't you just reject any update request during that time? That's not an ideal solution either but probably easier to get right and still much better than the current state.

 

[sandy]

hi Tobias.

... change the update script to update "*.troplin.ch" and "troplin.ch" or ...
... change my settings in the web interface .... to also be hosts @ and *

Please let me know how that works for you.

thanks
sandy

 

[Tobias Müller]

Hello Sandy,
it kind of works now.
After updating troplin.ch the script tries to update *.troplin.ch which is rejected, because the minimum time between requests has to be 600s.
I guess this gives the server enough time for a zone reload.
But this is definitely not an ideal solution either. The update script compares the actual IP address with the resolved address. It will try to update the "troplin.ch" until the IP resolves correctly. But this block the update of "*.troplin.ch" which is only updated after "troplin.ch" will finally resolve correctly.

On additional thing that I noted: Previously the order of update was: 1. "mail.troplin.ch" 2. "troplin.ch". Is it necessary to first update the root or is the order irrelevant?

 

[Tobias Müller]

Regarding the TTL, it was set to zero, now I've set it to 1 hour.
But I remember setting the TTL to something reasonable, definitely not zero. What could be the reason for this?

Also, there's a strange effect now. Here's the log of my update script:
1460754902 20160415-2315 currentip=85.2.255.180 lastip=85.4.59.200 response: <SUCCESS CODE="201" TEXT="no update required for troplin.ch to 85.2.255.180" ZONE="troplin.ch">
1460754003 20160415-2300 currentip=85.2.255.180 lastip=85.4.59.200 response: <SUCCESS CODE="201" TEXT="no update required for troplin.ch to 85.2.255.180" ZONE="troplin.ch">
1460752880 20160415-2241 currentip=85.2.255.180 lastip=176.127.156.114 response: <SUCCESS CODE="200" TEXT="troplin.ch updated to 85.2.255.180" ZONE="troplin.ch">
1460750238 20160415-2157 currentip=176.127.156.114 lastip=85.4.59.200 response: <SUCCESS CODE="201" TEXT="no update required for troplin.ch to 176.127.156.114" ZONE="troplin.ch">
1460749536 20160415-2145 currentip=176.127.156.114 lastip=85.4.59.200 response: <SUCCESS CODE="201" TEXT="no update required for troplin.ch to 176.127.156.114" ZONE="troplin.ch">
1460748674 20160415-2131 currentip=176.127.156.114 lastip=85.4.59.200 response: <SUCCESS CODE="201" TEXT="no update required for troplin.ch to 176.127.156.114" ZONE="troplin.ch">
As you can see, my IP adresses were
1. 85.4.59.200
2. 176.127.156.114
3. 85.2.255.180

The field lastip is what DNS resolves to. As you can see 22:41, the hostname "troplin.ch" correctly resolves to 176.127.156.114 (highlighted in green) and is updated successfully to 85.2.255.180. But after the update, it won't resolve to the updated IP, but instead it resolves to the even older IP 85.4.59.200 again (highlighted in red). How is that even possible?

 

[Tobias Müller]

Ok, I think this is not a zoneedit problem but something else...
nslookup now jumps seemingly random between the 3 IP adresses:

Protheseus:~ muelleto$ nslookup troplin.ch
Server: 192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
Name: troplin.ch
Address: 85.2.255.180

Protheseus:~ muelleto$ nslookup troplin.ch
Server: 192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
Name: troplin.ch
Address: 85.4.59.200

Protheseus:~ muelleto$ nslookup troplin.ch
Server: 192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
Name: troplin.ch
Address: 85.4.59.200

Protheseus:~ muelleto$ nslookup troplin.ch
Server: 192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
Name: troplin.ch
Address: 85.4.59.200

Protheseus:~ muelleto$ nslookup troplin.ch
Server: 192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
Name: troplin.ch
Address: 85.4.59.200

Protheseus:~ muelleto$ nslookup troplin.ch
Server: 192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
Name: troplin.ch
Address: 176.127.156.114

Protheseus:~ muelleto$ nslookup troplin.ch
Server: 192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
Name: troplin.ch
Address: 85.2.255.180

Protheseus:~ muelleto$ nslookup troplin.ch
Server: 192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
Name: troplin.ch
Address: 85.4.59.200

No sure what's happening here.
Authoritative servers seem to work correctly though:

Protheseus:~ muelleto$ nslookup troplin.ch dns1.zoneedit.com
Server: dns1.zoneedit.com
Address: 162.220.33.236#53

Name: troplin.ch
Address: 85.2.255.180

Protheseus:~ muelleto$ nslookup troplin.ch dns2.zoneedit.com
Server: dns2.zoneedit.com
Address: 166.88.18.58#53

Name: troplin.ch
Address: 85.2.255.180

 

[sandy]

The NS lookup ip address would be coming from your local resolvers.. the digs/nslookups directly on our servers are what are important.

TTL should be 600 seconds at the minimum ( ten minutes)

what is your current IP?

thanks
sandy

 

[Tobias Müller]

Yes, the direct nslookup works fine. I don't know why my local resolver was behaving like that but now it works correctly too. But that's not a problem on your side and I don't want to annoy you with that.
So consider this solved for the time being.

Still, I think that this reconfiguration is just a workaround for a problem that needs to be solved on your side. An update during a zone reload should never result in an inconsistent server state.
But as long as it works I won't complain.

Thanks for your patience
Tobias

 

[sandy]

hi Tobias.
we are looking at queuing dynamic updates to avoid this.. no ETA at present but it is something we will be looking into.

than ks
sandy

 

[tekert]

Hi, for the last year or so im having a similar problem from the one described here but from a different perspective:
In short, i have two dynamic records (@ and www subdomains)
Every 5 months or so when the ip needs to be changed i send two GET requests (using ssl, but i tested this without ssl too)

I Made a simple script to test this behaviour using httest (http://htt.sourceforge.net/cgi-bin/cwiki/bin/public)
Script: http://pastebin.com/CNnLHV0J
NOTE: just to keep the problem clean, the problem still occurs using software clients for this purpose. (Directupdate, ddclient, etc)

Host tested:
dynamic.zoneedit.com and api.cp.zoneedit.com
Files tested:
dyn/tomato.php, /dyn/generic.php, /auth/dynamic.html, and many others.
Params used:
it depends, for the php files for example, ?hostname=$host1&myip=$ip
for html files, ?host=$host1&dnsto=$ip
I even tryed only ?hostname=$host1 so to set the origin ip automatically.

They all work correctly..
Exept when "sometimes" when two request are sent at the same moment to different sudomains (in this case www.domain.com and domain.com), only the first one sent (tested this with sniffer in hand too) gets updated.
Both requests get the response <<SUCCESS CODE="200" TEXT="*ZONE* updated to *IP*" ZONE="*ZONE*"> OK
Doing a dig test on dns1, dns2, ns7, ns14, dns0 etc, and even on zoneedit.com website panel i see that one of the records (the last updated) is not updated even when i got OK response.

So i began digging in (no pun intended) and saw that this problem seems erratic, i mean, sometimes both get updated and sometimes only the first sent (within milliseconds of difference)
The other thing is that the TTL record for dynamic records get set to 0 (zero) even when changing it manually it gets reseted.
All these test where made with many variations, even switching to http 1.0, i mean, everthing i could think off. my conclusion is that zoneedit discards an update if its zone is updated too fast maybe depending on the current server load.
Other weirdness i encountered (rare) are SOA serial numbers that are way ahead of the primary server and stay that way for a long time.
clarification on the last comment: dns0.zoneedit.com is set as my primary nameserver, xfr0.zoneedit.com as the master transfer server. then i have the NS dns1.zoneedit.com NS ns7.zoneedit.com NS ns14.zoneedit.com and other remote NS on other servers. All had the same serial number exept ns7.zoneedit.com with a number way ahead of the rest, i waited for them to sync internally on zoneedit, like, 1 hour, and it stayed the same.

So my conclusion is that there is some problem on the zoneedit side when a record gets updated too fast.

My solution was to delay the update of www A record in this case and send the @ A record update first, within.. 150sec or so of each other. That solved it but i got a feeling this is somewhat muddy.