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

Rodney Joffe rjoffe at centergate.com
Fri Jul 14 02:27:24 UTC 2006


Hey Brad,

Jeroen has already responded to this. But I will step in and expand  
on a couple of items, and then follow up with a response to your next  
note, relating to UltraDNS...

First, I sense a pattern to your comments...

On Jul 12, 2006, at 7:05 PM, Brad Knowles wrote:

> At 8:34 AM -0700 2006-07-12, Rodney Joffe wrote:
>
>>  I believe so. Could you perhaps expand on your belief that a pure  
>> anycast
>>  TLD implementation is evil?
>
> Based solely on the problems I've heard reported by people who have  
> had issues with the domains operated by UltraDNS.  Maybe it was  
> NANOG, or some other list, but I definitely recall some problems  
> being reported that were related to routing issues resulting from  
> the anycast tricks being played, and which should have been  
> resolved if some non-anycast IP addresses were also made available  
> for that same zone.

You're making statements, and when asked to be specific, you cite  
second and third-hand information that you vaguely recall hearing  
somewhere or other as the basis for your initial statement, which was:

>> IIRC, OpenDNS is using anycast routing tricks, right?  Didn't we have
>> a knock-down, drag-out fight a while back over the evil that we've
>> seen happen with other pure-anycast TLD operators?  I mean, I know
>> that some of the root servers are doing anycast, but there are other
>> root servers that are pure unicast, and that should hopefully resolve
>> the routing weirdness issues for them.
>>
>> Or am I mis-remembering things?

At the very least. Never mind, we'll get back to this. Moving on...

>
>>  H'mmm. Perhaps you could explain how using two different AS's  
>> affects
>>  anything at all operationally.
>
> Well, my understanding is that at the core level, routing is done  
> by AS, which is associated with one or more blocks of network  
> addresses. Different subnets could have their routing advertised by  
> being in different ASes, but only if the other networks are willing  
> to carry those advertisements based on the size of the affected  
> network.  This results in an effective limit on the smallest size  
> of subnet that you can advertised differing routes for, which  
> precludes you from taking two machines on the same subnet and yet  
> having different routes for them.

As has now been pointed out to you, ASNs don't work in this way. Nor  
does BGP. In fact, your last statement completely stumps me, mainly  
because of your confusion regarding the use of the word "subnet"  
which we'll get to shortly. However...

>>                                 And what "appear" means in  
>> operational
>>  terms or effect? Please also use 204.74.112.1 and 199.7.66.1 as a
>>  working example, and describe the effects of separate AS's on those
>>  2 addresses. And perhaps how it would differ between 204.74.112.1  
>> and
>>  204.74.113.1?
>
> I can't use those addresses, because the ones that OpenDNS is  
> advertising for their recursive resolvers are 208.67.222.222 and  
> 208.67.220.220.  Try doing pings and traceroutes to these two IP  
> addresses yourself, and see if you get exactly the same route to  
> both, with RTTs in the same ballpart, etc....  That is what happens  
> for me.
>

I'm not sure why you can't use those addresses to explain your  
understanding of the issue. It has nothing to do with traceroute or  
ping, but to follow up on your response:

If OpenDNS announced each /24 from a different AS into the same  
network connections, why/how would that make any difference to their  
path, or latency or route?

Conversely, if you traceroute to 204.74.112.1 and 204.74.113.1, which  
have exactly the same origin AS, are you claiming they would have the  
same path from your cable modem? Would you mind pasting your  
traceroutes to those two ip addresses here?


> If the route is the same, then there is no redundancy which would  
> help guarantee continued service if the routing tables were to get  
> hosed for that one AS.

Could you explain how an *AS* gets hosed in the "routing table"?

>
>>  Also could you define "the same subnet"?
>
> At this level, having precisely the same route between me and them,  
> including the exact same final-but-one hop into the actual network  
> operated by OpenDNS.  Internally, there may be switching or hubbing  
> that is going on that is not externally visible, but that's what  
> I'm seeing.


Ahhhh. I begin to see the light...

 From my location:

rjoffe$ lft 199.7.68.1

Tracing ...........T

