NOM
csv1 - Format du fichier de zone csv1 utilisé par MaraDNS
CARACTÈRES SPÉCIAUX
| |
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. |
NOTES SUR L´INTERPRÉTATION
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.
FORMAT DES RR
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).
TYPES DE RR SUPPORTÉS
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
FORMAT DES TYPES DE RR SUPPORTÉS
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 [AT] 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 CSV1 D´EXEMPLE
# Fichier de zone pour example.com (exemple)
# En premier le
SOA, suivi des NS autoritaires pour la zone
Sexample.com.|86400|example.com.|hostmaster [AT] 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.
LEGAL DISCLAIMER
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.
AUTEUR
Sam Trenholme http://www.samiam.org/
TRADUCTEUR
Traduit en français par Thomas Seyrat <thomas [AT] glou.net>