DNS właśnie zaczął rozstrzygać moje adresy server.prod na 127.0.53.53

Mam serwery o nazwie jak server.prod.example.comi regularnie loguję się na nich jako server.prod. Ostatnio te nazwy hostów zaczęły być tłumaczone na 127.0.53.53.

Okazuje się, że ICANN niedawno włączył .prodTLD. Ponadto każde żądanie skierowane do .prodserwerów nazw jest przetwarzane na 127.0.53.53 zamiast wracać jako NXDOMAIN, co pozwoliłoby na prawidłowe działanie rozpoznawania. (Zgaduję, że kryje się za tym fakt, że ludzie muszą wiedzieć, że ich rzeczy ulegną pogorszeniu, zanim zaczną się rozwiązywać).

Jak mogę uniknąć wpisywania nazwy mojej domeny dla każdego takiego hosta?

Czy to cię czasem gryzie? Nie mogłem znaleźć listy nowych TLD i kiedy zostały one dodane, więc sam je skonfigurowałem: https://twitter.com/newgtldannounce

domain-name-system tld

— wfaulk
źródło

Ta zmiana wprowadzona przez ICANN służy również jako dobre przypomnienie, że zezwolenie aplikacjom na używanie ścieżek wyszukiwania jest złe. Chociaż pytanie to ma zdecydowanie uzasadnienie, gdy dane wejściowe użytkownika powodują takie zachowanie, najlepiej jest, aby aplikacje korzystały z wpisów w pliku hosta lub w nazwach FQDN z przyrostkiem kropki. Niewielu zdaje sobie sprawę, że glibc nie przejdzie na następny serwer, dopóki nie przekroczy limitu czasu próby podjęcia każdego zdefiniowanego sufiksu wyszukiwania.

— Andrew B,

Chciałbym tylko poświęcić chwilę, aby przypomnieć wszystkim, że .prodto cholernie głupie TLD. :(

— Lekkość wyścigów z Monicą

Twoje pytanie odpowiedziało na pytanie, które zamierzam zadać, mówiąc: „ICANN niedawno włączył <hokolwiek> TLD”. Okazało się, że używałem .haus do mojej sieci LAN i zacząłem otrzymywać: D Dzięki za pytanie / odpowiedź :)

— Arno Teigseth,

@LightnessRacesinOrbit .prod jest jednym z wielu nowych TLD Google. Obwiniaj ich.

— Michael Hampton

@LightnessRacesinOrbit może być głupie, jeśli spojrzysz na to w ten sposób, ale jednocześnie nie jest dobrze polegać na listach wyszukiwania lub używać nazw niezarejestrowanych globalnie, ponieważ uderzysz w kolizje.

— Patrick Mevzek,

Odpowiedzi:

Gdy zobaczysz, że domeny wewnętrzne nagle się rozwiązują 127.0.53.53, masz decyzję, a ICANN próbuje powiedzieć ci, że musisz pilnie naprawić konfigurację DNS.
Jeśli zwróci NXDOMAIN, jak sugerowałeś, masz rację, nadal będzie działać - na razie .

Wyciekłoby również z twojego wewnętrznego zapytania DNS do stron zewnętrznych.

Co gorsza, w przyszłości ktoś może się zarejestrować server.prodi sprawić ci znacznie więcej problemów.

Zobacz tutaj, aby uzyskać więcej informacji https://icann.org/namecollision lub uruchom:

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

Co do sposobu rozwiązania tego: Zależy od przypadku użycia, prawdopodobnie po prostu dodam je do .ssh/configkrótkich nazw. Lub zacznij naprawdę używać FQDN.

— oszust
źródło

@MichaelHampton nie bardzo, polecam rozdział 5.3:; Train users and system administrators in using FQDNs)

— faker

Tak, ponieważ naprawdę chcę pisać 20 razy dziennie ssh db.myreallylongdomainnamethatsomeassholefrommarketingpicked.comzamiast ssh db.

— wfaulk

@wfaulk: Dlaczego miałby to być „żart”? Jeśli nie lubisz nadmiernego pisania, dlaczego obsesyjnie unikasz najlepszego mechanizmu umożliwiającego interakcję z komputerem, który pozwala uniknąć nadmiernego pisania? Niektórzy z was frajerzy uniksowi są po prostu barmani.

— Wyścigi lekkości z Moniką

@ Lekkość Zasadniczo, ponieważ dążymy do hostii bastionu. Z upływem lat nasi korporacyjni zwierzchnicy coraz rzadziej pozwalają swoim pracownikom uruchamiać system uniksowy na urządzeniach wydanych przez ich firmę, a zaoszczędzone godziny pracy dzięki dostępowi do skryptów powłoki z naszego punktu dostępu łatwo pokonują wszystko, co oferuje GUI . Zarówno interfejs GUI, jak i konsole tekstowe wiążą się ze złymi nawykami. : P

