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

[Daniel Senie <dts@senie.com>]

At 05:10 AM 3/20/02, Robert Elz wrote:
>     Date:        Tue, 19 Mar 2002 10:33:41 -0500
>     From:        Daniel Senie <dts@senie.com>
>     Message-ID:  <5.1.0.14.2.20020319101724.00a368b0@mail.amaranth.net>
>
>   | 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.

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?


>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).

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.


>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.

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.


>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.

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.


>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.

I mean at zone or server reload.

>   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.

Absolutely.

>   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.

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
-----------------------------------------------------------------
Daniel Senie                                        dts@senie.com
Amaranth Networks Inc.                    http://www.amaranth.com