.ORG problems this evening

: Todd, you don't make the announcement for the anycast address from your
: border.. You do it from within the anycast cluster as a CONDITIONAL
: announcement. IE; you use a specially written BGP daemon that makes the
: announcement when the service is alive and retracts it when it isn't.

Um, I did in fact previously mention running BGP on the "cluster" -- which
was referring directly to the DNS service machines -- and you even responded
to that message. Yes, I do understand. (Ref: One of the things I do for a
living is work on a BGP4 peer implementation written from scratch.)

Doing this requires implementing keepalive handling in the service
monitoring side of the world correctly. Which, obviously, *the entity in
question did not*. Because of this, I can no longer trust them to get it
right "next time" without changing their fundamental design. It's not like
this is all that hard to grasp: the services for a TLD are much more
critical than a 2LD or 3LD and should be given much more thought into
failover handling than just "anycast will do it for us."

The other two of the Big Three gTLDs, and most ccTLDs, allow a client to
attempt queries to geographically diverse DNS servers at any time,
regardless of the BGP table's correctness, in order to allow some additional
level of failover and reliability assessment by the DNS client. Some of
these servers could run anycast, and I wouldn't even know it without looking
deeper. What I can trivially see, though, is where geographically diverse
servers are available on said TLDs, I can get a guarantee that at least two
from each zone's NS group go to different places.

Why is .ORG somehow different and special that I/we should trust a third
party to do the whole operation solely via anycast, where said anycast has
the possibility of becoming a single point of failure?