Besoin d'avis/commentaires sur fichier de zone BIND

Support Debian
#1

Hello,

Je souhaiterais avoir votre avis sur mon fichier de zone bind. Celui-ci correspond à mon master, il intègre la déclaration de mon serveur de mails, de mon DNS secondaire.

Il est fonctionnel, le test de la conf ne bronche pas, mais je souhaiterais surtout savoir si on ne peut pas mieux faire, l’optimiser ou corriger quelques erreurs qui ne ressortent pas forcément aux tests ni à l’utilisation. J’ai changé l’IP par souci de confidentialité :

$TTL    604800
@       IN      SOA     ns.mondomaine.ovh. root.mondomaine.ovh. (
                         2018290512         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;

;Name Server Information
       IN      NS      ns.mondomaine.ovh.
       IN        NS    puck.nether.net.

;IP address of Name Server
ns     IN      A       88.121.250.140

;Mail Exchanger
mondomaine.ovh.   IN     MX   10   mail.mondomaine.ovh.

;A - Record HostName To Ip Address
www     IN       A      88.121.250.140
mail    IN       A      88.121.250.140
smtp    IN       A      88.121.250.140
imap    IN       A      88.121.250.140
@       IN       A      88.121.250.140
;CNAME record
ftp     IN      CNAME   www.mondomaine.ovh.

et le reverse :

; BIND reverse data file for local loopback interface
;
$TTL    604800
@       IN      SOA     mondomaine.ovh. root.mondomaine.ovh. (
                         2018290513         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;

;Name Server Information
       IN      NS     ns.mondomaine.ovh.
       IN      NS     puck.nether.net.

;Reverse lookup for Name Server
140      IN      PTR    ns.mondomaine.ovh.

;PTR Record IP address to HostName
140     IN      PTR    www.mondomaine.ovh.
140     IN      PTR    mail.mondomaine.ovh.
140     IN      PTR    smtp.mondomaine.ovh.
140     IN      PTR    imap.mondomaine.ovh.
140     IN      PTR    mondomaine.ovh.

Merci à vous !

#2

La zone directe :

  • Je trouve les délais du SOA un peu longs.
  • Une raison particulière de définir ftp.mondomaine.ovh avec un CNAME et non avec un A comme les autres noms ?

La zone inverse :

  • “for local loopback interface” ?
  • A ma connaissance Free ne délègue pas la gestion du reverse DNS à l’abonné, donc peu probable que cette zone serve à l’extérieur. Le NS secondaire est donc sans objet.
  • Tu ne montres pas directement le nom de la zone inverse, mais je déduis du contenu du fichier qu’il s’agit de 250.121.88.in-addr.arpa. Cette zone fait autorité pour les reverses de tout le préfixe 88.121.250.0/24 et pas seulement pour ton adresse IP. Pour cela il aurait fallu définir une zone 140.250.121.88.in-addr.arpa. Si tu utilises ton serveur pour la résolution locale, tu ne pourras pas résoudre des reverses des adresses de tes “voisins” du même préfixe.
  • On ne définit normalement qu’un seul reverse pour une adresse IP donnée.
#3

La zone directe :

J’ai pris en compte tes remarques et ai modifié les ttl, qui effectivement étaient assez long. Pour le CNAME, c’est un oubli.

La zone inverse :

  • Oui, mais ici je vais quand même la laisser, juste histoire de garder une configuration cohérente par rapport à ce que je mettrai en prod par la suite (et j’aurai la délégation complète via l’autre fournisseur d’accès). Cette conf est une maquette.
  • Concernant les deux derniers points, je ne suis pas sûre de bien comprendre. Effectivement, la zone se nomme comme tu le dis, mais d’après toi, le nommage n’est pas correct dans la mesure où je ne gère qu’une seule ip, c’est bien ça ?
    Il faudrait donc que je renomme ma zone en 140.250.121.88.in-addr.arpa, mais alors, qu’est ce que ça changerait pour le contenu du fichier ?
  • Un reverse pour une adresse donnée : peux-tu développer stp, par rapport à mon exemple ?

Merci !

#4

Oui.

Supprimer le 140 puisqu’il ferait déjà partie du nom de la zone. Il n’y aurait que des enregistrements pour @.

Un seul enregistrement PTR par adresse, qui correspond à un des enregistrements A.

#5

Eh bien parfait, je viens de comprendre cette histoire de corrélation entre le nom de la zone reverse et le contenu de celle-ci par rapport au réseau.
Mettons que j’ai 4 IP publique, j’aurais pu garder le même nom de reverse et mettre dedans chaque IP (en lieu et place du 11 actuel), mais comme je n’en ai qu’une, je renomme ma zone reverse avec l’adresse complète de mon ip, tout en supprimant toute référence à celle-ci dans le fichier lui même.

Un point que je n’ai pas saisi du coup : Dois-je laisser ou non au moins un enregistrement PTR ou pas ? Si oui, lequel et sous quelle forme ? Tu suggères de supprimer les lignes avec 140, mais après tu évoques le fait de n’avoir qu’un enregistrement PTR par adresse, ce qui, dans mon esprit (certainement à mauvais titre) est contradictoire.

merci !

#6

Je n’ai rien compris à ce que tu as écrit.
Si tu as un bloc d’adresses IP publiques de taille inférieure à 256 avec délégation du reverse, soit le FAI fait une délégation de zone classique pour chaque adresse IP (peu probable), soit il fait une “classless delegation” pour le bloc, cf RFC 2317 - Classless IN-ADDR.ARPA delegation.
Tu ne peux pas utiliser le même nom de reverse pour chaque adresse (sauf si tu leur donne le même nom direct à toutes).
Quel “11 actuel” ?

Oui, évidemment. J’ai déjà écrit sous quelle forme : @ (l’origine, par défaut nom de la zone)

Relis-moi bien : j’ai écrit de supprimer le 140, pas les lignes avec 140.

#7

En me relisant, effectivement je n’étais pas clair et pour ce point, tu confirmes ce que je pensais.

Le 11 étant une erreur, je parlais de 140 (du numéro d’hôte, x.x.x.140, stricto sensu).

Désolé d’insister, mais je ne comprends toujours pas, un exemple sera plus parlant. Au final, ma zone devrait contenir :

root@test:~# cat /etc/bind/zones/140.250.121.88.in-addr.arpa.db

$TTL   86400
@       IN      SOA     ns.mondomaine.ovh. root.mondomaine.ovh. (
                         2018290520   ; Serial
                         28800        ; Refresh
                         14400        ; Retry
                         2419200      ; Expire
                         604800 )     ; Negative Cache TTL

;Name Server Information
        IN      NS      ns.mondomaine.ovh.
        IN      NS      puck.nether.net. ; sans objet ici car pas de delegation chez free

;Reverse lookup for Name Server
        IN      PTR     ns.mondomaine.ovh.

;PTR Record IP address to HostName
        IN      PTR     www.mondomaine.ovh.
        IN      PTR     mail.mondomaine.ovh.
        IN      PTR     smtp.mondomaine.ovh.
        IN      PTR     imap.mondomaine.ovh.
        IN      PTR     postfixadmin.mondomaine.ovh.
        IN      PTR     rainloop.mondomaine.ovh.
        IN      PTR     ftp.mondomaine.ovh.
        IN      PTR     mondomaine.ovh.

Ou bien :

$TTL   86400
@       IN      SOA     ns.mondomaine.ovh. root.mondomaine.ovh. (
                     2018290520   ; Serial
                     28800        ; Refresh
                     14400        ; Retry
                     2419200      ; Expire
                     604800 )     ; Negative Cache TTL

;Name Server Information
    IN      NS      ns.mondomaine.ovh.
    IN      NS      puck.nether.net. ; sans objet ici car pas de delegation chez free

;Reverse lookup for Name Server
    IN      PTR     ns.mondomaine.ovh.

C’est cette histoire de PTR que je ne comprends pas. Au final, je comprends qu’il ne doit y avoir dans la zone qu’un seul PTR, c’est donc cette version qui est juste ? Ici, je n’ai qu’un seul enregistrement PTR, qui correspond à un A dans la zone mondomaine.ovh .

Merci pour ta patience

#8

Oui, un seul PTR pour 140.250.121.88.in-addr.arpa. Tu peux le faire pointer vers n’importe lequel des noms qui pointent vers l’adresse IP. Pour plaire aux MX tâtillons, il vaudrait mieux que ce soit le nom annoncé par le MTA local dans son HELO/EHLO.

#9

Ok, parfait, c’est tout clair pour moi maintenant. Merci !