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

["Casey S. Ajalat" <cajalat@genuity.com>]

I would like to comment on the draft recently submitted.  Let me first say 
that I commend you on drafting such document to formalizing certain 
existing practices.  I do believe that publicizing such methods is a great 
contribution to the net community.  Also, I've read some of the historical 
threads on this document (very interesting) and I'll spare the group from 
re-addressing those :)  Also, I realize that I'm jumping in the tail end of 
discussions that are dating back to 1999 so please only take what I have to 
say as constructive suggestions and through out what you don't like.

comments 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]"

and placing a reference to RFC 1546 in the reference section below.

>   interfaces.  These interfaces may be either two physical interfaces
>   or one physical interface mapped to two logical interfaces.  One of
>   the network interfaces should use the IPv4 shared unicast address
>   associated with the authoritative name server.  The other interface,
>   referred to as the administrative interface below, should use a
>   distinct IPv4 address specific to that host.  The host should
>   respond to DNS queries only on the shared-unicast interface.  In
>   order to provide the most consistent set of responses from the mesh
>   of anycast hosts, it is good practice to limit responses on that
>   interface to zones for which the host is authoritative.

I see that we use the term "shared-unicast" and I saw roughly where that 
direction took place while reading the archives.  I think an already 
established term is "anycast" as seen in RFC 1546.  So instead of 
shared-unicast would it be too much of a problem if we used 
"anycast"?  Afterall, that is what is exactly what we're doing.

>
>1.2 Zone file delivery

[SNIP]

1.3 Synchronization

[SNIP]

>1.4 Server Placement

[SNIP]

>1.5 Routing
>
>   The organization administering the mesh of servers sharing a unicast
>   address must have an autonomous system number and speak BGP to its
>   peers.  To those peers, the organization announces a route to the
>   network containing the shared-unicast address of the name server.
>   The organization's border routers must then deliver the traffic
>   destined for the name server to the nearest instantiation.  Routing

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.

>   to the administrative interfaces for the servers can use the normal
>   routing methods for the administering organization.
>
>   One potential problem with using shared unicast addresses is that
>   routers forwarding traffic to them may have more than one available
>   route, and those routes may, in fact, reach different instances of
>   the shared unicast address.  Because UDP is self-contained, UDP
>   traffic from a single source reaching different instances presents
>   no problem.  TCP traffic, in contrast, may fail or present
>   unworkable performance characteristics in a limited set of
>   circumstances.  For split-destination failures to occur, the router
>   forwarding the traffic must both have equal cost routes to the two
>   different instances and use a load sharing algorithm which does
>   per-packet rather than per-destination load sharing.

This section assumes that an IGP such as OSPF is used.  If BGP is used 
internally then this problem doesn't really happen.  i.e. in OSPF when two 
equal cost paths are presented then the OSPF will load share on a 
per-destination basis.  One needs to go out of their way to configure 
per-packet load balancing.  Though per packet load balancing is not a 
recommended practice for a larger ISP, this can still occur and thus the 
validity of this section.  In BGP, regardless of the cost, BGP will choose 
a "best" path for a given destination and will not load balance.  In OSPF 
or BGP (or ISIS) the routing table will only contain one route while the 
route data base will contain metrics for all possible routes to a given 
anycasted address.  Also, RFC 1546 does go into some of the ramifications 
for using this technique for a state-full protocol (I personally like the 
last sentence in that RFC :)


>   Four things mitigate the severity of this problem.  The first is
>   that UDP is a fairly high proportion of the query traffic to name
>   servers.  The second is that the aim of this proposal is to
>   diversify topological placement; for most users, this means that the
>   coordination of placement will ensure that new instances of a name
>   server will be at a significantly different cost metric from

I don't think the significance of the difference is as important as the 
mere difference.  i.e. two routes to an anycasted address costing 1 and 
1000 respectively have the identical effect with costs of 999 and 
1000.  The arithmetic difference is insignificant.  But the fact that they 
are different is significant.  I believe this is what you might be 
suggesting so maybe changing this sentence around a bit can make the 
point.  i.e. I suggest changing the statement to something such as:

...will ensure that new instances of a name server will be at a different 
cost metric from....

>   existing instances.  Some set of users may end up in the middle, but
>   that should be relatively rare.

Again, this will only occur when OSPF is used (not sure of ISIS).  If BGP 
is used then BGP will just pick a best and always route to that destination 
even if the cost is identical.  There is a difference between a route in 
the route table and the routing data base.

[SNIP]

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.

>
>
>2. Administration

[SNIP]

>6. References
>
>[1] "Selection and Operation of Secondary Name Servers".  R. Elz, R. Bush,
>S Bradner, M. Patton, BCP0016.
>
>[2] "Root Name Server Operational Requirements". R. Bush,
>D. Karrenberg, M. Kosters, R. Plzak, BCP0040.

[3] RFC 1546


>7. Editor's address
>
>    Ted Hardie
>    Equinix, Inc.
>    2450 Bayshore Parkway
>    Mountain View, CA 94043-1107
>    hardie@equinix.com
>    Tel: 1.650.316.6226
>    Fax: 1.650.315.6903

[SNIP]