Subject: draft-ietf-dnsop-v6-name-space-fragmentation-01.txt

From: Mats Dufberg <[email-masked]>
Date: Tue, 19 Mar 2002 06:03:21 +0100 (CET)

The draft suggests that the master server checks that all delegations each
time it loads the zone. The check of the delegations includes making sure
that all nameservers in the delegation is reachable.

It is unrealistic to expect an ordinary TLD to do such frequent checks. A
delegation should be varified each time it is updated, and maybe at other
times. And such checks could preferably use a separate resolver if the
master server does not resolv.

Mats

----------------------------------------------------------------------
Mats Dufberg <[email-masked]>
----------------------------------------------------------------------

---

From: Daniel Senie <[email-masked]>
Date: Tue, 19 Mar 2002 10:33:41 -0500

>master server does not resolv.

Beyond "unrealistic," it would seem this could be quite damaging, and not 
just in the TLD case. Any large organization may have very large number of 
delegations. A flood of packets to verify the function of delegated servers 
represents a serious problem. The time delay to initiate thewe checks at 
service load/reload (and periodic checks thereafter?) may render the 
service unavailable to answer queries.

Might it not be better to think in terms of a separate function (perhaps 
implemented as a separate thread or subprocess of the name service, perhaps 
as a separate entity) which takes a slow, continuous walk around the name 
space looking for and reporting errors? This would eliminate the need to 
make the checks at start-up point, permitting the service to begin and 
continue functioning without being impeded by checks of other systems.

-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

---

From: Robert Elz <[email-masked]>
Date: Wed, 20 Mar 2002 17:10:37 +0700

Date:        Tue, 19 Mar 2002 10:33:41 -0500
    From:        Daniel Senie <[email-masked]>
    Message-ID:  <[email-masked]>

  | A flood of packets to verify the function of delegated servers 
  | represents a serious problem.

Come on, be reasonable.  A server that can't handle the occasional query
from its parent to return the NS/SOA (whatever is needed) for all the
zones it has delegated to it, shouldn't be installed in the first place,
as it certainly isn't going to cope with any real load.

Not that I think having a server do checks on all delegations every time
it loads a zone is rational either - but yours is not the counter argument.

Better is what the server would do with any delegation it is unable to verify,
one way or the other?   If it is going to just drop delegations that aren't
perfect any any random instant, then it just broke one of the DNS assumptions,
which is that servers aren't always there - that's why we have secondary
servers (more than one server for a zone).

If it is going to just ignore the error, then it might just as well have
not bothered checking.   To find completely broken delegations, a check
every zone load isn't needed - just one occasionally.

Attempting to count (and record) how frequently checks fail is way too
much overhead.

  | Might it not be better to think in terms of a separate function (perhaps 
  | implemented as a separate thread or subprocess of the name service, perhaps 
  | as a separate entity) which takes a slow, continuous walk around the name 
  | space looking for and reporting errors?

This is certainly a better approach than expecting a server to verify
delegations when it loads the zone.   It should validate syntax then, no
more than that.

But:

  | This would eliminate the need to 
  | make the checks at start-up point, permitting the service to begin and 
  | continue functioning without being impeded by checks of other systems.

I'm not sure which start-up point you mean.   If you mean when the server is
loading the zone, then I agree.  If you mean when the domain was initially
delegated, I disagree, servers (server operators, someone or something)
should always check delegations before they're made.  That is far and away
the best time to have problems corrected.  That's when the owners of the
domain are actively pursuing the issue, and paying attention to what is
happening.

kre

---

From: Daniel Senie <[email-masked]>
Date: Wed, 20 Mar 2002 10:12:57 -0500

>as it certainly isn't going to cope with any real load.

You miss the point entirely. Surely the child server will be handle the 
load. The packet flood I was speaking of was that leaving the parent, not 
arriving at the child. A server with thousands of children or more will 
generate a great flood of traffic, or else take a very long time, to check 
the function of all subordinate name servers.

What is a server to do in terms of answering queries during the time of 
uncertainty, between reload and when it has heard from, or timed out, on 
checks to all subordinates?

>servers (more than one server for a zone).

Agree. At the most, some alerts may be useful, but to whom do the alerts 
go? The name servers checked are not necessarily managed by the same entity 
as the parent. Does the server try to find out the identity of the 
administrator of the name server that's down and notify them? Seems like 
this isn't the business of the parent server.

>every zone load isn't needed - just one occasionally.

Precisely.

A separate utility which wanders delegations looking for down servers could 
be useful for smaller sites, though I suspect TLDs and other sites with 
large numbers of delegations would only be able to run it rarely.

>delegations when it loads the zone.   It should validate syntax then, no

It may still be useful for a utility to exist which does offer a check of 
the delegated server to see that it really serves the delegation (e.g. 
pulls the SOA record). For sites without too many delegations, this could 
actually be useful functionality.

>loading the zone, then I agree.

I mean at zone or server reload.

>   If you mean when the domain was initially
>should always check delegations before they're made.

Absolutely.

>   That is far and away

Agree. Once the delegation is made and running, the domain owner is the 
party with the most interest in keeping it running, and should bear the 
cost and burden to ensure the delegation remains operational and valid.

Dan

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 20 Mar 2002 16:18:27 +0100

