DNS Synch issues?

[#1]

I think these are the associated ip's..
50.31.164.172:80          ESTABLISHED
192.33.31.101:80          ESTABLISHED
109.123.122.221:80      ESTABLISHED

[#2]

Quote from: npr

May be worth rechecking your domain record at dnsimple.com. That is the NS for the domain camra.org.uk so I would have expected it to be the NS for the host www.halton.camra.org.uk, it appears no to be.

Hi npr,
At first, this did not make sense to me, but after a bit of digging, I think I now understand what you are alluding to, but I do not know if it has any relevance…

Quote from: nslookup

> www.halton.camra.org.uk Server:  dsldevice.lan Address:  192.168.1.254 ------------ Got answer:     HEADER:         opcode = QUERY, id = 6, rcode = NXDOMAIN         header flags:  response, want recursion, recursion avail.         questions = 1,  answers = 0,  authority records = 0,  additional = 0     QUESTIONS:         www.halton.camra.org.uk.lan, type = A, class = IN ------------ ------------ Got answer:     HEADER:         opcode = QUERY, id = 7, rcode = NXDOMAIN         header flags:  response, want recursion, recursion avail.         questions = 1,  answers = 0,  authority records = 0,  additional = 0     QUESTIONS:         www.halton.camra.org.uk.lan, type = AAAA, class = IN ------------ ------------ Got answer:     HEADER:         opcode = QUERY, id = 8, rcode = NOERROR         header flags:  response, want recursion, recursion avail.         questions = 1,  answers = 3,  authority records = 0,  additional = 0     QUESTIONS:         www.halton.camra.org.uk, type = A, class = IN     ANSWERS:     ->  www.halton.camra.org.uk         canonical name = www.camrabeerengine.org.uk         ttl = 3585 (59 mins 45 secs)     ->  www.camrabeerengine.org.uk         canonical name = dev.camrapubs.org.uk         ttl = 8136 (2 hours 15 mins 36 secs)     ->  dev.camrapubs.org.uk         internet address = 109.123.122.221         ttl = 8136 (2 hours 15 mins 36 secs) ------------ Non-authoritative answer: ------------ Got answer:     HEADER:         opcode = QUERY, id = 9, rcode = NOERROR         header flags:  response, want recursion, recursion avail.         questions = 1,  answers = 2,  authority records = 1,  additional = 0     QUESTIONS:         www.halton.camra.org.uk, type = AAAA, class = IN     ANSWERS:     ->  www.halton.camra.org.uk         canonical name = www.camrabeerengine.org.uk         ttl = 3585 (59 mins 45 secs)     ->  www.camrabeerengine.org.uk         canonical name = dev.camrapubs.org.uk         ttl = 8136 (2 hours 15 mins 36 secs)     AUTHORITY RECORDS:     ->  camrapubs.org.uk         ttl = 9681 (2 hours 41 mins 21 secs)         primary name server = ns.hosteurope.com         responsible mail addr = hostmaster.camrapubs.org.uk         serial  = 2012050201         refresh = 86400 (1 day)         retry  = 3600 (1 hour)         expire  = 1209600 (14 days)         default TTL = 14400 (4 hours) ------------ Name:    dev.camrapubs.org.uk Address:  109.123.122.221 Aliases:  www.halton.camra.org.uk           www.camrabeerengine.org.uk

Looking at WHOIS reports on UK Nominet...
www.halton.camra.org.uk is a sub-domain of camra.org.uk
camra.org.uk name servers are with dnsimple.com
DNSLOOKUP reports www.halton.camra.org.uk canonical name = www.camrabeerengine.org.uk
camrabeerengine.org.uk name servers are with acidy.com
DNSLOOKUP reports camrabeerengine.org.uk  canonical name = dev.camrapubs.org.uk
camrapubs.org.uk name servers are with 123-reg.co.uk

So where does ns.hosteurope.com come into the equation?

I am correct in concluding that to resolve www.halton.org.uk DNS lookups need to visit the 3 DNS name servers identified above, rather than just dnsimple.com ?

Whilst this has no bearing on the inconsistency of PN DNS name resolution it might point to something which CAMRA can improve.

Thanks,
Kevin

[#3]

There appears to be two remaining problems.
a) only one (ns4) of the dnsimple.com domain name servers giving the correct result.
b) opendns failing to find the subdomain.
a)
This dig command tells us the name servers for the domain "camra.org.uk

