DNS щойно почав вирішувати мої адреси server.prod на 127.0.53.53

У мене є сервери з ім'ям типу server.prod.example.com, і я регулярно входжу в них як server.prod. Нещодавно ці імена хостів почали поширюватися на 127.0.53.53.

Виявляється, нещодавно ICANN включив .prodTLD. Крім того, кожен запит, який надходить до .prodсерверів імен, вирішується до 127.0.53.53, а не повертається як NXDOMAIN, що дозволить резолюції продовжувати працювати належним чином. (Я здогадуюсь, суть цього в тому, щоб дати людям знати, що їхні речі погіршаться, перш ніж ті почнуть вирішувати щось реальне)

Як я можу уникнути необхідності вводити моє доменне ім’я для кожного такого хоста?

Це все-таки вас час від часу кусає? Я не зміг знайти список нових TLD і коли вони були додані, тому я створив його сам: https://twitter.com/newgtldannounce

domain-name-system tld

— wfaulk
джерело

Ця зміна ICANN також служить гарним нагадуванням про те, що дозволяти вашим програмам використовувати шляхи пошуку погано. Хоча це питання, безумовно, заслуговує на те, коли вхідні дані користувача приводяться до такої поведінки, краще, щоб ваші програми використовували записи хост-файлів або крапки з суфіксами FQDN. Мало хто розуміє, що glibc не перейде на наступний сервер, поки не вичерпається спроба кожного визначеного суфікса пошуку.

— Андрій Б

Дозвольте мені скористатися хвилиною, щоб нагадати всім, що .prodце химерний дурний TLD. :(

— Легкі перегони з Монікою

Ваше запитання відповіло на питання, яке я збирався задати, сказавши: "ICANN нещодавно ввімкнув <що б не було> TLD". Виявилося, що я використовував .haus для своєї локальної мережі і почав отримувати такі: D Дякую за запитання / відповіді :)

— Arno Teigseth

@LightnessRacesinOrbit .prod - один із багатьох нових TLD в Google. Звинувачуйте їх.

— Майкл Хемптон

@LightnessRacesinOrbit це може бути дурним, якщо ви дивитесь на це таким чином, але в той же час недобре залежати від пошукових списків або використовувати імена, не зареєстровані в усьому світі, оскільки ви зіткнетесь зіткненнями.

— Патрік Мевзек

Відповіді:

Коли ви бачите, що внутрішні домени раптово вирішуються, у 127.0.53.53вас виникає зіткнення імен, і ICANN намагається сказати вам, що вам потрібно терміново виправити конфігурацію DNS.
Якщо він поверне NXDOMAIN так, як ви запропонували, ви правильні, він би продовжував працювати - поки що .

Це також витікає ваш внутрішній призначений DNS-запит стороннім сторонам.

Гірше, що в майбутньому хтось може зареєструватися server.prodі заподіяти вам набагато більше клопотів.

Дивіться тут для отримання додаткової інформації https://icann.org/namecollision or run:

$ dig -t TXT server.prod +short
"Your DNS configuration needs immediate attention see https://icann.org/namecollision"

Щодо вирішення цього питання: Залежно від випадку використання, я, мабуть, просто додав би їх до .ssh/configкоротких імен. Або почніть реально використовувати FQDN.

— підробник
джерело

@MichaelHampton не дуже, рекомендую розділ 5.3 Train users and system administrators in using FQDNs

— :;

Так, тому що мені дуже хочеться 20 разів на день вводити ssh db.myreallylongdomainnamethatsomeassholefrommarketingpicked.comзамість цього ssh db.

— wfaulk

@wfaulk: Чому це був би "жарт"? Якщо вам не подобається надмірне введення тексту, чому ви нав’язливо уникаєте найкращого механізму, щоб дозволити взаємодію з комп'ютером, що дозволяє уникнути зайвого набору тексту? Деякі з вас, дурні Unix, просто барміли.

— Гонки легкості з Монікою

@ Легкість Зазвичай тому, що ми прагнемо тяжіти до бастіонних господарів. Наші корпоративні оверлодери все рідше і менше дозволяють своїм працівникам керувати Unix на пристроях, що випускаються компанією, з плином років, і люди, врятовані години, отримуючи доступ до скриптів оболонки з нашої точки доступу, зручно перемагають все, що може запропонувати GUI. . Графічний інтерфейс та текстові консолі мають частку шкідливих звичок, пов’язаних із ними. : P

