TC 9.0b1 updater just says hosts=null

[ghisler(Author)]

Sorry, I was a bit tired, I wanted to write "To those with the name server problem".

[LogicDaemon]

OpenDNS gives correct response for TXT record too (followed by control example to ensure bad behavior with A record persists):

Code: Select all

>nslookup -type=TXT releaseversion.ghisler.com
Server:  srv-inet.office0.mobilmir
Address:  192.168.1.1

Non-authoritative answer:
releaseversion.ghisler.com      text =

        "10.9.0.131,10.8.51.1"

>nslookup -type=txt releaseversion.ghisler.com 208.67.222.222
Server:  resolver1.opendns.com
Address:  208.67.222.222

Non-authoritative answer:
releaseversion.ghisler.com      text =

        "10.9.0.131,10.8.51.1"

>nslookup releaseversion.ghisler.com
Server:  srv-inet.office0.mobilmir
Address:  192.168.1.1

*** No internal type for both IPv4 and IPv6 Addresses (A+AAAA) records available for releaseversion.ghisler.com

>nslookup releaseversion.ghisler.com 208.67.222.222
Server:  resolver1.opendns.com
Address:  208.67.222.222

*** No internal type for both IPv4 and IPv6 Addresses (A+AAAA) records available for releaseversion.ghisler.com

[ghisler(Author)]

Good, I will use that as the main check then, and the old check as a fallback.

[wanderer]

The help\update in b2 says "TC is up to date". Is this normal for b2? Has there been a change in how b3 checks for updates?

[Sob]

The change is in beta 3, so beta 2 still uses the old way. And while new TXT record contains "10.9.0.131,10.8.51.1", the old A record (used by beta 2) contains "10.9.0.130", which I assume is the old value for beta 2 which was not updated by mistake.

[wanderer]

The change is in beta 3, so beta 2 still uses the old way.

After seeing history.txt which contains that specific DNS change, i assumed exactly that. I'm not sure if it was by mistake though or intentional.

[Sob]

By mistake I mean the number. New record contains 10.9.0.131, but the old one has 10.9.0.130. The old one should still be used as backup, if new one for some reason does not work. So they should both have the same number.

[ghisler(Author)]

I have set releaseversion.ghisler.com to 10.9.0.131 yesterday. However, nslookup still reports 10.9.0.130 here!

It seems that the expiration of 60 seconds is ignored. Apparently the DNS servers use the expiration of ghisler.com, which is currently set to 86400 seconds or 24 hours. Please try the update check again this afternoon.

I have now set the expiration to 3600 seconds (one hour), but this will only affect future lookups.

[Sob]

It looks to be some problem at your end. Because when I ask your nameservers (ns1.ghisler.com and ns2.ghisler.com) directly, I get the old value and TTL:

Code: Select all

# dig A releaseversion.ghisler.com @ns1.ghisler.com
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 52260
;; Flags: qr aa rd; QUERY: 1; ANSWER: 1; AUTHORITY: 2; ADDITIONAL: 2

;; QUESTION SECTION:
;; releaseversion.ghisler.com.          IN      A

;; ANSWER SECTION:
releaseversion.ghisler.com.     60      IN      A       10.9.0.130

;; AUTHORITY SECTION:
ghisler.com.            86400   IN      NS      ns1.ghisler.com.
ghisler.com.            86400   IN      NS      ns2.ghisler.com.

;; ADDITIONAL SECTION:
ns1.ghisler.com.        14400   IN      A       64.131.64.238
ns2.ghisler.com.        14400   IN      A       64.131.64.239

;; Received 128 B
;; Time 2016-06-23 17:43:56 CEST
;; From 64.131.64.238@53(UDP) in 124.4 ms

# dig A releaseversion.ghisler.com @ns2.ghisler.com
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 32547
;; Flags: qr aa rd; QUERY: 1; ANSWER: 1; AUTHORITY: 2; ADDITIONAL: 2