Quote

; <<>> DiG 9.8.6-P1 <<>> ns camra.org.uk @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43207 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;camra.org.uk.                  IN      NS ;; ANSWER SECTION: camra.org.uk.          3600    IN      NS      ns1.dnsimple.com. camra.org.uk.          3600    IN      NS      ns2.dnsimple.com. camra.org.uk.          3600    IN      NS      ns3.dnsimple.com. camra.org.uk.          3600    IN      NS      ns4.dnsimple.com.

If we lookup "www.halton.camra.org.uk" querying each of the domains NS:-
Querying ns1.dnsimple.com

Quote

; <<>> DiG 9.8.6-P1 <<>> www.halton.camra.org.uk @ns1.dnsimple.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63276 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 13 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.halton.camra.org.uk.      IN      A ;; ANSWER SECTION: www.halton.camra.org.uk. 3600  IN      CNAME  www.camrabeerengine.org.uk. ;; AUTHORITY SECTION: .                      518400  IN      NS      a.root-servers.net. .                      518400  IN      NS      b.root-servers.net. .                      518400  IN      NS      c.root-servers.net. .                      518400  IN      NS      d.root-servers.net. .                      518400  IN      NS      e.root-servers.net. .                      518400  IN      NS      f.root-servers.net. .                      518400  IN      NS      g.root-servers.net. .                      518400  IN      NS      h.root-servers.net. .                      518400  IN      NS      i.root-servers.net. .                      518400  IN      NS      j.root-servers.net. .                      518400  IN      NS      k.root-servers.net. .                      518400  IN      NS      l.root-servers.net. .                      518400  IN      NS      m.root-servers.net. ;; ADDITIONAL SECTION: a.root-servers.net.    3600000 IN      A      198.41.0.4 b.root-servers.net.    3600000 IN      A      192.228.79.201 c.root-servers.net.    3600000 IN      A      192.33.4.12 d.root-servers.net.    3600000 IN      A      128.8.10.90 e.root-servers.net.    3600000 IN      A      192.203.230.10 f.root-servers.net.    3600000 IN      A      192.5.5.241 g.root-servers.net.    3600000 IN      A      192.112.36.4 h.root-servers.net.    3600000 IN      A      128.63.2.53 i.root-servers.net.    3600000 IN      A      192.36.148.17 j.root-servers.net.    3600000 IN      A      192.58.128.30 k.root-servers.net.    3600000 IN      A      193.0.14.129 l.root-servers.net.    3600000 IN      A      198.32.64.12 m.root-servers.net.    3600000 IN      A      202.12.27.33 ;; Query time: 31 msec ;; SERVER: 198.241.10.53#53(198.241.10.53) ;; WHEN: Wed Feb 05 15:16:28 GMT Standard Time 2014 ;; MSG SIZE  rcvd: 494

Clearly a failed lookup, ns2 and ns3 give the same failed lookup every time.
Querying ns4.dnsimple.com

Quote

; <<>> DiG 9.8.6-P1 <<>> www.halton.camra.org.uk @ns4.dnsimple.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4563 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.halton.camra.org.uk.      IN      A ;; ANSWER SECTION: www.halton.camra.org.uk. 3600  IN      CNAME  www.camrabeerengine.org.uk. ;; Query time: 15 msec ;; SERVER: 50.31.243.53#53(50.31.243.53) ;; WHEN: Wed Feb 05 15:17:10 GMT Standard Time 2014 ;; MSG SIZE  rcvd: 75

Successful lookup only from ns4.dnsimple.com
The above problem may just be dnsimple being very slow to propagate the record between their name servers, I don't know but I would have expected better than this.
Whether it makes any difference or not I'm not sure. It may be that if a DNS query fails using one ns it will retry the other ns -- not sure about this.
b)
The problem with Opendns appears to be due to them picking up the wrong name server.
This command queries opendns (208.67.222.222) for the name server used by camra.org.uk

Quote

; <<>> DiG 9.8.6-P1 <<>> ns camra.org.uk @208.67.222.222 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7882 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;camra.org.uk.                  IN      NS ;; ANSWER SECTION: camra.org.uk.          256803  IN      NS      ns0.demon.co.uk. camra.org.uk.          256803  IN      NS      ns2.demon.net. camra.org.uk.          256803  IN      NS      ns1.demon.co.uk.

