Subject: [RRG] DNS down vs Network down

From: Randall Atkinson <[email-masked]>
Date: Fri, 22 Feb 2008 08:03:38 -0800

Earlier, William Herrin wrote:
% And, it also presupposes that DNS servers/resolvers
% for root, TLDs (especially arpa), and reachable destinations,
% will be available 100% of the time.

This raises a separate point which maybe is worth repeating.

The overwhelming majority of users/deployments today are unable
to distinguish "DNS service unavailable" from "network down".

I first learned this while working in network engineering for a
multi-continent residential broadband ISP in the latter half of
the 1990s.  It has been reinforced repeatedly since then when
I talk with network engineering/operations folks at various
other ISPs around the globe.

Just to be clear, those ISP folks consistently say that this user
inability to distinguish "network down" from "DNS service
unavailable" applies to all sorts of users: residential,
commercial, enterprise, academic/educational, government,
military, and everyone else.

So, for the overwhelming majority of users today, a DNS fault
is viewed as being identical to a hard network fault (such as
a fibre cut or power failure).

I think this means that being more explicitly reliant on DNS
service availability now, versus 20 years ago, is widely acceptable.

Cheers,

Ran

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: [email-masked] (Noel Chiappa)
Date: Fri, 22 Feb 2008 11:16:43 -0500 (EST)

> From: Randall Atkinson <[email-masked]>

    > The overwhelming majority of users/deployments today are unable to
    > distinguish "DNS service unavailable" from "network down".
    > ...
    > I think this means that being more explicitly reliant on DNS service
    > availability now, versus 20 years ago, is widely acceptable.

True, and a good point, but... We do need to distingiush between "a member of
the set of things required to be operational in order for normal users to be
able to do stuff" and "a dependency loop which could prevent network
engineering personnel from repairing a fault" - the latter set should be
empty!

	Noel

---

From: Dow Street <[email-masked]>
Date: Fri, 22 Feb 2008 10:05:19 -0800

> engineering personnel from repairing a fault" - the latter set  

It may be that DNS itself (at least, the human readable part) becomes  
less important to end users in the future.  The point of indirection  
between namespaces, and the corresponding lookup service, is no doubt  
useful.  However, there seems to be new human-friendly names emerging  
that end users prefer over direct DNS interaction (e.g. links in  
search engine results, bookmarks in browsers, etc).  These names may  
or may not bypass DNS.  Perhaps in the future folks will be unable to  
distinguish between "network down" and "favorite web portal down" -  
especially if most of their services are part of said portal.  Or  
maybe something like "skype works, but i can't get my mail".

Given this, how are we scoping the "routing" part of the problem?  Or  
perhaps, what is the nature of the service provided by the routing  
system (where failure of this service defines a fault)?  For example,  
given a sender knows of "some" name for the destination, and there  
exists a viable hop-by-hop router path between these endpoints, is it  
acceptable for delivery of packets along that path to depend on a box/ 
service that is off-path and perhaps unreachable?  If the delivery  
requires mapping one name to another, must this mapping mechanism  
reside along the path (i.e. basically become part of the routing  
system)?  If so, this would seem to make it easier to compare the  
complexity of different routing approaches.  Otherwise, the service  
provided by the various approaches is probably different.

R,
Dow

---

From: "William Herrin" <[email-masked]>
Date: Fri, 22 Feb 2008 18:28:17 -0500

>  engineering personnel from repairing a fault" - the latter set should be

Hi Noel,

I concur. Have you spotted anything in TRRP that concerns you in this
respect? I have endeavored to identify and remove dependency loops but
I may yet have missed something.

Regards,
Bill Herrin

-- 
William D. Herrin [email-masked] [email-masked]
3005 Crane Dr. Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004