Urgent ! Probleme de création de sous domaine sur le serveur plesk

[Locenfrance]

Bonjour,

Je suis ni webmaster, ni ingénieur, mais seulement gérant d'un site qui doit être lancé début Septembre.

Le site que nous mettons en ligne est un portail d'annonces et de sites internet indépendants.
Ces sites internet sont créés via un logiciel qui créer automatiquement les sous-domaines sur Plesk.
Jusque là tout va bien.

Cependant mon problème est le suivant :

Les sous-domaines se créer bien sur plesk et charge correctement les templates des sites. Cependant les sites ne sont pas mis en ligne sur internet et au pire des cas ne nous amène pas sur l'interface de Plesk.
Ce problème n'apparait pas à chaque fois mais de temps en temps, car certains sites sont bien mis en ligne.
Et même si on décide de supprimer le domaine manuellement et de le recréer cela ne marche pas.

La personne qui s'occupe de développement du site s'arrache les cheveux pour connaître la raison et me demande l'avis d'un administrateur réseau, c'est pour cela que je vous pose la question à tous ( administrateur réseau ou pas).

Si jamais quelqu'un connais la réponse à mon problème ou à une piste pour nous aider, n'hésitez surtout pas.
C'est assez urgent compte tenu de la date de lancement du site.

Merci.

[Marie-Aude]

ça serait sans doute bien si "la personne" venait directement. Cependant, à cette heure ci, je ne sais pas si les spécialistes trainent sur WRI. Pour un dépannage urgent un vendredi à 22h il vaut mieux avoir une relation établie avec un admin réseau ou plutôt en l'occurence un admin serveur

[IllusionPerdu]

Avec un peux plus de détail sur les différentes configuration aiderais surement a mieux comprendre le problème... Comment est configurer le serveur DNS car ça peut être juste un problème de propagation de celui ci et ce qui laisserais pensées que le site n'est pas enligne...

[spout]

Teste les domaines avec un outil du style: http://intodns.com/

[Leonick]

peut être un délais de rafraichissent du serveur dns trop important

[Locenfrance]

Voici le rapport de IntoDNS. Je ne sais pas si cela peut vous aider à mieux comprendre la configuration du serveur.
Désolé pour la présentation.


Category Status Test name Information send feedback
Parent Domain NS records Nameserver records returned by the parent servers are:

sdns1.ovh.net. ['213.251.188.140'] [TTL=172800]
ns300396.ovh.net. ['91.121.31.111'] [TTL=172800]

g.gtld-servers.net was kind enough to give us that information.
TLD Parent Check Good. g.gtld-servers.net, the parent server I interrogated, has information for your TLD. This is a good thing as there are some other domain extensions like "co.us" for example that are missing a direct check.
Your nameservers are listed Good. The parent server g.gtld-servers.net has your nameservers listed. This is a must if you want to be found as anyone that does not know your DNS servers will first ask the parent nameservers.
DNS Parent sent Glue Good. The parent nameserver sent GLUE, meaning he sent your nameservers as well as the IPs of your nameservers. Glue records are A records that are associated with NS records to provide "bootstrapping" information to the nameserver.(see RFC 1912 section 2.3)
Nameservers A records Good. Every nameserver listed has A records. This is a must if you want to be found.
NS NS records from your nameservers NS records got from your nameservers listed at the parent NS are:

sdns1.ovh.net ['213.251.188.140'] [TTL=86400]
ns300396.ovh.net ['91.121.31.111'] [TTL=86400]

