Un enregistrement DNS générique est-il une mauvaise pratique?

18

J'ai demandé à mon hébergeur d'ajouter trois sous-domaines pointant tous vers l'IP de l'enregistrement A. Il semble qu'il ait simplement ajouté un enregistrement DNS générique car tout sous-domaine aléatoire se résout maintenant à mon IP. Cela me convient d'un point de vue technique, car il n'y a pas de sous-domaines pointant ailleurs. Là encore, je n'aime pas qu'il ne fasse pas ce que j'ai demandé. Et donc je me demande s'il y a d'autres raisons de lui dire de changer cela. Y a-t-il?

Le seul point négatif que j'ai trouvé est que quelqu'un pourrait créer un lien vers mon site en utilisant http://i.dont.like.your.website.mywebsite.tld.

domain-name-system subdomain wildcard agent de problème
la source
8
Quelqu'un pourrait se connecter à votre serveur en utilisant " i.dont.like.your.website.mywebsite.tld " mais votre serveur ne devrait pas répondre à moins qu'il ne soit configuré pour y répondre (via des hébergeurs ou des hôtes virtuels).
joeqwerty
6
Dans certains cas, des caractères génériques peuvent être requis. Par exemple, des applications Web multi-locataires comme Wordpress peuvent être configurées pour générer automatiquement de nouvelles instances à l'aide de sous-domaines - par exemple site1.blog.example.com, site2.blog.example.com - avec le caractère générique en place pour *.blog.example.com, vous ne pas besoin d'aller configurer chacun d'eux individuellement.
jscott

Réponses:

16

Si vous mettez un ordinateur dans ce domaine, vous obtiendrez des échecs DNS bizarres, lorsque vous tenterez de visiter un site aléatoire sur Internet, vous arriverez à la place.

Considérez: vous êtes propriétaire du domaine example.com. Vous configurez votre poste de travail et le nommez. ... disons le let, yukon.example.com. Maintenant, vous remarquerez /etc/resolv.confqu'il contient la ligne:

search example.com

C'est pratique car cela signifie que vous pouvez effectuer des recherches de nom d'hôte, par exemple, wwwqui rechercheront www.example.comautomatiquement pour vous. Mais il a un côté sombre: si vous visitez, disons, Google, il recherchera www.google.com.example.com, et si vous avez un DNS générique, cela se résoudra sur votre site, et au lieu d'atteindre Google, vous vous retrouverez sur votre propre site.

Cela s'applique également au serveur sur lequel vous exécutez votre site Web! S'il doit appeler des services externes, les recherches de nom d'hôte peuvent échouer de la même manière. Ainsi, api.twitter.compar exemple, devient soudainement api.twitter.com.example.com, les routes reviennent directement à votre site, et bien sûr échoue.

C'est pourquoi je n'utilise jamais de DNS générique.

Michael Hampton
la source
3
@ChrisLively Blâme les systèmes Linux modernes d'être "utiles" et de les avoir ajoutés. BTW, utiliser ".local" est vraiment une mauvaise pratique, et pas seulement dans les environnements Windows.
Michael Hampton
6
J'ai en fait blogué à ce sujet en ce qui concerne un environnement Windows . Sans oublier qu'au moins trois groupes ont soumissionné sur le TLD .local maintenant que l'ICANN les vend à quiconque possède un portefeuille suffisamment substantiel. .localn'est pas réservé et ne doit pas être utilisé. Cela viole les RFC et n'est pas du tout nécessaire. La meilleure pratique consiste à utiliser un sous-domaine de troisième niveau délégué pour les ressources internes comme internal.company.com. Ce n'est pas parce que vous voyez beaucoup de choses que ça se passe bien.
MDMarra
2
Pourriez-vous s'il vous plaît me diriger vers la section de la RFC 2606 qui réserve .local? J'ai lu ce RFC au moins une douzaine de fois avec des gens qui l'utilisent dans cet argument et je peux vous dire avec certitude qu'il n'est pas là.
MDMarra
2
@Zypher En fait, cela n'a jamais été recommandé par Microsoft (cela a été démystifié dans mon blog également. Allez le lire, c'est un bon), mais le fait que SBS livré .localpar défaut ait vraiment fait ressembler MS à un gâchis à cet égard. SBS a été livré avec cette configuration car elle était destinée aux clients non-tech avec peu de connaissances techniques. C'était le chemin de la moindre résistance, mais les documents AD réels recommandent un sous-domaine de troisième niveau tout au long de l'ère W2K.
MDMarra
3
Oh, et dans quelques années, il sera très difficile d'obtenir des certificats pour .local, ce qui signifie que les certificats UCC / SAN pour Lync / Exchange devront être signés par une autorité de certification interne, ce qui sera pénible si vous avez joint un domaine non externe utilisateurs.
MDMarra
14

