Capita spesso di voler creare dei nomi della LAN interna con il FQDN di un nome a dominio pubblico o di voler sovrascrivere alcuni host con IP pubblico con gli stessi nomi, ma con IP interno.
La soluzione più comune è creare una zona con lo stesso nome della zona esterna con gli stessi contenuti, a meno di quelli che devono essere differenti.
Continua a leggerePer un caso del destino (o no?) a un mio cliente e ad un cliente di un collega questa settimana è successa la medesima cosa.
Continua a leggereSiamo abituati a ritenere che la risoluzione dei nomi avvenga tramite una richiesta in chiaro con protocollo UDP sulla porta 53 di uno dei server specificati nella configurazione dell’host. Per estensione, siamo abituati a credere che se si controllano in un qualche modo i server DNS impostati in un host, si può controllare il modo in cui l’host accede a determinati nomi a dominio.
DoH (DNS over HTTPS) potrebbe cambiare le regole del gioco e le nostre granitiche certezze.
(altro…)Il sistema dei nomi a dominio è una delle tecnologie essenziali per il funzionamento del servizio Internet come viene percepito dagli utenti.
Le connessioni ad Internet in cui c’è solamente l’apparecchio del provider forniscono come server DNS quello del provider stesso, ma non è obbligatorio (non per ora…) utilizzare per forza quel server. (altro…)
Il sistema dei nomi a dominio (Domanin Name System) è dato per scontato da molti utenti (e altrettanti tecnici), ma ha delle regole di funzionamento molto precise.
(altro…)Ogni host IP in una rete ha almeno un indirizzo e almeno un nome.
Se gli indirizzi sono spesso una classe /24 con spazio di manovra ridotto e, salvo eccezioni, vengono gestiti per lo più in maniera automatica, nella scelta dei nomi si scatenano fantasie e perversioni di utenti e amministratori. (altro…)
Non c’è solamente chi mette i titoli di Star Wars nei reverse DNS.
C’è qualcuno che utilizza in maniera creativa i record NAPTR.
dig +short naptr ascii.artsy.net|sort
Dovrebbe fornire qualcosa di questo tipo: (altro…)
Ogni server che ho installato da che ci sono le connessioni fisse a Internet ha sempre avuto un DNS server locale senza inoltro al DNS del provider.
Il DNS è spesso visto come una bestia nera da parte di molti tecnici, secondo forse solamente al subnetting delle classi IP. Su Linux uno dei problemi di BIND è che nelle prime versioni non era esattamente verboso in merito ai messaggi di errore, anzi era del tutto ermetico, quasi binario: o partiva o non partiva e forse ti faceva la grazia di dire qual era la zona con l’errore, ma poi erano affari tuoi.
Questo ha fatto in modo che, negli anni, molti tecnici abbiano sempre evitato di aver a che fare con la bestia e preferivano delegare ad altri la (ri)soluzione del problema.
La risoluzione di un nome a dominio è una faccenda troppo delicata per essere lasciata in mano a terzi, specialmente da quando sono iniziati gli attacchi ai DNS.
Le buone ragioni per avere un DNS locale sono molteplici e sono di gran lunga maggiori di quelle che consigliano di non averlo: (altro…)
Team Cymru ha pubblicato un report [PDF] che descrive una serie di attacchi portati ai router ADSL di fascia casalinga o SOHO.
I dispositivi coinvolti sono di molte marche tra cui TP-Link, ZxXEL, D-Link, Micronet, Tenda. Le vittime di questi attacchi sono concentrate in pochi Stati, tra cui anche l’Italia.
L’attacco sfrutta delle vulnerabilità del firmware dei dispositivi che permettono di modificare la configurazione dei dispositivi da remoto senza conoscere la password di accesso. Questi router permettono di modificare la configurazione da un IP esterno alla LAN per consentire al provider o comunque a chi fornisce il supporto di modificare le impostazioni senza intervenire sul posto. (altro…)
I recenti fatti che hanno riguardato Spamhaus hanno rimesso in risalto il problema non nuovo di un DNS amplification attack al punto che anche l’US-CERT ha diramato un bollettino in merito.
Innanzi tutto la risposta alla domanda legittima: cosa diavolo viene amplificato in questo attacco?
(altro…)Ryan Werber era annoiato dal cattivo tempo di Boston.
Ryan ha creato uno script PHP per configurare delle tabelle di routing virtuali su alcuni apparati CISCO. Quindi ha aggiornato in maniera opportuna i reverse DNS di un /24 IPv4.
Il risultato lo si può vedere facendo traceroute verso 216.81.59.173, avendo l’accortezza di usare il parametro -m (-h per Windows) per allungare il TTL e vedere tutta la storia.
D.ROOT-SERVERS.NET cambierà IPv4 il 3 gennaio 2013.
Il nuovo IPv4 è 199.7.91.13 che sostituisce l’attuale 128.8.10.90, che risolve anche TERP.UMD.EDU
Al fine di ridurre eventuali disservizi, il nuovo IPv4 del root DNS è già attivo e raggiungibile e il vecchio indirizzo sarà attivo per non meno di sei mesi dopo il cambio.
I SysAdmin possono cambiare, quindi, già da ora il file con le hint dei DNS che gestiscono. Dal 3 gennaio 2013 verranno aggiornati i file named.root e named.cache disponibili per il download presso InterNIC.
L’IPv6 del root DNS non cambia e rimane 2001:500:2d::d. (via nanog)