Учитывается ли регистр имени хоста?

Имена, разрешенные из DNS, нечувствительны к регистру. Это важно для предотвращения путаницы. Если бы он был чувствителен к регистру, у нас было бы восемь вариантов .com (.com, .Com, .cOm, .COm, .coM, .CoM, .cOM и .COM). Кодов стран будет четыре.

Если разрешение имен чувствительно к регистру для проверки связи, это не выполняется 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) более распространено следить за разным корпусом и перенаправлением. Это все зависит от приложения, поэтому ответ здесь - он варьируется.

Однако «по большей части» имя хоста не учитывает регистр на уровне приложения.