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

Я только что имел это здесь на работе. 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

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

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