— Андрій B

Це не місце для обговорення GUI проти CLI. Я запропонував рішення, воно може бути не найкращим для всіх, і це все, що можна сказати.

— факер

Якщо ви вводите ім'я хоста, у якому немає крапок, DNS-розв'язувачі намагаються знайти це ім'я, попередньо додавши до нього налаштовані пошукові домени.

Для більшості розв’язувачів, якщо ви використовуєте ім'я хоста, що містить хоча б одну крапку, розв'язувач спочатку спробує ім'я хоста самостійно та відновлює додавання налаштованих пошукових доменів.

Багато розв'язувачів мають можливість змінити свою поведінку, щоб вони додавали до пошукових доменів імена хостів крапками. Це часто відбувається через опцію, яка називається " ndots", яка повідомляє резолютору, скільки точок має мати ім'я хоста, перш ніж він спробує спочатку знайти ім'я хоста. Щоб зробити server.prodроботу, додайте цей рядок до свого resolv.conf:

options ndots:2

Якщо ви також хочете вирішити сервер server.subzone.prod, вам доведеться встановити параметр на 3 тощо.

Якщо хтось знає, як зробити цю роботу в MacOS X, будь ласка, дайте мені знати; зміна /etc/resolv.confзадокументована не працює (і не працює), і я не можу з’ясувати правильні scutilзаклики.

(Примітка. Я тут хеджую свої ставки більше, ніж, напевно, гарантовано. Я вважаю, що цей ndotsваріант буде працювати на 99% (не для MacOSX) Unix систем.)

— wfaulk
джерело

Ви плутаєте бібліотеку роздільної здатності ОС з BIND. /etc/resolv.confналежить ОС. :)

— Андрій Б

Більшість, якщо не всі, розв'язувачі ОС Unix виймаються прямо з бібліотек резолюцій BIND, якщо не прямо, використовуючи їх безпосередньо. Моя суть у виклику BIND полягає в тому, що можливо, що там є якась ОС, яка використовує щось інше, що не відповість на параметр "ndots".

— wfaulk

Таке твердження, швидше за все, вводить людей в оману, що думка про те, що роздільна здатність, реалізована стандартною бібліотекою С, залежить від бібліотек, наданих ISC. Що стосується glibc, то, звичайно, це не так .

— Андрій Б

Досить справедливо. Виправлено, щоб спробувати включити, що воно може не працювати, не посилаючись на BIND.

— wfaulk

Інші відповіді дали вам технічне рішення проблеми. Але ніхто не відповів на ваше:

Не вдалося знайти список нових TLD і коли вони були додані

Так ось воно.

У вас є різні способи.

Перейдіть на веб-сайт IANA за адресою: https://www.iana.org/domains/root/db ; ви побачите поточний список делегованих TLD, тобто тих, що вирішуються та знаходяться в кореневій зоні. Якщо натиснути будь-який на них, внизу ви побачите дату, яка повідомляє, коли вони з’явилися
Такі самі дані доступні whois, наприклад, у вашому випадку whois -h whois.iana.org prod | grep createdвам дадутьcreated: 2014-08-23
У Twitter / Mastodon є різні боти, які публікують, коли зміст вмісту IANA змінюється, див., Наприклад, https://twitter.com/ianawhois або https://twitter.com/rootchanges
Дані IANA можуть дещо відстати в оновленні, тому канонічна база даних для gTLD і побачити, на якому етапі вони перебувають (тепер це трохи суперечки, оскільки раунд впровадження нових gTLD в 2012 році ICANN в основному закінчений, але нові раунди будуть прибути), тут: https://gtldresult.icann.org/application-result/applicationstatus ; ви можете шукати за TLD. Для всіх gTLD також встановлено певний початковий період, тому ви знайдете дані тут: https://newgtlds.icann.org/en/program-status/sunrise-claims-periods, ви можете експортувати всі дані.
Ви також можете використовувати дані ICANN в JSON: https://www.icann.org/resources/registries/gtlds/v2/gtlds.json

— Патрік Мевзек
джерело