--On Tuesday, March 19, 2002 10:33:41 -0500 Daniel Senie <[email-masked]>
wrote:

> implemented as a separate thread or subprocess of the name service,
> perhaps as a separate entity) which takes a slow, continuous walk around
> the name space looking for and reporting errors? This would eliminate the
> need to make the checks at start-up point, permitting the service to
> begin and continue functioning without being impeded by checks of other
> systems.

I strongly second the separation of serving zones and verifying them; I
would go even further and suggest that one should refrain from specifying
this as a hard requirement, however beneficial this might be (as has been
seen in operational experience) 

One might envision a BCP-style document that outlines some procedures for
verifying large delegation masses -- effectively documenting the procedures
in place at among other some ccTLD management bodies. 
-- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC
                        MN1334-RIPE

---

From: Rob Austein <[email-masked]>
Date: Wed, 20 Mar 2002 14:09:06 -0600

Might I suggest that, since this entire discussion is about a
relatively minor point in Johan's draft (which, if you read carefully,
you will notice Johan is not even suggesting we should do, he's just
trying to show where one line of thinking might lead), it might make
more sense to discuss the main content of the draft, to wit: what the
bleep are we going to do about this fragmentation problem?

For folks who didn't make it to the face-to-face WG meeting yesterday,
here's the straw man I outlined towards the end of the meeting as a
possible strategy.  It'd be nice if we could do better than this, but
that's what we need to discuss.  This straw man does not address all
of the issues in Johan's draft or presentation, but I think that part
of Johan's point is that we are going to have to compromise on some
things because this is a choice among various bad options.  Anyway:

  Start out with all zones (v4 or v6 content) available via v4
  transport.

  Use dual stack resolvers (or forwarders or whatever) in IPv6 land
  until IPv4 is dead.  In latter stages, this probably means tunneling
  IPv4 addresses into IPv6-only clouds for this purpose.

  Eventually this will start to break down.

  Customers who are just in the v6 cloud (lack access to dual stack
  resolver for whatever reason) will start complaining about not being
  able to reach sites (will look like ordinary failures).  V4-based
  servers will push their zones into v6 space as well, if they care,
  if not, perhaps we don't care about them.

  Servers that are just in v6 land will start popping up when v4
  addresses get really hard to obtain.  Clients stuck in v4 land will
  whine to their ISPs, who will install translation boxes or will
  upgrade the customer's software or whatever so that customer is now
  on v6.

  Eventually the number of people remaining in the v4-only cloud will
  not be worth supporting, and will be orphaned.  This will suck, but
  it's what happens with every technology change.  So we live with it.

Johan and I expect to do some work on further detailing the problem.
So please read the above as an attempt to provoke discussion, and
perhaps as a dead-simple model against which others can be measured
(that is: anything that's obviously even worse than this proposal
probably need not be considered).

--Rob

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 20 Mar 2002 23:34:22 +0100

> probably need not be considered).

I think we can summarize this to "we need to surf precisely on top of the
big transition wave, not braking it, perhaps gently speeding it up". 

The path lined out here seems to be -- at a glance -- a viable
"minimal-pain" transition model. The crucial thing is that we need to
embrace the eventual reality of breakage for v4-only systems, as a natural
consequence of progress. After all, who expects a local-battery,
non-rotary-dial 1920's phone[0] to support direct-dial? 

[0] http://www.beredskapstid.org/bilder/originalbilder/falttelefon.jpg

---

From: Mats Dufberg <[email-masked]>
Date: Thu, 21 Mar 2002 03:21:35 +0100 (CET)

>   upgrade the customer's software or whatever so that customer is now

I think we should devide the zones into a few categories:

1. The root zone

2. The TLD zones

3. Special zones such as in-addr.arpa, ip6.arpa, e164.arpa

4. Customer zones

I think that we can say that it is a MUST that 1, 2 and 3 be served under
at least one IPv4 connected namnserver until IPv4 is closed down as part
of Internet.

We should recommend that customers zones (4) be served under IPv4, but I
think it is a misstake to think that customers can rely on free
namesservers.  Free nameserver service has limitations.

Mats

---

From: Måns Nilsson <[email-masked]>
Date: Thu, 21 Mar 2002 04:15:49 +0100

> at least one IPv4 connected namnserver until IPv4 is closed down as part

That would mean until "forever", unless there is a flag day. It might be
smarter and more flexible to devise a traffic sampling scheme to serve as
input to a reoccurring review of the need for v4 service for a given zone.
This also implies that the decision process could be distributed. (the
various cases outlined above would of course be dealt with separately, but
I suspect horisontal decision fragmentation (ie between namn.se and
example.se) would take place as well.)

> namesservers.  Free nameserver service has limitations.

I do not think that we should specify this either. We might advise, but
what people ultimately use for serving their zones is their own problem, as
long as they fulfill the requirements of their mother zone.

---

From: Rob Austein <[email-masked]>
Date: Sun, 24 Mar 2002 13:31:30 -0500

> namesservers.  Free nameserver service has limitations.

Never intended to imply that this would be a free public service.
Presumably it would work out much the same way as DNS service works
out now: some sites would do everything themselves, some would
outsource to a commercial provider, some would beg service from
better-connected friends, some would pool resources to rent better
connected rack space, and some would undoubtedly find some other
approach not listed here.