Hi Ben,
On 2013-09-18, at 17:28, Ben
Also sometimes root servers seem to disappear from locations, like f.root-servers.net used to have a location in NZ, but now seems to go to Brisbane...
I hear from my friends at ISC that work is afoot to repair the Auckland F-Root node, so hopefully it becomes more local for you in due course. L-Root ought to be local for you though (send me a traceroute if not, and we'll see what we can do).
The second is that it should be considered that this will perform no better than ISP name servers, but add diversity, and/or be more likely to work if on mobile network, remote wifi network, or if usual place of connection changed upstreams. This means if the ISP name server does mirrored caching between multiple POP's then this one could too, but the intention shouldn't be to extend beyond normal ISP DNS capabilities and create any kind of improved performance.
I think what a lot of people are discovering is that running a really reliable resolver service (especially if DNSSEC validation is involved) requires active operational management. We are past the point where you could start the shipping DNS resolver service on the OS of your choice and leave it running unattended for ten years without there ever being a problem; you need dedicated staff, active monitoring, disaster recovery plans, hardware support, an ear to the ground in the usual open and closed/secret forums, etc, etc which is easier to achieve if you're Comcast with eleventy-gazillion customers than if you're smallisp.net.nz. So this is not a question of technology or technical capability; it's a question of how much it makes sense to spend on DNS operations.
The third is that ISP's should still dish out their primary DNS servers over DHCP, and tell their users to use their own DNS servers. Support for such should be hidden, and not required for an ISP, but optimise the performance for end users that have had their DNS set to use this as primary/secondary/tertiary.
Sure, but perhaps an ISP could also hand out the addresses of a managed/supported DNS resolver service provisioned through appliances in the ISP's own network and find some comfortable middle ground.
Something not completely related or unrelated, is that when people are doing Anycast for DNS in general (both authoriative and recursive) it seems pretty common to send both primary and secondary DNS to the same region. I've seen this with both recursive and authorative, and it icnreases the chance of problems. The simple solution is to make secondary not be anycast and in an unrelated region, as I understand it can be complicated to shift traffic around right to use anycast in a secondary region while optimising all other paths.
The right thing here I think is to provision multiple clouds on the same set of anycast nodes where the overlap between clouds is managed, and provision each nameserver service (the name and associated addresses for each NS record) on a different cloud. That way you get useful diversity, but the individual services are still massively redundant. This requires lots of anycast nodes to be able to do well, of course. Another approach followed by people such as Afilias is to use more than one anycast service for the zones you care about. ORG is hosted on one cloud provisioned by PCH and another one run directly by Afilias, for example. I agree that having the path to two apparently-different nameservers for the same zone land on the same anycast node is probably a bad idea :-) Joe