csv1 - Format du fichier de zone csv1 utilisé par MaraDNS

|

délimite les champs

#

Ceci indique un commentaire. Les lignes commençant par ce symbole sont ignorées, autrement, il n'a pas de sens particulier.

%

est remplacé partout par le nom de la zone.

*

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.

\

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.

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.

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.

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).

MaraDNS supporte actuellement les types suivants de RR :

Lettre Type Valeur RFC1035 §3.2.2

A A 1

N NS 2

C CNAME 5

S SOA 6

P PTR 12

@ MX 15

T TXT 16

U any déterminé dans le dernier champ de la ligne

Voici les formats, par lettre :

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

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é.

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.

Les enregistrements NS (N ici) sont décrits dans le RFC1035.

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.

Les enregistrements CNAME (C ici) sont décrits dans le RFC1035.

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

Les enregistrements SOA (S ici) sont décrits dans le RFC1035.

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.

Les enregistrements PTR (P ici) sont décrits dans le RFC1035.

@: 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.

Les enregistrements MX (@ ici) sont décrits dans le RFC1035.

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

Les enregistrements TXT (T ici) sont décrits dans le RFC1035.

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

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".

# 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.

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.

Sam Trenholme http://www.samiam.org/

Traduit en français par Thomas Seyrat <thomas@glou.net>