DNS server alternativi

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. Leggi tutto “DNS server alternativi”

I nomi a dominio

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.

La gestione amministrativa dei nomi a dominio si divide in tre livelli:

  1. IANA gestisce i root name server
  2. I registrar rivendono i nomi, generalmente di secondo livello
  3. Le entità (persone, società, organizzazioni), acquistano (meglio sarebbe dire “affittano”) i nomi e ne fanno l’uso che credono.

Se dovessimo adottare un’analogia di mercato dei beni, IANA è il produttore o il grossista e i registrar sono i supermercati o i negozianti. È possibile che tra il registrar e il titolare finale del dominio ci siano uno o più intermediari.

Prima di addentrarci nella spiegazione della parte amministrativa è meglio spiegare come funziona tecnicamente il sistema dei nomi a dominio.

Il sistema dei nomi serve, principalmente (non solo, ma per lo scopo di questo articolo ci limitiamo a questo) a convertire un nome comprensibile dagli utenti come siamogeek.com in un indirizzo IP utilizzabile per l’accesso ai server. Risolvere è l’azione di convertire un nome in un indirizzo.

Per fare ciò è stato implementato un sistema di database gerarchico distribuito che si basa sul concetto di delega. Vedete il sistema gerarchico come le radici di un albero.

In cima ci sono i root DNS, ovvero i DNS che devono essere noti per poter risolvere un nome. Ogni server DNS che vuole risolvere un nome deve conoscere l’indirizzo IP (di certo non il nome…) di almeno un root DNS. IANA mantiene un elenco scaricabile in veri formati dei root DNS. Certo, per accedere al sito di IANA dovete avere un server DNS funzionante che vi risolve i nomi.

I root DNS non contengono l’elenco di tutti i possibili nomi a dominio attivi, ma solamente gli indirizzi dei DNS delegati per essere l’autorità (authoritative DNS) in merito ai domini di primo livello.

I livelli di un nome a dominio si leggono da destra verso sinistra, quindi i domini di primo livello sono quelli geografici (IT, UK, GR, US, JP, detti anche ccTLD) e quelli generici (COM, ORG, NET, INFO, ROCKS, ORIENTEXPRESS, detti anche gTLD).

A loro volta, i Registrar delegati per la gestione dei domini di primo livello avranno nel loro DNS, referenziato dai root DNS, gli indirizzi IP dei DNS delegati per la gestione di ciascun secondo livello. In questo caso, i DNS del Registrar contengono l’elenco di tutti i nomi a dominio di secondo livello registrati da loro.

I singoli gestori dei domini di secondo livello (siamogeek.com è un dominio di secondo livello) possono creare i nomi che vogliono al di sotto (ovvero a sinistra) del nome che hanno acquistato, quindi io posso creare pippo.siamogeek.com, jarjarabrams.siamogeek.com, chebruttoesempio.siamogeek.com, eccetera.

Come fa un computer su cui un utente scrive pippo.siamogeek.com a trovare l’indirizzo associato?

Il computer si rivolge ad un programma che si chiama server DNS o anche resolver; il programma può girare sul computer stesso, sul un altro computer della LAN, presso il provider di connettività, o presso uno dei fornitori pubblici di risoluzione nomi, per il momento non ci interessa dove sia, anche se ha una certa rilevanza per altre ragioni.

Il resolver accetta la richiesta “dimmi che IP ha pippo.siamogeek.com” e spezza il nome a partire da destra.

Il primo livello è COM, quindi il resolver interroga i root DNS per sapere l’IP del DNS autoritario per il primo livello COM.

Ottenuto quell’IP, il nostro resolver si collega all’autoritario di COM e chiede l’IP del DNS autoritario per SIAMOGEEK.COM.

Con in mano questa informazione, il resolver chiede al DNS di SIAMOGEEK.COM quale accidenti sia l’IP di PIPPO.SIAMOGEEK.COM (e si becca un errore di nome inesistente, Murphy sghignazza).

Fermi. No, non avviene tutto questo cinema per ogni singola risoluzione dei nomi, sennò sarebbe un macello.

Ad ogni richiesta (query) ai server DNS assieme all’informazione viene consegnato un numero espresso in secondi che rappresenta la durata (TTL, Time To Live) dell’informazione. Il resolver non dovrebbe ripetere la medesima richiesta se la durata non è scaduta. Ecco motivata la cosiddetta propagazione delle modifiche ad DNS.

Visto questo funzionamento del DNS, vien da sé che l’associazione di un indirizzo ad un nome è monodirezionale, ovvero quando viene indicato che pippo.siamogeek.com ha indirizzo 1.2.3.4 non è automatico l’inverso; per avere la risoluzione inversa (rDNS) si usa sì il DNS, ma in un altro modo, che vedremo in un altro articolo.

Ora che abbiamo capito come funziona tecnicamente la risoluzione dei nomi, torniamo alla parte amministrativa.

IANA è un’organizzazione americana senza fini di lucro che gestisce i domini di primo livello (TLD).

I TLD geografici (ccTLD) sono di due lettere latine ASCII secondo lo standard ISO 3166-1 alpha-2 oppure IDN di lunghezza variabile. Alcuni Registrar nazionali (si pensi a TO, TV, ME, PW…) hanno aperto la possibilità a tutti di registrare un dominio.

I TLD generici (gTLD) erano in origine COM, NET, ORG, INT, EDU, GOV, MIL a cui si aggiunge ARPA usato ora per usi tecnici della gestione del DNS.

Recentemente è stato ha deciso di aprire il mercato dei gTLD a chi vuole riservarne uno per sé o per rivenderlo. La lista (http, ftp) dei gTLD cambia molto rapidamente.

Per ora, IANA impone che i domini siano almeno di secondo livello e vieta l’utilizzo dei dotless domain.

Siamo arrivati alla fine del nostro calvario cammino: l’acquisto di un nome a dominio.

Come detto in apertura, tecnicamente si tratta più di un affitto o di una tariffa per un servizio che un passaggio definitivo di proprietà, ma lasciamo da parte i cavilli.

Un qualsiasi Signor Nessuno che voglia registrare il suo bel nome a dominio deve rivolgersi ad uno dei tanti Registrar, scegliere il nome che desidera (ovviamente non deve essere già registrato da altri), compilare i pochi (o tanti, dipende dal registrar) dati richiesti, pagare e… voilà! Dopo qualche minuto (o qualche ora, se state registrando un .IT) il vostro nome a dominio è online e noto a tutto il mondo.

Dal punto di vista del mero mantenimento del nome, vi dovete solo ricordare di rinnovare la registrazione prima della scadenza, applicare ogni ragionevole sicurezza al vostro account presso il Registrar (se vi rubano quello, vi rubano tutti i nomi a dominio associati) e non cadere nelle trappole delle mail di chi vi vuole rubare soldi per chiedervi fantomatiche “registrazioni”.

Nomi degli host in LAN

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. Leggi tutto “Nomi degli host in LAN”

Risolvere i nomi a casa propria

by Paul MasonOgni 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: Leggi tutto “Risolvere i nomi a casa propria”

Attacchi ai router ADSL

luce rossaTeam 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. Leggi tutto “Attacchi ai router ADSL”

DNS amplification attack

VIA TRAFFICOI 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?

L’amplificazione consiste nella differenza tra i byte che l’attaccante trasmette alla vittima e quelli che la vittima trasmette indietro. In altre parole è la differenza tra la banda necessaria per portare l’attacco e la banda che viene consumata sui server della vittima.

Un ipotetico attacco portato ad un server FTP ha un fattore di amplificazione vicino all’unità perché se vogliamo occupare la banda in upload del server FTP ci vuole anche qualcuno che abbia altrettanta banda in download per accettare i suoi pacchetti TCP.

Differente è un attacco portato ad un server DNS: con una query di poche decine di byte via UDP si ottengono risposte molto importanti, ecco un esempio: Leggi tutto “DNS amplification attack”

I titoli di Star Wars in un traceroute

Darth Maul lightsaberRyan 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.
Leggi tutto “I titoli di Star Wars in un traceroute”

D.ROOT-SERVERS.NET cambierà indirizzo IPv4

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)

Elenco aggiornato dei TLD

Royal Mail buildingCi sono alcuni contesti in cui farebbe comodo avere a disposizione un elenco aggiornato dei TLD.

IANA mette a disposizione questo elenco in formato testo [MD5].

L’ultimo aggiornamento del 12 agosto saluta di questo file l’arrivo del TLD .POST voluto dall’UPU.

La gestione del nuovo TLD verrà delegata all’UPU; la registrazioni di domini di secondo livello non sarà accessibile al pubblico, ma saranno riservate agli operatori pubblici e privati, alle organizzazioni e agenzie governative che forniscono e supportano servizi postali universali sicuri ed affidabili.

SEO e spostamento dei siti

COS'E'PAZZNell’ultima settimana ho spostato un po’ di siti web, incluso questo e ho verificato ancora una volta quello che avevo già notato.

Quando si sposta un sito da un server ad un altro la procedura è più o meno questa:

  1. Verifica che il server destinazione abbia i prerequisiti necessari;
  2. backup del sito;
  3. restore sul server destinazione;
  4. verifica del restore usando artifizi come la forzatura in /etc/hosts del nome;
  5. modifica della zona relativa al nome a dominio del sito;
  6. rimozione del virtual host (o similare) dal vecchio server.

Qualcuno noterà che spesso il punto (1) viene fatto dopo il punto (4), ma sto divagando.

Leggi tutto “SEO e spostamento dei siti”

IDN? No grazie… (almeno per il momento)

Dalle ore 14:00 dell’11 luglio 2012 il NIC italiano (l’ente preposto a regolamentare e gestire la registrazione dei domini con estensione .it) consente di registrare domini IDN (internationalized domain name) ovvero domini contenenti lettere accentate ed altri caratteri speciali che prima non erano consentiti nei domini italiani.

Peccato che nessuno si è preso la briga di controllare se i vari programmi in uso dagli utenti o in funzione sui server siano compatibili e supportino i nuovi domini.

Lo standard per i nomi di dominio non permette normalmente caratteri non ASCII ma alla fine un metodo per internazionalizzare i nomi di dominio in un formato ASCII standard è stato trovato, salvaguardando con ciò la stabilità del Domain Name System. La prima bozza di IDN è stata proposta nel 1996 ed implementata nel 1998. Nel marzo 2008 l’Internet Engineering Task Force ha formato un nuovo IDN Working Group per rimodernare il corrente protocollo IDNA.

Attualmente diverse decine di domini di primo livello supportano la registrazione gli IDN. Anche il dominio di primo livello .eu, dal 10 dicembre 2009, supporta gli IDN.

Ovviamente perché tutto funzioni tutte le varie tessere del mosaico di software che costituisce Internet deve essere aggiornato e compatibile. E quì cominciano i problemi.

Ho eseguito personalmente dei test di invio mail da alcuni dei più grandi (come numero utenti) sistemi webmail verso delle mailbox appositamente create con domini IDN ed i risultati a parer mio sono sono disastrosi.

Gmail e Tiscali non supportano gli IDN e non consentono l’invio del messaggio. Yahoo prima lo accetta poi manda un messaggio d’errore perché uno dei suoi server non riesce ad inviare il messaggio a destinazione. V’invito ad effettuare dei test con altri account, se lasciate un commento, indicando la vostra mail vera nell’apposito campo, con il quale chiedete di collaborare al test vi contatterò personalmente per indicarvi un paio di indirizzi verso cui inviare i test. I risultati saranno pubblicati su questo blog.

ATTENZIONE! Non indicate la mail nel commento ma nell’apposito spazio del form. In questo modo io potrò vedere la vostra mail e contattarvi ma questa non sarà pubblicata sul sito.

KRB_AP_ERR_MODIFIED

Portamatite di floppy / Floppy pen holder 7/7Cosa c’è di meglio che iniziare la settimana con un errore del genere da un cliente?

Due server Windows (un 2003 e un 2008), sul 2003 la snap-in Active Directory Users and Computers all’avvio mostra un bell’errore “Nome principale di destinazione scorretto” e non mostra utenti; ovviamente nessuni si può collegare al server.

Negli eventi è loggato un errore ID 4 di Kerberos che così recita:

The kerberos client received a KRB_AP_ERR_MODIFIED error from the server xxxxxxxxx$. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm (yyyyyyyyyy), and the client realm. Please contact your system administrator.

Leggi tutto “KRB_AP_ERR_MODIFIED”

Dove sono i root DNS?

Come abbiamo visto in un altro articolo, il sistema dei nomi a dominio si basa sui root DNS.

Non ci vuole certo un esperto di networking per capire che i root DNS non solo sono un punto critico del sistema dei nomi a dominio, ma sono anche dei server molto trafficati.

Più i root DNS sono prossimi agli utenti più questi saranno veloci nel risolvere i nomi e, quindi, ad accedere ai servizi della Rete.

paf  ha raccolto su Google Maps la posizione dei root DNS nel mondo; la mappa potrebbe non essere aggiornatissima, ma aiuta molto a capire come sono distribuiti questi server.

