OVH Community, votre nouvel espace communautaire.

Changement des DNS


cassiopee
20/08/2012, 19h57
Cool Content pour toi

gobanban
20/08/2012, 19h07
Donc avec cPanel, il faut cliquer sur un bouton Synchronise DNS Records après avoir fait les modifs sur named.conf pour que ce soit pris en compte. Ca n'est dit nulle part, mais bon, je l'ai trouvé et ça marche!

Merci énormément pour ton aide sans laquelle j'aurais été perdu. J'essaierai d'aider les nouveaux utilisateurs de cPanel dans le futur

cassiopee
20/08/2012, 18h12
Ok, c'est ce qu'il me semblait : ce fichier que tu modifies n'est pas pris en compte par bind

Vraisemblablement, ce qui est utilisé c'est un fichier de configuration DNS de Cpanel,
peut-être dans sa base de données ou équivalent.

Donc il faudrait faire la manip de suppression du ou des "allow-transfer" depuis/dans CPanel
et redémarrer Bind depuis CPanel également.

Après je ne sais pas s'il re-créé des fichiers de configurations "named.conf"
à partir de sa base interne ou si ces derniers sont purement et simplement
ignorés.

Autre piste :

Il se peut également qu'il y a une notion de "cache" (fichiers ou répertoire)
pour les fichiers de configurations DNS et qu'il faille purger ce cache
afin de forcer CPanel à tenir compte des nouvelles directives.

J'adooore ces panels de gestion ...
(et encore, visuellement, CPanel est plutôt pas mal)

gobanban
20/08/2012, 18h01
C'est fait! Rien à signaler, le restart s'est passé sans pb.

cassiopee
20/08/2012, 17h53
Ok, faisons un autre test : à l'intérieur de la directive "options"
du "named.conf" ajoute la ligne :

Code:
 version "12345";
et ensuite redémarre bind (toujours "manuellement")

gobanban
20/08/2012, 17h48
et j'ai oublié le named.rfc1912.zones

Code:
// named.rfc1912.zones:
//
// Provided by Red Hat caching-nameserver package
//
// ISC BIND named zone configuration for zones recommended by
// RFC 1912 section 4.1 : localhost TLDs and address zones
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
zone "." IN {
        type hint;
        file "named.ca";
};

zone "localdomain" IN {
        type master;
        file "localdomain.zone";
        allow-update { none; };
};

zone "localhost" IN {
        type master;
        file "localhost.zone";
        allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
        type master;
        file "named.local";
        allow-update { none; };
};

zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
        type master;
        file "named.ip6.local";
        allow-update { none; };
};

zone "255.in-addr.arpa" IN {
        type master;
        file "named.broadcast";
        allow-update { none; };
};

zone "0.in-addr.arpa" IN {
        type master;
        file "named.zero";
        allow-update { none; };
};

gobanban
20/08/2012, 17h45
named.conf:

Code:
include "/etc/rndc.key";

controls {
        inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; };
};

options {
    /* make named use port 53 for the source of all queries, to allow
         * firewalls to block all ports except 53:
         */

     query-source    port 53;

    /* We no longer enable this by default as the dns posion exploit
        has forced many providers to open up their firewalls a bit */

    // Put files that named is allowed to write in the data/ directory:
    directory                "/var/named"; // the default
    pid-file                 "/var/run/named/named.pid";
    dump-file                "data/cache_dump.db";
    statistics-file          "data/named_stats.txt";
   /* memstatistics-file     "data/named_mem_stats.txt"; */
notify yes;
};

logging {
/*      If you want to enable debugging, eg. using the 'rndc trace' command,
 *      named will try to write the 'named.run' file in the $directory (/var/named").
 *      By default, SELinux policy does not allow named to modify the /var/named" directory,
 *      so put the default debug log file in data/ :
 */
    channel default_debug {
            file "data/named.run";
            severity dynamic;
    };
};


// All BIND 9 zones are in a "view", which allow different zones to be served
// to different types of client addresses, and for options to be set for groups
// of zones.
//
// By default, if named.conf contains no "view" clauses, all zones are in the
// "default" view, which matches all clients.
//
// If named.conf contains any "view" clause, then all zones MUST be in a view;
// so it is recommended to start off using views to avoid having to restructure
// your configuration files in the future.

view "localhost_resolver" {
/* This view sets up named to be a localhost resolver ( caching only nameserver ).
 * If all you want is a caching-only nameserver, then you need only define this view:
 */
    match-clients         { 127.0.0.0/24; };
    match-destinations    { localhost; };
    recursion yes;

    zone "." IN {
        type hint;
        file "/var/named/named.ca";
    };

    /* these are zones that contain definitions for all the localhost
     * names and addresses, as recommended in RFC1912 - these names should
     * ONLY be served to localhost clients:
     */
    include "/var/named/named.rfc1912.zones";
};

view "internal" {
/* This view will contain zones you want to serve only to "internal" clients
   that connect via your directly attached LAN interfaces - "localnets" .
 */
    match-clients        { localnets; };
    match-destinations    { localnets; };
    recursion yes;

    zone "." IN {
        type hint;
        file "/var/named/named.ca";
    };

    // include "/var/named/named.rfc1912.zones";
    // you should not serve your rfc1912 names to non-localhost clients.

    // These are your "authoritative" internal zones, and would probably
    // also be included in the "localhost_resolver" view above :

zone "itilog.com" {
        type master;
        file "/var/named/itilog.com.db";
};


zone "gps-coordinates.net" {
        type master;
        file "/var/named/gps-coordinates.net.db";
};


zone "pensez-y.fr" {
        type master;
        file "/var/named/pensez-y.fr.db";
};

};

view    "external" {
/* This view will contain zones you want to serve only to "external" clients
 * that have addresses that are not on your directly attached LAN interface subnets:
 */
    recursion no;
    // you'd probably want to deny recursion to external clients, so you don't
    // end up providing free DNS service to all takers

    // all views must contain the root hints zone:
    zone "." IN {
        type hint;
        file "/var/named/named.ca";
    };

    // These are your "authoritative" external zones, and would probably
    // contain entries for just your web and mail servers:

    // BEGIN external zone entries


zone "itilog.com" {
        type master;
        file "/var/named/itilog.com.db";
};


zone "gps-coordinates.net" {
        type master;
        file "/var/named/gps-coordinates.net.db";
};


zone "pensez-y.fr" {
        type master;
        file "/var/named/pensez-y.fr.db";
};

};
rndc.key:

Code:
key "rndc-key" {
        algorithm hmac-md5;
        secret "/xxxxxxxxx";
};
rndc.conf:

Code:
# Start of rndc.conf
key "rndc-key" {
        algorithm hmac-md5;
        secret "/w4wYbZAQ01F6ucu6F/W+A==";
};

options {
        default-key "rndc-key";
        default-server 127.0.0.1;
        default-port 953;
};
# End of rndc.conf

# Use with the following in named.conf, adjusting the allow list as needed:
# key "rndc-key" {
#       algorithm hmac-md5;
#       secret "/xxxxxxxxxx";
# };
#
# controls {
#       inet 127.0.0.1 port 953
#               allow { 127.0.0.1; } keys { "rndc-key"; };
# };
# End of named.conf

cassiopee
20/08/2012, 17h26
Nope, redémarrer le VPS ne servirait à rien de plus.

Le souci est que plus haut tu dis que plus aucun "allow-transfer" n'est en place
or le transfert est toujours refusé par bind, donc c'est qu'il y a encore quelque
part une directive qui limite le transfert (un allow-transfer actif donc).

Quel est le contenu intégral du ou des fichiers de configuration de bind actuellement ?

( "/etc/named.conf" et fichiers inclus à partir de ce dernier )

gobanban
20/08/2012, 17h14
Je l'avais déjà fait, et je l'ai refait (/etc/init.d/named restart). Le résultat de l'opération donne:

Code:
root@vps11005 [/]# /etc/init.d/named restart
Stopping named: .                                          [  OK  ]
Starting named:                                            [  OK  ]
Est-ce qu'un reboot du VPS peut aider?

Merci encore pour toute l'aide!

cassiopee
20/08/2012, 16h42
Ok, ça semble tout bon. Le souci à mon avis est le non-redémarrage correct de bind
(parce que je ne peux toujours pas initier un transfert de ton .fr)

Il faut passer par le script de bind et non par cpanel.

Quelque chose de ce genre :

/etc/init.d/named restart

/etc/rc.d/named restart

/etc/init.d/bind restart

/etc/rc.d/bind restart

