Date: Wed, 25 Jun 2003 20:29:23 -0400 From: Ken Smith <kensmith@cse.Buffalo.EDU> To: freebsd-hubs@freebsd.org Subject: Re: DRAFT - DNS Admin Guide Message-ID: <20030626002923.GA23194@electra.cse.Buffalo.EDU> In-Reply-To: <7m7k7b564w.wl@black.imgsrc.co.jp> References: <20030624173337.GD11784@electra.cse.Buffalo.EDU> <7m7k7b564w.wl@black.imgsrc.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
Since I seem to be in "Fully explain" mode...
On Wed, Jun 25, 2003 at 09:54:07AM +0900, Jun Kuriyama wrote:
> I like Kris's suggestion, but I don't think we need a bottle neck such
> as coordinator as above.
I'm not against that in principal, just the cost/benefit ratio.
> The idea in my mind is to create "name vs email" table to identify
> who is authoritative of this DNS name. Like:
>
> ftp-master.FreeBSD.org peter@FreeBSD.org
> kuriyama@FreeBSD.org
> cvsup-master.FreeBSD.org kuriyama@FreeBSD.org
> ftp.FreeBSD.org foo@example.net
> bar@example.com
> ftp2.FreeBSD.org blah@example.org
>
> and, create a collection of PGP public keys of above contactee.
>
> If we can prepare this table, dnsadm@ can easily identify the signed
> request is authorized or not.
I had thought about Kris's message too. The problem I saw with it
came up when I tried to think about what valid DNS related requests
would originate at a site *after* it has been recognized and added
to the above table. You probably know of others that I'm not aware
of but the only three I could think of were:
1) "I needed to change my site's hostname/IP address, please
update your info for that."
2) "I don't want to be a FreeBSD site any more."
3) Please change our site contact info from "fred@foo.bar"
to "barney@foo.bar" because Fred quit and we hired Barney
to replace him.
That was all I could think of. Anything else would be originating from
someone else. Again - I'm probably wrong about this out of ignorance but
I need help with learning what other sorts of requests come from the sites
themselves.
My guess was that there are very few of (1). If (2) came along the
help of the Mirror Site Coordinator would be desirable in deciding
what to do about the problem. (3), at the dnsadm@ level, is only
needed because we need to build and maintain this big table. My guess
was the number of (3)'s would exceed the number of (1)'s, *and* the
Mirror Site Coordinator should be aware of (3)'s as well.
--
Ken Smith
- From there to here, from here to | kensmith@cse.buffalo.edu
there, funny things are everywhere. |
- Theodore Geisel |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030626002923.GA23194>