orm@doc-tcpip.org

Erstellt: November 1999 - Letzte Modifikation: Oktober 2001

[ Main | Local ]

Konfiguration des named
Der Zusammenhang von named, BIND und Resolvern
Die Datenfiles - Alles, was der Server wissen muß
Syntax und Begriffe
Die Daten über eine Adresse oder Hostnamen
Die Klassen der RRs
Resource Record Typen
Subdomains und Delegation
Subdomänen
Delegation
Classless Reverse Delegation
Ein Beispiel

Der Zusammenhang von named, BIND und Resolvern

Ist eigentlich ganz simpel: Der named, also der name-Deamon, ist der Service/Deamon, der die netzweite Namensauflösung sicherstellt. Dieser Deamon sitzt auf dem "well known" Port 53 und gibt auf Anfragen aus den in seinen Datenfiles oder in seinem Cache befindlichen Informationen antwort.
Für den Austausch von Zonen-Daten gibt es ein Programm namens named-xfer, das im Zusammenspiel mit dem named die Zonen zwischen den Servern synchron hält.

Eine von vielen, allerdings die verbreitetste Software/Implementation, die diese Services bietet, ist BIND (Berkely Internet Name Deamon). Davon gibt es 3 verschiedene Releases:
bind4 - die "normale" Version. Mit letzten Patches sicher.
bind8 - eine deutlich erweiterte Version, die neue Features in Punkto Sicherheit, Konfiguration und Datentypen (SRV-Records) zuläßt. Unterscheidet sich von der Architektur und der Konfiguration deutlich von der Version 4.
bind 9 - ein kompletter Rewrite des Bind. Baut auf bind8 auf.

Es gibt eine Reihe anderer Software, die aber fast immer Beschränkungen aufweist. Ausserdem kenne ich diese Programme nur sehr schlecht ;-).

Das war jetzt die Serverseite. Auf der Client-Seite sind einige Routinen nötig, die es einem Client ermöglichen, mit dem Server zu sprechen und die Information richtig zu interpretieren. Das ist der sogenannte Resolver, der z.B. mit dem BIND mitkommt und seperat installiert werden kann (es sind ein Satz von Bibliotheken (Libaries)).

Also: DNS ist das Protokoll, named und named-xfer (sowie ns_update) sind die Deamons/Services auf der Serverseite, während der Resolver auf der Clientseite die Anfragen stellt und die Antworten interpretiert. Ein Softwarepaket, was all das implementiert, ist eine beliebige Version von BIND - neben anderen.

Die Datenfiles - Alles, was der Server wissen muß

DNS ist ein hierachisches System, das den gesamten Raum in Domänen einteilt. Die alles umfassende, oberste Domäne ist die Root-Domäne. Für eine solche Domäne existiert mindestens ein Server, der entweder die einzelnen Hosts direkt auflösen kann, oder der über die weitere einteilung der Domäne bescheid weiss. Der Server, der die wirklichen Daten, also die Zuordnung Hostname - IP Adresse hat und managed, ist authoritative für diesen Bereich.
Die Daten eine Domäne sind im Regelfall in sogenannte Zonen unterteilt. Diese Zonen reflektieren logische, administrative oder zur besseren Wartung gebildete Teile des Namensraumes. Eine Zone ist die eigentliche Einheit, für die man verantwortlich, authoritative, sein kann. Das ist ein sehr wichtiges Konzept, und der Zusammenhang von Zone und Domäne muß klar sein: Eine Domäne ist etwas, worauf man von außen zeigen kann, während eine Zone eine klar begrenzte Untermenge darstellt, deren Verantwortung beliebig delegiert werden kann.

In einer beliebigen Domäne gibt es also viele Zonen, für die jeweils ein Server voll verantwortlich ist. Nach aussen ist mindestens ein Server sichtbar, der über die Aufteilung bescheid weiss und so Anfragen weiterleiten kann. Nach unten kann man die Verantwortung einer Zone auf beliebig viele Schultern verteilen, also neue Zonen bilden - das ist nach oben transparent und die Domäne wird davon nicht beeinflußt.

Welche Informationen müssen jetzt vorliegen?
Einmal eine Liste mit Servern, an die man sich wenden kann, wenn man auf eine Anfrage überhaupt keine Antwort weiss. Das sind Verweise auf die Server der Root-Domäne. Dann brauche ich für jede der Zonen, für die ich voll verantwortlich bin, ein File mit der Zuordnung Hostname - IP-Adresse (die direkte Auflösung) und ein File mit der Zuordnung IP-Adresse - Hostname (die reverse Auflösung). Für jede Zone, die ich von einem anderen Server als Slave lade, gilt dasselbe. In der Regel werde ich auch das Loopback-Netz bedienten. Im einfachsten Fall sähe das ungefähr so aus: 

-rw-r--r-- root/root      2769 2001-01-30 16:32:31 zone-data/root.hint
-rw-r--r-- root/root       184 2001-01-30 16:32:31 zone-data/localhost.zone
-rw-r--r-- root/root       228 2001-01-30 16:32:31 zone-data/127.0.0.zone
-rw-r--r-- root/root       891 2001-07-24 15:30:26 zone-data/orm.zone
-rw-r--r-- root/root       395 2001-07-24 12:43:33 zone-data/172.168.2.zone

Ich habe ein File mit den Root-Servern (root.hint), die direkte und reverse Auflösung der loopback Zone (localhost-zone und 127.0.0.zone) und das eigentliche Herzstück, die Zone, für die der ganze Aufwand gemacht wird (orm.zone und 172.168.2.zone).

Syntax und Begriffe

Generell werden alle Files ohne Beachtung der Groß- und Klein-Schreibung gelesen und gespeichert.

Es ist sehr wichtig, die verschiedenen "Arten" von Namen verstanden zu haben. Wie erwartet hat eine Maschine einen Hostnamen, der auch als Domänenname bezeichnet wird, wenn die entsprechende Domäne angehängt ist. Das sorgt meist für etwas Konfusion, den meist wird als Domäne nur das Ende des Namens gesehen. Das ist aber variabel, und hängt vom Origin ab, also der Ausgangspunkt des Teiles des Namensraumes, meist der Bereich, über den man herrschen kann. Bezieht sich ein Name auf die Root-Domäne des gesamten DNS Raumes, dann ist der Name FDQN - der Fully Qualified Domain Name.

Es gibt eine Reihe spezielle Zeichen:

Hostnamen mit einem Punkt am Ende sind absolute Namen, also komplett. Ohne Punkt sind sie relativ, der komplette, absolute Name wird also durch Anfügen des Ausgangspunktes (also des $ORIGIN) erzeugt. Diese Information findet der Deamon entweder im File, oder er wird auf der Kommandozeile mitgegeben. Ohne diese Information gibt es einen Fehler.

$ORIGIN domänen-name setzt den Ausgangspunkt für die folgenden Namen: Name.$ORIGIN
$INCLUDE file-name domänen-name schiebt den Inhalt des Files hier ein. Gibt man einen Domänen-Namen mit an, so wird der relative Ausgangspunkt für die im File aufgeführten Host-Namen verändert.
$TTL setzt einen globalen Wert für die Time To Live der in der Datenbank referenzierten Resource Records.

Die Daten über eine Adresse oder Hostnamen

Alle Information über eine Zone, also die Namen und Adressen der Hosts in der Zone, der Mailserver, die Nameserver, welche Maschinen welche Services anbieten etc. sind in sogenannten Resource Records gespeichert. Diese RRs haben einen Besitzer (Owner), der an erster Stelle steht. Führt ein Blank, dann wird der Resource Record dem zuletzt erwähnten Besitzer zugerechnet. Es folgen dann TTL und Class des Records. Danach Angaben zum Type und schließlich die eigentliche Information, die Resource Daten (RData):
Owner TTL Class Type Daten
Owner Class TTL Type Daten
Klasse und TTL können fehlen, es wird dann der Default-Wert angezogen. Und die Reihenfolge ist auch egal, was Klasse und TTL angeht.

Die Klassen der RRs

Sind in RFC 1035 spezifiziert.
Die Klasse eines Resource Records hängt von der Art des Netzwerk-Protokolles ab. Es gibt 4 Klassen, wobei 98% aller Leute nur die Klasse für das Internet kennen und brauchen. Die anderen Klassen sind entweder propietär oder nur intern verwirklicht. Hier die vier Klassen:

Resource Record Typen

Das ist in folgenden RFCs spezifiziert: 1035, 1183, 1664.
Art bzw. Typ eines Resource Records - was man mit der Information anfangen soll oder kann. Es gibt eine ganze Reihe verschiedener Typen, und je nach Anforderung werden neue hinzugefügt. Hier eine nicht vollständige Aufführung der üblichen und nützlichen Typen (wenig benutzte Typen habe ich weggelassen, es sei den sie sind sehr interessant):

Subdomains und Delegation

Subdomänen

Subdomänen sind logische und geografische Untereinheiten des Namensraumes. Ein Beispiel: orm.org ist ein Netz mit 10Mbit, ein paar Privilegierte haben aber 100Mbit. Dafür ist die Subdomäne fast.orm.org eingerichtet worden.
Das wird in den Datenfiles so gehandhabt: 
.... normaler Inhalt
neuerechner.fast IN A
andererechner.fast IN A
IN MX 10 ... .
IN MX 10 ... .
IN CNAME --.--.-.-.
Der Namensteil der Subdomäne wird also an den Rechnernamen mit angehängt. Schließlich wird ja das Origin "orm.org." später noch angefügt. Man kann sich die Schreibarbeit sparen, indem man explizit die $ORIGIN Variable setzt: 
$ORIGIN fast.orm.org.
neuerrechern IN A
..
Dieses Origin gilt für alle weiteren Einträge bzw. bis zu einem neuen $ORIGIN. Setzt man eine $INCLUDE Variable, so kann man auf ein anderes File verweisen, indem die Daten zu "fast.orm.org" oder zu beliebigen Teilen des Namensraumes stehen. Dabei kann man das Origin ändern, muß es aber nicht.

Delegation

Diese Subdomäne ist nach wie vor eine Domäne, die dieser Server voll verantwortet. Es kann jetzt viele Gründe geben, diese Verantwortung an eine andere Maschine abzugeben. Das ist eine Delegation. Dabei gilt, das man nur Bereiche delegieren kann, die in der DNS-Hierarchie abwärts vom eigenen Standpunkt angesiedelt sind. Nach aussen hin ist weiterhin dieser Server Ansprechpartner, verweist aber dann auf den wirklich verantwortlichen Server. Diese Maschine ist dann Master für die entsprechende Zone, und genau wie ein Master eingerichtet. Man richtet alles ein und Testet gründlich. Wenn innerhalb der Subdomäne dann alles einwandfrei läuft, kann man die Delegation vornehmen.

Das geschieht auf den übergeordneten Master. Dort wird innerhalb der Hauptdomäne auf den Nameserver der jetzt eigenständigen Subdomäne verwiesen: 

fast 86400 IN NS ns.fast.orm.org.
86400 IN NS ns-sec.fast.orm.org.
#(Das müssen kanonische Namen sein!)
Damit ist die Verantwortlichlkeit klar, und die Nameserver sind auch benannt. Dummerweise liegen die aber schon in der neuen Zone, und es gibt einen Weg, an die IP zu kommen - diese ist nur in der Subdomäne bekannt. Daher muß man beide Domänen zusammenkleben: Dazu dient der glue-record. Das ist einfach die Angabe des A-Records der Server: 
fast 86400 IN NS ns.fast.orm.org.
86400 IN NS ns-sec.fast.orm.org.
ns.fast.orm.org. 86400 IN A 172.168.12.4
ns-sec.fast.orm.org. 86400 IN A 172.168.16.13
Die reverse Domäne, also die in-addr.arpa Domäne, muß natürlich auch delegiert werden. Da es sich meist um einen definierten Block Adressen handelt, ist das in der Regel einfach. Im Beispiel ist orm.org 192.168.1, und fast.orm.org 172.168. Es muß also 172.168.0.0 delegiert werden: 
172.168 86400 IN NS ns.fast.orm.org.
IN PTR ns.fast.orm.org.

Classless Reverse Delegation

Mit einem "definierten Block" sind hier Adressräume gemeint, die mit Netzmasken definiert sind, die genau Byte-weise gesetzt sind, also 255.255.0.0 oder 255.255.255.0. Schwierig wird die Angelegenheit, wenn man Netzmasken hat, die Bit-weise den Adressblock einteilen. Ein Beispiel wäre 255.255.248.0. Die Zuordnung im DNS erfolgt nach IP-Adressen, und zwar in Dezimaler Darstellung. Bei einem Bitweise umgebrochenen Netz sind die IP-Adresse aber nicht mehr stetig aufwärts zählend zugeordnet (die binären Zahlen schon..).

Man kann jetzt einfach den reversen Namensraum in eine große Zone packen, was eine richtige Delegation mit Delegation der Verantwortung unmöglich macht, weil sich die Administratoren weiterhin gegenseitig informieren müßen. Oder man muß jeder IP eine eigene Zone zuordnen.

Abhilfe schafft hier der RFC2317, Classless IN-ADDR.ARPA delegation. Nach dieser Methode wird auf dem Master-Server, der die Zonen delegiert hat, die reverse Namensauflösung verändert. Es wird für den ganzen reversen Namensraum ein File zone.in-addr.arpa.dns angelegt, indem für jede IP-Adresse ein Alias (also ein CNAME Record) eingefügt wird. Dieser Record zeigt auf einen virtuellen Domänennamen: 

1.xx.xx.xx.in-addr.arpa. IN CNAME 1.0-63.xx.xx.in-addr.arpa.
2.xx.xx.xx.in-addr.arpa. IN CNAME 2.0-63.xx.xx.in-addr.arpa.
....
65.xx.xx.xx.in-addr.arpa. IN CNAME 65.64-127.xx.xx.in-addr.arpa.
66.xx.xx.xx.in-addr.arpa. IN CNAME 66.64-127.xx.xx.in-addr.arpa.
....
Diese virtuellen Domänen zeigen dann wieder auf die entsprechenden Nameserver, die für diesen Teil der reversen Namensraum verantwortlich sind (also die Server, auf die dieser Teil des Adressraumes delegiert worden ist): 
0-63.xx.xx.in-addr.arpa.  86400 IN NS ns.kklkkjklkl.
64-127.xx.xx.in-addr.arpa.  86400 IN NS ns2.kklkkjklkl.
Auf der Seite der Server der Subdomäne (also die, die die Delegation tragen) muß nun ein File 0-63.xx.xx.in-addr.arpa.dns mit den Resource Records zu den Adressen .1 - .63 angelegt und verwaltet werden.

Wird jetzt außerhalb der Subdomain eine reverse Namensauflösung angefordert, so leitet der Server der Hauptdomäne die Anfrage transparent über den CNAME Record auf den Nameserver weiter, der in diesem Record mit der virtuellen Domäne verknüpft ist. Mit diesem Kunstgriff werden nichtzusammenhängende Bereiche von IP-Adressen auf eine Domäne gebündelt, und dieser Domäne wird ein verantwortlicher Server zugeordnet.

Ein Beispiel

Hier ein Beispiel zur Illustration: Die Maschine linux ist der Master-Server für die Domäne orm.org. Das dazugehörige Netz ist 172.168.1/24.

Dieser Server vergibt dieses Netz (172.168.1/24) in drei Teilen, die er an andere Server delegiert:

Ein kleiner Exkurs: Es sind weitere Netze möglich:
Mit einer 1 Bit Netzwerkmaske: 2*63 zwei Netze mit je 63 Adressen:
0 => 0, 1 => 128
Mit einer 2 Bit Netzwerkmaske: 4*31 vier Netze mit je 31 Adressen:
00 => 0, 01 => 64, 10 => 128, 11 => 192
Mit einer 3 Bit Netzwerkmaske: 8*15 acht Netze mit je 15 Adresen:
000 => 0, 001 => 32, 010 => 64, 011 => 96, 100 => 128, 101 => 160, 110 => 192, 111 => 224

Auf dem von aussen sichtbaren Server (linux.orm.org) gibt es für die ganze Zone orm.org und für den ganzen Adressbereich (172.168.1.0/24) einen Eintrag in der /etc/named.conf (es gibt natürlich noch mehr Domänen, hier nur die wesentlichen Teile): 

#
# orm.org
#
zone "orm.org" IN {
type master;
file "zone-data/orm.zone";
# by default, any host can receive zone transfers
allow-transfer { any; };
notify yes;
};

#
# fast.orm.org, slow.orm.org, old.orm.org
# entstehen durch Delegation
#

zone "1.168.172.in-addr.arpa" IN {
type master;
file "zone-data/172.168.1.rev";
check-names fail;
allow-update { none; };
};

Auf dieser Maschine delegiere ich jetzt einmal den direkten Namensraum (also Teile der Domäne orm.org, im File /var/named/zone-data/orm.zone): 

@		IN SOA	orm.org.   root.linux.orm.org. (
2		; serial
2D		; refresh
4H		; retry
6W		; expiry
1W )		; minimum
;
; Name Server fuer diese Zone
;
IN NS		linux.orm.org.
;
; Die kanonischen Namen der Maschinen
;
linux4 		IN A		192.168.1.4
[Hier ein paar Adressen mehr ... ]
linux 		IN A		192.168.1.9
;
;
fast			IN NS	elpequeno.fast.orm.org.
elpequeno.fast.orm.org.	IN A	172.168.1.12
slow			IN NS	linux4.slow.orm.org.
linux4.slow.orm.org.	IN A	192.168.1.4
old			IN NS	dumpy.old.orm.org.
dumpy.old.orm.org.	IN A  	172.168.1.202
;End of File.

Interessant sind die letzten 3 NS Records. Das ist die Delegation der Subdomänen fast, slow und old. Der NS-Record ist der Verweis auf den zuständigen Nameserver, also auf die Maschine, die die Delegation annimmt. Da diese Maschinen in der Regel in einem anderen Netz liegen, muß man das auch sagen. Daher der A Record, ein sogenannten Glue-Record.

Für die reverse Namensauflösung auf dieser Maschine tue ich das, was der RFC2317 empfielt. Ich lege für jede Adresse einen CNAME Record an, der auf eine Dummy-Domäne verweist, die dann auf die Nameserver der Subdomänen delegiert werden kann (File /var/named/zone-data/172.168.1.rev): 

@		IN SOA		linux.orm.org.   root.linux.orm.org. (
blah blah blah )
;
; Name Server
;
IN NS		linux.orm.org.
;
; CNAME Records für jede Adresse, die auf eine Dummy-Domäne
; und deren NS deuten
;
; 0-127 /25 (fast.orm.org)
;
0-25	IN	NS	elpequeno.fast.orm.org.

1	IN	CNAME	1.0-25.1.168.172.in-addr.arpa.
2	IN	CNAME	2.0-25.1.168.172.in-addr.arpa.
[Hier ein paar Adressen mehr ... ]
125	IN	CNAME	125.0-25.1.168.172.in-addr.arpa.
126	IN	CNAME	126.0-25.1.168.172.in-addr.arpa.

;
; 128-191 /26 (slow.orm.org)
; (der Server liegt in orm.org...)
;
128-26	IN	NS	linux4.orm.org.

129	IN	CNAME	129.128-26.1.168.172.in-addr.arpa.
130	IN	CNAME	130.128-26.1.168.172.in-addr.arpa.
[Hier ein paar Adressen mehr ... ]
189	IN	CNAME	189.128-26.1.168.172.in-addr.arpa.
190	IN	CNAME	190.128-26.1.168.172.in-addr.arpa.
;
;
; 192-223 /27 (old.orm.org)
;
192-27	IN	NS	dumpy.old.orm.org.

193	IN	CNAME	193.192-27.1.168.172.in-addr.arpa.
194	IN	CNAME	194.192-27.1.168.172.in-addr.arpa.
[Hier ein paar Adressen mehr ... ]
221	IN	CNAME	221.192-27.1.168.172.in-addr.arpa.
222	IN	CNAME	222.192-27.1.168.172.in-addr.arpa.
;End of File.

Die Namen meiner Dummy-Domänen baue ich nach verbreiteter Sitte aus der Netzwerknummer und den Bits der Netzmaske zusammen: 192-27 ist also das Netz 172.168.1.192, die Netzmaske 255.255.255.224, also 27 Bit.

Für jede der delegierten Zonen brauche ich einen NS Record, der auf den Server zeigt, der diesen Bereich übernimmt. Danach muß ich nur noch für jede denkbare Adresse einen CNAME Record, also ein Alias anlegen. Von diesem Moment an ist alles ein Problem der Administratoren der Subnetz-Nameserver. Ich habe mit der Sache nur noch zu tun, wenn sich der Name eines dieser Server ändert. Die Arbeit, hunderte von CNAME Records anzulegen, nimmt mir BIND ab: Im Datenbank-File trage ich das Keywort $GENERATE ein. In einer angegebenen Range werden gleiche Einträge erzeugt, die sich nur durch eine Zahl unterscheiden. Das obige File kann ich also auch so erzeugen: 

@		IN SOA		linux.orm.org.   root.linux.orm.org. (
blah blah blah )
;
; Name Server
;
IN NS		linux.orm.org.
;
; CNAME Records für jede Adresse, die auf eine Dummy-Domäne
; und deren NS deuten
;
; 0-127 /25 (fast.orm.org)
;
0-25	IN	NS	elpequeno.fast.orm.org.

$GENERATE 1-126 $ CNAME $.0-25

;
; 128-191 /26 (slow.orm.org)
; (der Server liegt in orm.org...)
;
128-26	IN	NS	linux4.orm.org.

$GENERATE 129-190 $ CNAME $.128-26

;
;
; 192-223 /27 (old.orm.org)
;
192-27	IN	NS	dumpy.old.orm.org.

$GENERATE 193-222 $ CNAME $.192-27

;End of File.
Ob es stimmt muß man durch einen Dump der Datenbank prüfen (entweder mit kill -INT oder mit dem Administrationstool ndc, Unterbefehl dumpdb).

Auf den Servern der Subdomänen müssen Namen und Adressen verwaltet werden. Für die direkte Namensauflösung ist das leicht, es wird ein normales File mit A Records erstellt. Hier als Beispiel der Server elpequeno in der Subdomäne fast.orm.org: 

@		IN SOA	fast.orm.org.   root.elpequeno.fast.orm.org. (
blah blah blah )

IN NS		elpequeno.fast.orm.org.
;
; Domain fast.orm.org
;

fast1 		IN A		172.168.1.1
fast2 		IN A		172.168.1.2
[ Was man so an Namen vergeben hat ]
fast19 		IN A		172.168.1.19
fast20 		IN A		172.168.1.20
;
;End of File.

Mit der reversen Namensauflösung ist das etwas schwieriger. Einmal ist auf diese Maschine ja die Dummy-Domäne 0-25.1.168.172.in-addr.arpa delegiert worden. Das ist aber nicht die "echte" Domäne. Ich muß also auch für das Netz 1.168.172.in-addr.arpa Service zur Verfügung stellen, denn die Dummy-Domäne ist nur den Anfragen von aussen bekannt. Ich habe das gelöst, indem ich in der named.conf 2 Zonen-Statements einfüge, die dasselbe File laden. Somit reagiert der Server auf Anfragen für beide Zonen. Leider weiss ich nicht, wie der Server unterscheiden soll, ob die Anfrage eine Adresse aus seinem Adressraum oder aus dem Adressraum von z.B. Server linux4 (128-26.1.168.172.in-addr.arpa) ist. 

#
# fast.orm.org
#
zone "fast.orm.org" IN {
type master;
file "zone-data/fast.orm.zone";
# by default, any host can receive zone transfers
allow-transfer { any; };
notify yes;
};


zone "1.168.172.in-addr.arpa" IN {
type master;
file "zone-data/172.168.1.0-25.rev";
check-names fail;
allow-update { none; };
};

zone "0-25.1.168.172.in-addr.arpa" IN {
type master;
file "zone-data/172.168.1.0-25.rev";
check-names fail;
allow-update { none; };
};
;End of File.

Wahrscheinlich muß ich auf Server linux zurückverweisen... Das gemeinsame Zonenfile sieht so aus: 

@		IN SOA		fast.orm.org.   root.elpequeno.fast.orm.org. (
blah blah blah )

IN NS		elpequeno.fast.orm.org.

1		IN PTR		fast1.fast.orm.org.
2		IN PTR		fast2.fast.orm.org.
[ etc. etc. ]
;End of File.

Für die anderen beiden Server ist das analog. Man kann natürlich Teile der erzeugten Sub-Domänen auch auf dem Server linux laufen lassen - der Server würde sich dann selbst die Zone delegieren.

[ Main | Local ]

[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]

Copyright 2001-2021 by Orm Hager - Es gilt die GPL
Feedback bitte an: Orm Hager (orm@doc-tcpip.org )