ou équivalent, selon ta distribution.

gobanban
20/08/2012, 16h17
Merci Cassiopee, j'avais eu l'idée d'enlever la directive sur ton post

Voilà sinon j'ai fait un restart de bind en console, et voici le résultat de la commande checkconf:

Code:
zone localdomain/IN: loaded serial 42
zone localhost/IN: loaded serial 42
zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700
zone 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 1997022700
zone 255.in-addr.arpa/IN: loaded serial 42
zone 0.in-addr.arpa/IN: loaded serial 42
zone itilog.com/IN: loaded serial 2012081704
zone gps-coordinates.net/IN: loaded serial 2012081804
zone pensez-y.fr/IN: loaded serial 2012081904
zone itilog.com/IN: loaded serial 2012081704
zone gps-coordinates.net/IN: loaded serial 2012081804
zone pensez-y.fr/IN: loaded serial 2012081904

cassiopee
20/08/2012, 15h50
Citation Envoyé par Nowwhat
Sans
allow-transfer { a.b.c.d; };
ou a.b.c.d est l'IP de ton DNS secondaire (un serveur dns chez OVH)
ça ne va jamais marcher.
Euh ... si si, par défaut, s'il n'y a aucune directive "allow-transfer",
le transfert est autorisé à tous, donc y compris sdns2.ovh.net

Arghh, ça ne marche toujours pas...
Mais encore ?

A l'heure actuelle, pour le nom de domaine "pensez-y.fr", sdns2.ovh.net
n'est toujours pas synchronisé (donc si ton navigateur a essayé de l'utiliser
pour accéder à ton site web, c'est "normal" que l'accès ne fonctionne pas).

En revanche, le transfert de zone n'est toujours pas possible pour moi
par exemple. Ce qui veut dire que si tu as bien supprimé tous les
"allow-transfer", cette nouvelle configuration n'a pas été prise en compte
par bind ( as-tu redémarré bind après cette modification ?
Redémarrer "manuellement", pas via cpanel car j'ai déjà vu le gag où le panel
ne redémarrait pas vraiment bind ).

Que donne comme résultat un :

Code:
named-checkconf -z
?

Nowwhat
20/08/2012, 15h33
Sans
allow-transfer { a.b.c.d; };
ou a.b.c.d est l'IP de ton DNS secondaire (un serveur dns chez OVH)
ça ne va jamais marcher.

Base toi sur http://forums.ovh.com/showthread.php?t=82074 pour commencer, ou soit prêt à laisser la gérance de tes domaines chez OVH.

gobanban
20/08/2012, 15h23
Arghh, ça ne marche toujours pas...
J'ai carrément enlevé la directive allow-transfer, sans plus de succès. Je ne sais plus quoi essayer

Nowwhat
20/08/2012, 11h46
Bonjour.
Citation Envoyé par gobanban
En gros, comment tu as fait pour identifier ce pb que je sois capable de le faire la prochaine fois
En gros: demander au processus de te communiquer ce qu'il fait

Balance ceci dans ton /etc/bind/named.conf.options :

Code:
logging {
    channel "debug" {
        file "/var/log/bind9/debug.log" versions 10 size 5m;
        print-time yes;
        print-category yes;
        severity dynamic;
    };
    category "default" { "debug"; };
    category "database" { "debug"; };
    category "security" { "debug"; };
    category "config" { "debug"; };
    category "resolver" { "debug"; };
    category "xfer-in" { "debug"; };
    category "xfer-out" { "debug"; };
    category "notify" { "debug"; };
    category "client" { "debug"; };
    category "unmatched" { "debug"; };
    category "network" { "debug"; };
    category "update" { "debug"; };
    category "dispatch" { "debug"; };
    category "dnssec" { "debug"; };
    category "lame-servers" { null; };

    channel "general" {
        file "/var/log/bind9/general.log" versions 10 size 5m;
        print-time yes;
        print-category yes;
        severity dynamic;
    };
    category "general" { "general"; };
        
    channel b_query {
        file "/var/log/bind9/query.log" versions 10 size 5m;
        print-time yes;
        print-category yes;
        severity dynamic;
    };
    category "queries" { "b_query"; };
};
Avant de redémarrer bind, check ton config.
(de mémoire: named-confcheck -z)
Avant de redémarrer bind, vérifié que toutes les chemins dans le code proposé sont ok pour ton serveur.

