Re: draft-ietf-dnsop-hardie-shared-root-server-04.txt

[hardie@equinix.com]

Casey,
	Thanks for your message; thanks as well for your thorough
reading of the archives on this topic.  I've responded inline below.

> At 10:01 PM 3/26/2001, IETF Mail Server wrote:
> >1. Architecture
> >
> >1.1 Server Requirements
> >
> >   Operators of authoritative name servers may wish to refer to [1] and
> >   [2] for general guidance on appropriate practice for authoritative
> >   name servers.  In addition to proper configuration as a standard
> >   authoritative name server, each of the hosts participating in a
> >   shared-unicast system should be configured with two network
> 
> I would like to suggest referencing RFC 1546 which addresses in great 
> detail the use of anycasting.  RFC 1546 does not in anyway suggest use of 
> anycasting for DNS.  Searching through the archives I didn't see any 
> reference in any discussion on RFC 1546 and how it directly relates to this 
> draft.  This draft does address a specific use of anycast and thus not 
> conflict with anything RFC 1546 suggests but rather a way to capitalize on 
> anycasting.  Therefore, I would recommend amending
> 
> "shared-unicast system"
> 
> to
> 
> "anycasted DNS resolvers [3]"

I agree that there is enough relevant overlap between the current doc
and RFC1546 that there should be a connection made for the reader; I
will add a reference to 1546 to the document to handle that and a note
using the term "anycast" so that the doc will come up on appropriate
searches.  I believe, however, that the architectural differences
between 1546 and current practice are important enough not to adopt it
as too close an ancestor.  In particular, the IRTF's conclusion about
anycast address space does not match the use discussed in this
document; its discussion of the routing issues also sees the problem
space in a very different light.  I personally would prefer to keep
the term "shared-unicast" as a way of signalling that this practice
does rely on or deliver a full anycast system.

> I would like to suggest including a section on routing methods.  You 
> mention in this last sentence that it is up to the organization to route 
> the traffic in an appropriate manner to the anycasted address.  Use of 
> anycast for DNS is not new.  I know that several large organization 
> including my own (Genuity) have been using this technique for years 
> now.  But what hasn't been addressed is the method for doing so and the 
> advantages/disadvantages experienced as a result of the chosen method.  If 
> we go into detail in section 1.3 to address good practice techniques for 
> synchronization of DNS servers then it would make perfect sense to go into 
> the same level of detail for "routing" approprirately within the AS for the 
> anycasted addresses.  I therefore suggest adding sections 1.5.1 and 1.5.2 
> below.

The working group certainly recognized that using this system for DNS
is not new, and I appreciate your sharing your operational experience
with the working group.  I am reluctant, however, to include a section
on routing methods in this document.  My presumption, and I believe that
of the group, is that this can be made to work with several different
flavors of IGP, and that organizations would not be making choices
about IGP on this basis.  We did want to acknowledge the possibility
of problems with tcp flows, but I don't think it is within the
scope of this document to drill much further down on that set
of problems.

> I recommend adding the following sections:
> 
> 1.5.1 Static Routing
>    Each upstream router from each of the anycasted servers can announce a 
> static route that is redistributed within the AS's routing tables as a more 
> specific route (potentially a host route).  However, failures of the server 
> must be reflected into the network by constantly monitoring the server and 
> acting upon server failure in either a manual method or an automated 
> method.  Inherent DNS query timeouts will force a requester to query the 
> secondary authoritative unless a method is implemented for removing the 
> specific route from the failed server upstream router.
> 
> 1.5.2 Dynamic Routing
>    A method that implements a dynamic routing protocol between the unique 
> address of the DNS server and its upstream offers a significantly more 
> resilient method to remedy the failure scenario in 1.5.1.  Typically an 
> anycasted server participates in an IGP or EGP routing process such that 
> directly connected routes (i.e. virtual interfaces or second interfaces) 
> are announced to the neighboring router; in this case the anycasted address 
> is announced by the DNS server through a participating routing process 
> (i.e. gated for instance).  Upon failures of the DNS process a simple 
> removal of the announcement from the anycasted server forces a routing 
> update to eliminate a route from the IGP/EGP.
> 

In discussions of the IPv6 work on anycasting services, Bernard Aboba
made similar comments, and it is clear that the document would benefit
from additional language here.  Essentially, this document presumes
that the usual DNS failover methods are the only ones used to ensure
reachability of the data for clients.  It does not advise that the
routes be withdrawn in the case of failure; it advises instead the the
DNS process shutdown so that servers on other addresses are queried.
There is a trade-off here between performance and operational
complexity.  Clearly, it is far more complex to keep a gated/zebra
instance running on the DNS server to do direct announcements and
withdrawals than to do external monitoring.  Equally clearly, it is
far easier to simply allow failures to be resolved at as DNS failovers
rather than implement either.  That is this document's presumption.
It should be made clear that it is a presumption and that there are
other possibilities, but I would not like to change that presumption
without consensus on a clear operational benefit to taking that
side of the trade.

Thanks again for your comments.  I will wait a week or so for further
input, then re-issue the document to incorporate them.
			regards,
				Ted Hardie