DNS ha appena iniziato a risolvere i miei indirizzi server.prod in 127.0.53.53

Ho un server chiamato like server.prod.example.come accedo regolarmente a loro come server.prod. Di recente, questi nomi host hanno iniziato a risolversi in 127.0.53.53.

Si è scoperto che l'ICANN ha recentemente abilitato il .prodTLD. Inoltre, ogni richiesta inviata ai .prodnameserver viene risolta in 127.0.53.53 invece di tornare come NXDOMAIN, il che consentirebbe alla risoluzione di continuare a funzionare correttamente. (Immagino che il punto dietro questo sia far sapere alle persone che le loro cose andranno peggio prima che quelle inizino a risolversi in qualcosa di reale.)

Come posso evitare di dover digitare il mio nome di dominio per ogni host come questo?

Ti sta ancora mordendo di tanto in tanto? Non sono riuscito a trovare un elenco di nuovi TLD e quando sono stati aggiunti, quindi ne ho creato uno io: https://twitter.com/newgtldannounce

domain-name-system tld

— wfaulk
fonte

Questa modifica di ICANN serve anche a ricordare che lasciare che le tue applicazioni utilizzino i percorsi di ricerca è un male. Mentre questa domanda ha sicuramente merito quando l'input di un utente provoca questo comportamento, è meglio che le tue applicazioni utilizzino voci di file host o nome di dominio completo con dot dot. Pochi si rendono conto che glibc non passerà al server successivo fino a quando non è scaduto il tentativo di provare ogni suffisso di ricerca definito.

— Andrew B,

Vorrei solo prendere un momento per ricordare a tutti che .prodè uno stupido TLD frakking. :(

— Lightness Races with Monica

La tua domanda ha risposto alla domanda che stavo per porre, dicendo "L'ICANN ha recentemente abilitato il <whatever> TLD". Ho scoperto che stavo usando .haus per la mia LAN e ho iniziato a ricevere questi: D Grazie per

— avermi

@LightnessRacesinOrbit .prod è uno dei tanti nuovi TLD di Google. Dai la colpa a loro.

— Michael Hampton

@LightnessRacesinOrbit può essere stupido se lo guardi in quel modo, ma allo stesso tempo non è bene dipendere da elenchi di ricerca o usare nomi non registrati a livello globale, poiché colpirai le collisioni.

— Patrick Mevzek,

Risposte:

Quando vedi domini interni improvvisamente risolti in 127.0.53.53te hai una namecollision e ICANN sta cercando di dirti che hai urgente bisogno di correggere la tua configurazione DNS.
Se restituisse NXDOMAIN come da te suggerito, hai ragione, continuerebbe a funzionare - per ora .

Perderebbe anche la tua query DNS destinata internamente a soggetti esterni.

Peggio ancora, in futuro qualcuno potrebbe registrarsi server.prode causarti molti più problemi.

Vedi qui per maggiori informazioni https://icann.org/namecollision o esegui:

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

Quanto a come risolvere questo: dipende dal caso d'uso, probabilmente li aggiungerei semplicemente .ssh/configcon i nomi brevi. O inizia a usare davvero i nomi di dominio completi.

— impostore
fonte

@MichaelHampton non proprio, consiglio il capitolo 5.3 Train users and system administrators in using FQDNs

— :;

Sì, perché voglio davvero, 20 volte al giorno, digitare ssh db.myreallylongdomainnamethatsomeassholefrommarketingpicked.cominvece di ssh db.

— Wfaulk,

@wfaulk: Perché dovrebbe essere uno "scherzo"? Se non ti piace la digitazione eccessiva, perché stai evitando in modo ossessivo il miglior meccanismo per consentire l'interazione con un computer che evita la digitazione eccessiva? Alcuni di voi nerd di Unix sono solo barmy.

— Lightness Races with Monica

@Lightness Generalmente perché tendiamo a gravitare verso gli ospiti del bastione. I nostri padroni aziendali hanno sempre meno probabilità di consentire ai loro dipendenti di far funzionare un Unix sui dispositivi emessi dalla loro azienda nel corso degli anni e le ore lavorative risparmiate avendo accesso agli script di shell dal nostro punto di accesso battono facilmente qualsiasi cosa una GUI abbia da offrire . La GUI e le console di testo hanno entrambe la loro parte di cattive abitudini associate ad esse. : P

— Andrew B,

Questo non è il posto dove fare una discussione tra GUI e CLI. Ho proposto una soluzione, potrebbe non essere la migliore per tutti e non c'è altro da dire.

— falso

Se si digita un nome host senza punti, i resolver DNS cercano di cercare quel nome host aggiungendo prima i domini di ricerca configurati.

Per la maggior parte dei risolutori, se si utilizza un nome host con almeno un punto al suo interno, il risolutore prima prova il nome host da solo e ricorre all'aggiunta dei domini di ricerca configurati.

Molti risolutori hanno la possibilità di cambiare il loro comportamento in modo da aggiungere i domini di ricerca per i nomi host con punti. Ciò avviene spesso tramite un'opzione chiamata " ndots" che indica al risolutore quanti punti deve avere il nome host prima di provare a cercare prima il nome host. Per far server.prodfunzionare, aggiungi questa riga al tuo resolv.conf:

options ndots:2

Se vuoi anche essere in grado di risolvere server.subzone.prod, dovrai impostare l'opzione su 3, ecc.

Se qualcuno sa come farlo funzionare in MacOS X, per favore fatemi sapere; il cambiamento /etc/resolv.confè documentato per non funzionare (e non funziona) e non riesco a capire gli scutilincantesimi giusti .

(Nota: sto coprendo le mie scommesse qui più di quanto sia probabilmente garantito. Credo che l' ndotsopzione funzionerà sul 99% dei sistemi Unix (non MacOSX).)

— wfaulk
fonte

Stai confondendo la libreria del resolver del sistema operativo con BIND. /etc/resolv.confè di proprietà del sistema operativo. :)

— Andrew B,

La maggior parte, se non tutti, i risolutori del sistema operativo Unix vengono strappati direttamente dalle librerie del risolutore di BIND, se non addirittura direttamente utilizzati. Il mio punto nel chiamare BIND è che è possibile che ci sia qualche sistema operativo là fuori che utilizza qualcosa di diverso che non risponderà all'opzione "ndots".

— Wfaulk,

Una simile affermazione ha maggiori probabilità di indurre in errore le persone a pensare che il resolver implementato dalla libreria standard C abbia una dipendenza dalle librerie fornite dall'ISC. Nel caso di glibc, sicuramente no .

— Andrew B,

Giusto. Risolto il problema per provare a incorporare che potrebbe non funzionare senza fare riferimento a BIND.

— Wfaulk,

Altre risposte ti hanno fornito la soluzione tecnica per il problema. Ma nessuno ha risposto al tuo:

Non sono riuscito a trovare un elenco di nuovi TLD e quando sono stati aggiunti

Quindi eccolo qui.

Hai vari modi.

Visita il sito web IANA all'indirizzo: https://www.iana.org/domains/root/db ; verrà visualizzato l'elenco corrente di TLD delegati, ovvero quelli che si risolvono e si trovano nella zona principale. Se fai clic su uno di essi, in basso otterrai una data che ti dice quando sono comparsi
Che gli stessi dati esatti siano disponibili sopra whois, ad esempio nel tuo caso whois -h whois.iana.org prod | grep createdti daràcreated: 2014-08-23
Ci sono vari bot su Twitter / Mastodon che pubblicano quando i contenuti IANA cambiano, vedi ad esempio https://twitter.com/ianawhois o https://twitter.com/rootchanges
I dati IANA potrebbero essere un po 'indietro nell'aggiornamento, quindi il database canonico per i gTLD e per vedere in quale fase si trovano (ora è un po' controverso dal momento che il round ICANN del 2012 di introdurre nuovi gTLD è quasi finito, ma i nuovi round lo faranno arriva), è qui: https://gtldresult.icann.org/application-result/applicationstatus ; puoi cercare per TLD. A tutti i gTLD è inoltre richiesto un periodo di inizio specifico, quindi troverai i dati qui: https://newgtlds.icann.org/en/program-status/sunrise-claims-periods per poter esportare tutti i dati.
Puoi anche utilizzare i dati ICANN in JSON: https://www.icann.org/resources/registries/gtlds/v2/gtlds.json

— Patrick Mevzek
fonte