HTTPS redirection à partir de la racine du domaine (c'est à dire de l'apex ou de "nues") de " www " sous-domaine sans navigateur de vomir?

DNS enregistrements A besoin que d'une adresse IP à être codées en dur dans votre application la configuration DNS

...qui Heroku recommande d'éviter. Heroku suggère deux solutions:

...à l'aide d'un fournisseur de DNS qui prend en charge l'enregistrement CNAME les fonctionnalités à l'apex, et à l'aide de sous-domaine redirection`.

Ma question tourne autour de la dernière option (parce que l'ancien n'est pas pris en charge par DreamHost autant que je sache):

Est-il possible de rediriger à partir de la racine (c'est à dire de l'apex ou de "nues") de domaine pour le 'www' sous-domaine pour les requêtes HTTPS sans le navigateur de vomir?

Heroku ne pense pas:

...les applications nécessitant un cryptage SSL doit utiliser l'ALIAS/NOM de la configuration à la racine du domaine. Sous-domaine de redirection sera la cause d'une erreur de navigateur lorsque la racine de domaine est demandée sur SSL (c'est à dire https://example.com).

...mais j'espère que c'est une incomplètes ou incorrectes) déclaration.

CLARIFICATION DE MISE À JOUR:

Le vrai problème avec la redirection à partir de l'apex de 'www' est que de taper https://example.com directement dans un navigateur de soulever un avertissement de certificat. Bien sûr, c'est un cas limite, mais pas un petit.

SOLUTION DE MISE À JOUR:

J'ai résolu ce problème avec DNSimple. (N'ai même pas eu le transfert de mon nom de domaine!)

