Date: Tue, 24 Jun 2003 13:33:37 -0400 From: Ken Smith <kensmith@cse.Buffalo.EDU> To: freebsd-hubs@freebsd.org Subject: DRAFT - DNS Admin Guide Message-ID: <20030624173337.GD11784@electra.cse.Buffalo.EDU>
next in thread | raw e-mail | index | archive | help
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 "*.<country-code>.freebsd.org" is in the
country identified by <country-code>. 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.<country-code>.freebsd.org". Creation of the new
"<country-code>.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 |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030624173337.GD11784>