On Tue, 27 Sep 2005, Hallam-Baker, Phillip wrote:

> 
> > From: Dean Anderson [mailto:dean@av8.com] 
> 
> > It is not DNSSEC that is broken.
> 
> Anycast has been deployed for four years. 

I think it is three years. But it has been controversial from the start.

> Any change to the DNS infrastructure that is incompatible with use of anycast
> is not acceptable and will not be deployed.

I don't think you get to make that demand. Or rather, I don't think you get to
impose that demand.  But Root server operators have to comply with RFC2870.  
RFC2870 does get imposed.

> Anycast significantly improves the response time and the robustness of
> DNS operations and allows operations to be made more scalable and run
> more economically. 

This is not true, either.  But it is yet another Nanog legend. I've analyzed
this in detail previously.  But I'm not going to get into it in detail now.
Here's the short answer:

The following is predicated on BGP anycasting (without PPLB), in which a subset
of clients talk to only one anycast instance.  If you do Lan anycasting, the
analysis is similar, but not exactly the same.

Response time:

Response time is primarily dependent on network latency. This has nothing to do 
with choice of anycast or unicast.

Robustness, scalability:

If you have only 4 servers to configure, then 4 unique IP address better
distribute load than 4 anycast servers on the same IP. Given the same resources,
A DOS against a single IP is more effective than a DOS distributed against 4
IPs.  With unicast servers, all 4 servers have to go down before service is cut
to clients. Nor is anycast more robust for DOS: suppose the DOS is sufficient to
take down 2 servers of 4 anycast. All of clients of those 2 servers with be out
of service. This may not be half of the clients because load isn't evenly
distributed. It may be more than half, or less than half. So, more servers with
unique IP addresses is better.

Does it get better if you take your 4 servers and make 2 IPs with 2 Anycast
each?  No. Because a DOS only has to divide its resources in half, instead of by
fout.  Given our same premise, that they can take out 2 servers, they attack
each anycast server and take out one for each IP. This will affect something
like 25% of the clients with a total outage (but again, not exactly, because
load isn't distributed evenly.

The number of servers in this analysis can be 13, 26, 52, etc.  With fewer than 
13 servers, we can easily have 13 IP addresses. With more than 13 servers, 
people think they have no option but anycast. There are alternatives.

> Core DNS is subject to continuous DDoS attacks. Without anycast there is
> a possibility that at some point in the future it might not be possible
> to support the bandwidth needed to defeat these attacks.

We'll have to deal with that in the future.  

I think it would be better to find a way to allow more than 13 root servers.  
There are several ways to do that: allow an EDNSO or perhaps a truncated
response, or limit authoritive data from the root response. so one would have
more than 13 servers in the nameserver root hints but only 13 in the authoritive
response. As long as the responding server is in the authoritative list, the
resolver and cache should have no problems.  Those caches that overwrite the
in-memory hints with the authoritive response would then be limited to a subset
of only 13 servers. But this isn't a bad thing.  There are a number of things
that can be worked out to have allow more than 13 servers without breaking DNS.

But of course, its also possible to build bigger servers.

Anycast is not the only solution to DDOS attacks.

> The DNS has operated successfully without DNSSEC up to this point. The
> onus is always on those proposing a change to work within the deployed
> infrastructure.

Well, thats one view. There are other views about the operation of DNS up to
this point, with respect to Anycast Extension. Since the Anycast Extension isn't
approved, the onus seems to be on root server operators to use approved
practices.  The deployment of unworkable technology seems to go against the view
of "successfully operated".

> The DNSSEC spec makes several proposals that appear to address the
> packet fragmentation issue. If you think these are inadequate you should
> explain why.

I have explained. You just don't seem to understand.  DNSSEC can't address the
problem. Its at a layer below DNSSEC.  The problem has nothing to do
specifically with DNSSEC in any way that DNS could possibly change.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   




_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf