[Snap] Accessing/resolving .nz TLD's from Snap connection

Forums › 2degrees (including Slingshot, Orcon, Flip, Stuff Fibre, MyRepublic, 2talk and Vocus) › [Snap] Accessing/resolving .nz TLD's from Snap connection

1 | 2

jarledb

Webhead
3253 posts

Uber Geek

Moderator

ID Verified

Trusted

Lifetime subscriber

#1276915 3-Apr-2015 21:27

So if you are changing where host names point AND name servers at the same time, the right way to do it is:

1) Well in advance, lower TTL so you can make a quick switch of the host names.
2) Change the pointers for the hosts you want to update on the old DNS servers
3) Make sure new nameservers have the same zone files and setup, so you don't break anything when moving.
4) Move to new nameservers.

Now both the old and the new nameservers should be pointing at the same hosts, and everything should be hunky dorey.

Jarle Dahl Bergersen | Referral Links: Want $50 off when you join Octopus Energy? Use this referral code
Are you happy with what you get from Geekzone? Please consider supporting us by making a donation or subscribing.

Aaroona

3193 posts

Uber Geek

#1276918 3-Apr-2015 21:35

jarledb: So if you are changing where host names point AND name servers at the same time, the right way to do it is:

1) Well in advance, lower TTL so you can make a quick switch of the host names.
2) Change the pointers for the hosts you want to update on the old DNS servers
3) Make sure new nameservers have the same zone files and setup, so you don't break anything when moving.
4) Move to new nameservers.

Now both the old and the new nameservers should be pointing at the same hosts, and everything should be hunky dorey.

Thanks mate.

Lets forget everything here and go back to basics;

1. I bought a new domain.
2. I changed the NS records immediately, to point to Cloudflare.
3. SNap took 24 hours to update (which someone has replied is the default TTL for the .nz tld)
4. Cloudflare's TTL is by default, around 5 minutes. I am now adding A records etc. to my zone, which are now taking longer to become "cached" into DNS, than those that are on my .com domain, through the same DNS provider.

I think I need an ELI5 post from someone to help me understand what's going on here. :P

sorceror

163 posts

Master Geek

#1276922 3-Apr-2015 21:41

to work thru your example -

if you are looking for an A record for test.domain.com:

1) Snap queries the root name server for test.domain.com
2) Root name server tells Snap to query the .com gTLD server (this response is cached, usually 2 days)
3) Snap queries the .com gTLD server
4) .com gTLD server tells Snap to query the authoritative NS that's configured at the registrar (this response is cached, usually 24 hours)
5) Snap queries the correct name server for test.domain.com

So if you change your NS at the registrar at step 4), Snap might still have a cached response from the gTLD server that points to the old NS for up to 24 hours
---

As for new A records not being active as quickly, this would definitely be happening at step 5) - this is between you and your NS provider.

edit: As mentioned below, there could be negative caching going on, although I'm not sure whether Snap has this implemented or not. Negative caching would occur if you're a bit too trigger happy and for example try and look up a domain before your NS providers web portal updates the zone files.

The TTL for negative caching is obtained from the SOA record for your domain (the default is an hour). You should be able to set this to a lower value.

jarledb

Webhead
3253 posts

Uber Geek

Moderator

ID Verified

Trusted

Lifetime subscriber

#1276923 3-Apr-2015 21:41

I think what you experienced is that you triggered DNS queries on the Snap DNS servers before that information was available from the root servers.

DNS servers will cache negative results to avoid having to do the same queries over and over again. Sometimes for longer than the TTL of the root servers.

I would guess that the other name servers you tested later got information from the root servers (for .nz) and that is why it was working there.

Aaroona

3193 posts

Uber Geek

#1276928 3-Apr-2015 21:56

jarledb:... DNS servers will cache negative results to avoid having to do the same queries over and over again. Sometimes for longer than the TTL of the root servers.

sorceror: ...As for new A records not being active as quickly, this would definitely be happening at step 5) - this is between you and your NS provider.

edit: As mentioned below, there could be negative caching going on. the TTL for these type of records is obtained from the SOA record for your domain (default is an hour)

Thanks for the replies, Gents.
My understanding on how it worked is correct then (phew!) - though wasn't aware of the caching of negative responses... Good stuff to know.

To give you an idea of how I tested it;

(No trying to access A record prior)
- Add A record to domain.
- Wait 10-15 minutes, then ping the A record from both the Snap and Telstra connection (and also tried Telecom and Vector connections to be sure)

The only one that didn't respond was Snap.

Given what's been discussed here, and the results, I'm inclined to believe it's my Snap connection (well, Snap's config)

FYI, also tried Google DNS, and it also responded quickly... so only difference I can see is Snap's DNS.

sorceror

163 posts

Master Geek

#1276929 3-Apr-2015 22:04

the point to take away is that DNS servers are quite dumb and have very little config. All of the control is done via records.

are you creating the records on the Snap connection? there's a chance that when the records are being created you are also doing a lookup (Chrome likes to do this for example, it does DNS lookups on every link on a page before you click them to speed up browsing time)

Aaroona

3193 posts

Uber Geek

#1276933 3-Apr-2015 22:22

sorceror: the point to take away is that DNS servers are quite dumb and have very little config. All of the control is done via records.

are you creating the records on the Snap connection? there's a chance that when the records are being created you are also doing a lookup (Chrome likes to do this for example, it does DNS lookups on every link on a page before you click them to speed up browsing time)

Yes, and I was previously with the .com ones as well, which didn't have an issue.

But to rule it out, I just created the records over 3G on my mobile, and am testing now via my Snap connection, with the same results... Worth mentioning though, that .com records also not updating as quick any more.

Oh well, maybe I should take this chance to change my DNS providers! (running DNS Benchmark now)

Equinox IT

Cloud spending continues to surge globally, but most organisations haven’t made the changes necessary to maximise the value and cost-efficiency benefits of their cloud investments. Download the whitepaper From Overspend to Advantage now.

sorceror

163 posts

Master Geek

#1276934 3-Apr-2015 22:30

very strange! another way to rule out negative caching would be to drop the default/minimum TTL setting on your SOA record but it doesn't sound like that is what's happening here.

Aaroona

3193 posts

Uber Geek

#1276936 3-Apr-2015 22:47

sorceror: very strange! another way to rule out negative caching would be to drop the default/minimum TTL setting on your SOA record but it doesn't sound like that is what's happening here.

Hmm.. Isn't the SOA controlled by the NS provider though?

But either way not sure that would fix the issue. :)

I guess the main thing is, at least it's not just me who thinks it's a strange result. I might stick with Google DNS (both IPv4 and 6) for a bit, and see how things go.

Cheers for the advice! Not sure there's much more I can do to resolve this using Snap DNS.

sorceror

163 posts

Master Geek

#1276953 3-Apr-2015 23:02

SOA should be controlled by you - i know i can change my SOA record via my providers web portal

1 | 2