Учитывается ли регистр имени хоста? Является
ping MYHOST
равно
ping myhost
Зависит ли это от используемого DNS? Есть ли различия между системами Win / Mac / Unix?
Ответы:
Имена, разрешенные из DNS, не чувствительны к регистру. Это важно для предотвращения путаницы. Если бы он был чувствительным к регистру, то у нас было бы восемь вариантов .com (.com, .Com, .cOm, .COm, .coM, .CoM, .cOM и .COM). Коды стран будут иметь четыре.
Если разрешение имен чувствительно к регистру для Ping, оно не выполняется DNS.
Я только что имел это здесь на работе. DNS должен быть регистрозависимым .... RFC указывает это. https://tools.ietf.org/html/rfc4343, но не говорит, что он ДОЛЖЕН быть в нижнем регистре.
Таким образом, мы имели удовольствие устранять неполадки хоста, который не решал проблемы для нашего внутреннего домена "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
Зачем решать смешанный случай? Потому что это то, что tcpdump показывал как DNS-запрос, потому что это то, о чем просило работающее программное обеспечение. pgbouncer был настроен на использование «p123-db» в своей конфигурации, а resolv.conf указал поисковый домен «t.local». Так что же запутывает случай?
Оказывается, glibc переключал случай в случайном порядке. Этот процесс называется «заполнение 0x20» и впервые был описан в 2008 году в разделе «Использование бита 0x20 в метках DNS для улучшения идентификации транзакции» http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00
Основная цель состоит в том, чтобы увеличить энтропию, чтобы было сложнее подделать ответ - случай вопроса должен соответствовать случаю ответа.
Хорошее обсуждение может быть найдено здесь. https://developers.google.com/speed/public-dns/docs/security?csw=1#randomize_case
Отдельно мы запускаем powerDNS внутри, и это делает поиск в базе данных. В течение многих лет никто не использовал имя хоста или полное доменное имя в домене t.local с заглавной буквой, поэтому мы никогда не замечали, что наш внутренний домен чувствителен к регистру.
Это было исправлено некоторыми изменениями в запросе, но это могло нарушить поиск в смешанном регистре 0x20, как указано выше - клиент может потребовать, чтобы ответ был возвращен в том же случае, в котором он был запрошен.
Краткий ответ : DNS не должен быть чувствительным к регистру, но в будущем вопрос и ответ должны быть идентичными.
Я только что закончил устранение проблемы на встроенном устройстве SE Linux, где разрешение имени хоста показывало чувствительность к регистру.
"ping MYHOST" будет пинговать до 127.0.0.1, тогда как "ping myhost" будет пинговать правильный IP-адрес.
nslookup выдает правильные результаты как в верхнем, так и в нижнем регистре, указывая на то, что DNS-сервер не был виновен.
Но в отличие от nslookup, который игнорирует кэш, «getent hosts MYHOST» выдает «0.0.0.0», а «getent hosts myhost» выдает правильный IP-адрес.
Так что NSCD, очевидно, чувствителен к регистру. Вызов «nscd -i hosts» для очистки кэша устранил проблему.
MYHOST в (верхний регистр) кешируется с 0.0.0.0 из-за процесса, пытающегося установить соединение с MYHOST до создания записи DNS, что происходит, когда удаленное устройство получает свое назначение DHCP.
Как упомянул BillThor, он не чувствителен к регистру на уровне разрешения DNS или netbios.
Различные операционные системы также не будут иметь проблем с различными корпусами.
Тем не менее, приложения могут знать о них. Например, веб-платформы в различных средах могут проверять чувствительность к регистру. В настоящее время по причинам, связанным с поисковой оптимизацией (SEO), чаще приходится следить за различными вариантами и перенаправлением. Это все зависит от приложения, хотя ответ таков, что он меняется.
Для «большей части» имя хоста также не учитывает регистр символов на уровне приложения.