[dns-operations] Delegation checking (was: Re: Some DNSSEC trivia)

[Paul Vixie]

> > i wish that every registry would do this.  would it help if BIND had either
> > a tool to do this, or a server option to do this in the background?
> 
> My gut reaction is it would help only a little. In my experience the main
> barrier for this isn't a lack of tools. Existing generic checkers are easily
> found. More likely, though, is that something can be written without much
> effort to talk to the registry backend and also implement each TLD's own
> idea of what tests should be performed. That's not very difficult. Throw a
> little perl, python, etc. at the problem.

i suspect that you're speaking from great experience, and that there are zone
administrators (registry or not) with far less experience for whom the tools
are the hardest part.  i envision a toolset written in C using BIND9's libs
that AXFR's the zone periodically, populates a database using ODBC, slowscans
that database, keeping state on number of timeouts/mismatches/etc, and emits
IODEF events toward the local ticket system based on configurable threshold
crossings.  if something like that existed, my belief is, it would get used
almost universally among serious zone administrators, even if many of them are
precluded by policy from suspending/revoking delegations based on the results.

(note, i don't know how to fund this development yet, but knowing what we need
to be working on is a possible first step toward knowing how to pay for it.)

> What made it a serious burden back when I was doing this sort of thing was
> dealing with the mostly confused, occasionally irate, queries from domain
> contacts who had been notified of their zone's `problem'. A registration had
> a zone-contact in addition to a technical-contact but there were many, many
> occasions where email sent to either ended up in some CEO's secretary's
> inbox, with clueless customer support in a technically indifferent bulk
> domain hosting outfit, or with the end customer who would sue me personally
> if anything happened to his website (threats of litigation were an
> occupational hazard).

i think ICANN has to ask the community what it wants here, and that the answers
is likely to be "lame delegations are bad" and "inadequate technical contact
information is bad".  if i'm right about those predictions, then contracts and
RFC's and whatnot can be crafted to allow a massive cleanup of authority DNS
data to be done.  (perhaps we can also place an upper limit on the number of
times a zone's NS RR or a nameserver's A RR can change per day, like, say, 1?)

in other words, don't treat the policies as immutable.  steve crocker's ICANN
SSAC is full of well meaning busibodies with too much time on our hands.  any
well reasoned observations/proposal on this topic would get a fair hearing,
and while it might take a long time before IETF and the ICANN board get solid
recommendations/results to act on, the fact is, we and the internet are going
to get that much older in that time whether we're working on this or not.

> We did a full run two or three times but as the number of delegations grew
> it became infeasible to handle the volume of customer queries with a small
> and already very busy technical team.

so what you need is a level playing field so that your competitors all have
the same burdens and costs, lest you self-penalize by doing the right thing?

> It was policy to run a delegation check when a zone was created and again
> for every subsequent modification. We had to leave it at that. You could
> probably argue that since we did those checks already the level of noise
> created by an unprompted delegation check for our TLD would be at the lower
> end of the scale (since we made sure you got things correct at least once,
> at initial registration). Registries which have never done this sort of
> thing before would probably fare even worse.

what i'm extracting from this thread so far is, we need better tools, and we
need better policies, if we want to start pulling the weeds in the authority
DNS field.  (weeds in this context means flakey/lame delegations.)