Ariel Lira's picture

Hi guys, I been using tklapp for a couple of years on several servers with excelent results but sometimes, in particular last year, I found some issues with invalid * domains resolution. 

My server has a fixed public IP with and no 'x' bit in /etc/cron.hourly/hubdns-update. The domain was registered using hubdns-update command.  Also, I am almost sure the server had no downtime and that it was 100% online. 

Usualy after several days, maybe a month, I get alerts indicating that does not work anymore (because it redirects to After that, I have to manually run hubdns-update on the server and alert everyone to wait a couple of hours in order to DNS caches get updated.

I think I may have 2 problems here: 

a) not locating my server. Perhaps this is because I have no 'x' bit in hubdns-update cronjob? Again, I am sure the server was alive all the time.

b) the DNS caches are outdated for too long, despite the domain being ok. 

For example, if I run hubdns-update after a) issue, and I ask my DNS for, I get for several hours

;; ANSWER SECTION:                                                                                            85986   IN      CNAME                                    85986   IN      A   

 but if I ask to one of tklapp DNSs at AWS, I get the right IP (XYZ.XYZ.XYZ.XYZ)

;; ANSWER SECTION:   10      IN      A       XYZ.XYZ.XYZ.XYZ

I think this issue may be caused by a CNAME record to with very high TTL (1 day). Perhaps if CNAME records to have a lower TTL, like 3600, DNS caches will be cleared sooner?

Any advice will be welcome!



Jeremy Davis's picture

TBH I don't know much about HubDNS but it does take longer to update than ideal, but for me it's only ever been ~10 mins (I use Google Public DNS). I have noticed that a new domain works straight away, whereas reassigning an existing one takes 5-10 mins to update.

Where is your DNS coming from? You can see from your dig of AWS nameservers that the TTL is 10s. So it's the caching between the AWS nameserver and your browser that is causing the issues.

I note that for me:

dig @ # Google DNS

Still not 10s but significantly less than yours.
Ariel Lira's picture

Hi Jeremy, 

The ttl of valid and resolved tklapp domains is perfect. My issue is with the ttl returned for the CNAME record in case of invalid domains (or valid but unresolved by for some reason like I expressed previously). See bold text in the following example :


;  IN      A

;; ANSWER SECTION: 86400 IN  CNAME             86400   IN      A

Then, for about 86400 secs (1 day) this CNAME record is allowed to live in DNS caches and if I register with hubdns, it would be invisible to me and others because DNS caches in the middle would redirect me to, despite the right A record is available in AWS servers.

I ve tried with my ISP DNS and Google DNS.  

I think you can replicate the scenario with the following steps:

  1. dig @ (you will get a CNAME to and cause the results get cached in google DNS)
  2. hubdns-init APIKEY && hubdn-update (in a server with ip XYZ.XYZ.XYZ.XYZ)
  3. dig @ (you will get a CNAME to instead of the A record to XYZ.XYZ.XYZ.XYZ)

Please let me know if you need more info.




Jeremy Davis's picture

Sorry that I missed your initial point. Re-reading your OP I get it and I think you may be right! Interestingly though I get the high TTL for the CNAME record if I query one of the AWS nameservers (same as you 86400 i.e. 24 hours), but I don't if I query Google (21599 = ~6 hours). It's still far from ideal, but is significantly less. I wonder what is going on.

FWIW I have updated the existing issue on our tracker with an overview of your info. I've linked to this thread but feel free to elaborate over there if you want.

Thanks for your info.

Add new comment