DNS только что начал преобразовывать мои адреса server.prod в 127.0.53.53

38

У меня есть серверы с именем вроде 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
источник
5
Это изменение ICANN также служит хорошим напоминанием о том, что позволить вашим приложениям использовать пути поиска плохо. Хотя этот вопрос определенно имеет смысл в том случае, когда пользовательский ввод приводит к такому поведению, лучше, чтобы ваши приложения использовали записи файла хоста или полные доменные имена с суффиксами. Мало кто понимает, что glibc не перейдет к следующему серверу, пока не истечет время ожидания при попытке каждого определенного суффикса поиска.
Андрей Б
13
.prodПозвольте мне на минутку напомнить всем, что это глупый TLD. :(
Легкость гонок с Моникой
Ваш вопрос ответил на вопрос, который я собирался задать, сказав, что «ICANN недавно включила домен TLD». Оказывается, я использовал .haus для своей локальной сети и начал получать их: D Спасибо за вопрос / ответ :)
Arno Teigseth
2
@LightnessRacesinOrbit .prod - одно из многих новых TLD от Google. Винить их.
Майкл Хэмптон
@LightnessRacesinOrbit это может быть глупо, если вы посмотрите на это с такой стороны, но в то же время не стоит полагаться на списки поиска или использовать имена, не зарегистрированные в глобальном масштабе, поскольку вы столкнетесь с коллизиями.
Патрик Мевзек

Ответы:

37

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

Это также приведет к утечке вашего внутреннего DNS-запроса внешним сторонам.

Хуже того, в будущем кто-то может зарегистрироваться server.prodи доставить вам гораздо больше хлопот.

Смотрите здесь для получения дополнительной информации https://icann.org/namecollision или выполните:

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

Что касается того, как решить эту проблему: Зависит от варианта использования, я, вероятно, просто добавил бы их .ssh/configс короткими именами. Или начать использовать FQDN действительно.

обманщик
источник
5
@MichaelHampton не совсем, я рекомендую главу 5.3:; Train users and system administrators in using FQDNs)
фейкер
3
Да, потому что я действительно хочу, 20 раз в день, печатать ssh db.myreallylongdomainnamethatsomeassholefrommarketingpicked.comвместо ssh db.
wfaulk
3
@wfaulk: Почему это будет "шутка"? Если вам не нравится чрезмерная типизация, почему вы одержимо избегаете лучшего механизма, позволяющего взаимодействовать с компьютером, который позволяет избежать чрезмерной типизации? Некоторые из вас, ботаники Unix, просто скупы.
Гонки на легкость с Моникой
4
@Lightness Вообще, потому что мы склонны тяготеть к хозяевам бастиона. Наши корпоративные начальники с меньшей вероятностью позволят своим работникам запускать Unix на устройствах, выпущенных их компанией, с годами, а человеческие часы, сэкономленные благодаря доступу к сценариям оболочки с нашей точки доступа, легко превзойдут все, что может предложить графический интерфейс. , GUI и текстовые консоли имеют свою долю вредных привычек, связанных с ними. : P
Андрей B
4
Это не место для обсуждения GUI против CLI. Я предложил решение, оно может быть не лучшим для всех, и это все, что можно сказать.
Мошенник
13

Если вы введете имя хоста без точек, DNS-преобразователи попытаются найти это имя хоста, сначала добавив к нему настроенные домены поиска.

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

Многие распознаватели могут изменять свое поведение, добавляя в домены поиска имена хостов с точками. Это часто происходит с помощью параметра, называемого « ndots», который сообщает распознавателю, сколько точек должно иметь имя хоста, прежде чем он попытается сначала найти имя хоста самостоятельно. Чтобы сделать server.prodработу, добавьте эту строку в ваш resolv.conf:

options ndots:2

Если вы также хотите разрешить server.subzone.prod, вам нужно установить опцию 3 и т. Д.

Если кто-нибудь знает, как заставить это работать в MacOS X, пожалуйста, дайте мне знать; изменение /etc/resolv.confзадокументировано не для работы (и не работает), и я не могу понять правильные scutilзаклинания.

(Примечание: я хеджирую свои ставки здесь больше, чем это возможно. Я считаю, что этот ndotsвариант будет работать на 99% (не MacOSX) Unix-систем.)

wfaulk
источник
1
Вы путаете библиотеку распознавателя ОС с BIND. /etc/resolv.confпринадлежит ОС. :)
Андрей B
Большинство, если не все, распознаватели Unix OS извлекаются прямо из библиотек распознавателя BIND, если не используются напрямую. Моя точка зрения в отношении BIND заключается в том, что, возможно, существует какая-то ОС, которая использует что-то другое, что не отвечает на опцию «ndots».
wfaulk
2
Такое утверждение, скорее всего, вводит людей в заблуждение, полагая, что преобразователь, реализованный стандартной библиотекой C, зависит от библиотек, предоставляемых ISC. В случае с glibc это определенно не так .
Андрей Б
1
Справедливо. Исправлена ​​попытка включить, что он может не работать, не ссылаясь на BIND.
wfaulk
0

Другие ответы дали вам техническое решение проблемы. Но никто не ответил на ваши:

Я не смог найти список новых TLD и когда они были добавлены

Так и здесь.

У вас есть разные способы.

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