From owner-freebsd-hubs@FreeBSD.ORG Tue Jun 24 10:33:39 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 CD66737B401 for ; Tue, 24 Jun 2003 10:33:39 -0700 (PDT) Received: from electra.cse.Buffalo.EDU (electra.cse.Buffalo.EDU [128.205.32.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98EA443FA3 for ; Tue, 24 Jun 2003 10:33:38 -0700 (PDT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from electra.cse.Buffalo.EDU (kensmith@localhost [127.0.0.1]) h5OHXbbr016265 for ; Tue, 24 Jun 2003 13:33:37 -0400 (EDT) Received: (from kensmith@localhost) by electra.cse.Buffalo.EDU (8.12.9/8.12.9/Submit) id h5OHXbQ8016264 for freebsd-hubs@freebsd.org; Tue, 24 Jun 2003 13:33:37 -0400 (EDT) Date: Tue, 24 Jun 2003 13:33:37 -0400 From: Ken Smith To: freebsd-hubs@freebsd.org Message-ID: <20030624173337.GD11784@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: DRAFT - DNS Admin Guide 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: Tue, 24 Jun 2003 17:33:40 -0000 FreeBSD.org DNS Admin Guide V0.0 ================================ [ed: Stuff that is in square brackets with "ed:" is me asking questions or providing info, it will be ripped out of the end result.] [ed: Question: Someone suggested the current "hostmaster@freebsd.org" setup is meant to help as a SPAM deterrent. If yes how can/should that be factored into what gets proposed? Even if it wasn't, should that issue be considered? ] Executive Summary ----------------- The dnsadm@ staff, who handle the updates to the FreeBSD.org DNS information, need a mechanism to determine when update requests should be done or not. A short list of people who are authorized to make update requests will be created. The people will be selected from the five groups (see list in "Background" section) whose operation relies on DNS. The focus of administration will be based on "function", not based on geographic regions though the layout of the FreeBSD.org namespace will continue to reflect geographic regions (e.g. FTP Mirror Sites will be administered together regardless of what country they are in, though their names will continue to include country codes as part of the name so users can easily find "close" mirrors). Introduction ------------ Guidelines need to be established for determining who can request updates to the DNS Information for FreeBSD.org. The updates themselves can be handled by the staff who currently take care of email sent to "dnsadm@freebsd.org" but they need to have a list of who is allowed to make these update requests. The same list will provide the dnsadm@ staff contacts to forward update requests to when unauthorized requests are sent to the dnsadm@ alias. Background ---------- DNS by its nature is designed to allow delegation of authority. For organizations that are very large this is a good thing but at this time the FreeBSD Organization is not large enough to require much delegation. Having things delegated too much also leads to confusion about who is responsible for what among the people responsible for doing the work, end-users do not know whom to contact for relatively simple things, etc. There are several more or less distinct groups whose function at least partially involves DNS. The groups are: 1) WWW site administrators 2) cvsup site administrators 3) FTP mirror site administrators 4) email system administrators (support for @freebsd.org email) 5) operations support administrators (provide machine(s) for release builds, ports builds, etc). The group who administer the DNS system itself are assumed to be in either (4) or (5) [ed: I'm not sure which, anyone know?]. Each of the groups have varying needs, size, levels of organization, etc. Not all groups will have a "presence" in each piece of the FreeBSD.org namespace so dividing things up based on country codes or that sort of thing is probably not the best approach. Proposed Layout --------------- We propose identifying one [ed: two?] person who is the "Coordinator" of each group listed above. By default this will be the only person who can request DNS updates. To make things simpler for the dnsadm@ staff there will be no explicit rules on what sorts of updates any individual Coordinator is allowed to request - it will be assumed each Coordinator knows enough about DNS to make only the requests appropriate to their group's needs and can be trusted to not act maliciously. These Coordinators may appoint other people who are allowed to request DNS changes but should do so conservatively. Keeping things simple is important. For example if the Mirror System is so large that the Mirror Site Coordinator feels the need to delegate administration of European sites s/he can request a second person be allowed to request DNS changes. Again, unless it becomes necessary, no explicit rules will be set for who is allowed to request specific types of changes under the assumption the people granted permission to make update requests know what they are doing. [ed: I can't decide if requiring PGP signatures is overkill...] People identified as Coordinators need to have usernames in freebsd.org. Messages requesting changes should be PGP signed and, if possible, from their @freebsd.org email address. Messages requesting updates should be sent to "dnsadm@freebsd.org", no matter what piece of the FreeBSD namespace the update is being requested for (see below). FreeBSD Namespace ----------------- The FreeBSD.org namespace is currently divided up by country codes. As with much of the Internet it started off as a United States centric thing so for the most part "*.freebsd.org" is in the United States (there are exceptions...) and "*..freebsd.org" is in the country identified by . For some things this is important because it is meant to help end-users find a resource (e.g. mirror site) that is "close". The namespace will continue to reflect geographic region. Some requests may result in the creation of a new Zone in the FreeBSD Namespace. For example if a brand new FTP Mirror site comes online in a country that, so far, has none its name should be "ftp..freebsd.org". Creation of the new ".freebsd.org" Zone would be viewed as a side-effect of the FTP Mirror Site Coordinator requesting the name be created. The dnsadm@ staff will take care of adding in the new country code and handle the new zone on the existing DNS server infrastructure. At their discretion dnsadm@ may delegate pieces of the namespace and will route update requests to the people responsible for any given namespace. The above mentioned Coordinators need not worry about how this delegation is laid out. There are pieces of the DNS information that can wind up out of sync with reality but will not have a Coordinator. One example is the "responsible party" in the SOA records. The dnsadm@ staff are ultimately responsible for those - if requests for changes in those come in any adjustments will be at the discretion of dnsadm@ staff. Handling of Requests -------------------- Requests sent to dnsadm@ will be checked against a list of people authorized to make requests (the list generated as described above) and the PGP signature will be checked. If the message is valid the requested update will be made. If the request comes from someone not approved to make requests (e.g. a random net user tries to point out an FTP server has gone away) on a best-effort basis the dnsadm@ staff will route the request to the primary Coordinator for the group associated with the information (in this case the Mirror Site Coordinator). All current documentation should be adjusted so that errors get routed to the appropriate Coordinator instead of "hostmaster" or "dnsadm". If SPAM is an issue to be addressed perhaps leave the current documentation in place (saying send updates to "hostmaster@freebsd.org") but adjust the autoresponder email to direct people to the Coordinators instead of dnsadm@. Coordinator Duties ------------------ In addition to just sending in DNS update requests it is suggested that the Coordinators record information about the sites they work with. The information about the individual sites should remain with the Coordinators and not with dnsadm@. The Coordinators are in the best position to decide how many Official sites should be present in the individual Zones, when an individual site is no longer performing satisfactorily, etc. If a Coordinator needs to leave her/his position they should recommend a replacement. At times the same person may be Coordinator of more than one group as listed above (e.g. at times the Cvsup Coordinator may be the same person as the FTP Mirror Site Coordinator) but that will probably fluctuate through time. -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel |