<!-- Do *not* edit this file; it was automatically generated by ej2html
Look for a name.ej file with the same name as this filename -->
<!-- Last updated Tue Mar 12 11:30:04 2002 -->
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=utf-8">
</HEAD><BODY>
<h1>NOM</h1>
csv1 - Format du fichier de zone csv1 utilisé par MaraDNS
<h1>CARACTÈRES SPÉCIAUX</h1>
<dl>
<dt>
|
<dd>
délimite les champs
<dt>
#
<dd>
Ceci indique un commentaire. Les lignes commençant par ce symbole sont
ignorées, autrement, il n'a pas de sens particulier.
<dt>
%
<dd>
est remplacé partout par le nom de la zone.
<dt>
*
<dd>
Ceci signifie "tout nom d'hôte ne résolvant pas d'une autre manière". Il
doit être placé au début d'un nom DNS.
<dt>
\
<dd>
Ceci est utilisé comme caractère d'échappement, ou bien pour échapper
une valeur octale, comme '\045' pour %, ou pour échapper le caractère
% afin qu'il perde sa signification particulière, ou bien pour
échapper le caractère barre-oblique-inverse.
</dl>
<h1>NOTES SUR L'INTERPRÉTATION</h1>
Tous les noms DNS sont convertis en leurs équivalents en minuscules
avant de procéder à l'interprétation. Ceci est dû à la non-sensibilité à
la casse des données DNS une fois dans la base. Ceci est ma manière de
résoudre le désir schizophrénique du RFC1035 de permettre à la fois des
noms DNS binaires, en conservant la non-sensibilité à la casse.
<p>
Le fichier de zone doit disposer d'un enregistrement SOA, suivi d'un ou
plusieurs enregistrements DNS, suivis d'autres enregistrements. Les
champs NS et SOA initiaux doivent être RR pour cette zone. Les
enregistrements NS suivant tout enregistrement non-NS doivent faire
partie d'une autre zone. L'algorithme de résolution n'échouera pas si
des enregistrements non-CNAME sont partagés avec des CNAME, mais ce
n'est pas une bonne idée.
<p>
<h1>FORMAT DES RR</h1>
Un enregistrement DNS est constitué d'une lettre désignant son type,
suivie immédiatement du nom DNS utilisant des points comme délimiteurs,
terminant par % ou un point final. Si le nom de domaine ne se termine
pas par un % ou un point, une erreur est générée (j'espère changer ce
comportement dans une future version de MaraDNS).
<h1>TYPES DE RR SUPPORTÉS</h1>
MaraDNS supporte actuellement les types suivants de RR :
<br>
<table>
<td>Lettre<td>Type<td>Valeur RFC1035 §3.2.2<tr>
<td>A<td>A<td>1<tr>
<td>N<td>NS<td>2<tr>
<td>C<td>CNAME<td>5<tr>
<td>S<td>SOA<td>6<tr>
<td>P<td>PTR<td>12<tr>
<td>@<td>MX<td>15<tr>
<td>T<td>TXT<td>16<tr>
<td>U<td>any<td>déterminé dans le dernier champ de la ligne<tr>
</table>
<h1>FORMAT DES TYPES DE RR SUPPORTÉS</h1>
Voici les formats, par lettre :
<pre>
A: possède trois champs
premier champ: nom DNS
deuxième champ: TTL pour ce nom en secondes
troisième champ: adresse IP, en notation décimale pointée
Exemple:
Ahost.example.com.|7200|10.1.2.3
</pre>
Les enregistrements A sont décrits avec des détails abondants dans la
RFC1035. En bref, un enregistrement A est une adresse IP associée à un
nom donné.
<pre>
N: possède trois champs
premier champ: nom de domaine
deuxième champ: TTL pour ce nom en secondes
troisième champ: nom de domaine concerné par ce NS
Exemple:
Nexample.com.|86400|ns.example.com.
</pre>
Les enregistrements NS (N ici) sont décrits dans le RFC1035.
<pre>
C: possède trois champs
premier champ: nom DNS
deuxième champ: TTL pour ce nom en secondes
troisième champ: nom DNS pointé par ce CNAME
Exemple:
Calias.example.org.|3200|realname.example.org.
</pre>
Les enregistrements CNAME (C ici) sont décrits dans le RFC1035.
<pre>
S: possède neuf champs
premier champ: nom DNS
deuxième champ: TTL pour ce nom en secondes
troisième champ: origine du domaine
quatrième champ: adresse e-mail de contact pour le domaine (RFC822, pas
au format BIND)
cinquième champ: numéro de série pour ce domaine
sixième champ: délai de rafraîchissement du domaine
septième champ: délai de réessai pour le domaine
huitième champ: délai d'expiration du domaine
neuvième champ: TTL minimal par défaut du domaine
Exemple:
Sexample.net.|86400|example.net.|hostmaster@example.net.|19771108|7200|3600|604800|1800
</pre>
Les enregistrements SOA (S ici) sont décrits dans le RFC1035.
<pre>
P: possède trois champs
premier champ: adresse IP vers laquelle pointer (en format in-addr.arpa)
deuxième champ: TTL pour ce nom en secondes
troisième champ: nom pleinement qualifié pour l'adresse en question
Exemple:
P3.2.1.10.in-addr.arpa.|86400|ns.example.com.
</pre>
Les enregistrements PTR (P ici) sont décrits dans le RFC1035.
<pre>
@: possède quatre champs
premier champ: nom DNS recevant le courrier
deuxième champ: TTL pour ce nom en secondes
troisième champ: préférence associé à cet enregistrement MX
quatrième champ: nom de l'hôte auquel envoyer le courrier pour le
premier champ
Exemple:
@example.com.|86400|10|mail.example.com.
</pre>
Les enregistrements MX (@ ici) sont décrits dans le RFC1035.
<pre>
T: possède trois champs
premier champ: l'hôte sur lequel on souhaite préciser des informations
supplémentaires
deuxième champ: TTL pour ce nom en secondes
troisième champ: texte d'information. Toute donnée saisie rentre dans
l'enregistrement avant une nouvelle ligne. La nouvelle ligne ne
fait pas partie de l'enregistrement TXT.
Exemple:
Texample.com.|86400|Example.com: achat en ligne
</pre>
Les enregistrements TXT (T ici) sont décrits dans le RFC1035.
<pre>
U: possède quatre champs
premier champ: nom DNS
deuxième champ: TTL pour ce nom en secondes
troisième champ: Code numérique pour le type de données (33 pour SRV,
etc.)
quatrième champ: donnée binaire
Exemple:
Uexample.com|3600|40|\\010\\001\\002Kitchen sink data
</pre>
L'exemple ce-dessus est un enregistrement "Kitchen Sink" (évier de
cuisine, NDT) avec une "signification" de 8, un "codage" de 1, et un
"sous-codage" de 2, et "Kitchen sink data" comme donnée elle-même. Comme
ce type de donnée n'est pas encore formalisé par un RFC au moment
présent, la méthode la plus appropriée de stockage est d'utiliser une
syntaxe non-supportée "attrape-tout".
<h1>FICHIER DE ZONE CSV1 D'EXEMPLE</h1>
<pre>
# Fichier de zone pour example.com (exemple)
# En premier le SOA, suivi des NS autoritaires pour la zone
Sexample.com.|86400|example.com.|hostmaster@example.com.|19771108|7200|3600|604800|1800
Nexample.com.|86400|ns1.example.com.
Nexample.com.|86400|ns2.example.com.
# Quelques enregistrements 'IN A'
Aexample.com.|86400|10.1.2.3
Amx.example.com.|86400|10.1.2.4
Ans1.example.com.|86400|10.0.0.1
Ans2.example.com.|86400|192.168.0.1
# Un enregistrement 'IN MX'
@example.com.|86400|10|mx.example.com.
# Un enregistrement 'IN CNAME'
Cwww.example.com.|86400|example.com.
# An 'IN TXT' record
Texample.com.|86400|Example.com: Buy examples of products online!
# Un enregistrement utilisant % comme raccourci pour désigner la zone
Aftp.%|3600|10.7.8.9
# MaraDNS supporte les méta-caractères
@*.example.com.|3600|10|mx.example.com.
# Note: cet enregistrement ne fait pas partie du domaine example.com,
# et, de ce fait, ne peut être transféré avec l'utilitaire getzone.
P3.0.0.127.in-addr.arpa.|1234|nslookup.bug.workaround.
</pre>
<h1>LEGAL DISCLAIMER</h1>
THIS SOFTWARE IS PROVIDED BY THE AUTHORS ''AS IS'' AND ANY EXPRESS
OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
<h1>AUTEUR</h1>
Sam Trenholme
<A href=http://www.samiam.org/>http://www.samiam.org/</a>
<h1>TRADUCTEUR</h1>
Traduit en français par Thomas Seyrat <thomas@glou.net>
</BODY></HTML>
