Le nom d'hôte est-il sensible à la casse?
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?
Les noms résolus à partir du DNS ne sont pas sensibles à 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.
Je viens de l'avoir ici au travail. DNS doit être insensible à la casse .... la RFC spécifie que . https://tools.ietf.org/html/rfc434 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-
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é de nom d'hôte ou de nom de domaine complet 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 dans le futur.
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 était sensible à 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 à "hôtes nscd -i" pour effacer le cache a résolu le problème.
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.
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 des 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.