Recursive Queries Good. Your nameservers (the ones reported by the parent server) do not report that they allow recursive queries for anyone.
Same Glue The A records (the GLUE) got from the parent zone check are the same as the ones got from your nameservers. You have to make sure your parent server has the same NS records for your zone as you do according to the RFC. This tests only nameservers that are common at the parent and at your nameservers. If there are any missing or stealth nameservers you should see them below!
Glue for NS records INFO: GLUE was not sent when I asked your nameservers for your NS records.This is ok but you should know that in this case an extra A record lookup is required in order to get the IPs of your NS records. The nameservers without glue are:
213.251.188.140
91.121.31.111
You can fix this for example by adding A records to your nameservers for the zones listed above.
Mismatched NS records OK. The NS records at all your nameservers are identical.
DNS servers responded Good. All nameservers listed at the parent server responded.
Name of nameservers are valid OK. All of the NS records that your nameservers report seem valid.
Multiple Nameservers Good. You have multiple nameservers. According to RFC2182 section 5 you must have at least 3 nameservers, and no more than 7. Having 2 nameservers is also ok by me.
Nameservers are lame OK. All the nameservers listed at the parent servers answer authoritatively for your domain.
Missing nameservers reported by parent OK. All NS records are the same at the parent and at your nameservers.
Missing nameservers reported by your nameservers OK. All nameservers returned by the parent server g.gtld-servers.net are the same as the ones reported by your nameservers.
Domain CNAMEs OK. RFC1912 2.4 and RFC2181 10.3 state that there should be no CNAMEs if an NS (or any other) record is present.
NSs CNAME check OK. RFC1912 2.4 and RFC2181 10.3 state that there should be no CNAMEs if an NS (or any other) record is present.
Different subnets OK. Looks like you have nameservers on different subnets!
IPs of nameservers are public Ok. Looks like the IP addresses of your nameservers are public. This is a good thing because it will prevent DNS delays and other problems like
DNS servers allow TCP connection OK. Seems all your DNS servers allow TCP connections. This is a good thing and useful even if UDP connections are used by default.
Different autonomous systems OK. It seems you are safe from a single point of failure. You must be careful about this and try to have nameservers on different locations as it can prevent a lot of problems if one nameserver goes down.
Stealth NS records sent Ok. No stealth ns records are sent
SOA SOA record The SOA record is:
Primary nameserver: ns300396.ovh.net
Hostmaster E-mail address: vincent.vdb-creation.fr
Serial #: 2011082699
Refresh: 10800
Retry: 3600
Expire: 604800 1 weeks
Default TTL: 10800
NSs have same SOA serial OK. All your nameservers agree that your SOA serial number is 2011082699.
SOA MNAME entry OK. ns300396.ovh.net That server is listed at the parent servers.
SOA Serial Your SOA serial number is: 2011082699. This appears to be in the recommended format of YYYYMMDDnn.
SOA REFRESH OK. Your SOA REFRESH interval is: 10800. That is OK
SOA RETRY Your SOA RETRY value is: 3600. Looks ok
SOA EXPIRE Your SOA EXPIRE number is: 604800.Looks ok
SOA MINIMUM TTL Your SOA MINIMUM TTL is: 10800. This value was used to serve as a default TTL for records without a given TTL value and now is used for negative caching (indicates how long a resolver may cache the negative answer). RFC2308 recommends a value of 1-3 hours. Your value of 10800 is OK.
MX MX Records Your MX records that were reported by your nameservers are:

10 mail.locenfrance.com 91.121.31.111

[These are all the MX records that I found. If there are some non common MX records at your nameservers you should see them below. ]
Different MX records at nameservers Good. Looks like all your nameservers have the same set of MX records. This tests to see if there are any MX records not reported by all your nameservers and also MX records that have the same hostname but different IPs
MX name validity Good. I did not detect any invalid hostnames for your MX records.
MX IPs are public OK. All of your MX records appear to use public IPs.
MX CNAME Check OK. No problems here.
MX A request returns CNAME OK. No CNAMEs returned for A records lookups.
MX is not IP OK. All of your MX records are host names.
Number of MX records OK. Looks like you only have one MX record at your nameservers. You should be careful about what you are doing since you have a single point of failure that can lead to mail being lost if the server is down for a long time.
Mismatched MX A OK. I did not detect differing IPs for your MX records.
Duplicate MX A records OK. I have not found duplicate IP(s) for your MX records. This is a good thing.
Reverse MX A records (PTR) Your reverse (PTR) record:
111.31.121.91.in-addr.arpa -> ns300396.ovh.net
You have reverse (PTR) records for all your IPs, that is a good thing.
WWW WWW A Record Your www.locenfrance.com A record is:
www.locenfrance.com -> locenfrance.com -> [ 91.121.31.111 ]

[Looks like you have CNAME's]
IPs are public OK. All of your WWW IPs appear to be public IPs.
WWW CNAME OK. You do have a CNAME record for www.locenfrance.com.Your CNAME entry also returns the A record for the CNAME entry, which is good.

[Locenfrance]

Avec un peux plus de détail sur les différentes configuration aiderais surement a mieux comprendre le problème... Comment est configurer le serveur DNS car ça peut être juste un problème de propagation de celui ci et ce qui laisserais pensées que le site n'est pas enligne...

Bonjour,

Je ne sais pas si ce que j'ai mis sur la configuration du serveur peut t'aider à mieux comprendre.

Salutation

[Locenfrance]

Nouvelle informations concernant le problème.

Nous avons trouvé la source du problème mais nous ne savons pas comment agir le résoudre.

Plesk ne créer pas les zones DNS de certains Sous domaines.

Manuellement nous arrivons à créer les zones DNS des sous domaines qui ne fonctionnent pas mais nous ne savons pas quelle configuration changer pour que le problème se résoude automatiquement.