What is Esgob Anycast Secondary DNS?
Esgob's Free Secondary DNS is "an anycast DNS service spanning multiple countries and continents".
I found out about it when I was searching for information on how I would go about using anycast for my DNS and, possibly, my Web sites.
That search eventually led me to the following UKNOF30 talk by Nat Morris, Anycast on a shoestring. The slides for the talk [www.slideshare.net] are available online.
Video: UKNOF30 - Anycast on a shoe string
Play Video Embedded Watch Video on YouTube Google Privacy Policy Google CookiesDuring the talk, Nat Morris explained that his aim was to build an anycast DNS service for under 1,000 USD per year.
In other words, this service aimed to do what I was looking at doing. Given how much it would likely cost for a big chunk of Provider Independent (PI) IPv4 IP addresses (the bigger the chunk, the more likely it will be in BGP routing tables) I decided to give Esgob's service a try.
When it comes to BGP and route announcements, anything less than a /24 and it is unlikely your IPs will be reachable from everywhere on the Internet. Getting a /24 these days from RIPE looks like a lot of hassle. If Esgob can do what I want, why do it myself?
Registration
Registering for the service is rather simple.
Upon clicking on the Register Now button you are taken to a form and asked for the following:
- Name (your name)
- Account name (user name)
- Email Address
- Answer to a simple maths-based accessible (screen reader friendly) captcha.
Registrations are processed manually in batches. Eventually you will get an e-mail confirming your Account name. The e-mail also includes your API key.
At the time of writing there is no way (either through the Web site or API) to change your API key (nor modify your name, account name, or e-mail address).
Because exposure of your API key and account name would grant anyone with those details the ability to switch your master nameserver's IP address and force an AXFR or to delete your domain(s) from the service, and it would require e-mailing Esgob for support to change your API key, it is important you keep it secret and secure.
Fortunately, once you have things up and running the only times you would need to use the REST API (and thus your account name and API key) is when you need to (a) change the IP address of your master nameserver for a domain, or (b) when you need to add or delete a domain from the service.
Adding a Domain
Adding a domain to the service is itself a simple task. You just need to make a GET request using the REST API.
Waiting Time
In the talk Nat says that from adding a domain to it being served from all anycast instances takes about 5 seconds. That has not been my experience.
With my first domains I waited over a week after adding a domain before sending an e-mail to ask if I was doing something wrong.
Hi, am I doing something wrong?
watfordjc.uk and johncook.co.uk are only showing as OK on 'England, London, B' and 'Los Angeles, US':
I got an automated response a minute later saying a support ticket had been opened, but I didn't hear anything back.
Eventually the other anycast instances started showing as OK as well, but we're talking about weeks here rather than days.
A couple of months ago I added another domain, johncook.uk, to the service. For a long time no anycast instances were serving my zone, and in fact it took some time for the AXFR transfer host to list my zone as OK with the correct serial number.
At the time of writing only Dublin, Ireland; England, Hemel hempstead; and Vienna, Austria instances are giving an OK response for johncook.uk. Both johncook.co.uk and watfordjc.uk show an OK response from all but two anycast instances now, so it will likely just be a matter of time for the other instances to start serving johncook.uk as well.
It may, however, be the case that there is still a bug somewhere preventing propagation of my zones to all instances.
Based on my analysis, it looks like it is either a problem with the way NSD4 serves AXFR responses, somewhere in Esgob's anycast system is a bug that makes the instances (including the AXFR transfer host) think they aren't authoritative for a zone for a long time, or there is an issue somewhere between the AXFR transfer host and the instances.
Whichever it is, it is not a major issue while I also use Hurricane Electric DNS for secondaries unless Hurricane Electric DNS were to start returning NXDOMAIN or empty results to DNS queries. If the nearest Esgob anycast instance doesn't think it is authoritative for a zone, it replies with a SERVFAIL response giving a client's DNS resolver the opportunity to go and ask another authoritative DNS server for an answer.
Anycast Instance Locations
So, what countries are Esgob currently serving WatfordJC.UK from? England, Scotland, Northern Ireland, (Republic of) Ireland, Denmark, India, Netherlands, Iceland, Singapore, Russia, USA (Boston), Austria, and Poland.
Other countries have anycast instances currently under maintenance (thus not serving WatfordJC.UK) including some more in USA (Detroit, San Francisco, and Los Angeles), Germany, and Australia.
England has the highest concentration of anycast instances, with 2 in London (a third is under maintenance), another instance under maintenance in Fareham, one in progress (i.e. not yet live) in Manchester, plus other non-London live instances in Studley and Hemel Hempstead. That means England would (if all those instances were live at the same time) have 7 anycast DNS servers/instances.
That would be a total of 9 anycast instances in the UK, and a total of 10 anycast instances in the British Isles.
Since I am based in the UK, having that many anycast servers should result in faster DNS lookup times. In my case the nearest anycast instance returned a DNS lookup over IPv4 in 13 milliseconds, whereas my master nameserver did it in 21 milliseconds (over IPv6 that was 28 and 21 milliseconds respectively).
At a guess the nearest instance to me is Hemel Hesmptead which only supports IPv4 at the moment, so the nearest IPv6 instance to me is probably London B.
Master Nameserver
One of the problems with using anycast and unicast DNS together (or even just multiple anycast DNS providers) is that NS records are treated equally.
In the simple case of mixed anycast and unicast, you can expect 50% of lookups to go to the unicast nameserver, and the other 50% going to the anycast nameservers.
With simple mixed multicast from two providers, 50% of the lookups will go to the nearest instance with one provider, with the other 50% of lookups going to the nearest instance with the other provider.
NS records are not weighted. You can't, for example, say "use this multicast nameserver first, and only use this unicast one for fallback". You also can't say "these four IP addresses are anycasted, use whichever nameserver is closest to you".
In other words, if I switch to purely using my master nameserver and Esgob secondary DNS, 50% of DNS lookups would travel to my VPS in Maidenhead, England. If you're in Thailand, there is a 50% chance your DNS lookup will travel half way around the world rather than going to the nearest Esgob anycast instance.
On the other hand, only using Esgob for DNS (i.e. having a hidden master) would mean that if the nearest anycast instance isn't working (or responds SERVFAIL as it doesn't think it is authoritative) there won't be a fallback DNS server the client can use.
Multiple Nameservers With Same IP
Something I am going to try is adding multiple nameservers (hostnames) that have the same A/AAAA records.
For example, example.com having four NS records (ns1.example.com, ns2.example.com, ns3.example.com, ns4.example.com) with each of those nameservers having an A record of 198.51.100.33 and a AAAA record of 2001:db8:1a1a:cooc::53:1.
That would, if permitted by the registry and registrar (for glue records) result in 100% of lookups going to the same IP address.
If I then switched ns4.example.com to 198.51.100.34 and 2001:db8:2b2b:cooc::53:2, the nameserver at that IP should see 25% of the DNS traffic with the other 75% still going to the other IP.
Testing
dig @nsa.nic.uk +additional johncook.co.uk… ;; ADDITIONAL SECTION: ns8.johncook.co.uk. 172800 IN A 149.255.108.141 ns8.johncook.co.uk. 172800 IN AAAA 2a03:ca80:8001:769d::5 anycastns.johncook.co.uk. 172800 IN A 193.47.147.100 anycastns.johncook.co.uk. 172800 IN AAAA 2001:67c:1b43:100::100 …
After adding a nameserver through Nominet's Web Domain Manager, it looks like I can have multiple nameservers with identical glue records on the same domain:
dig @nsa.nic.uk +additional johncook.co.uk… ;; ADDITIONAL SECTION: ns8.johncook.co.uk. 172800 IN A 149.255.108.141 ns8.johncook.co.uk. 172800 IN AAAA 2a03:ca80:8001:769d::5 anycastns.johncook.co.uk. 172800 IN A 193.47.147.100 anycastns.johncook.co.uk. 172800 IN AAAA 2001:67c:1b43:100::100 anycast-esgob-ns1.johncook.co.uk. 172800 IN A 193.47.147.100 anycast-esgob-ns1.johncook.co.uk. 172800 IN AAAA 2001:67c:1b43:100::100 …
In the case of johncook.co.uk, there are now 7 nameservers listed at the parent (Nominet) nameservers. 2 of those are for Esgob, 4 for Hurricane Electric, and 1 for my master nameserver.
Put another way, 57% of lookups now go to one of Hurricane Electric's unicast nameservers, 14% of lookups to my unicast master name server, and 29% to Esgob's anycast nameservers.
This means some weighting of NS records is possible, even if priority of NS records is not. By "some" I mean that limitations apply, given the maximum number of nameservers allowed per domain at the registry and the number of nameservers you want to use. If limited to 10 nameservers and you want to use 5, you'd be limited to a minimum of 10% of traffic and a maximum of 50% of traffic going to a particular nameserver.
If I just have 2 Esgob and my master, 67% would go to Esgob anycast and 33% to my master.
In the end, I settled on 4 Esgob and my master, meaning 80% of DNS lookups should go to the nearest anycast node, and 20% to my unicast master nameserver.