As you can see it's erroneously picking up demon.co.uk
Strangely opendns (208.67.220.220) is picking up the correct dnsimple.com NS.
These problems may well resolve them selves over time, but they are certainly taking longer than I would expect.
If I get chance I'll report the opendns issue in their forum.

[#4]

Quote from: npr

As you can see it's erroneously picking up demon.co.uk

It's not picking them up, but rather serving the now-stale records from its cache. You can verify this by repeating the dig query and you'll see the cache timer falling.
This is not a fault on Opendns's part but actually that of the person responsible for managing CAMRA's DNS. The cache timer for these NS records at the time of your lookup was 256803 seconds i.e. 71 hours. The TTL must therefore been set even higher. OpenDNS is simply doing what CAMRA's DNS manager wanted them to - look up the record and keep the result (i.e. don't ask me again) for (at least) 71 hours.
What CAMRA's DNS manager should've done is either i) dropped the old TTL to a low value way before the changeover so that the changes would effectively propogate quickly, or ii) run the new and old DNS servers side-by-side for sufficient time for the old records to expire from caches (and in the meantime either put new registrations on hold or make sure they get populated on both sets of servers). Either they weren't aware of the need to do this (most likely) or didn't care that their domain, and everything within it, will remain in an indeterminate state of flux for a few days.
As you say, the delegations will sort themselves out but it'll take at least 71 hours from the time the changes were made before all cached results expire. This of course assumes all the records got transferred correctly which, given that they failed with the NS TTL's, we will have to wait and see!

[#5]

I've raised the problem with opendns, I'll report back when I hear anything.
All 4 dnsimple.com name servers are now resolving the subdomain.
Interestingly the new name server (ns) has a ttl of 1 hour, whereas the old ns (demon) had a ttl measured in days.
Any future changes should now take affect much quicker.

[#6]

Thank you all for the informative input on the CAMRA side of the equation, I will pass the observations on to them.
Does the long TTL explain the inconsistent resolution of the NEW domain name (a sub domain) of CAMRA.org.uk by the various PN DNS caches?
Cheers,
Kevin

[#7]

Absolutely. High TTL's help keep the loading on the DNS down as well as provide some stability during outages. However, it does so at a cost - if you want to make changes it takes them longer to propogate*. Is is a tradeoff between stability/robustness and dynamism/flexibility.
The lower TTLs of the new records could well be because they've learnt from their mistakes the hard way! They may well end up raising them once this is all over though.
[* Note: Whilst we say 'propogate' this implies an active push of the new records from their DNS to everyone elses resolvers however this isn't the case. It relies on other servers pulling the new records but they will only do that if required to do so by a connecting client. The problems come when a client/resolver fetches a record just prior to a changeover - it is then stuck with this 'old' record for as long as the TTL said to keep it for hence why lowering the TTL way before a change is considered best practice in these circumstances because it means it won't hang around for as long.]

[#8]

MJN,
Thank you for the interest and detailed information - just to help me understand better, am I correct in concluding that the TTL has to expire before asking the registrar for the names server details again?
That said though, surely if one cache within a pool gets a new A record for a domain, then all associated caches should be updated at the same time?
Cheers,
Kevin

[#9]

Quote from: Townman

am I correct in concluding that the TTL has to expire before asking the registrar for the names server details again?

That is correct although note that it doesn't just apply to name server details but rather any DNS record - they all have TTLs attached to them.

Quote

That said though, surely if one cache within a pool gets a new A record for a domain, then all associated caches should be updated at the same time?

You say one cache within a pool however there's no reason why each server within a pool wouldn't have it's own cache. In fact, that is preferable in many ways as whilst there might be benefits of sharing cached results it also takes away some of the resilience and redundancy that a pool of fully autonomous DNS servers would otherwise provide. The records that benefit most from caching are those that are commonly queried which, by definition, means that that a common cache wouldn't be of much additional benefit given each independent cache would likely not have to wait long before it would be asked for the record itself anyway. (I hope that makes sense - I'm having trouble explaining it!)

[#10]

Opendns are telling me "I've cleared the DNS cache for the domain www.halton.camra.org.uk."
Every thing now appears ok with this domain lookup from opendns.
Just checked the opendns cache for this domain.
It now shows their caches world wide to all have the correct IP.