Hop LFT trace to pdns3.ultradns.org (199.7.68.1):80/tcp
1  host (216.190.149.1) 1.4ms
2  s9-1-0-1--0.gw02.phnx.eli.net (216.190.149.197) 5.2ms
3  so-4-0-1--0.cr01.phnx.eli.net (207.173.113.141) 51.4ms
4  pos10-0.cr01.lsan.eli.net (207.173.113.105) 12.5ms
5  p9-0.cr02.sntd.eli.net (207.173.114.54) 21.5ms
6  so-0-0-0--0.er02.plal.eli.net (207.173.114.142) 23.0ms
7  ge1-1-0.103-100m.ar2.pao2.gblx.net (208.49.158.141) 30.9ms
8  so2-1-0-2488m.ar1.sjc2.gblx.net (67.17.74.158) 26.5ms
9  66.238.190.2.ptr.us.xo.net (66.238.190.2) 26.0ms
10  [target] pdns3.ultradns.org (199.7.68.1):80 25.7ms

and

rjoffe$ lft 204.74.115.1

Tracing ...........T

Hop LFT trace to pdns6.ultradns.co.uk (204.74.115.1):80/tcp
1   host (216.190.149.1) 2.0ms
2  s9-1-0-1--0.gw02.phnx.eli.net (216.190.149.197) 6.6ms
3  so-4-0-1--0.cr01.phnx.eli.net (207.173.113.141) 8.3ms
4  pos10-0.cr01.lsan.eli.net (207.173.113.105) 12.9ms
5  p9-0.cr02.sntd.eli.net (207.173.114.54) 28.4ms
6  so-0-0-0--0.er02.plal.eli.net (207.173.114.142) 22.6ms
7  ge1-1-0.103-100m.ar2.pao2.gblx.net (208.49.158.141) 23.1ms
8  so2-1-0-2488m.ar1.sjc2.gblx.net (67.17.74.158) 46.1ms
9  66.238.190.2.ptr.us.xo.net (66.238.190.2) 25.8ms
10  [target] pdns6.ultradns.co.uk (204.74.115.1):80 25.3ms

By your definition, technically, 199.7.68.1 and 204.74.115.1 are on  
the same subnet? OK. I think I begin to see where the challenges are.

> If you run example.com, and you want to advertise yourself as a  
> world expert on DNS and DNS services, don't you think that you'd  
> want your own nameservices to be under the same example.com, so  
> that it looks like you're eating your own dog food?

Oh, you mean, like:

rjoffe$ dig vix.com ns

; <<>> DiG 9.2.2 <<>> vix.com ns
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30623
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 7

;; QUESTION SECTION:
;vix.com.                       IN      NS

;; ANSWER SECTION:
vix.com.                697     IN      NS      ns-ext.isc.org.
vix.com.                697     IN      NS      ns.sql1.vix.com.
vix.com.                697     IN      NS      ns.lah1.vix.com.
vix.com.                697     IN      NS      ns1.gnac.com.

or
rjoffe$ dig verisign.net ns

; <<>> DiG 9.2.2 <<>> verisign.net ns
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5505
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3

;; QUESTION SECTION:
;verisign.net.                  IN      NS

;; ANSWER SECTION:
verisign.net.           172271  IN      NS      ns1.crsnic.net.
verisign.net.           172271  IN      NS      bay-w1- 
inf5.verisign.net.
verisign.net.           172271  IN      NS      goldengate-w2- 
inf6.verisign.net.

or

rjoffe$ dig ripe.net ns

; <<>> DiG 9.2.2 <<>> ripe.net ns
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55523
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 10

;; QUESTION SECTION:
;ripe.net.                      IN      NS

;; ANSWER SECTION:
ripe.net.               166666  IN      NS      ns-ext.isc.org.
ripe.net.               166666  IN      NS      ns-pri.ripe.net.
ripe.net.               166666  IN      NS      sec3.apnic.net.
ripe.net.               166666  IN      NS      sunic.sunet.se.
ripe.net.               166666  IN      NS      ns3.nic.fr.


Well, maybe a stretch. I'm not sure that it indicates clue, one way  
or the other.



More information about the dns-operations mailing list