Val la pena di evidenziare che, a causa della topologia di Internet, per molti utenti di Milano potrebbe essere più vicino il root DNS di Roma o di un’altra città europea.

Aggiornamento 17/2/2012 18:30Il sito dei root DNS ha una mappa piu precisa e aggiornata da cui si evince che in Italia ci sono due istanze a Torino, tre a Milano, due a Roma e una a Napoli.

La propagazione del DNS

Dolci riflessi a DolceacquaLe modifiche sono a posto, ora deve aspettare 48 ore perché si propaghino

Ve l’hanno detto talmente tante volte che il concetto che il DNS si deve propagare in 48 ore è radicato nella mente di tutti, anche di alcuni SysAdmin.

Eppure nessuno (o pochi) si è mai chiesto come mai riesco a parlare in tempo reale con l’altro lato del mondo, riesco a scaricare in pochi istanti un’immagine da un server remoto, riesco ad inviare velocemente una mail, ma ci vogliono due giorni per far propagare una modifica del DNS, manco le portassero UPS o DHL con consegne overnight da un server all’altro.

Le 48 ore sono in parte un retaggio storico in parte un modo per pararsi le terga da parte del gestore ed è un valore che può essere cambiato a piacere.

Leggi tutto “La propagazione del DNS”

Possibile DoS in BIND 9

Alcune organizzazioni hanno notato che BIND 9 è vulnerabile ad un attacco di tipo DoS quando risponde a query ricorsive.

È stato, infatti, notato che le versioni 9.4-ESV, 9.6-ESV, 9.7.x e 9.8.x di BIND escono in maniera anomala loggando l’errore INSIST(! dns_rdataset_isassociated(sigrdataset)) quando rispondono a determinate query ricorsive.

Sono disponibili le patch alle versioni coinvolte; le versioni che non presentano questo problema sono 9.8.1-P1, 9.7.4-P1, 9.6-ESV-R5-P1 e 9.4-ESV-R5-P1 (via ISC).

 

DNS poisoning

Qui siam tutti onesti, lo dice il cartello!Leggo che il tema del DNS poisoning è ancora attuale, circa tre anni dopo la sua esplosione.

Prima di tutto, un’introduzione per chi non conosce il funzionamento del DNS.

Ogni macchina su Internet è identificata da un indirizzo numerico (per ora, principalmente nella forma a.b.c.d dove le lettere rappresentano dei numeri da 0 a 255 decimale), ma è un dato difficile da ricordare e su uno stesso IP possono vivere più server virtuali, nel caso di httpd. È stato quindi creato un sistema che associa delle sequenze più facili da ricordare ad un indirizzo numerico: è più facile ricordare siamogeek.com piuttosto che 84.19.182.37. Il sistema per passare dal nome usato dagli umani all’indirizzo numerico utilizzato dalle macchine è detto risoluzione del nome, il quale si basa sul sistema dei nomi a dominio (DNS).

Leggi tutto “DNS poisoning”

DNS prefetching: una pessima idea

Mucca / Cowbrowser moderni hanno una funzione apparentemente utile, ma che provoca un notevole e inutile incremento di traffico DNS.

Una piccola spiegazione a grandi linee su cime funziona la risoluzione dei nomi, una delle tecnologie che stanno alla base del funzionamento di Internet per l’utente finale.

Ogni macchina (host) collegata a Internet ha un indirizzo IP che è necessariamente univoco (tralasciamo i NAT delle reti private che non ci interessano in questo contesto). L’indirizzo IP è, per ora, formato da una quaterna di numeri decimali da 0 a 255 separati da punti, tipo 1.2.3.4

Per rendere più facile la memorizzazione dei siti, esiste un sistema che assegna ad ogni indirizzo (ad esempio 209.62.58.154) uno più nomi a dominio (ad esempio siamogeek.com). Questo accoppiamento è gestito dal DNS. Leggi tutto “DNS prefetching: una pessima idea”

Script per blacklistare i domini su Windows Server

BloccoDarknet ha pubblicato un interessante script in PowerShell 2 di Jason Fossen che permette di blacklistare alcuni nomi a dominio ritenuti pericolosi.

Lo script crea una zona e, opzionalmente, degli host su un server DNS di Windows associandoli all’IP 0.0.0.0 o ad un altro indirizzo indicato. Leggi tutto “Script per blacklistare i domini su Windows Server”