Dès que bind tourne de nouveau, adresse toi ici http://forum.ovh.com/showthread.php?...light=xfer-out - message 8.

Ce qui ce passe maintenant:
Dès démarrage de bind, il va notifier ton dns secondaire qu'un changement pourrait lui intéresser - incrémente le SOA pour forcer une transfert.
Dès que le dns secondaire a l'envie de se synchroniser, il y aura un xfer-out dans te logs de bind.

cassiopee
20/08/2012, 11h21
Toujours "spéciaux" ces panels d'administration

Enfin, l'essentiel est que ça fonctionne

gobanban
20/08/2012, 11h11
On va attendre alors!

Pour l'histoire du point dans l'adresse email, ça fait planter cpanel de l'échapper. Mais j'ai pu juste enlever le point car si tu as xx.yy@gmail.com, tu as aussi par défaut xxyy@gmail.com - merci pour le conseil bonus en tous cas!

cassiopee
20/08/2012, 10h46
Citation Envoyé par gobanban
Bonjour,

Merci beaucoup pour cette réponse. J'ai donc rajouter l'IP 213.251.188.141 dans le fichier named.conf.
Impec.

Comment je peux vérifier maintenant si mon VPS accepte maintenant le transfert de zone pour sdns2.ovh.net? En gros, comment tu as fait pour identifier ce pb que je sois capable de le faire la prochaine fois
Réponse emprique : il suffit d'attendre (que sdns2.ovh.net se synchronise)
normalement c'est fait sous moins de deux heures, parfois un peu plus.

Une commande pour voir où ça en est pendant ce temps :

Code:
dig @sdns2.ovh.net soa pensez-y.fr
Une bonne réponse serait (comme on l'a actuellement avec ton VPS) :

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32247
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; ANSWER SECTION:
pensez-y.fr. 86400 IN SOA vps11005.ovh.net. xx.yy.gmail.com. 2012081902 86400 7200 3600000 86400
(c'est moi qui ait remplacé la vraie adresse email par xx/yy pour éviter le spam ; à noter que pour l'adresse email de contact :
http://forum.ovh.com/showpost.php?p=485624&postcount=6 )

Tant que sdns2.ovh.net n'est pas synchronisé, la réponse sera (comme actuellement) :

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55341
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

gobanban
20/08/2012, 10h35
Bonjour,

Merci beaucoup pour cette réponse. J'ai donc rajouter l'IP 213.251.188.141 dans le fichier named.conf. Comment je peux vérifier maintenant si mon VPS accepte maintenant le transfert de zone pour sdns2.ovh.net? En gros, comment tu as fait pour identifier ce pb que je sois capable de le faire la prochaine fois

Merci,
Albna

cassiopee
20/08/2012, 10h01
Dans ton cas ce n'est pas une désynchronisation des serveurs DNS
mais une absence de début de synchronisation

Sinon cf par là : http://forums.ovh.com/showthread.php?t=82074
car ce sont les mêmes vérifications à faire.

Pour l'instant ton VPS refuse, par défaut, les transferts de zones ( = synchronisation),
ce qui est bien mais il faut s'assurer que le transfert est bien autorisé pour
"sdns2.ovh.net" sinon il ne pourra pas se synchroniser avec ton VPS.

gobanban
20/08/2012, 09h08
Bonjour,

Je suis en train de procéder aux changements de DNS de trois domaines vers mon VPS (ip:46.105.3.27). Je n'arrive pas à résoudre un problème avec le dns secondaire sdns2.ovh.net.
Les 3 domaines sont:
- gps-coordinates.net
- itilog.com
- pensez-y.fr

J'ai bien indiqué sdns2.ovh.net comme dns secondaire dans cpanel, et j'ai aussi fait l'enregistrement des ndd dans le manager v5 sous paramètres avancés. Mais quand je fais le zone check, j'ai toujours l'erreur fatale (et ce depuis hier soir):

[TEST présence d'un enregistrement SOA]: échec du serveur: (SOA itilog.com)
sdns2.ovh.net/2001:41D0:1:4A8D::1

Je dois avouer que je ne m'en suis rendu compte qu'après avoir essayé de transférer le .fr car j'essuie un refus (ce qui n'est pas le cas avec les autres extensions).

Merci de votre aide,
Alban