— Andrew B,

To nie jest miejsce na dyskusję na temat GUI kontra CLI. Zaproponowałem rozwiązanie, może nie być najlepsze dla wszystkich i to wszystko, co można powiedzieć.

— faker

Jeśli wpiszesz nazwę hosta bez kropek, resolwery DNS spróbują wyszukać tę nazwę hosta, najpierw dołączając do niej skonfigurowane domeny wyszukiwania.

W przypadku większości programów tłumaczących, jeśli użyjesz nazwy hosta z co najmniej jedną kropką, resolver najpierw spróbuje samodzielnie nazwę hosta i powróci do dołączania skonfigurowanych domen wyszukiwania.

Wiele programów tłumaczących może zmieniać swoje zachowanie, tak aby dodawały domeny wyszukiwania nazw hostów za pomocą kropek. Często dzieje się tak dzięki opcji o nazwie „ ndots”, która informuje przelicznik, ile kropek musi mieć nazwa hosta, zanim spróbuje najpierw samodzielnie wyszukać nazwę hosta. Aby server.prodpraca działała, dodaj ten wiersz do resolv.conf:

options ndots:2

Jeśli chcesz również rozwiązać problem server.subzone.prod, musisz ustawić opcję na 3 itd.

Jeśli ktoś wie, jak to zrobić w MacOS X, daj mi znać; /etc/resolv.confudokumentowane jest, że zmiana nie działa (i nie działa) i nie mogę znaleźć odpowiednich scutilzaklęć.

(Uwaga: zabezpieczam swoje zakłady tutaj bardziej, niż jest to prawdopodobnie uzasadnione. Wierzę, że ndotsopcja będzie działać na 99% systemów uniksowych (innych niż MacOSX).)

— wfaulk
źródło

Mylisz bibliotekę tłumaczącą OS z BIND. /etc/resolv.confjest własnością systemu operacyjnego. :)

— Andrew B,

Większość, jeśli nie wszystkie, resolwery systemu operacyjnego Unix są zgrywane bezpośrednio z bibliotek resolvera BIND, jeśli nie są bezpośrednio używane. Moim celem przywołanie BIND jest to, że możliwe jest, że istnieje jakiś system operacyjny, który używa czegoś innego, co nie zareaguje na opcję „ndots”.

— wfaulk

Takie stwierdzenie może bardziej wprowadzać ludzi w błąd, myśląc, że resolver implementowany przez bibliotekę standardową C jest zależny od bibliotek dostarczanych przez ISC. W przypadku glibc na pewno nie .

— Andrew B

Słusznie. Naprawiono próbę włączenia, że może nie działać, gdy nie odwołuje się do BIND.

— wfaulk

Inne odpowiedzi dały techniczne rozwiązanie problemu. Ale nikt nie odpowiedział na twoje:

Nie mogłem znaleźć listy nowych TLD i kiedy zostały dodane

Więc oto jest.

Masz różne sposoby.

Wejdź na stronę IANA pod adresem : https://www.iana.org/domains/root/db ; zobaczysz bieżącą listę delegowanych domen TLD, czyli tych, które rozwiązują i znajdują się w strefie głównej. Jeśli klikniesz dowolną z nich, u dołu zobaczysz datę, kiedy się pojawiły
Dokładnie te same dane są dostępne whois, na przykład w twoim przypadku whois -h whois.iana.org prod | grep createdda cicreated: 2014-08-23
Istnieją różne boty na Twitterze / Mastodon, które publikują zmiany treści IANA, patrz na przykład https://twitter.com/ianawhois lub https://twitter.com/rootchanges
Dane IANA mogą być nieco opóźnione w aktualizacji, więc kanoniczna baza danych dla gTLD i sprawdzenie, na jakim etapie są (teraz jest trochę dyskusyjna od rundy wprowadzania nowych gTLD przez ICANN w 2012 r., Ale większość nowych rund zostanie zakończona przybyć), jest tutaj: https://gtldresult.icann.org/application-result/applicationstatus ; możesz wyszukiwać według TLD. Wszystkie domeny gTLD są również zobowiązane do określonego okresu początkowego, więc dane znajdziesz tutaj: https://newgtlds.icann.org/en/program-status/sunrise-claims-periods możesz eksportować wszystkie dane.
Możesz także korzystać z danych ICANN w JSON: https://www.icann.org/resources/registries/gtlds/v2/gtlds.json

— Patrick Mevzek
źródło