On Tue, 27 Sep 2005, Hallam-Baker, Phillip wrote: > > > From: Dean Anderson [mailto:dean@xxxxxxx] > > > 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf