Le nom d'hôte est-il sensible à la casse?

26

Le nom d'hôte est-il sensible à la casse? Est

ping MYHOST

égal à

ping myhost

Cela dépend-il du DNS utilisé? Existe-t-il des différences entre les systèmes Win / Mac / Unix?

domain-name-system hostname case-sensitive

— michelemarcon
source

2

Voici un RFC. tools.ietf.org/html/rfc4343

— Zoredache

24

Les noms résolus à partir du DNS ne respectent pas la casse. Ceci est important pour éviter toute confusion. S'il était sensible à la casse, nous aurions alors huit variantes de .com (.com, .Com, .cOm, .COm, .coM, .CoM, .cOM et .COM). Les codes de pays en auraient quatre.

Si la résolution de noms est sensible à la casse pour Ping, elle n'est pas effectuée par DNS.

— BillThor
source

Cela devient apparemment quelque peu délicat après l'ajout des noms de domaine internationalisés. Dans des contextes non ASCII, le cas peut être important.

— Zoredache

1

@Zoredache: Il semble que les domaines internationalisés utilisant le système IDNA doivent être encodables en Punycode, ce qui implique une traduction en minuscules. Il existe également des restrictions supplémentaires pour garantir que les noms sont visuellement distincts. De plus, vous ne voulez pas forcer les utilisateurs à s'assurer qu'ils obtiennent le bon dossier.

— BillThor

6

Je viens de l'avoir ici au travail. Le DNS doit être insensible à la casse ... la RFC le précise. https://tools.ietf.org/html/rfc4343 mais ne dit pas qu'il DOIT être en minuscules.

Nous avons donc eu le plaisir de dépanner un hôte qui n'a pas résolu les problèmes pour notre domaine interne "t.local"

p123$ ping p123-db.t.local
PING p123-db.t.local (192.168.106.175) 56(84) bytes of data.
....works ok

p123$ ping P123-dB.T.lOcal
ping: unknown host P123-dB.T.lOcal

Pourquoi s'embêter à résoudre le cas mixte? Parce que c'est ce que tcpdump montrait comme requête DNS parce que c'est ce que le logiciel en cours d'exécution demandait. pgbouncer a été configuré pour utiliser "p123-db" dans sa configuration, et resolv.conf a spécifié un domaine de recherche "t.local". Alors, qu'est-ce qui mélange le cas?

Il s'avère que la glibc faisait basculer le cas au hasard. Le processus est appelé «remplissage 0x20» et a été décrit pour la première fois en 2008 dans «Utilisation du bit 0x20 dans les étiquettes DNS pour améliorer l'identité de transaction» http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00

Le but principal est d'augmenter l'entropie afin qu'il soit plus difficile de simuler une réponse - le cas de la question doit correspondre au cas de la réponse.

Une bonne discussion peut être trouvée ici. https://developers.google.com/speed/public-dns/docs/security?csw=1#randomize_case

Séparément, nous exécutons powerDNS en interne, et cela effectue des recherches sur une base de données. Pendant des années, personne n'a utilisé un nom d'hôte ou FQDN dans le domaine t.local avec une majuscule, nous n'avons donc jamais remarqué que notre domaine interne était sensible à la casse.

A été corrigé par quelques ajustements dans la requête, mais cela aurait rompu les recherches de casse mixte 0x20 comme ci-dessus - le client peut exiger que la réponse soit retournée dans le même cas que celui demandé.

Réponse courte : DNS ne devrait pas être sensible à la casse, mais la question et la réponse devront être identiques à l'avenir.

— Criggie
source

2

La réponse, 4 ans après la question, est subtilement différente. Je me demande dans 4 ans la réponse sera "oui - le DNS est désormais sensible à la casse"

— Criggie

4

Je viens de terminer le dépannage d'un problème sur un appareil SE Linux intégré où la résolution du nom d'hôte faisait preuve de sensibilité à la casse.

"ping MYHOST" exécuterait un ping vers 127.0.0.1, tandis que "ping myhost" exécuterait un ping sur l'adresse IP correcte.

nslookup a produit des résultats corrects pour les majuscules et les minuscules, indiquant que le serveur DNS n'était pas en faute.

Mais contrairement à nslookup, qui ignore le cache, "getent hosts MYHOST" sort "0.0.0.0" et "getent hosts myhost" sortent la bonne adresse IP.

Donc, nscd est apparemment sensible à la casse. L'appel à "nscd -i hosts" pour effacer le cache a résolu le problème.

Le MYHOST en (majuscule) s'est retrouvé en cache avec 0.0.0.0 en raison d'un processus essayant d'établir une connexion à MYHOST avant la création de l'entrée DNS, ce qui se produit lorsque le périphérique distant obtient son affectation DHCP.

— Andrew Weimholt
source

0

Comme l'a mentionné BillThor, il n'est pas sensible à la casse au niveau de la résolution DNS ou netbios.

Les différents systèmes d'exploitation n'auront pas non plus de problème avec les différents boîtiers.

Cependant, les applications peuvent en avoir connaissance. Par exemple, les plates-formes Web des différents environnements peuvent vérifier la sensibilité à la casse. Il est plus courant maintenant, pour des raisons d'optimisation pour les moteurs de recherche (SEO), de surveiller les différents casse et redirection. Tout dépend de l'application, donc la réponse est qu'elle varie.

Dans la plupart des cas, le nom d'hôte n'est pas non plus une préoccupation sensible à la casse au niveau de l'application.

— Scott Forsyth - MVP
source