Действительно ли имя хоста чувствительно к регистру?
Имена, разрешенные от DNS, нечувствительны к регистру. Это важно для предотвращения беспорядка. Если бы это было чувствительно к регистру затем, то у нас было бы восемь вариантов .com (.com.Com, .cOm.COm, .coM.CoM, .cOM, и.COM). Коды страны имели бы четыре.
Если определение имен чувствительно к регистру для Ping, оно не делается DNS.
Как BillThor упомянул, это не чувствительно к регистру в DNS или netbios уровне разрешения.
Различные Ose не будут иметь проблемы с другим преобразованием регистра также.
Однако приложения могут знать о них. Например, веб-платформы на различных средах могут проверить на чувствительность к регистру. Это более распространено теперь по причинам оптимизации поисковой системы (SEO) наблюдать за другим преобразованием регистра и перенаправлением. Это - все до приложения хотя так ответ, там то, что это варьируется.
Для 'большей части части' имя хоста не является чувствительным к регистру беспокойством о прикладном уровне также все же.
Я только что закончил устранение неполадок на встроенном устройстве 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 -i hosts» для очистки кеша устранил проблему.
MYHOST в (верхний регистр) закэшировался с 0.0.0.0 из-за того, что процесс пытался установить соединение с MYHOST до создания записи DNS, что происходит, когда удаленное устройство получает назначение DHCP.
Я только что получил это на работе. 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 не должен быть чувствительным к регистру, но вопрос и ответ должны быть идентичный случай, в будущем.