Un enregistrement DNS générique est-il une mauvaise pratique?

Personnellement, je n'aime pas ça. Surtout quand il y a des machines dans ce domaine. Les fautes de frappe ne sont pas contrôlées, les erreurs sont moins évidentes ... mais il n'y a rien de fondamentalement mauvais avec ça.

Le seul point négatif que j'ai trouvé est que quelqu'un pourrait créer un lien vers mon site en utilisant http: //i.dont.like.your.website.mywebsite.tld .

Demandez à votre serveur http de rediriger toutes ces demandes vers les adresses canoniques appropriées ou de ne pas répondre du tout. Pour nginx, ce serait quelque chose comme :

server {
    listen 80;
    server_name *.mywebsite.tld;
    return 301 $scheme://mywebsite.tld$request_uri;
    }

puis le régulier

server {
    listen  80;
    server_name mywebsite.tld;
    [...]
    }
Putain de terminal
la source
7

C'est une question d'opinion. Pour moi, ce n'est pas une mauvaise pratique.

Je crée une application multi-locataire qui utilise une base de données par locataire. Il sélectionne ensuite la base de données à utiliser en fonction du sous-domaine.

Par exemple milkman.example.com, utilisera la tenant_milkmanbase de données.

Comme cela , j'ai séparés des tables pour chaque locataire, comme, tenant_milkman.users, tenant_fisherman.users, tenant_bobs_garage.users, qui à mon avis est un énorme beaucoup plus facile à maintenir pour cette application spécifique, au lieu d'avoir tous les utilisateurs de toutes les sociétés de la même table.

[edit - Michael Hampton has a good point]

Cela étant dit, si vous n'avez pas de raison spécifique d'accepter un sous-domaine (variable), comme moi, vous ne devriez pas les accepter.

Pedro Moreira
la source
4
Vous avez une bonne raison technique d'utiliser le DNS générique. La plupart des gens ne le font pas.
Michael Hampton
1
En fait, cela me semble très dangereux - cela vous permet d'accéder à une base de données arbitraire en changeant le nom de domaine. Je dirais qu'il s'agit d'un type de vulnérabilité d'injection. Certes ce n'est pas forcément exploitable - mais pourquoi prendre des risques?
sleske
1
@sleske Ce n'est pas le cas, car l'utilisateur doit s'authentifier auprès de ce sous-domaine (pour cette base de données). S'il change, il devra s'authentifier à nouveau, car il est considéré comme un "site" complètement différent.
Pedro Moreira
@PedroMoreira: Oui, cela réduit la surface d'attaque. Pourtant, l'accès à des bases de données arbitraires semble dangereux. Par exemple, que se passe-t-il s'il existe une base de données de sauvegarde avec des informations d'identification identiques, mais des données qui ont été purgées de la base de données principale - cela permettrait à toute personne qui connaît le nom d'accéder. Pourtant, je me rends compte que la sécurité est toujours un compromis - je voulais juste souligner le danger inhérent.
sleske
1
@sleske C'est pourquoi toutes les bases de données accessibles sont préfixées tenant_. Je me suis assuré que l'application ne pouvait même pas s'y connecter.
Pedro Moreira
2

Un autre problème ici est le référencement: si tous *.example.comaffichent le même contenu, votre site Web sera mal référencé, au moins par Google ( https://support.google.com/webmasters/answer/66359 ).

Clément Moulin - SimpleRezo
la source
Les deux points sont orthogonaux. Même si tous les noms pointent vers la même IP, le serveur Web obtient le nom demandé et peut fournir un contenu complètement différent.
Patrick Mevzek
C'est pourquoi j'ai précisé "si tout * .example.com affiche le même contenu" ... Le risque SEO me semble quelque chose d'intéressant à mentionner.
Clément Moulin - SimpleRezo
"Le risque SEO me semble quelque chose d'intéressant à mentionner." Peut-être, mais ils ne sont absolument pas liés à l'utilisation d'un caractère générique ou non. Vous pouvez avoir de nombreux noms distincts, tous résolus en une seule adresse IP sans aucun type de caractères génériques et donc avoir (ou non) les risques SEO dont vous parlez. L'utilisation d'un caractère générique ne change rien dans aucune direction ici.
Patrick Mevzek
0

C'est vraiment une mauvaise idée, supposons que si vous souhaitez héberger un sous-domaine a.company.com dans un serveur Web, et b.company.com dans un autre serveur Web, peut être un autre FAI. Que vas tu faire ?. Le DNS générique n'est donc pas une option, il doit être précis, créer un enregistrement pour chaque sous-domaine et pointer vers l'IP pertinente. Il y a des chances de déplacer votre serveur Web d'un FAI à un autre FAI, dans ce cas, que ferez-vous?

vembutech
la source
0

Je sais que c'est une vieille question, mais je voudrais partager un exemple réel où l'utilisation de domaines génériques peut causer des problèmes. Je vais cependant changer le nom de domaine et cacher également l'enregistrement SPF complet pour éviter l'embarras.

J'aidais quelqu'un qui avait des problèmes avec DMARC, dans le cadre des vérifications, je recherche toujours le dossier DMARC avec DIG

;; ANSWER SECTION:
_dmarc.somedomain.com. 21599 IN      CNAME   somedomain.com.
somedomain.com.      21599   IN      TXT     "v=spf1 <rest of spf record> -all"

J'ai également obtenu le même résultat en recherchant leur record DKIM.

Par conséquent, les e-mails envoyés à partir de ce domaine obtiendront un échec DKIM car le module DKIM essaiera d'analyser l'enregistrement SPF pour une clé DKIM et échouera, et obtiendra également un Permerror pour DMARC pour la même raison.

Les domaines génériques peuvent sembler une bonne idée, mais s'ils sont mal configurés, ils peuvent provoquer toutes sortes de problèmes.

Ravenstar68
la source
-2

Un enregistrement DNS générique est-il une mauvaise pratique?

Non, et contrairement à d'autres, je pense que c'est une bonne pratique.

La plupart des internautes fatent un nom DNS à un moment donné. Ils taperont ww.mycompany.comou wwe.mycompany.com que préférez-vous arriver un "oups nous n'avons pas pu trouver ce site" ou pour eux de faire apparaître votre page d'accueil principale? Le plus souvent, ne pas les faire afficher votre page d'accueil principale est préférable. C'est ce que beaucoup de gens font.

Même si quelqu'un y mettait un lien, votre page d'accueil i.dont.like.your.website.whatever.comapparaîtrait , ce qui est en fait ce que vous voulez. Après tout, ils ne peuvent pas faire en sorte que ce site accède à leur serveur, vous contrôlez toujours le routage DNS afin qu'il se rende au vôtre.i.dont....

Pas moi
la source
5
Le problème que j'ai avec ce raisonnement est que 1. il casse la gestion des erreurs, 2. il est entièrement centré sur www tandis que vos enregistrements génériques affecteront également les autres protocoles. Le résultat est que vous avez interrompu la gestion des erreurs pour d'autres choses où vous n'avez fait aucun effort pour corriger les choses.
Håkan Lindqvist
-2

Je pense que la meilleure raison de ne pas avoir un enregistrement DNS générique en premier lieu est d'éviter de donner l'adresse IP de votre serveur à un attaquant potentiel et de réduire l'exposition aux attaques DDOS. Cette configuration est également recommandée par Cloudflare: https://blog.cloudflare.com/ddos-prevention-protecting-the-origin/

Michael Rogers
la source
2
L'utilisation de domaines génériques ne modifie pas l'exposition à de telles attaques. Et le lien ne prend pas en charge vos réclamations incorrectes. Tout ce lien indique que Cloudflare facture un prix plus élevé pour les domaines génériques. Cela ne dit rien sur les modèles commerciaux de Cloudflare et rien sur la pratique d'utilisation des domaines génériques.
kasperd
Si vous utilisez des DNS génériques avec cloudflare car il ne passe pas par cloudflare (à moins que vous ne payiez une entreprise, la plupart ne le font pas), n'importe qui peut cingler un sous-domaine composé et trouver votre véritable IP. Sans caractère générique, ils ne peuvent pas. c'est tout ce qu'on peut en dire.
Michael Rogers
Oui, dans le cas d'un tel service, ils peuvent vous facturer plus pour la protection des caractères génériques. Bien que cette question ne concerne pas ces types de services, elle concerne les DNS génériques et si elle doit être effectuée ou non dans des situations normales.
Chris