New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
A 1 second ttl is bad for performance, in my case. Why not respect the RFC and cache based on subnets.
Edit: and even with 1 second, that's still 1 second cache - still not good.
@vld - remember that clients never query our servers directly, always via public DNS (such as Google DNS or OpenDNS). As mentioned earlier EDNS0 packets are never cached on packet level and not cached on backend level if TTL is lower than 30 sec. We have customers which do over billion requests domain/month and they are happy with our GeoDNS. In your case of your test - try to create new test records are previous can still be cached
@gbshouse: sure, I'm open to ideas and happy to discuss options. In the meantime, here's what I'm looking for in terms of DNS management:
zone templates + adding zones en masse;
zone name wildcards + zone category field, making it possible to modify all zones in same category or using wildcard (using zone templates);
DDNS + automation (i.e. API making zone + record adding/modifying using scripts possible);
configurable TTL;
DNSSEC support;
vanity nameservers, including SOA record;
economy of scale, i.e. same (low) cost at 1000 and 10,000 domains
Have I forgotten about anything here...?
But seriously now: started doing housekeeping in my little domain collection and almost went bonkers trying to set up zones and make modifications using run of the mill DNS CP of one of my providers. Threw in the towel at domain no. 50 of 1000+ or thereabouts. And this is just the beginning. Hence this sudden, crazy urge to set up my own DNS, together with some bells and whistles while at it 
EDIT: I mention DNS management and not DNS CP, as I'm perfectly happy to deal with raw text files and scripts, without benefit of any webpanel or DB backend. Automation is key here. Managing each zone separately is out of the question.
I feel that AnyCast is somewhat misunderstood sometimes. Shortening it somewhat bluntly, Anycast solves the Providers problem (availability, least cost reachability, etc) while aglodek wants to mainly accomodate the client. Also, as some correctly noted, AnyCast isn't concerned anout the "best" Ip but about getting you to the closest DNS server (or a fall back if needed).
As for GeoIP I wouldn't worry at all about the precision of data. After all, the point here is not "find the best/next pop in your city" but sth. like "You're in Asia. OK, we won't send you to a server in Norway but one in India or HK or ...".
I agree that some "customer accessible BGB routing" (btw: AnyCast does it's magic using ... bingo, BGB) or some kind of GeoIP based solution is better and more adequate.
One "but" though: Considering the low granularity needed ("roughly your part of the world") and the project (couple a 1000 domains) and the resources available (VPS) I'd opt for a "cooked myself every day" local GeoIP DB rather than creating lots of traffic and lag with dyn. lookups. In other words: Get a worldmap every day or, even better, a changes only map, process that (say, with country granularity) and use it for a given day (Hint: Doing that and providing it might turn into a profitable small service itself).
MaxMind provides international GeoIP database with selectable granularity, with daily diffs or fulls.
Cool! So, voila, there's a simple and liteweight solution for that problem. Any idea about cost?
Very good point here. Correct me if I'm wrong, but my understanding of anycast DNS was that it works like BIND Views, where each DNS node is assigned a "View" with different "A" record(s), selected for their proximity - n'est pas? If not this, then how does the DNS node, receiving the query, determine which "A" record, out of the many listed, points to the closest POP (webserver or whatever)?
Exactly right. And from where I sit, I'm not concerned with miliseconds but differences measured in hundreds of miliseconds... well, maybe 50's of miliseconds
Huh! Yesno. Like many funny things AnyCast sounds dead simple - but isn't.
Sure, you can set up every dns server with data for "it's" region. So, if a client ends up at your EU DNS server, (s)he gets the EU "view", i.e. the IP of, say, your NL web server.
But (that's where it gets funny) What if your Asia DNS is down and, thanks to AnyCast, your client get's routed to the EU DNS? Before you say "So what. A bad answer is better than asking a dead DNS server" wait. Because there hve been cases were the server was alive but the DNS service wasn't. And AnyCast happily sent people to a dead DNS service on a not dead server.
Moreover, you are usually not in control of the underlying bits and pieces (like BGB), unless you are a pretty hefty major player. Which basically means that AnyCast for you is a bet with many open variables.
Also, don't forget that you are not talking about dozens of AnyCasted servers but just a handful. Which means that each of your 3 or 5 (anycasted) DNS servers must have all records for all zones anyway (after all, a client might come from who knows where thanks to AnyCast and your modest setp). Bingo, you are back at start.
And there are more funny issues you as a not major player wouldn't love to meet ...
Probably most importantly though, DNS already has built-in fall back capability. Each of your domains has >= 2 DNS servers in its records anyway.
I see it like that:
Solution: ExaBGB would be nice but they are, in a way, having the same problem you have, namely (still) modest operations and low coverage. Once they have grown bigger that might be very interesting to look at. I think they've got something really interesting and promising, albeit not yet grown to an attractive size (like 10 or 12 smartly distributed global POPs).
Currently standard, well implemented DNS combined with some reasonably low granularity and reasonable dynamic (like 1 - 4 times per day update) GeoIP looks like the best and most reasonable way to go.
BTW: A compliment to ourselves, the colourful LET community here! I find it amazing, how even not that trivial problems get crunched, digested, processed and solved here thanks to the guys and the combined know-how, experience and brain-power (well, except me, probably **g) around here.
Very good point, but as you correctly point out later in your comment, there will be at least 2 anycast DNS nodes in each POP (ns1 + ns2). Me, like Arthur C. Clarke's Ramans, like threes, so: ns1 + ns2 + ns3
This aside, assuming that all "A" records for all regions are listed in each DNS node and there are no BIND-like Views, my question stands: how does the DNS node, receiving the query, determine which "A" record, out of the many listed, points to the closest POP (webserver or whatever)?
@gbshouse or @William - if it's not a closely held secret?
Raw (dynamic lookup) or cooked GeoIP I suggest, the latter being more attractive in your case.
Oh, and btw: your 2nd anycasted DNS server won't do you no good because from AnyCasts point of view there is no problem. Actually it may turn against you because you can't know how the "client" (usually an ISPs recursor) interprets the situation (and reacts) nor how AnyCast reacts the next time. Large players typically handle those trouble cases (in one way or another depending on their general setup) through unicast measures but you can't do that easily because almost everything in the whole game is outside your control.
@bsdguy: what do you mean by "raw (dynamic lookup)?
Raw: Client request comes in, dns server asks GeoIP server "Where is this (clients) IP from?", GeoIP server answers "country X", dns server finds closest/best/whatever IP for country X and responds to client.
Cooked: You download 1 - 4 times/days the GeoIP changes, update your local (low granularity) database and serve DNS requests based on your local GeoIP copy.
Sounds pretty straightforward. Do you know if NSD4 comes with any API/hooks to build on maybe?
Sorry, no. But from what I remember (from quite some while ago) the source was well structured and of good quality.