[dns-operations] Too Open (Was: OpenDNS makes your Internet work better

[Nicholas Suan]

On 7/13/06, John Payne <john at sackheads.org> wrote:
>
> On Jul 13, 2006, at 10:53 PM, Nicholas Suan wrote:
>
> > On 7/13/06, Rodney Joffe <rjoffe at centergate.com> wrote:
> >
> >>> Right, but when the cluster nearest to you is broken and the
> >>> routing table forces all your packets to that IP address to be
> >>> delivered to that cluster, then all zones served by UltraDNS are
> >>> broken, at least as far as you can tell.
> >>
> >> H'mmm. I'm interested in what form of routing foo you're apparently
> >> aware of that would allow packets from you to a specific IP address
> >> to *ever* go to a different location when the "closest" location to
> >> you is broken, but the route still exists. Could you share? And how
> >> that relates to "all zones served by UltraDNS are broken, at least as
> >> far as you can tell"? What do zones have to do with clusters, or
> >> routes?
> >>
> >
> > Who says there's any routing-fu involved? In the root zone, (I use it
> > as an example since some of the nodes are anycasted) if one server
> > times out, it's no problem for a resolver to go and check another
> > instance of the root, which will most likely be located someplace that
> > isn't malfunctioning. This was not the case with UltraDNS, as both IP
> > addresses in the NS records for org. were anycasted.
>
> OK... this is tiring now.  Why do you think things are any different
> now?
>

I never sad I did. I just handn't bothered to look at UltraDNS' setup
at the time of the post, so I couldn't say 'is', lest the current
setup differed from the old one. Now that I've looked into it, 'was'
sill seems appropriate, as there are more than two NS records for org.

> There definately seems to be some confusion here.
>
>  From an _outsiders_ point of view, what appeared to happen is two
> ultradns pods in Virginia had a problem answering queries, but still
> continued advertising their routes.
>
> Now, how is this ANY different to a unicasted pod having problems
> answering queries?
>

As I saw it at the time, it wasn't really an anycast problem, it was
an 'UltraDNS put in only two NS records for in for org.' problem.


> Again, from an outsiders point of view, the problem I saw when the
> now infamous incident occurred was that UltraDNS only had two NS
> records for .org, so recursers only had 2 choices, and so 2 failures
> would have some impact.  This is no longer the case.
>
>

We really don't seem to be disagreeing on anything. Perhaps I should
have been a bit clearer in my last message and said "This was not the
case with UltraDNS, as both IP addresses in the NS records for org.
were being anycasted from places that were unreachable, and there were
only two NS records for the domain."