Domain object template
- Date: Wed, 11 Jan 1995 09:41:16 +0100
Folks,
Francis has made an update to the old domain object template. A draft
version of his document is attached below. Please comment on this
document, it should preferably be OK'ed at the coming RIPE meeting.
This document is also available as:
ftp://ftp.ripe.net/ripe/drafts/ripe-domain.{txt|ps}
Cheers,
-Marten
RIPE Database Template for Domains
Francis Dupont
Document ID: ripe-049-bis
Obsoletes: ripe-049
ABSTRACT
This paper describes the format and syntax
for the representation for Internet domains and
associated contact persons in the RIPE database.
1. Introduction
RIPE (Reseaux IP Europeens) coordinates TCP/IP networking
for the research community in Europe.
One of the activities of RIPE is to maintain a database of
European IP networks, DNS domains and their contact persons
along with various other kinds of network management infor-
mation. This database content is public information for
agreed Internet operational purposes. This supports
NICs/NOCs all over Europe and beyond to perform their
respective tasks.
This document describes the format and syntax for Internet
domain information and the closely related contact person
information.
Top, first and sensible level domains should be registered
in the RIPE database.
Each object in the database describes a single entity in the
real world. This basic principle means that information
about that entity should only be represented in the
corresponding database object and not be repeated in other
objects.
Objects are described by attributes value pairs, one per
line. Objects are separated by empty lines. An attribute
that consists of multiple lines should have the attribute
name repeated on consecutive lines. The information stored
about domain UKA.DE consists of five objects, one domain
object and four person objects and looks like this:
ripe-049-bis.txt January, 1995
- 2 -
domain: UKA.DE
descr: Universitaet Karlsruhe
descr: Informatik Rechnerabteilung IRA
descr: Am Fasanengarten 5
descr: D-7500 Karlsruhe, FRG
admin-c: Werner Zorn
tech-c: Michael Rotert
tech-c: Klaus Becker
tech-c: Arnold Nipper
nserver: iraun1.IRA.UKA.DE iramu1.IRA.UKA.DE
nserver: unido.Informatik.Uni-Dortmund.DE
sub-dom: ira
dom-net: 129.13.0.0 192.54.104.0
changed: nipper@localhost 910208
source: RIPE
person: Werner Zorn
address: Universitaet Karlsruhe
address: Informatikrechnerabteilung
address: Am Fasanengarten 5
address: D-7500 Karlsruhe
phone: +49 721 608 3981
fax-no: +49 721 699 284
e-mail: zorn@localhost
changed: dfk@localhost 11-Apr-90
source: RIPE
person: Michael Rotert
address: Universitaet Karlsruhe
address: Informatikrechnerabteilung
address: Am Fasanengarten 5
address: D-7500 Karlsruhe
phone: +49 721 608 4221
fax-no: +49 721 699 284
e-mail: rotert@localhost
nic-hdl: MR78
changed: dfk@localhost 11-Apr-90
source: RIPE
person: Klaus Becker
address: Universitaet Karlsruhe
address: Informatikrechnerabteilung
address: Am Fasanengarten 5
address: D-7500 Karlsruhe
phone: +49 721 608 3973
fax-no: +49 721 699 284
e-mail: becker@localhost
changed: dfk@localhost 11-Apr-90
source: RIPE
person: Arnold Nipper
address: Universitaet Karlsruhe
address: Informatikrechnerabteilung
ripe-049-bis.txt January, 1995
- 3 -
address: Am Fasanengarten 5
address: D-7500 Karlsruhe
phone: +49 721 608 4331
fax-no: +49 721 699 284
e-mail: nipper@localhost
nic-hdl: AN45
changed: dfk@localhost 11-Apr-90
source: RIPE
1.1. How to access the Database ?
The database is public information for agreed Internet
operational purposes. It can be accessed via a whois server
on host whois.ripe.net (tcp port 43). The whole database is
also available via anonymous ftp from ftp.ripe.net as file
ripe.db in directory ripe/dbase. There is also a compressed
version of the database available in that same directory, as
well as a version of the database in which the different
objects have been collected in different files. This "split"
version of the database can be found in the subdirectory
split.
1.2. How to submit information to the database ?
Database updates should be sent via electronic mail to
auto-dbm@localhost
Be sure to supply a person object [1] for each contact per-
son mentioned in the network objects. Of course you
need not supply person objects if they are already present
in the database and the information is still correct.
Updates sent in should only contain the objects that need to
be updated. The mail is automatically parsed by software
that cannot intercept any messages that may be in the mail.
If an update needs human intervention, or you have general
questions on the procedures, please refer to ripe-
dbm@localhost.
Currently no special authorisation is needed to create,
modify or delete objects that describe persons or domain
name space. However extensive audit trails of all changes
are being kept.
2. Format and syntax of the domain object
In a short summary below, the attribute column indicates the
name of the attribute inside the object, the second column
indicates whether this attribute is optional or mandatory,
and the third column indicates whether this attribute can
ripe-049-bis.txt January, 1995
- 4 -
appear more than once per object:
attribute optional/mandatory multiple/single
domain: mandatory single
descr: mandatory multiple
admin-c: mandatory multiple
tech-c: mandatory multiple
zone-c: optional multiple
nserver: optional multiple
sub-dom: optional multiple
dom-net: optional multiple
remarks: optional multiple
notify: optional multiple
mnt-by: optional multiple
changed: mandatory multiple
source: mandatory single
Below each of these attributes and their format and syntax
are described in more detail, and examples are given.
domain: The domain attribute contains the fully qualified
domain name without trailing ".". Note that DNS
names are case insensitive. An example:
domain: UKA.DE
Status: mandatory, only one line allowed
descr: The descr attribute consists of a short description
of the organization and location where this domain
is used. The description can have multiple lines.
It need not contain the full postal address as this
is required in the contact person objects (see
further in this document). Free text is allowed.
An example:
descr: Universitaet Karlsruhe
descr: Informatik Rechnerabteilung IRA
Status: mandatory, multiple lines allowed
admin-c: The admin-c attribute contains the name or the NIC
handle of the administrative contact person. This
is someone who will be contacted about administra-
tive things such as domain registration etc. A NIC
handle (if known) is preferred. Please do not use
formal titles like 'Dr', 'Prof' or 'Sir'. Do not
add full stops between names or initials. This
value should be exactly the same as the attribute
in the person object (see further below). More
than one administrative contact person can be
specified, by simply repeating the attribute. An
ripe-049-bis.txt January, 1995
- 5 -
example of both the NIC handle and normal name use:
admin-c: Daniel Karrenberg
or (preferred)
admin-c: DK58
Status: mandatory, multiple lines allowed
tech-c: The tech-c attribute contains the name or the NIC
handle of the technical contact person. This is
someone to be contacted for technical problems such
as (mis)behavior of nameservers on the net etc.
The format and syntax is the same as the admin-c
attribute above.
Status: mandatory, multiple lines allowed
zone-c: The zone-c attribute contains the name of the zone
contact for the domain. This is the person listed
in the SOA record for the domain when the domain is
a zone too (the same argument, not every domains
are zones, applies to nserver attribute). The for-
mat and syntax is the same as the admin-c attribute
above.
Status: optional, multiple lines allowed
nserver: The nserver attribute contains the list of
nameservers for of this domain, primary first. The
format is fully qualified domain name without
trailing "." OR IP Address(es) of the nameserver.
Only one server should be described per line. An
example:
nserver: iraun1.IRA.UKA.DE
Status: optional, multiple lines allowed
sub-dom: The sub-dom attribute contains the list of sub-
domains of the domain. The format is relative
domain name to the domain (in order to keep the
list compact). An example:
sub-dom: ira
Status: optional, multiple lines allowed
dom-net: The dom-net attribute contains the list of IP net-
works in this domain. The format is dotted quad
including trailing 0s, extended formats defined in
[1] for range of IP address space are allowed. An
example:
dom-net: 129.13.0.0 192.54.104.0
ripe-049-bis.txt January, 1995
- 6 -
Status: optional, multiple lines allowed
remarks: The remarks attribute contains any remarks about
this domain that cannot be expressed in any of the
other attributes. Although multiple lines are
allowed, it should be only be used if it provides
extra information to users of the database, and
usage should be kept to a minimum. For format is
like the description attribute free text. An exam-
ple:
remarks: MX record only
Status: optional, multiple lines allowed
notify: The notify attribute contains an email address to
which notifications of changes to this object
should be send. This can be useful if more than one
person manage the same object. A more detailed
description can be found in [2]. The format is one
RFC822 electronic mail address per line. Although
multiple lines are allowed, usage should be kept to
a minimum. An example:
notify: operations@localhost
Status: optional, multiple lines allowed
mnt-by: The maintainer attribute contains a registered
maintainer name. This attribute is used for author-
isation of database update requests. It is
described in more detail in [2]. The format is a
registered maintainer name. An example:
mnt-by: RIPE-DBM
Status: optional, multiple lines allowed
changed: The changed field contains information on who last
changed this object, and when this change was made.
The format is an RFC 822 electronic mail address of
the person who made the change, and the date of
change in YYMMDD format. Multiple lines are allowed
and shows the update history of an object. An exam-
ple:
changed: marten@localhost 940328
Status: mandatory, multiple lines allowed
source: The source contains a source of information. For
the RIPE database, the value should always be
"RIPE". This field is used to combine and exchange
information between various database sources around
ripe-049-bis.txt January, 1995
- 7 -
the world. Fixed value:
source: RIPE
Status: mandatory, only one line allowed, fixed
value
3. References
[1] Lord, A., Terpstra, M., "RIPE Database Template for
Networks and Persons", ripe-119, October 1994.
[2] Karrenberg, D., Terpstra, M., "Authorisation and Notif-
ication of Changes in the RIPE Database", ripe-120,
October 1994.
ripe-049-bis.txt January, 1995
|
you are here: RIPE -> RIPE Maillists > Archives