;; QUESTION SECTION:
;; releaseversion.ghisler.com.          IN      A

;; ANSWER SECTION:
releaseversion.ghisler.com.     60      IN      A       10.9.0.130

;; AUTHORITY SECTION:
ghisler.com.            86400   IN      NS      ns2.ghisler.com.
ghisler.com.            86400   IN      NS      ns1.ghisler.com.

;; ADDITIONAL SECTION:
ns1.ghisler.com.        14400   IN      A       64.131.64.238
ns2.ghisler.com.        14400   IN      A       64.131.64.239

;; Received 128 B
;; Time 2016-06-23 17:44:39 CEST
;; From 64.131.64.239@53(UDP) in 122.6 ms

Edit: Also your SOA record looks suspicious:

Code: Select all

ghisler.com.            86400   IN      SOA     ns1.ghisler.com. support.ghisler.com. 2015062315 7200 7200 2419200 86400

Did you perhaps use wrong serial number? It seems to use YYYYMMDDcc format (2015062315), but then it would have wrong year.

[ghisler(Author)]

Sorry, what do you mean with suspicious? I didn't set this myself, it was set by CPanel. I only set the releaseversion.ghisler.com.
But I also had a releaseversion_test.ghisler.com - maybe this was confusing the DNS server? I have renamed that now to testreleaseversion.ghisler.com. I was using that for testing the function, so I didn't have to change the live values...

[Sob]

I mean the serial number. It probably needs a little background...

Serial number in SOA record identifies the zone. When you change any record, serial number must be increased, because it's used by slave DNS servers (your own, responsible for the zone). When master server has higher serial number, it tells them there are some changes and they should download them. Serial number can be just that, a simple number. But because originally it had to be increased manually, it often led to mistakes. So the recommended way for creating serial numbers is to make them from current date and change number within the day (YYYYMMDDcc). It makes it a little more obvious, if it was changed or not.

Your serial number appears to use this format, but the year would be 2015. So it is suspicious. But not necessarily wrong. It can happen that you start using DNS server software which uses this date-encoded format, and then later switch to another software, which uses simple number increments. But you can't just start from 1 or any lower number than was the last one used. So if the last one was e.g. 2015062301, it simply gets incremented by 1 every time you change something. And it may still appear like it's using date, even though it doesn't.

I didn't know how you manage your DNS. If you have some control panel, this is handled automatically. And it seems it does work, because current serial number (2015062321) is higher than it was last time (2015062315). And also both records now have correct values and new 1 hour TTL.

The most likely explanation is that something got stuck in control panel, modified records were correctly saved to database (you could see them as changed), but they weren't transfered to actual DNS servers.

You can check what your servers have even from Windows:

Code: Select all

nslookup -querytype=A releaseversion.ghisler.com ns1.ghisler.com
nslookup -querytype=TXT releaseversion.ghisler.com ns1.ghisler.com

Generally control panels update DNS servers within few minutes after you apply changes in web interface.

[ghisler(Author)]

I see - I cannot set this record myself with CPanel. I guess that it was set to 2015 something when a zone was last created, and then just increased by one each time I made a change...

Btw, nslookup A releaseversion.ghisler.com does return 10.9.0.131 here now! Can you confirm it?

[wanderer]

Btw, nslookup A releaseversion.ghisler.com does return 10.9.0.131 here now! Can you confirm it?

I can confirm that b2 upon startup reports that there is a new version (b3) available for download, if that helps.

[Sob]

Yes, it already returned correct value yesterday. As I wrote in last post, you can always verify it yourself, if you ask servers handling ghisler.com directly:

Code: Select all

nslookup -querytype=A releaseversion.ghisler.com ns1.ghisler.com

That's what the last parameter is for. You (as you probably know :) have two, ns1.ghisler.com and ns2.ghisler.com. If they return correct data, then everything is fine, because that's where the whole world gets it from (not directly, they ask some dns cache, it might ask another, but in the end something asks your servers).