Configuration Bind9

Bonjour,
Je posséde un VPS avec une Debian 7.0, hébergé par Nuxit avec pour ip: 94.247.177.15 et nom de machine: de2535

J’ai acheté il y a peu le nom de domaine: youraltislife.fr

Les DNS de mon nom de domaine son: de2535.ispfr.net et en secondaire: dns.ispfr.net
Le but ici étant d’utiliser Bind9 sur mon serveur.

J’ai utilisé la doc ici:http://doc.ubuntu-fr.org/bind9#configuration

Mais lorsque je tente de joindre mon site youraltislife.fr, aucune réponse.

Voici les fichiers de configuration:
named.conf.local:

zone "youraltislife.fr" {
             type master;
             file "/etc/bind/db.youraltislife.fr";
             //allow-transfer {xx.xx.xx.xx;};
        };

zone "177.247.94.in-addr.arpa" {
            type master;
            notify no;
            file "/etc/bind/db.94";
};

mon db.youraltislife.fr:

;
; BIND data file for local loopback interface
;
$TTL    604800
@       IN      SOA     ns.youraltislife.fr. adresseperso.gmail.com. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      ns.youraltislife.fr.
ns      IN      A       94.247.177.15

mon db.94:

;
; BIND reverse data file for local loopback interface
;
$TTL    604800
@       IN      SOA     ns.youraltislife.fr. adresseperso.gmail.com. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      ns.
15      IN      PTR     ns.youraltislife.fr.

merci du coup de main :006

Quelle est la question ?

Mes observations :

Par convention, le numéro de série dans le SOA est de la forme AAAAMMJJNN où AAAA=année, MM=mois, JJ=jour et NN=numéro d’ordre de la dernière modification.

Dans le fichier de zone pour ton domaine, il manque un enregistrement NS avec le DNS secondaire dns.ispfr.net, et des enregistrements “utiles” pour utiliser le domaine (A, MX…).

Si tu ne l’as pas fait dans les options globales, il faut autoriser le transfert de zone pour l’adresse IP du DNS secondaire dns.ispfr.net (ou l’adresse source qu’il utilise pour demander le transfert, qui peut être différente, voir la documentation de l’hébergeur, dans ce cas ajouter une option [mono]also-notify[/mono] pour cette adresse) dans la définition de la zone.

Dans les options globales, pense à désactiver la récursion au moins pour les requêtes non locales pour éviter les abus de ton serveur.

Je doute que ton serveur ait la délégation pour la zone inverse 177.247.94.in-addr.arpa du bloc contenant son adresse IP. Cette zone n’a donc pas à être définie sur ton serveur.

Bonjour,

Concernant ton domaine [mono]youraltislife.fr[/mono] , il faut :

  • Que tu fasses publier les enregistrements NS dans la zone [mono]fr[/mono] . Cela se fait par le biais de l’organisme auprès duquel tu as acquis le domaine.

  • Que tu fasse publier un “glue record” étant donné que ton serveur DNS a un nom de domaine qui fait partie de ton domaine. Ou alors que tu utilises le nom de domaine du genre vps-177-247-94-15.nuxit.com éventuellement mis en place par Nuxit mais c’est un peu moche. Cela se fait aussi auprès de l’organisme.

Une autre remarque : La zone “177.247.94.in-addr.arpa” n’est pas du tout de ton ressort et il est donc inutile de la configurer. Si tu as besoin de configurer le “reverse” du VPS, il faut le faire via ton hébergeur, Nuxit.


AnonymousCoward

La publication de la délégation et du glue record dans la zone parente n’intervient que dans un second temps lorsque la zone est correctement créée sur les serveurs faisant autorité (primaire et secondaires).

La définition de la zone inverse sur le serveur n’est pas seulement inutile, elle peut être nuisible. En effet si le serveur utilise le BIND local pour ses propres résolutions DNS récursives(ce n’est pas une obligation, il peut utiliser les serveurs DNS récursifs de l’hébergeur), alors il recevra des informations fausses de la zone inverse locale au lieu des informations provenant des serveurs faisant autorité pour cette zone.

Merci de vos réponses.
Il semble que je n’ai pas été assez claire, excuse moi.
Ma quéstion est: Comment effectuer la configuration de bind9 pour acceder a mon nom de domaine via youraltislife.fr au lieu d’utiliser l’adresse ip du serveur.

Voici doncles changements effectué:

zone "youraltislife.fr" {
             type master;
             file "/etc/bind/db.youraltislife.fr";
             allow-transfer {195.114.19.2;};
        };

dans le named.conf.options j’ai ajouté:

allow-recursion { localhost; };

Par contre pour vos autres conseils, je suis perdu :confused:

Que ne comprends-tu pas dans les autres conseils ? La gestion d’un serveur DNS ne s’improvise pas, tu devrais t’être documenté(e) et familiarisé(e) avec les notions indispensables.

Que veux-tu dire par “accéder” ? A quel nom de domaine ? youraltislife.fr est un nom de domaine. Que veux-tu faire concrètrement avec ce nom de domaine ?

Mon serveur héberge un site, le but est de faire coïncider mon adresse ip > nom de domaine.

Voila la partie que je n’ai pas saisie

La correspondance entre un nom de domaine et une adresse IP(v4) se fait avec un enregistrement de type A (AAAA pour une adresse IPv6) dans le fichier de zone, par exemple :

www.youraltislife.fr. IN A 94.247.177.15
signifie que www.youraltislife.fr a pour adresse IP 94.247.177.15.

Les enregistrements de type MX servent à définir la correspondance entre une domaine de courrier et le nom des serveurs SMTP chargé de recevoir le courrier destiné à ce domaine, par exemple :

youraltislife.fr. IN MX 10 mail.youraltislife.fr. mail.youraltislife.fr. IN A 94.247.177.15
signifie que le courrier destiné à *@youraltislife.fr doit être délivré au serveur mail.youraltislife.fr qui a pour adresse IP 94.247.177.15.

Le nombre devant le nom du serveur de courrier représente la priorité : s’il y a plusieurs enregistrements MX pour un même domaine, le serveur avec le nombre le plus bas sera utilisé en premier et ainsi de suite.