Le server DNS autorisé pour un domaine autorise-t-il la récursion pour permettre aux loggings CNAME de pointer vers d'autres domaines?

J'ai donc un domaine enregistré avec Dreamhost, qui apparemment ne fait pas de search récursive, et une application sur Heroku. Les applications Heroku sont toujours configurées pour utiliser un logging CNAME sur proxy.heroku.com .

Alors:

 Authoritative DNS: ns1.dreamhost.com (for foo.com) CNAME record: app.foo.com -> proxy.heroku.com Resolves to: Set of A records for EC2 IPs 

Certains clients ont essayé de se connecter à l'application par derrière un server DNS Windows Server 2003 qui a été utilisé par SERVFAIL de manière différente et ne peut pas résoudre le DNS. J'essaie de comprendre si c'est vraiment une question de configuration de mon côté ou de leur part, notamment par le titre:

Le server DNS autorisé pour un domaine doit-il être récursif pour permettre aux loggings CNAME de pointer vers d'autres domaines?

    Non, vous n'avez pas besoin de recursion pour les servers DNS autorisés. Selon ce que vous requestz, il est même considéré comme une bonne pratique (si possible) que votre server faisant autorité ne soit pas récursif car il s'agit d'une ligne de défense contre certaines attaques DoS. (Le document de Cisco est ici par exemple)

    Un exemple de mon domaine est ci-dessous (le server exécute Bind 9 et n'est pas récursif).

     ; <<>> DiG 9.5.1-P3 <<>> mail.<snip> @<my authoritative master> ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1216 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;mail.<snip>. IN A ;; ANSWER SECTION: mail.<snip>. 86400 IN CNAME ghs.google.com. ghs.google.com. 158151 IN CNAME ghs.l.google.com. ghs.l.google.com. 33 IN A 74.125.47.121 ;; AUTHORITY SECTION: google.com. 153556 IN NS ns4.google.com. google.com. 153556 IN NS ns2.google.com. google.com. 153556 IN NS ns3.google.com. google.com. 153556 IN NS ns1.google.com. ;; ADDITIONAL SECTION: ns1.google.com. 169823 IN A 216.239.32.10 ns2.google.com. 169823 IN A 216.239.34.10 ns3.google.com. 169823 IN A 216.239.36.10 ns4.google.com. 169823 IN A 216.239.38.10 

    Cela ressemble plus à une mauvaise configuration DNS au DNS Windows 2003 que toute autre chose.

    Les servers autorisés ne doivent PAS être configurés pour offrir un service récursif. Pas même pour contourner un bug potentiel de Microsoft.

    Je ne peux pas citer le chapitre et le verset en ce moment (si je le trouve, je vais mettre à jour). Cependant, c'est la "meilleure pratique courante" acceptée pour l'exploitation de servers DNS.

    Si un résolveur dans votre string de search returnne SERVFAIL cela indique simplement une mauvaise configuration quelque part ou que vous posez la mauvaise question (ou la bonne question avec les mauvais indicateurs).

    Dans votre cas, les servers dreamhost.com renvoient SERVFAIL si vous requestz une réponse récursive (ce qui se passe pour être ce que nslookup fait par défaut). Ils ont parfaitement le droit de le faire, ils sont des servers authentiques, pas récursifs.

    Sur mon système, si j'utilise dig place et spécifiquement désactiver la récursivité, je reçois:

     % dig +norecurse @ns1.dreamhost.com mail.scotchi.net. ; <<>> DiG 9.6.0-APPLE-P2 <<>> +norec @ns1.dreamhost.com mail.scotchi.net. ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54426 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 13 ;; QUESTION SECTION: ;mail.scotchi.net. IN A ;; ANSWER SECTION: mail.scotchi.net. 14400 IN CNAME ghs.google.com. 

    Dreamhost utilise powerdns (ugh), tout aussi mauvais … mais les résolveurs récursifs de Windows supposent en effet.

    La question est la suivante: pourquoi les boîtes Windows dns sur vos sites clients obtiennent SERVFAIL? Ils ne devraient pas l'être.

    Et, l'affiche ci-dessus est correcte – si vous êtes autorisé à un domaine, vous pouvez l'avoir cname, A, échouer, vous le nommer, à n'importe quel domaine / ip (vous ne devez pas connaître la colle à l'autre domaine ).

    Peut-être que c'est-à-dire que les résolveurs DNS qui ont demandé votre logging A (et a obtenu un nom c) ont pensé qu'il connaitrait également la colle pour heroku.com.

    Vous pouvez parsingr les servers de noms répertoriés pour la requête d'origine pour voir ce qui se passe, mais dans un scénario «pire cas», vous pouvez simplement dessiner des loggings «A» … ce serait simplement un PITA.

    Si vous souhaitez publier un domaine d'échec réel, c'est cool; vous pourriez aussi PM ou AIM nerdNG: p (J'adore find des problèmes de cause de racine avec dns. Aller fig.)

    J'ai cherché des questions "semblables" à la mienne ici et il semble y avoir quelques points similaires (p. Ex. Serveurs DNS Windows2003 et réponse SERVFAIL)

    Si quelqu'un a un lien vers le "bug potentiel de Microsoft" ci-dessus, cela ne voudrait-il pas afficher les détails.

    Très appréciée.