[dns-operations] No public calendar for the root signing deployment

[Doug Barton]

Stephane Bortzmeyer wrote:
> On Thu, Dec 10, 2009 at 06:48:30PM -0800,
>  Doug Barton <dougb at dougbarton.us> wrote 
>  a message of 47 lines which said:
> 
>> frankly I don't think that putting it on the front page of every
>> major news outlet would really make a measurable dent in "fixing"
>> the problem. IMO the primary value in documentation on this issue
>> will be after the fact, so that we have something to refer people to
>> when their stuff breaks.
> 
> Whether it is useful before the fact (I'm also a skeptic: users often
> don't listen unless they have an actual problem to solve) or just
> after is irrelevant: we should do something.

Yes, we're in agreement on that. I just wanted to cast the thing in an
operational light. :)  I also wanted to point out the irony that even
in our operationally-oriented world where we are pretty much in
agreement that documentation before-the-fact is next to useless, we're
also in agreement that it should have been done anyway.

>> My suggestion on this would be that WE, as (arguably) exemplars of
>> the operator community put something together now.
> 
> OK, and, IMHO,
> <http://labs.ripe.net/content/preparing-k-root-signed-root-zone> is a
> good example (may be we could just refer to it? After all, it was
> written by a root operator.)

I read that document and I think it will be a good "for more
information" link, but IMO it's still too techy-oriented. My feeling
is that if we go past 3 paragraphs we will lose the people who need
the information the most. The outline I have in mind is:

1. The root zone is adding DNSSEC signatures. This is a good thing
because it increases security, blah blah. However this will increase
the size of the response packet to > 512 bytes for most queries. This
may be a problem for you because ...

2. In the early days of DNS UDP responses were limited to 512 bytes or
less, which led authors of various firewall/CPE/etc. softwares to
hard-code that assumption into their gear. You can test whether or not
that's true for you by doing <this>, <this>, or <this>.

3. If you are unable to receive query responses of > 512 bytes you
MUST fix it.

Then we would need a list of "If you have FOO, go <here> to get
instructions on how to fix it" where knowledgeable members of the
community are able to fill in those blanks. It would also be nice if
we could leverage some of the research that's already been done on CPE
equipment that's FUBAR, "If you have any of <these> you'll just have
to get a new one" along with some recommendations on things that
should actually work.

Finally we'd have a list of "additional information," which is where I
think that RIPE page should go.

>> Joe, I'm sorry but I have to hit you with the same stick that I got
>> hit with numerous times when the bullseye was painted on MY chest.
> 
> I agree that "There's no excuse for not having had this documentation
> on line already" but it is probably not Joe's fault.

Having "been there, done that" myself, I am pretty much certain it's
not Joe's fault. And my offer of assistance was sincere BTW. I can
easily envision the situation where lack of bandwidth pushed this
issue down the stack so I'm proposing an equally ICANN-style solution,
throw money at it. :)


Doug

-- 

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/