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 leggere
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…)
Sono in arrivo nuovi domini generici di primo livello.
Il prossimo 11 novembre partirà il sunrise di questi gTLD:
Mentre il prossimo 3 dicembre partirà il sunrise di questi altri:
In base al regolamento ICANN, è obbligatorio stabilire un periodo iniziale di sunrise di almeno 30 giorni durante il quale la registrazione di nomi sotto quel gTLD è riservata ai possessori di marchi.
ICANN ha dato il via libera per la delega dei primi gTLD.
I TLD approvati sono:
Non ci vuole molto a capire che sono tutti TLD IDN: lo scopo di questa scelta è chiaramente dare un segnale che Internet non è limitata a chi utilizza i caratteri latini.
I tre Registry che si sono aggiudicati i gTLD hanno passato test rigorosi di funzionamento e sono pronti ad operare.
L’avvio dei TLD (generici o no che siano) IDN impone a tutti i SysAdmin e sviluppatori di rivedere eventuali filtri o RegEx per la validazione dei nomi a dominio e impone in maniera definitiva il supporto dei caratteri internazionali non latini e con senso di scrittura da destra a sinistra.
Negli ultimi tempi mi è capitato più volte di avere a che fare con problemi legati all’intestatario di un nome a dominio.
Premessa: questo è un articolo generico e non costituisce una consulenza di tipo legale, che deve essere fornita da professionisti specializzati.
Il titolare di un dominio è l’entità indicata nel campo Registrant. Il titolare è anche il responsabile dell’utilizzo del nome a dominio.
(altro…)ICANN ha pubblicato l’elenco delle richieste pervenute per la creazione dei nuovi gTLD a pagamento.
Bisogna tener presente che ICANN per ogni richiesta (anche non soddisfatta) di un nuovo gTLD ha incassato 185.000 dollari, come da sezione 5 delle FAQ.
Ho importato l’elenco pubblicato in una tabella SQL e ho fatto un po’ di analisi.
(altro…)
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:30 – Il 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.
“Le 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.
(altro…)Al momento esistono quattro categorie di domini di primo livello (TLD) approvati da ICANN:
Secondo Reuters presto ICANN potrebbe aprire a tutti la possibilità di avere un proprio TLD.
Se venisse approvata questa norma, chiunque potrebbe teoricamente richiedere un proprio TLD, rispettando, ovviamente, alcune norme.
Innanzi tutto, il costo per avanzare una simile richiesta è fissato attualmente a 185.000 dollari; inoltre il richiedente dovrà dimostrare la titolarità del nome legato al TLD.
I possibili acquirenti sono, ovviamente, i brand famosi, ma si potrebbero fare avanti anche zone metropolitane.
Visto che, stante l’attuale struttura, più in alto del TLD non si può andare, sarà interessante vedere cosa succede in caso di omonimie: ad esempio, se lo spumante Ferrari riuscisse a soffiare a Maranello il TLD cosa potrebbe succedere?
Aggiornamento 20/6/2011 6:30 – ICANN ha approvato la creazione di nuovi gTLD sponsorizzati con 13 voti a favore, 1 contrario e 2 astenuti. Le richieste potranno essere presentate dal 12 gennaio 2012 al 12 aprile 2012.
Oggi mi sono trovato nuovamente di fronte al problema di mettere dei client Windows 7 in un dominio con DC Samba. Il problema e` che occorre una versione recente di Samba (3.4.x o 3.5.x) e che spesso i server che ho presso i clienti hanno una versione vecchia di Debian, versione che quando e` possibile evito di aggiornare, seguendo la regola d’oro che dice “Quando va che tanto basta, non toccar che poi si guasta”.
Se serve Samba 3.4.x per Debian Lenny, e` disponibile nel repository dei backports, ma se si deve installare su vecchie Debian Etch o addirittura Sarge, tutto potrebbe essere molto ma molto rognoso.
Per fortuna mi e` venuto in aiuto un sito, http://enterprisesamba.org/, che mette a disposizione Samba (recente) bello pronto e pacchettizzato (a 32 e 64 bit) per diverse distribuzioni Linux, fra le quali Debian, e supporta versioni decisamente vecchie (ad oggi, Lenny, Etch e Sarge). Il sito manca purtroppo di chiarezza su quali siano esattamente le differenze fra le loro scelte di patch (o assenza di patch) e di parametri di compilazione fra la versione “Debian ufficiale” e la loro, pero` messo alle strette ho deciso di dare loro fiducia, e direi che l’installazione di Samba 3.4.x dal loro sito su una Debian Etch abbia avuto esito assolutamente positivo. Occorre solo fare un minimo di attenzione alle dipendenze quando si aggiorna (di fatto si sostiuisce) la versione Debian originale di Samba con questa.
Domani finiro` di mettere le macchine client nel dominio, e vedremo se mi pentiro` di aver detto che funziona con troppo anticipo e troppo entusiasmo. Se qualcuno volesse seguire le mie orme, vi ricordo che oltre alla versione giusta di Samba, occorre anche applicare una piccola patch ai client Win7, come scritto qui: http://wiki.samba.org/index.php/Windows7
Darknet 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. (altro…)