firstname.lastname@example.org (Joe Greco) writes:
> So, anyways, would it be entertaining to discuss the relative merits of
> various DNS implementations that attempt to provide geographic answers
> to requests, versus doing it at a higher level? (I can hear everyone
> groaning now, and some purist somewhere probably having fits)
off topic. see <http://lists.oarci.net/mailman/listinfo/dns-operations>.
Possibly, but I found myself removed from that particular party, and the
request was on NANOG, not on dns-operations. I was under the impression
that dns-operations was for discussion of DNS operations, not
implementation choices. Whether NANOG is completely appropriate remains
to be seen; I haven't heard a ML complaint though. There would ideally
be a list for implementation and design of such things, but I've yet to
see one that's actually useful, which is, I suspect, why NANOG got a
request like this.
Besides, if you refer back to the original message in this thread, where I
was driving would be much closer to being related to what the OP was
Hank was saying:
What I am looking for is a commercial DNS service.
Another service I know about is the Ultradns (now Neustar) Directional DNS:
But this service is based on statically defined IP responses at each of
their 14 sites so there is no proximity checking done.
So there are three basic ways to go about it,
1) Totally static data (in which case anycast and directionality are not a
consideration, at least at the DNS level), which does not preclude doing
things at a higher level.
2) Simple anycast, as in the Directional DNS service Hank mentioned, which
has thoroughly been thrashed into the ground as to why it ain't great,
which it seems Hank already understood.
3) Complex DNS implementations. Such as ones that will actually do active
probes, etc. Possibly combined with 1) even.
I was trying to redirect the dead anycast horse beating back towards a
discussion of the relative merits of 1) vs 3). The largest problems with
3) seem to revolve around the fact that you generally have no idea where
a request /actually/ originated, and you're pinning your hopes on the
client's resolver having some vague proximity to the actual client.
Redirection at a higher level is going to be desirable, but is not always
possible, such as for protocols like NNTP.
I'm happy to be criticized for guiding a conversation back towards being