From owner-freebsd-hubs@FreeBSD.ORG Fri Jun 27 18:53:24 2003 Return-Path: Delivered-To: freebsd-hubs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EED737B401 for ; Fri, 27 Jun 2003 18:53:24 -0700 (PDT) Received: from electra.cse.Buffalo.EDU (electra.cse.Buffalo.EDU [128.205.32.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B46643FD7 for ; Fri, 27 Jun 2003 18:53:23 -0700 (PDT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from electra.cse.Buffalo.EDU (kensmith@localhost [127.0.0.1]) h5S1rMbr019798 for ; Fri, 27 Jun 2003 21:53:22 -0400 (EDT) Received: (from kensmith@localhost) by electra.cse.Buffalo.EDU (8.12.9/8.12.9/Submit) id h5S1rMwv019797 for freebsd-hubs@freebsd.org; Fri, 27 Jun 2003 21:53:22 -0400 (EDT) Date: Fri, 27 Jun 2003 21:53:22 -0400 From: Ken Smith To: freebsd-hubs@freebsd.org Message-ID: <20030628015322.GA19335@electra.cse.Buffalo.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: DNS Admin Attempt #2 X-BeenThere: freebsd-hubs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD Distributions Hubs: mail sup ftp List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2003 01:53:24 -0000 Didn't take me as long to write up as I thought it would... A lot of this is general how-coordination-works and does not need to be sent to dnsadm@ as guidelines on how they operate (that was what Jun said he wanted). But it describes the whole picture and making sure the whole picture makes sense to hubs@ is important... I took my best shot at it based on this week's discussions. Looking on the bright side it can't possibly be worse than my first attempt. :-) As before - minor editing issues straight to me, discussion to the list please. Thanks everyone. DNS Administration Guide V0.1 ============================= Zone Administrators ------------------- The FreeBSD.org DNS namespace will be divided up by Country Code, for example "us.freebsd.org" for the United States. All DNS issues for any zone will be handled by the Administrators for that zone. Addition of new mirror sites, removal of mirror sites, and modification of existing mirror sites are done by these zone administrators. It is the decision of these administrators how many mirror sites are appropriate, etc. Other non-mirror-site information added to the DNS are at the discretion of these administrators. To keep things simple for end-users these administrators must be reachable as "hostmaster@CC.freebsd.org". Delegation ---------- If any given country has a local infrastructure with the interest and ability to handle it the DNS zone for that country can be delegated to them. With the delegation comes responsibility for: - Zone Administrator duties as described above. - DNS server infrastructure. - email support minimally capable of handling the "hostmaster@CC.freebsd.org" requirement. Zones with a small number of Official Mirror Sites and no special local DNS needs are encouraged to not request delegation. Too much delegation may have an impact on overall freebsd.org DNS stability. If the situation warrants it countries can group together in regions and have their DNS/email infrastructure use the same set of servers. At the discretion of the Mirror Site Coordinator (next section) several countries may be administered by one Zone Administrator. The CC.freebsd.org DNS zones for all countries participating in that larger "regional unit" will be delegated to the one Zone Administrator, and the "hostmaster@CC.freebsd.org" email for all those countries should flow to that Zone Administrator. As an example if all of Europe wanted to function as one large region all CC.freebsd.org zones for all the countries involved could be delegated to one Zone Administrator. This sort of situation is not expected, the preferred setup would be for the zones to not be delegated. But if the participants felt a strong enough need to form a larger region like this it would at least be considered. n Mirror Site Coordinator ----------------------- The Mirror Site Coordinator will be: 1)it is best if s/he is a Zone Administrator of a delegated zone (e.g. us.freebsd.org) 2)handle Zone Administrator duties as described above for their zone plus all zones that are not delegated 3)handle general coordination of the entire Mirror system, including the mirror systems in the TLD The reason for (1) is that they should have all the support to be Mirror Coordinator if they are functioning in this role. DNS updates for non-delegated zones will be handled by sending the request to dnsadm@ and that communication channel should be well established for someone handling a delegated zone already. The request email flow (hostmaster@CC.freebsd.org) for the non-delegated zones can follow the exact same pathway as the email for their delegated zone (e.g. it is a simple email configuration to have email sent to "hostmaster@us.freebsd.org" follow the exact same path as "hostmaster@hr.freebsd.org" and reach the correct person(s)). And, as importantly, incoming requests for delegation will be handled by this person. Functioning in this role already themselves they can better evaluate the need for delegation, the ability of the requestors to handle it, and help make the transition as smooth as possible. Note that the us.freebsd.org system above is an example. It could just as easily be jp.freebsd.org. If the Mirror Site Coordinator duties need to move from the person who takes care of us.freebsd.org to the person who takes care of jp.freebsd.org the transition should be relatively easy to accomplish - it is just DNS reconfigurations. The change should be transparent to end users, no documentation changes required, etc. In addition to handling requests as above the Mirror Site Coordinator will be responsible for handling: - requests that arrive on hubs@ (described in next section) - keeping current list of all mirror sites so they can be provided to re@ at Release Time, Web documentation can be kept up to date, and /stand/sysinstall can be adjusted - maintain lists of mirror sites in the TLD, presumably consulting with others who can advise - handle fallout if a delegated zone falls apart Flow of Request Email --------------------- The documentation tells users to send email to "hostmaster@CC.freebsd.org" when making mirror site offers. The cases are: - CC.freebsd.org is delegated, those Zone Administrators handle the request themselves sending a note to the Mirror Site Coordinator if it results in a change so documentation can be kept up to date. - CC.freebsd.org is not delegated, email will wind up going to Mirror Site Coordinator. S/he decides if another mirror site is warranted, guides them through becoming a mirror (requests they be added to a master site's ACL's, etc) and then sends request to dnsadm@ if this is a site addition. If it's a complaint investigate and deal with it. Documentation says if sending email to "hostmaster@CC.freebsd.org" yields no results or if CC.freebsd.org does not exist yet send email to hubs@. Mirror System Coordinator handles all DNS related email on hubs@. - If CC.freebsd.org is delegated forward the request to "hostmaster@CC.freebsd.org" and Zone Administrators should keep Mirror Site Coordinator in cc of messages. User was probably mistaken sending to hubs@ but this could be a case of a delegated zone falling apart, deal with it if yes. - If CC.freebsd.org is not delegated or does not exist handle just like any other request Mirror Site Coordinator would handle. If new CC-based zone is a result adjust DNS/email so "hostmaster@CC.freebsd.org" will work for new zone (typically don't offer delegation at this point). If dnsadm@ ever receives email related to mirror sites they can bounce it to Mirror Site Coordinator who will handle as above. Email Security -------------- All DNS requests should be made with PGP signed email. Zone Administrators should obtain PGP keys from the site contacts (note Mirror Site Coordinator functions as a Zone Administrator). Site contacts may only request changes for their site. Zone Administrators have direct control over the DNS for their zone and no email communication is required. Mirror Site Coordinator maintains PGP signatures for all Zone Administrators and shares that with dnsadm@. The vast majority of communication with dnsadm@ will be from Mirror Site Coordinator. -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel |