Чи чутливим є регістр імені хоста? Є
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" у своїй конфігурації, а резоль.conf вказав пошуковий домен "t.local". Отже, що змішує випадок?
Виявляється, glibc перемикав справу випадковим чином. Процес називається "0x20 padding" і вперше був описаний в 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 внутрішньо, і це робить пошук у базі даних. Протягом багатьох років ніхто не використовував ім'я хоста або FQDN у домені t.local з великої літери, тому ми ніколи не помічали, що наш внутрішній домен враховує регістри.
Виправлено деякі зміни в запиті, але це призвело б до порушення змішаних пошукових записів 0x20, як зазначено вище - клієнт може вимагати повернення відповіді в тому ж випадку, що і запитував.
Коротка відповідь : DNS не повинен враховувати регістри, але питання і відповідь у майбутньому повинні бути однаковими.
Я щойно закінчив вирішення проблеми на вбудованому пристрої SE Linux, де дозвіл імені хоста виявляв чутливість до регістру.
"ping MYHOST" буде писати 127.0.0.1, тоді як "ping myhost" пінг правильної IP-адреси.
nslookup дав правильні результати як для великого, так і для малого регістру, вказуючи на те, що сервер DNS не був винен.
Але на відміну від nslookup, який ігнорує кеш, "getent хости MYHOST" виводять "0.0.0.0", а "getent хости myhost" виводять правильну IP-адресу.
Тож nscd, мабуть, чутливий до регістру. Виклик "nscd -i хостів", щоб очистити кеш, вирішив проблему.
MYHOST в (великому регістрі) закінчився кешем з 0,0.0.0 через процес, який намагався встановити з'єднання з MYHOST до створення запису DNS, що відбувається, коли віддалений пристрій отримує призначення DHCP.
Як зазначав БілТор, на рівні роздільної здатності DNS або netbios це не враховує регістр.
Різні ОС також не матимуть проблем з різними корпусами.
Однак програми можуть їх знати. Наприклад, веб-платформи в різних середовищах можуть перевірити наявність чутливості до справ. Зараз частіше для причин оптимізації пошукових систем (SEO) слідкувати за різними корпусами та переадресаціями. Це все залежить від програми, хоча відповідь є, що вона різниться.
Здебільшого, ім'я хоста також не викликає особливих обставин проблем на рівні програми.