RIPE NetNews WG
Internet Draft Daniel Diaz
Document: draft-diaz-nhns-01.txt RIPE NNWG
Expires: February 2002 August 2002
NHNS - Netnews Hierarchy Names System
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Comments should be sent to the author or the RIPE NetNews WG
Mailing list: <netnews-wg@ripe.net>
Abstract
This document is focused on and describes one of the projects
supported and carried out by the RIPE NetNews Working Group. NHNS is
a system and service based on a DNS-like structure that has been
discussed, developed and deployed under the umbrella of the RIPE
NetNews Working Group. This is an update on the draft version
published in October 2000.
D.Diaz Expires - February 2003 [Page 1]
NHNS - Netnews Hierarchy Names System August 2002
Table of Contents
1. Introduction......................................................2
2. Origin and history of NHNS........................................3
3. Technical description.............................................3
3.1 Introduction...............................................3
3.2 Existing SW to support NHNS................................5
3.3 Use of the TXT Resource Record.............................5
3.4 Use of the RP Resource Record..............................6
3.5 Zone file considerations...................................6
3.6 Client tools...............................................6
3.7 DNS updates................................................7
4. Use of the NHNS service by news administrators....................8
5. Pending administrative issues.....................................8
6. Security considerations...........................................9
6.1 Security recommendations...................................9
References...........................................................8
Acknowledgments.....................................................10
Author's Addresses..................................................10
1. Introduction
This document defines the use of the known and regularly used DNS
service as a database to store all the information related to Usenet
(i.e. newsgroups, newsgroup descriptions, newsgroup moderators,
grouplists, hierarchy maintainers, hierarchy descriptions, etc).This
system is called Netnews Hierarchy Names System, hereafter referred
to as "NHNS".
Familiarity with the DNS system [RFC1034, RFC1035] and the New DNS RR
definitions [RFC1183] is assumed.
D.Diaz Expires - February 2003 [Page 2]
NHNS - Netnews Hierarchy Names System August 2002
2. Origin and history of NHNS
NHNS emerged from the RIPE NetNews Working Group (NNWG) around May
1999. The NNWG agreed to create the 'groupsync project' just after
suffering a 'fork-bomb' attack around May 1998(a form of DoS attack
utilising high volume faked control messages) which caused many of
the Usenet core servers to collapse
The initial goal of this project was providing the Usenet community
with a consistent source of information to synchronize their servers
in a secure and reliable way.
Several solutions were proposed but were never deployed, one based on
a perl script collecting information from ftp and http resources and
a second one based on the CVS software. The NHNS approach was
proposed and presented in RIPE-34 (Vienna, May 1998) and received the
support of the NetNews Working Group.
Nowadays netnews server software does much to reduce the
effectiveness of such an attack (i.e. forkbomb attacks) as PGP
processing of control messages is regularly serialized and it is
therefore under control. However the benefits of a system offering
access and coordination of Usenet administrative information, (i.e.
newsgroup names, group lists, maintainers, maintainers PGP keys,
newsgroup moderators) are still useful for administration, control
and reference purposes.
3. Technical description
3.1 Introduction
NHNS is based on the well known and widely used DNS service and has
benefited from community experience with DNS operational issues as
well as existing DNS software implementations.
The hierarchical structure of Usenet group names and moderator
information bears a significant resemblance to the structure of the
DNS hierarchy. Based on this, NHNS maps group names to their
descriptions using TXT resource records. And maps moderators'
addresses using 'RP' resource records.
D.Diaz Expires - February 2003 [Page 3]
NHNS - Netnews Hierarchy Names System August 2002
This approach was first deployed as a private DNS cloud. This cloud
consisted of a fake top level domain called 'usenet.', under which
all existing top level hierarchies (alt.*, comp.*,..., at.*, ch.*,
de.*, es.*,...) were located, as shown in the figure below:
.
/
usenet
/\ \ \
/ \ \ \
/... \ ... \ ... \
ch es alt comp
The structure described above, was supported by a faked root-server
being the primary server for 'usenet.', and some secondary name
servers for the same domain. Around a dozen collaborators
participated in a small pilot, operating primary name servers for
each of the hierarchies involved in addition to providing secondary
name service for the 'usenet.' root zone.
This 'embryo' allowed the testing of the NHNS system in a semi-
production environment as well as aiding the development of a small
set of tools for use in retrieval and application of the data held in
the NHNS system as explained in greater detail later in this
document.
It should be kept in mind that a Usenet groupname represented in DNS
is reversed, (i.e. similar to the representation of an IP address
within the in-addr.arpa DNS tree) thus:
USENET groupname's order: <group>.<category_n-1>.<...>.<tlh>
NHNS groupname's order: <tlh>.<category_1>.<...>.<group>
D.Diaz Expires - February 2003 [Page 4]
NHNS - Netnews Hierarchy Names System August 2002
Following the test phase the fake DNS hierarchy rooted in 'usenet.'
was relocated to an official DNS domain 'usenet.nhns.net.' giving the
current DNS cloud shown below:
.
/
net
/
nhns
/
usenet
/ \ \ \
/... \ ... \ ...... \
ch es alt comp
The two experiences described above have proven the technical
feasibility of the system and the value of the service.
3.2 Existing SW to support NHNS
The NHNS system has been designed to take advantage of the
distributed database provided by the existing DNS system amd service.
Another benefit of this approach being that it uses existing well
proven software, no modification of any DNS sources are required to
make NHNS work (i.e. bind, nsd, djdns, cachedns,... should work just
fine).
3.3 Use of the TXT Resource Record
Format of the 'text' (TXT) resource record is specified in [RFC1183,
section 3.3.14].
TXT records are used in NHNS to map groupnames to their descriptions
as shown below:
news.es. IN TXT "Netnews group mapped in NHNS"
As shown above, the groupname is reversed when represented in DNS.
D.Diaz Expires - February 2003 [Page 5]
NHNS - Netnews Hierarchy Names System August 2002
3.4 Use of the RP Resource Record
Format of the 'Responsible Person' (RP) resource record is specified
in [RFC1183, section 2.2].
RP records are used in NHNS to map groupnames to their moderators' e-
mail addresses as shown in the example below:
news.es.usenet.nhns.net. IN RP es-news@rediris.es "Mod. for es.news"
The 'owner' field is the groupname in reverse order (i.e.
news.es.usenet.nhns.net, representing es.news), the 'MBOX-DNAME'
field is the group's moderator e-mail address in the Usenet's
moderators file format (i.e. the one distributed by Tale). The
'TXT_DNAME' field will normally contain a comment.
3.5 Zone file considerations
In NHNS terminology a DNS zone-file is equivalent to a NetNews
grouplist. A hierarchy name in NHNS is equivalent to a domain name
(i.e. the es.* hierarchy grouplist is equivalent to the
'es.usenet.nhns.net.' DNS zone file data).
3.6 Client tools
An NHNS server may be queried using any of the available DNS client
tools (i.e bind-tools like 'dig', 'named-xfer', 'nslookup', etc).
It should be noted in regard to these tools that while they can be
used to query a nameserver for NHNS information, the information will
be returned according to format of the TXT and RP records, which in
terms of NHNS is reversed. This is shown in [3.3] and [3.4].
The circumstance described lead us to develop adapted tools to handle
the DNS information to sort the groupnames and print them in the
common 'Usenet' order, this set of tools is described below:
D.Diaz Expires - February 2003 [Page 6]
NHNS - Netnews Hierarchy Names System August 2002
nhlookup:
Tool to issue single queries to a given DNS server for NHNS
information.The description of the group and the moderators e-mail
address in case it is a moderated group, will be obtained and sent to
standard output.
nh-xfer:
Tool to obtain a grouplist of a supported hierarchy by performing a
zone-transfer and translating the returned zone data into a common
Usenet grouplist format.
nhtlh:
This tool can be used to obtain the list of authoritative nameservers
for any of the existing TLHs.
newsync:
Used to synchronise the typical configuration files of a news server,
being them, the 'active' and 'newsgroups' files.in an INN server, or
It issues multiple zone-transfers to later process and file
synchronization.
guins:
'guins' is a graphical user interfaced coded in Perl/Tk to provide an
easy use of all the previous tools in a bundle.
All these tools and more information are available at
http://www.nhns.net/
3.7 DNS updates
Thanks to the 'DNS UPDATE' feature, used by some of the existing
NHNS-tools, a hierarchy maintainer is not enforced to set up and
administrate a name server. This task could be delegated to any
collaborator who would administrate the name server itself and would
allow the official maintainer to update records (i.e maintain the
grouplist remotely, ...), in the same way a maintainer sends a
control message nowadays in order to create, delete, or modify a
newsgroup.
D.Diaz Expires - February 2003 [Page 7]
NHNS - Netnews Hierarchy Names System August 2002
4. Use of the NHNS service by news administrators
Right now, netnews server administrators may use the tools available
with the different DNS implementations, like the existing and well-
known bind-tools or the NHNS specific tools developed with the
collaboration of the RIPE Netnews WG.
Administrators obtain many advantages from the NHNS service.
Information such as the following can be obtained through a simple
query:
- Verify correctness of grouplists, active, newsgroups and moderators
files.
- Find the Responsible Person for a given TLH.
- Synchronise a news server by means of a zone-transfer.
- Look for a newsgroup description or moderator in a Usenet TLH.
5. Pending administrative issues
The current Usenet reliance on the regular distribution of
administrative information (e.g. the moderators list posted by David
Lawrence, the control.ctl file maintenance, the maintainer PGP keys,
etc) is somewhat reminiscent of the hosts.txt philosophy which the
DNS system was deployed to replace. The arguments put forward for
this could easily be applied in the case of NHNS.
Since the beginning Usenet hierarchy maintainers have had trusted
authority over their hierarchies and the related administrative data.
Therefore the cooperation of maintainers would be required to
successfully roll out the NHNS service.
As the NHNS service gathers necessary momentum, certain
administrative issues will likely require to be solved by the
respective organizations, like the possible creation of a new gTLD to
support the system and the handing over of control of this to the
appropriate party to control the delegation of the domains therein.
Currently all the NHNS tree exists below the domain usenet.nhns.net.
as a proof of concept, however this may not be appropriate in case
this would become a public-wide service for the mentioned
administrative reasons.
It should be born in mind however that this draft is concerned only
with the technical feasibility of the service and that the above
D.Diaz Expires - February 2003 [Page 8]
NHNS - Netnews Hierarchy Names System August 2002
paragraph is merely a suggestion of possible issues which may be
presented in the course of further development.
6. Security considerations
The NHNS system and service makes use of the existing DNS service and
structure, therefore all security issues related to DNS apply also to
NHNS.
In practice, NHNS server administrators (i.e. nameserver
administrators) must take care of the permissions to update resource
records as well as the permissions to transfer zones. The following
section will try to give some recommendations to a potential NHNS
server administrator in order to secure the server.
6.1 Security recommendations
This section recaps the essential an administrator should know to
secure a NHNS server.
When the first version of this draft was published, only IP filtering
could be done with the existing BIND 8 versions, and this was not a
warranty of security for DNS servers as IP-spoofing was enough to
spoil our server's information, but, since BIND 8.2.3 there's the
possibility to use nice security features like TSIG keys (or TSIG
secrets), to encrypt DNS messages (i.e. secure the communication
between two servers, an updater and a server, etc).
Normally an updater will only deal with one (or not many more)
netnews hierarchy, so only one TSIG key is necessary. This makes TSIG
a suitable feature regarding key management for the purpose of
securing any DNS updates (i.e. updating a newsgroups list).
Nowadays, the Perl Module "Net::DNS: includes methods to support TSIG
and other DNS-Sec features since version 0.21.
D.Diaz Expires - February 2003 [Page 9]
NHNS - Netnews Hierarchy Names System August 2002
References
1 [RFC1183] New DNS RR Definitions. C.F. Everhart, L.A. Mamakos, R.
Ullmann,P.V. Mockapetris. Oct-01-1990.
2 Elmar K. Vins, NHNS server configuration tutorial
http://www.nhns.net/nhns/DOC/nhnstutorial-1.0.txt September 1999.
3 Daniel Diaz, newsync command tutorial
http://www.nhns.net/nhns/DOC/newsync.txt. October 1999.
4 [RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound
Dynamic Updates in the Domain Name System," RFC 2136, ISC &
Bellcore & Cisco & DEC, April 1997.
5 [RFC2137] Secure Domain Name System Dynamic Update. D. Eastlake.
April 1997.
6 [SSU] B. Wellington, "Simple Secure Domain Name System (DNS)
Dynamic Update, " draft-ietf-dnsext-simple-secure-update-01.txt,
Nominum, May 2000.
Acknowledgments
- Juan Garcia (SATEC, S.A): Who is half the inventor of this evil
thing.
- Dave Knight (RIPE NCC): for a wonderful help adapting this text
into English)
- Dave Wilson (HeaNet): for donating the NHNS.NET. domain.
- Jose M. Femenia (& all the UV): for hosting nhns.uv.es. and more.
- Olaf Kolkman (RIPE NCC): for helping to solve the Net::DNS bugs.
- Felix Kugler (SWITCH), Gerhard Winkler (ACONET)for their support.
- All OPS at RIPE NCC for their support.
Author's Addresses
Daniel Diaz Luengo
RIPE NNWG
Singel 258, 1016AB Amsterdam, The Netherlands
Phone: +31 20 535 4444
Email: Daniel.Diaz@ripe.net, Daniel.Diaz@nhns.net
D.Diaz Expires - February 2003 [Page 10]