mararc - Format du fichier de configuration mararc utilisé par MaraDNS

Le fichier mararc utilise une syntaxe constituant un sous-ensemble de la syntaxe Python 1.5.2. En particulier, Python 1.5.2 (et peut-être d'autres versions de Python) peut relire un fichier mararc correctement rédigé sans erreur.

À la différence de Python, toutefois, un fichier mararc ne peut utiliser que certains noms de variables, et ces variables doivent être définies comme suit.

Les commentaires (lignes ignorées par le parser MaraDNS) commencent par le caractère '#', comme ceci:

# Ceci est un commentaire

Le parser MaraDNS ignore également les lignes uniquement composées d'espace blanc.

Suit la liste des variables pouvant être déclarées dans le fichier mararc.

Une variable dictionnaire est un tableau pouvant comporter plusieurs éléments indexés par des chaînes au lieu de nombres. Ceci est analogue aux tableaux associatifs, que Perl dénomme hachage.

La syntaxe d'une variable dictionnaire est la suivante :

nom["index"] = "valeur"

Où nom est le nom de la variable dictionnaire, index est l'index du tableau, et valeur la valeur stockée à cet index.

Chaque fois qu'une variable dictionnaire (comme csv1) est utilisée, il est nécessaire de l'initialiser auparavant de la manière suivante :

csv1 = {}

Ici, csv1 est le nom de la variable dictionnaire utilisée.

Voici une liste des variables-dictionnaires qu'utilise MaraDNS:

csv1

csv1: Associe un nom de fichier de zone à une zone donnée

csv1["zone"] = "fichier"

csv1: Fichier au format csv1. Voir la page de manuel csv1(5) pour une description de ce format. zone: zone pour laquelle le serveur est autoritaire.

fichier: fichier contenant les données de la zone au format csv1.

Notez que les fichiers csv1 sont lus après que MaraDNS ait changé sa racine, et, de ce fait, le nom du fichier est relatif à chroot_dir.

ipv4_alias

ipv4_alias: utilisé pour donner des noms courts à des groupes de paires IP/masque d'adresses IPv4 (standard 32 bits)

ipv4_alias["nom"] = "ip1/masque1,ip2/masque,etc"

nom: Nom de l'alias en question

ip: Adresse IP dans la paire IP/masque

masque: Masque de réseau de la paire IP/masque

,: Utilisé pour séparer les paires IP/masque. Ne pas séparer avec des espaces avant ou après.

Une adresse IP est au format décimal pointé, par exemple 10.1.2.3.

Le masque peut-être noté de deux manières différents : un simple nombre entre 1 et 32, qui indique le nombre de bits forts "1" du masque, ou une adresse en décimal pointé.

Le masque est utilisé pour désigner une classe d'adresses IP.

"exemples ipv4_alias"

10.1.1.1/24 désigne toute adresse entre 10.1.1.0 et 10.1.1.255. 10.1.1.1/255.255.255.0 est identique à 10.1.1.1/24.

10.2.3.4/16 désigne toute adresse entre 10.2.0.0 et 10.2.255.255.

10.2.3.4/255.255.0.0 est identique à 10.2.3.4/16.

127.0.0.0/8 désigne toute adresse avec 127 comme premier octet.

127.0.0.0/255.0.0.0 est identique à 127.0.0.0/8.

Le masque est optionnel et, si absent, indique que seule une adresse doit faire partie de l'alias, par exemple :

10.9.9.9/32, 10.9.9.9/255.255.255.255, et 10.9.9.9 fonctionnent de manière identique, seule l'adresse 10.9.9.9 est concernée.

Les alias sont imbricables. Par exemple :

ipv4_alias["susan"] = "10.6.7.8/24" 
ipv4_alias["office"] = "susan,10.9.9.9"

Ainsi, "susan" dans "office" désigne l'alias "susan".

Il est possible d'imbriquer plusieurs alias. Toutefois, un alias pointant vers lui-même génèrera une erreur.

root_servers

root_servers: il s'agit d'une variable dictionnaire particulière désignant (pour l'instant) seulement un unique élément ".", qui désigne ou une adresse IP, ou un alias d'adresses désignant le ou les serveurs racine.

root_servers["."] = "liste_de_serveurs"

"." est la seule référence utilisable pour désigner les serveurs racine (ce format est utilisé pour une possible extension future), et liste_de_serveurs est une liste de serveurs de noms racine du même format que ipv4_aliases.

Notez que, bien que les IP de la liste des serveurs de noms racine peuvent comporter des masques, ceux-ci sont ignorés.

"Note finale sur les variables-dictionnaire"

csv1, ipv4_alias, et root_servers sont pour l'instant les seuls variables-dictionnaire.

Variables standard. Il s'agit de variables ne prenant qu'une seule valeur. La syntaxe d'une variable standard est de la forme :

nom = "valeur"

Où nom est le nom de cette variable, et value sa valeur.

Voici une liste des variables normales utilisées par le fichier mararc :

bind_address

bind_address: adresse IP à donner au serveur MaraDNS La valeur à donner est une simple adresse IP en notation décimale pointée (par ex.: "127.0.0.1"), qui spécifie l'adresse IP sur laquelle le serveur MaraDNS écoutera. Pour faire écouter MaraDNS sur toutes les adresses IP d'un serveur donné, utiliser la valeur "0.0.0.0".

chroot_dir

chroot_dir: le répertoire dans lequel MaraDNS se chroote. La valeur est le chemin absolu à utiliser comme prison de chroot. Notez que les fichiers de zone csv1 sont lus après cette opération de chroot. Ainsi, tous les fichiers de zone à charger doivent être contenus dans cette prison.

maradns_uid

maradns_uid: L'UID numérique de fonctionnement de MaraDNS La valeur est un unique nombre : l'identifiant utilisateur sous lequel faire fonctionner MaraDNS.

MaraDNS abandonne ses privilèges root dès que possible, minimisant les dommages potentiels qu'un attaquant pourrait faire subir au système, un problème de sécurité survenant dans MaraDNS. Ceci est l'UID à utiliser une fois les privilèges abandonnés.

maradns_gid

maradns_gid: Argument optionnel, GID de fonctionnement de MaraDNS. La valeur est un unique nombre : l'identifiant du groupe sous lequel faire fonctionner MaraDNS.

Cet argument optionnel donne les privilèges de groupe que MaraDNS doit utiliser à l'abandon des privilèges.

maxprocs

maxprocs: Nombre maximal de threads ou processus que MaraDNS est autorisé à lancer à un instant donné. Cette variable est utilisée pour minimiser l'impact sur les ressources du serveur lorsque MaraDNS est hautement sollicité. Lorsque ce nombre est atteint, il est impossible à MaraDNS de lancer de nouveaux threads/processus jusqu'à ce que ce nombre diminue.

max_tcp_procs

Parfois il est souhaitable d'avoir un nombre maximum de processus et de processus du serveur de zones différent. Si cette variable n'est pas positionnée, le nombre maximum de processus TCP est "maxprocs". no_fingerprint

no_fingerprint: Drapeau rendant MaraDNS plus difficile à détecter. Certaines personnes pensent qu'il est plus approprié que certaines informations, tel le numéro de version de MaraDNS, ne soit pas public.

La valeur normale est 0.

En positionnant no_fingerprint à 1, cette information n'est plus disponible publiquement.

default_rrany_set

defult_rrany_set: nombre définissant les RRs à retourner si le type de requête envoyée à MaraDNS est ANY. Certains registrars exigent qu'une requête ANY retourne les enregistrements NS et parfois le SOA également.

Lorsque default_rrany_set est positionné à 3 (la valeur par défaut), la réponse à une requête ANY retourne seulement les enregistrements A et MX.

Lorsque default_rrany_set est positionné à 15, la réponse à une requête ANY retourne les enregistrements A, MX, NS, et SOA.

max_chain

max_chain: nombre maximal d'enregistrements à renvoyer dans une chaîne d'enregistrements. Avec DNS, il est possible d'avoir plus d'un RR d'un nom DNS donné dans une même zone. Par exemple, "example.com" peut avoir, comme enregistrements A, plusieurs adresses IP différentes.

Ceci positionne le nombre maximum d'enregistrements à retourner pour un RR donné.

MaraDNS fait normalement tourner par "round-robin" les enregistrements d'un nom DNS avec plusieurs RRs donné. Ainsi, tous les enregistrements disponibles seront visibles, mais pas simultanément, si il y a plus d'enregistrements que max_chain.

max_ar_chain

max_ar_chain: nombre maximal d'enregistrements à retourner si la section additionnelle (par ex. l'adresse IP d'un serveur DNS ou l'adresse IP d'un MX) possède plus d'une valeur. Ceci est similaire à max_chain, mais ne s'applique qu'aux enregistrements de la section additionnelle (AR).

En raison de limitations dans la structure interne des données que MaraDNS utilisent pour stocker les RRs, si ce nombre est inférieur au nombre d'enregistrements du RR, le "round-robin" est désactivé.

max_total

max_total: nombre maximal d'enregistrements à montrer en tout pour une requête DNS donnée. verbose_level

verbose_level: nombre de messages à journaliser sur la sortie standard Ceci peut prendre quatre valeurs:

0: pas de messages excepté le démenti légal et les erreurs fatales survenues à l'interprétation du fichier de configuration au démarrage

1: Seulement les messages de démarrage (niveau par défaut)

2: Requêtes erronées journalisées

3: Toutes les requêtes journalisées

zone_transfer_acl

zone_transfer_acl: liste d'adresses IP autorisées à pratiquer des transferts de zone sur le serveur de zones Le format de cette variable est identique au format d'une entrée ipv4_alias.

recursive_acl

recursive_acl: liste d'adresses autorisées à pratiquer des requêtes récursives sur le serveur MaraDNS Le format de cette variable est identique au format d'une entrée ipv4_alias.

random_seed_file

randsom_seed_file: emplacement du fichier depuis lequel 16 octets sont lus afin d'obtenir la graine de 128 bits nécessaire au fonctionnement du générateur de nombres pseudo-aléatoires. Idéalement ce fichier est une bonne source d'entropie (par ex. /dev/urandom), mais peut également être un fichier fixe si votre système d'exploitation ne dispose pas d'une telle source d'entropie. Dans ce cas, veillez à ce que le contenu de ce fichier soit aléatoire et de permissions 600, avec root comme propriéraire. Ce fichier est lu *avant* d'abondonner les privilèges root.

maximum_cache_elements

maximum_cache_elements: nombre maximum d'éléments à conserver dans le cache des requêtes récursives. Ce cache de requêtes récursives est utilisé pour conserver des réponses à des requêtes récursives déjà effectuées.

Si l'on approche cette limite, le "videur" entre en action. Il retire des éléments aléatoires du cache\(em(8 éléments retirés par requête\(emjusqu'à atteindre 99% d'occupation environ.

spammers

spammers: une liste de serveurs DNS que le resolver récursif n'interrogera pas. Ceci est là essentiellement pour ne pas autoriser les domaines de spammers à résoudre, puisque les spammers utilisent fréquemment des serveurs DNS mal configurés de FAI afin de résoudre leurs domaines, leur permettant ainsi de passer de FAI en FAI.

Le format de cette variable est identique au format d'une entrée ipv4_alias.

max_glueless_level

Maximum glueless level allowed when performing recursive lookups. The default value is 10. Niveau "glueless" maximum autorisé lors de requêtes récursives. Le niveau par défaut est 10.

Ceci est le nombre maximal de fois autorisées où MaraDNS doit "retourner aux root servers" pour trouver l'adresse IP d'un serveur de noms pour lequel l'adresse IP n'est pas disponible immédiatement, ou pour trouver l'enregistrement A associé à un CNAME.

max_queries_total

Ceci est le nombre maximal de requêtes à réaliser lors d'une requête récursive. Le nombre par défaut est 32. Ceci est le nombre maximal de fois où MaraDNS peut envoyer une requête à des serveurs DNS pour trouver la réponse à sa question initiale.

timeout_seconds

Ceci ne s'applique qu'aux requêtes récursives. Le temps maximum à attendre, en secondes, la réponse à la requête vers un serveur DNS distant avant d'essayer le serveur DNS suivant disponible sur la liste. La valeur par défaut est de 2 secondes. Notez que, plus élevée est la valeur, plus lent MaraDNS sera à pratiquer les requêtes récursives lorsque le serveur DNS ne répond pas aux requêtes.

hide_disclaimer

Si cette variable est positionnée à "YES", MaraDNS n'affichera pas le démenti légal au démarrage.

# Example mararc file

# The various zones we support

# First, we must initialize the csv1 hash, or things will fail with a # (potentially) obscure error message csv1 = {}

# This is just to show the format of the file csv1["example.com."] = "db.example.com"

# The address this DNS server runs on. If you want to bind # to all addresses a given machine has, use "0.0.0.0". bind_address = "127.0.0.1" # The directory with all of the zone files chroot_dir = "/etc/maradns" # The numeric UID MaraDNS will run as maradns_uid = 99 # The maximum number of processes MaraDNS is allowed to use maxprocs = 64

# The number of messages we log to stdout # 0: No messages, except syntax error messages # 1: Only startup messages logged (Default) # 2: Error queries logged # 3: All queries logged (not very verbosely right now) verbose_level = 1

# Normally, MaraDNS has some MaraDNS-specific features, such as DDIP # synthesizing, a special DNS query (erre-con-erre-cigarro.maradns.org. # with a TXT query returns the version of MaraDNS that a server is # running), unique handling of multiple QDCOUNTs, etc. Some people # might not like these features, so I have added a switch that lets # a sys admin disable all these features. Just give "no_fingerprint" # a value of one here, and MaraDNS should be more or less # indistinguishable from a tinydns server. no_fingerprint = 0 # Normally, MaraDNS only returns A and MX records when given a # QTYPE=* (all RR types) query. Changing the value of default_rrany_set # to 15 causes MaraDNS to also return the MX and SOA records, which # some registars require. The default value of this is 3 default_rrany_set = 3

# These constants limit the number of records we will display, in order # to help keep packets 512 bytes or smaller. This, combined with # round_robin record rotation, help to use DNS as a crude load-balancer. # The maximum number of records to display in a chain of records (list # of records) for a given host name max_chain = 8 # The maximum number of records to display in a list of records in the # additional section of a query. If this is any value besides one, # round robin rotation is disabled (due to limitations in the current # data structure MaraDNS uses) max_ar_chain = 1 # The maximum number of records to show total for a given question max_total = 20

# Initialize the IP aliases, which are used by the list of root # name servers, the ACL for zone transfers, and the ACL of who # gets to perform recursive queries ipv4_alias = {}

# Various sets of root name servers # Note: Netmasks can exist, but are ignored when specifying root # name server

# ICANN, the most common and most controversial root name server ipv4_alias["icann"] = "198.41.0.4,128.9.0.107,192.33.4.12,128.8.10.90,192.203.230.10,192.5.5.241,192.112.36.4,128.63.2.53,192.36.148.17,198.41.0.10,193.0.14.129,198.32.64.12,202.12.27.33"

# OSRC: http://www.open-rsc.org/ ipv4_alias["osrc"] = "199.166.24.1,205.189.73.102,199.166.24.3,204.80.125.130,207.126.103.16,195.117.6.10,199.166.31.3,199.166.31.250,199.5.157.128,205.189.73.10,204.57.55.100,213.196.2.97"

# AlterNIC: http://www.alternic.org/ ipv4_alias["alternic"] = "160.79.129.192,65.2.214.15,160.79.133.70,24.13.64.102,216.99.37.240,199.224.64.190,160.79.133.66,216.99.37.246,216.99.37.247"

# OpenNIC: http://www.opennic.unrated.net/ ipv4_alias["opennic"] = "209.21.75.51,216.74.72.7,216.74.72.8,209.21.75.53,209.104.33.250,209.104.63.249"

# Pacific Root: http://www.pacificroot.com/ ipv4_alias["pacificroot"] = "204.107.129.2,208.179.42.162,12.28.140.20,204.107.129.10,212.115.192.151,202.76.159.5,209.54.94.3,167.160.132.2"

# IRSC: http://www.irsc.ah.net/ ipv4_alias["irsc"] = "203.21.205.2,203.21.205.3,212.234.36.20,212.234.36.19,207.180.91.9,198.199.168.92,207.180.91.10"

# TINC: http://www.tinc-org.com/ ipv4_alias["tinc"] = "64.6.65.10,208.128.113.35,212.172.21.254,207.112.147.14,145.89.234.7,209.133.38.16"

# Super Root: http://www.superroot.org/ ipv4_alias["superroot"] = "195.117.6.10,199.166.31.3,199.5.157.128,205.189.73.10,199.166.31.250,199.166.24.1,205.189.73.102,199.166.24.3,204.80.125.130,207.126.103.16,204.57.55.100"

# Here is the ACL which restricts who is allowed to perform # zone transfer from the zoneserver program

# VERY IMPORTANT: Do not put spaces in the zone_transfer_acl list # Good: zone_transfer_acl = "office,home" # Bad: zone_transfer_acl = "office, home"

# Simplest form: 10.1.1.1/24 (IP: 10.1.1.1, 24 left bits # in IP need to match) and 10.100.100.100/255.255.255.224 # (IP: 10.100.100.100, netmask 255.255.255.224) are allowed # to connect to the zone server # zone_transfer_acl = "10.1.1.1/24,10.100.100.100/255.255.255.224"

# More complex: We create two aliases: One called "office" # and another called "home". We allow anyone in the office or # at home to perform zone transfers # ipv4_alias["office"] = "10.1.1.1/24" # ipv4_alias["home"] = "10.100.100.100/255.255.255.224" # zone_transfer_acl = "office,home"

# More complex then the last example. We have three employees, # Susan, Becca, and Mia, whose computers we give zone transfer # rights to. Susan and Becca are system administrators, and # Mia is a developer. They are all part of the company. We # give the entire company zone transfer access # ipv4_alias["susan"] = "10.6.7.8/32" # Single IP allowed # ipv4_alias["becca"] = "10.7.8.9" # also a single IP # ipv4_alias["mia"] = "10.8.9.10/255.255.255.255" # 1 IP # ipv4_alias["sysadmins"] = "susan,becca" # ipv4_alias["devel"] = "mia" # ipv4_alias["company"] = "sysadmins,devel" # This is equivalent to the above line # ipv4_alias["company"] = "susan,becca,mia" # zone_transfer_acl = "company"

# Recursive ACL: Who is allowd to perform recursive queries. # The format is identical to that of "zone_transfer_acl", # including ipv4_alias support # ipv4_alias["localhost"] = "127.0.0.0/8" # recursive_acl = "localhost"

# Random seed file: The file form which we read 16 bytes from # to get the 128-bit random Rijndael key. This is ideally a # file which is a good source of random runbers, but can also be # a fixed file if your OS does not have a decent random number # generator (make sure the contents of that file is random and # with 600 perms, owned by root, since we read the file *before* # dropping root privledges)

# random_seed_file = "/dev/urandom"

# The maximum number of elements we can have in the cache. If # we have more elements in the cache than this amount, the # "custodian" kicks in to effect, removing elements at random from # the cache (8 elements removed per query) until we are at the 99% # level or so again.

# maximum_cache_elements = 1024

# The root servers which we use when making recursive queries.

# The following line must be uncommented to enable recursive queries # root_servers = {}

# You can choose which set of root servers to use. Current # values (set above) are: icann, osrc, alternic, opennic, # pacificroot, irsc, tinc, and superroot. # root_servers["."] = "osrc"

# You can tell MaraDNS to *not* query certain DNS servers when in # recursive mode. This is mainly used to not allow spam-friendly # domains to resolve, since spammers are starting to get in the habit # of using spam-friendly DNS servers to resolve their domains, allowing # them to hop from ISP to ISP. The format of this is the same as for # zone_transfer_acl and recursive_acl

# As of August 12, 2001, azmalink.net is a known spam-friendly DNS # provider (see doc/en/misc/spammers/azmalink.net for details). # Note that this is based on IPs, and azmalink.net constantly # changes IPs (as they constantly have to change ISPs) # Updated 2002/10/12 to reflect their current ISP ipv4_alias["azmalink"] = "12.164.194.0/24"

# As of September 20, 2001, hiddenonline.net is a known spam-friendly # DNS provider (see doc/en/misc/spammers/hiddenonline for details). ipv4_alias["hiddenonline"] = "65.107.225.0/24"

spammers = "azmalink,hiddenonline"

Si l'on venait à déclarer deux fois un index dans une variable dictionnaire, MaraDNS se terminerait en erreur fatale. Ceci est dû au fait que des versions précédentes de MaraDNS ne réagissait pas comme Python 1.5.2. Avec Python 1.5.2., la dernière déclaration est utilisée, alors que MaraDNS utilisait la première.

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>