Je crois que easyDNS offre une fonctionnalité similaire, mais la surprise de constater que la plupart des autres domaine de l'hébergement d'entreprises ne sont pas.

  • Le problème, c'est que votre serveur doit retourner un certificat SSL (afin de configurer la connexion HTTPS) avant de se les en-têtes de demande, tels que la Host en-tête, et donc avant qu'il ne sait quel nom d'hôte est utilisé. Donc, si elle renvoie un certificat SSL qui dit que c'est pour la www-sous-domaine, l'utilisateur reçoit un message d'erreur lors de la visite du domaine racine; et vice versa. (Sauf si vous utilisez des hôtes virtuels pour exécuter ces deux domaines séparer les adresses IP, dans ce cas, vous pouvez identifier l'accueil de cette façon.)
  • upvoted pour "vomir"
InformationsquelleAutor thewillcole | 2013-05-14
  1. 86

    Il y a deux distincts mais interdépendants, les niveaux d'indirection à considérer ici. La première est ce que l'adresse IP d'un nom DNS, finalement, décide de. La deuxième est ce que le serveur à l'adresse IP n'.

    Rappelez-vous que lorsque vous tapez une URL dans un navigateur, la première chose qui arrive, c'est une recherche DNS. Habituellement, cela est géré par le système d'exploitation ne le navigateur lui-même.

    De sorte que votre navigateur va demander à l'OS, "quelle est l'adresse de example.com?" L'OS va chercher le dossier, et si cela devient un CNAME, va chercher que record, jusqu'à ce qu'il trouve un A enregistrement. L'OS répond alors le navigateur avec une réponse.

    Votre navigateur ouvre une connexion TCP vers l'adresse IP:

    • Si une URL http://, il se connecte sur le port 80, puis émet une requête HTTP.
    • Si un https://URL de l', il se connecte sur le port 443, établit une connexion TLS/SSL (ce qui signifie la validation de certificats), puis émet une requête HTTP à travers le canal sécurisé.

    Seulement à ce point peut redirection HTTP arriver. Le navigateur envoie une requête (GET /, et le serveur peut répondre avec une 301 à toute autre URL.

    Comprendre que "le sous-domaine de redirection de" services offerts par les bureaux d'enregistrement ne sont rien de plus qu'un simple serveur HTTP qui émet des redirections 301. Lorsque vous optez pour un bureau d'enregistrement de l'option de redirection, ils ont juste mis la A enregistrement de votre nom de domaine de l'apex à un serveur de contrôle, et que le serveur indique aux navigateurs pour aller à http://www.example.com.

    Puisque la plupart des bureaux d'enregistrement ne vous permet pas de télécharger un certificat SSL pour leur serveur de redirection, les navigateurs ne peuvent pas établir la connexion sécurisée au serveur, et par conséquent, ils n'ont jamais question d'une requête HTTP. Ainsi, les demandes de https://example.com échouer.

    Alors pourquoi ne pouvez-vous pas juste CNAME de l'apex? Il est interdit.

    Le domaine du système fournit une telle fonctionnalité en utilisant le nom canonique
    (CNAME) RR [Enregistrement de Ressource]. Un CNAME RR identifie son propriétaire comme un alias, et
    spécifie le correspondant nom canonique dans le RDATA section de la
    RR. Si un CNAME RR est présent à un nœud, pas d'autres données doivent être
    présent    , ce qui garantit que les données pour un nom canonique et son alias
    ne peut pas être différent. Cette règle garantit également que le cache CNAME peut être
    utilisé sans vérifier avec un serveur faisant autorité pour les autres types RR.

    La spécification exige qu'un CNAME record d'être le seul enregistrement pour une (sous -) domaine. C'est en contradiction avec l'exigence d'avoir un SOA record sur l'apex. (Il y a quelques efforts pour changer les spécifications pour permettre CNAME et SOA à coexister, mais il ya encore beaucoup de cassé SMTP implémentations qui sera confondu par la CNAME sur un domaine).

    Vous disposez des options suivantes pour obtenir SSL de travail sur l'apex:

    • Utiliser un service tiers qui prend en charge le protocole SSL sur le serveur de redirection. Vous aurez probablement payer pour cela. Voici un service. Je ne serait pas recommandons cette voie, puisqu'il prend le contrôle de la fiabilité de vos mains, et vous oblige à remettre les clés de votre certificat SSL pour quelqu'un qui peut ou peut ne pas être digne de confiance.
    • Lancer votre propre serveur de redirection. Depuis le sommet implique un A enregistrement, vous aurez besoin d'une adresse IP statique, les services comme Heroku et d'AWS ELB ne fournissent pas. Donc, si vous êtes dans un environnement de cloud, il sera très difficile (voire impossible) pour garantir la fiabilité. Sur le côté positif, vous gardez le contrôle de vos clés SSL.
    • Utiliser un hôte DNS qui vous permet de définir un alias. Point de l'alias à votre Heroku de domaine/ELB/whatever. Ceci est probablement la meilleure option.

    Un alias n'est pas techniquement un type d'enregistrement DNS. Au lieu de cela, c'est une configuration particulière de l'hôte DNS secondaires qui renvoie un A l'enregistrement à partir du résultat d'une autre recherche. En d'autres termes:

    1. Vos questions sur l'OS d'une requête DNS pour example.com de votre hôte DNS.
    2. Votre hôte DNS lit l'interne de la configuration de l'alias, et émet une requête DNS pour ce domaine. Donc, si vous avez un alias mis en place pour example.herokuapp.com, elle ressemblerait à la A enregistrement de ce domaine.
    3. L'hôte DNS renvoie une simple A enregistrement avec l'IP(s) qu'il a obtenu à partir de l'alias de recherche.

    Avec un enregistrement d'alias, vous pouvez pointer votre apex pour le même nuage de l'équilibrage de charge de votre www de domaine est CNAMEd pour. En supposant que vous avez mis en place SSL sur le www domaine, le nu de domaine fonctionne très bien. À ce point, c'est votre choix si votre application envoie une redirection, ou tout simplement de votre contenu directement sur le nu de domaine.

    • Eh bien, il semble que Amazon vous peut en fait point d'Un enregistrement à un ELB à l'aide de Route53, qui sera de retour quel que soit IP de l'équilibreur de charge a, donc il suffit de faire votre utilisation du domaine Route53 serveurs DNS, et payer pour cela (c'est pas beaucoup...)
    • Quelqu'un de nouveau à la configuration d'un domaine avec un fournisseur de cloud à lire cette première réponse!!
    • Oh pinaise, ce post est donc parfaitement détaillées.... maintenant je sais pourquoi je suis triste : (
    • L'Option 3 ne fonctionne pas toujours. À partir de mes expériences, même lorsqu'il est correctement configuré, les serveurs de Google ignorer https://example.com tout en répondant aux https://www.example.com
    • cela devrait mentionner CNAME aplatissement, je pense que blog.cloudflare.com/...
    InformationsquelleAutor josh3736
  2. 2

    Vous avez besoin d'un certificat qui fixe à la fois http://www.example.com et example.com.

    InformationsquelleAutor nmit026
  3. 0

    NOTE: je n'ai pas essayé cela avec Heroku app.
    Je suis encore le partage de cette solution ici car c'est le premier stackoverflow page qui s'affiche pour "redirection de domaine de niveau supérieur pour www version" de recherche. Il peut aider les autres qui sont à la recherche d'une réponse générique de redirection.

    J'ai réussi redirigé nu de domaine www version.
    En outre, j'ai également redirigés vers la version de HTTP à HTTPS version à l'aide de google domaines paramètres DNS dans la synthèse des dossiers.

    1. Supprimer tout 'A' enregistrement pour '@' dans votre DNS.
    2. Ajouter un synthétique enregistrement avec sous-domaine = '@' et le rediriger vers www version de votre site web.
    3. Après l'addition, de modifier cette même dossier et de modifier la valeur par défaut " http://www.example.com ' à 'https://www.example.com' . Notez le " s " http ici. Cliquez Sur Enregistrer.
    4. Que c'est. Votre redirection est maintenant pris en charge par les paramètres DNS.

    Détail les étapes sont documentées ici:
    https://www.am22tech.com/redirect-naked-domain-www-http-https-google-domains/

    InformationsquelleAutor Anil Gupta