cose tecniche

Marco d'Itri md a LINUX.IT
Gio 8 Ago 2002 11:24:52 CEST


Questo messaggio contiene alcune mie riflessioni su aspetti tecnici
della gestione del ccTLD it che credo dovrebbero essere approfonditi.
Vi prego di farmi conoscere le vostre opinioni su questi argomenti,
e ovviamente spero che lo staff della RA voglia chiarirmi il suo punto
di vista.

Preciso che ho la massima stima dello staff della RA e spero che nessuno
intenda questo messaggio come un attacco, voglio che sia solo un modo
per confrontarsi su delle questioni tecniche.


Tutti i domini geografici[1] tranne 7 sono delegati a due soli name
server: dns.nic.it dns2.nic.it, che fanno parte della stessa rete.
Anche supponendo che questi due server (cluster di server?) e
l'infrastruttura di rete circostante non costituiscano un single point
of failure (a proposito, la connettività fisica dello IAT è a prova di
scavatore?), la rete di cui fanno parte è annunciata da AS137 aggregata
in 193.204.0.0/15.
Quindi (senza nulla togliere allo staff del GARR, si intende :-) ) basta
qualche flap della route e il successivo dampening per rendere
effettivamente irrisolvibili tutti i domini geografici.
Se questo ovviamente non è accettabile per i domini direttamente sotto
it, perché lo è per quelli sotto i domini geografici?
Mi è appena venuto in mente: cosa è successo nei giorni successivi
all'11 settembre, quando il GARR ha perso il transito? Era stato trovato
un backup di emergenza per questa route? Se sì, ha superato i filtri
degli altri carrier?

A dire il vero non mi è del tutto chiaro perché quando il controllo dei
domini geografici è passato alla RA sono stati mantenuti i zone cut
invece che mettere i domini di terzo livello direttamente nella zona it.
(Per accorciare il black out durante il reload della zona?)

Tutti i server sono una monocultura di BIND 8. Sono l'unico a
considerarlo potenzialmente pericoloso?
Sia BIND 9 che NSD mi sembrano candidati degni di essere valutati per
affiancare BIND 8. È in programma cercare alternative a BIND 8?

Che livello di servizio fornisce dns.nic.it? E gli altri server
autorevoli?
Ha ciascun server, se non un hot spare o un cluster, almeno dell'hardware
di ricambio immediatamente disponibile?
La notte capita spesso di trovarne uno che non risponde durante lo zone
transfer, qualcuno lo considera un problema? Inoltre, spesso
dns[23].nic.it ignorano i NOTIFY perché troppo carichi.
(Esistono delle statistiche sulla raggiungibilità e latenza dei server?)

Che garanzie di sicurezza (fisica e logica) sono richieste agli sponsor
dei name server?
Mi ricordo che dopo l'ultimo grosso buco di BIND uno di essi è rimasto
vulnerabile per mesi, sono l'unico che se ne è preoccupato?

È una opinione diffusa che un name server autorevole (in particolare per
un TLD) non debba essere ricorsivo per evitare ogni possibilità di
spoofing.
Metà dei server autorevoli per it accettano query ricorsive. Perché?
Considerazioni analoghe si possono fare per l'opzione fetch-glue e si
possono estendere ai name server dedicati al servizio di slave.
Tra non molto probabilmente bisognerà modificare la delega della zona
it per sostituire ns.ripe.net, è il caso di valutare se ci sono dei
secondari che non soddisfano alcuni requisiti di sicurezza minimi?

C'è un grande numero di glue record sbagliati nella zona it.
Fondamentalmente perché non esiste il concetto di host record (una pecca
del software di RIPE, suppongo perché *loro* non ne avevano bisogno per
gestire il reverse mapping) e perché una volta registrato un oggetto
domain non viene più fatto alcun controllo.
Per esempio ci sono 835 domini[2] delegati a dns.nis.garr.it, che non
esiste più da chissà quanti anni.
Se è considerata una buona idea verificare con estrema pedanteria[3] la
correttezza formale dei dati al momento della registrazione, perché dopo
non lo si fa mai più?

Un problema che ho visto essere molto frequente sono le risposte
contenenti record A doppi, causate da oggetti domain non aggiornati.
Esempio pratico: dig bersafe.it ns @dns.nic.it restituisce due record A
per ns.bersafe.it. Questo accade perché il vero IP è cambiato l'anno
scorso (e di conseguenza è stato aggiornato l'oggetto domain relativo a
bersafe.it), ma esiste anche un altro oggetto domain non aggiornato
che ha un attributo nserver contenente ns.bersafe.it e il vecchio IP.
Non aiuta il fatto che vengano creati anche glue record non strettamente
necessari, per esempio firenze.linux.it per hacklab.it.
Possibili soluzioni:
- quando si estraggono i glue record per generare la zona, l'unico IP
  considerato è quello indicato nell'oggetto domain del dominio
  contenente la label
- ottenere i glue record tramite delle normali query ogni volta che si
  genera la zona
- quando si modifica un oggetto domain che causa la generazione di un
  glue record bisogna contemporaneamente modificare tutti gli altri
  oggetti domain delegati allo stesso server
- controllare la validità dell'IP di ogni attributo nserver e avvertire
  gli zone-c di quelli sbagliati [pausa per le risate]

La prima mi sembra facilmente implementabile e senza ovvii svantaggi.
In più restituisce il controllo sul glue record all'unica entità che
deve avere diritto di modificarlo, cioè l'assegnatario del dominio che
contiene la label.


Feature requests:

Iniziano ad essere diffusi name server raggiungibili tramite IPv6.
Quando sarà possibile ottenere la creazione di glue record AAAA, come
già ora permettono altri ccTLD?

La RA ha in programma di fornire connettività IPv6 ad almeno uno dei
server autorevoli per la zona it, come hanno già fatto altri ccTLD?

BIND già da tempo permette di aggiornare una zona in tempo reale
mediante UPDATE, e mi pare che alcuni TLD lo permettano. Qualcun altro
la considera una caratteristica desiderabile?


Per finire una cosa non tecnica ma che mi interessa lo stesso: come può
un dominio essere in stato CHANGING-MNT dal 1995? Non avrebbe dovuto
essere stato cancellato perché nessuno ne paga le spese?


[1] whois -h whois.nic.it -i mnt-by RA-GEO-MNT

[2] whois -h whois.nic.it -i nserver dns.nis.garr.it | grep -c ^domain:

[3] ancora non mi va giù non potere usare secondary.com come secondario
dei miei domini it perché l'MNAME del SOA non esiste. Questa restrizione
non ha una giustificazione tecnica e non è documentata da nessuna parte.

--
ciao,
Marco



Maggiori informazioni sulla lista ita-pe