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

Jeroen Massar jeroen at unfix.org
Thu Jul 13 07:07:25 UTC 2006


On Wed, 2006-07-12 at 21:05 -0500, 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.

There is no difference between a 'static' IP address or a 'anycasted' IP
address routing wise, except that it might happen that when a SPF
recalculation happens that one suddenly reaches a different box, but
with the same IP address. As such the only difference is that if that
SPF recalc happens during a session you might notice a problem of a
disconnect, but as most of the time DNS is using UDP and otherwise quite
shortlived TCP sessions (way less than 5 mins at least and recalcs are
not that often, at least they should ;) this is not an issue at all.

"Anycast" just means that a certain prefix gets announced from the same
ASN and that there actually might be different physical locations and
boxes behind them.

The only problems reported with the UltraDNS setup was that at a certain
points one of the various clusters got broken. But then you only have 1
broken cluster out of maybe 5 visible ones, see below.

For UltraDNS, then it is easy to figure out which cluster it is:
dig @[UltraDNS Anycast name or ip address] whoareyou.ultradns.net A

Or where you are querying from:
dig @[UltraDNS Anycast name or ip address] whoami.ultradns.net A

You might also be interrested to know that at least .org is served by:
TLD1.ULTRADNS.NET   	A	204.74.112.1
TLD2.ULTRADNS.NET   	A	204.74.113.1
TLD3.ULTRADNS.org   	A	199.7.66.1
TLD4.ULTRADNS.org   	A	199.7.67.1
TLD5.ULTRADNS.INFO  	A	192.100.59.11
TLD6.ULTRADNS.CO.UK 	A	198.133.199.11

According to ISC routeviews;
204.74.112.0/24   AS12008
204.74.113.0/24   AS12008
199.7.66.0/24     AS12008
199.7.67.0/24     AS12008
192.100.59.0/24   AS12008
198.133.199.0/24  AS12008

Thus they are already in different prefixes and looking at the AS paths
and traceroutes most likely they even refer to different clusters.

> >  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. 

The "AS" is only a grouping function, the prefixes still are separate,
thus if 204.74.112.0./24 gets removed the rest is not affected.

Might I suggest you read up at:
http://www.bgpexpert.com/'BGP'-by-Iljitsch-van-Beijnum/

? :)

> 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.

That is why UltraDNS uses /24's, which is the general filter length
used. Which according to some people is silly as they can handle
zillions of routes in their routers *chuckle*

That some other folks have different ideas is their problem, at least
you are not forced to use them.

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 313 bytes
Desc: This is a digitally signed message part
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20060713/df641d01/attachment.sig>


More information about the dns-operations mailing list