DNS Stuff Proposal

Daniel Lang dl at leo.org
Thu Jun 26 04:11:30 PDT 2003


Hi,

lots of stuff to read, I may have overlooked the details, but anyway
I want to suggest something. My suggestion will also be a lot to
read (much more than I intended, but still I ask you, to take
a look at it).

Foreword:

I agree with Oli, that the present system does not work so bad.
I also agree with Ken, that there are things, that could be
improved, notably in the cases, where no delegation exists, yet.
Further, I guess everyone agrees, that the system should not be
too complex.

So here's my proposal:

============================================================

In general things remain mostly, as they are and work well.

Responsibilities and Delegation
-------------------------------

1. Case: Where delegation exists, the admins maintaining the
   the delegation are responsible for anything under their
   domain. All complaints and problems concerning services
   within this domain, should be handled withing this domain.
   By means that the maintainers of this domain decide.

   Example: uk.freebsd.org is delegated to some people, including
            Joe. They are responsible for any request that concerns
            UK. The contact address is <hostmaster at uk.freebsd.org>.
			  
   This is conform with the present system as documented in the hubs
   article.

2. Case: No delegation exists, but is requested:

  a) The requesting admin of the new site is willing to
     take responsibility and have the zone delegated, assuming
     all required responsibilties.

     In this case, the request is passed to some Mirror/DNS
     coordinator, i.e. the person Ken called "Chris".
     "Chris" evaluates the request and the requesting party,
     granting or denying the request.

     The contact address for this request should be something
     obvious and easy. It could be <dnsadm at freebsd.org>, 
     <hostmaster at freebsd.org> or if you want to avoid
     to hassle this team, put something up front:
     <mirror-coordinator at freebsd.org> (beeing "Chris").

     If granted, the new site gets the delegation, and becomes
     case 1.

     Example: Admins in Croatia offer a new site and are willing
              and able to take zone responsiblity.
              "Chris" approves and <dnsadm at freebsd.org> delegates
              the zone hr.freebsd.org once to the Croatian folks.
              The future contact for Croatia is
              <hostmaster at hr.freebsd.org>.

  b) The requesting admin is NOT willing to take responsiblity
     OR, the delegation request was denied by "Chris".

     "Chris" then decides the following:

     i) the site is still worth adding, but delegation cannot
        be put into the hands of the requesting party.
        =>
        The delegation still takes place and the zone is created,
        BUT it is maintained by <dnsadm at freebsd.org>. 
        So, the zone is created and delegated, but to
        the <dnsadm at freebsd.org> people themselves.
        The contact address for this new zone will be 
        <hostmaster at newzone.freebsd.org>.

        This makes it transparent, if the zone can be transferred
        to some admins in that country, if they are available.
        Of course, the <dnsadm at freebsd.org> folks, would have to be
        willing to carry and maintain the zone.

		It avoids confusion, because the general rule, that
		<hostmaster at cc.freebsd.org> as documented in the hubs
		article, does still apply.

        This is a fallback solution, and I don't expect too many
        cases like that.

        Example: Crotian admins want to have an official ftp mirror, 
                 but are not willing or not able to assume responsibilty
                 for the zone, but "Chris" thinks it's still worth.
                 The zone hr.freebsd.org is created but maintained by
                 the dnsadm-team, still the contact address will be
                 <hostmaster at hr.freebsd.org>, which will reach some
                 member(s) from the <dnsadm at freebsd.org> team.
                 They will add an entry for the requested server.
    
    ii) "Chris" decides, it's not worth the trouble, and the
        request is finally rejected. (No example).

3. Delegation exists, but the current maintainers of the zone
   are unable to continue their contribution.

   a) Within the existing zone, there are other maintainers, that
      can take over. They can apply to "Chris" for the job, or
      the current maintainers can suggest them to "Chris".

      If "Chris" approves, the delegation is transferred to the
      new admins.

      Example: Joe can no longer maintain uk.freebsd.org, but
               Brian is willing and able. Joe suggest Brian
               (or Brian suggest himself). "Chris" talks to Brian,
               and thinks thats a good solution.
               <dnsadm at freebsd.org> transfer the delegation from Joe's
               nameserver to Brian's.
			   <hostmaster at uk.freebsd.org> remains valid, but
			   reaches now Brian instead of Joe.
        
   b) No one can take over the zone maintenance.
      GOTO 2.b)  :-))

      It's really the same here as in 2.b) now. Either the site is
      dropped, or the delegation goes back to <dnsadm at freebsd.org>
      but with the <hostmaster at uk.freebsd.org> (uk as an example here)
      contact address remaining valid.
      Extra Goodies that have been provided by Joe, may be dropped
      most likely, but that's inevitable.

4. Delegation exists, but the admins are unresponsive, there
   are problems, and site admins within the zone are unhappy
   with how current <hostmaster at cc.freebsd.org> handles their
   requests.

   In this case, "Chris" needs to decide, if this becomes case 3.
   or remains case 1.

So far how to handle and delegate requests. This proposal should
solve most issues brought up by Ken, while still maintaining
best current practice (where it works) and beeing transparent
enough to avoid confusion.

Drawbacks: * Some person or team must be willing to assume the role
             of "Chris", which is a very responsible role.
		   * The <dnsadm at freebsd.org> team may need to take care of
		     additional zones (but only in some cases), still this
			 will result in more work, than just right now.


Authorisation and Authentication
--------------------------------

This issue has been addressed above only indirectly.
Of course "Chris" evaluates and approves or denies 
requests, so he/she has to power of authorization.

But to simplify things, the following could be
established. 

For each delegation an OpenPGP conform key-pair should
be created, that is used to sign any further requests to
"Chris" or <dnsadm at freebsd.org>.
A signed request can much quicker be decided.

"Chris" will have to build a directory with at least the following
content:

<zone>, <admins of that zone>, <OpenPGP public key of that admin team>

Example(!):

uk.freebsd.org:   FreeBSD UK Admins <hostmaster at uk.freebsd.org>
                  Joseph Karthauser <joe at freebsd.org>
				  Brian Somers <brian at awfulhak.org>

Approved public key: .......
Fingerprint        : .......
[..]

----------

Additionally "Chris" can also maintain a list of responsible people
for individual sites, but it may not necessarily be maintained
that accurate. Like

<site>, <admins of that site>, <OpenPGP key of that admins>

Example(!):

ftp7.de.freebsd.org, Oliver Fromme <olli at lurza.secnetix.de>, PGP key ....
[..]

--------

Of course the sites in a zone, that is not really delegated, but
maintained by the <dnsadm> team, should at least be accurate in the
site-maintainer's list.

So much for authorization and keeping track of current admins.

Discussion media
----------------

The default channel to handle any requests, questions or problems
with FreeBSD sites, should be the <hubs at freebsd.org> list,
"Chris" should be subscribed to this list.

Additionally, local zone administrators can set up local lists
to handle and discuss requests, problems, etc within a zone. Example:

<de-bsd-hubs at de.freebsd.org>

------------------


Ok, thanks for reading this so far. A soon as some proposal
(like this) has been approved by you hub admins and the FreeBSD
folks, we can put it (or the parts, that have passed)
in another article to be published. That makes it easier
for us all to implement anything, that we agree upon.

Best regards,
 Daniel
-- 
IRCnet: Mr-Spock     - Cool people don't move, they just hang around. -  
Daniel Lang * dl at leo.org * ++49 89 289 18532  * http://www.leo.org/~dl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6020 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hubs/attachments/20030626/847ffb02/smime.bin


More information about the freebsd-hubs mailing list