Newsgroup: it.news.net-abuse
Titolo: ICANN annuncia i "custom TLD" - fine delle URIBL ?

Stavo leggendo questo
http://news.cnet.com/8301-30685_3-20019282-264.html
e la cosa mi ha fatto quasi immediatamente pensare
alle "URIBL", il dubbio che mi assilla �... riusciranno
le URIBL a sopravvivere ad una cosa del genere ?
Non per altro, ma, dal punto di vista dei servers che
tengono in piedi le liste, la mole di dati aumenter� a
dismisura e, dal punto di vista dei "clients" diventer�
problematico controllare il TLD ed "estrarre" da un
dato nome host il dominio
o quantomeno questo � il dubbio che mi � balzato
alla mente, spero di sbagliarmi o che comunque
mi sia sfuggito qualcosa e spero che qualcuno
possa aiutarmi a chiarire quanto sopra

 dato nome host il dominio
Anche questo non � necessariamente un problema, e pressoch� tutto il SW
in circolazione � gi� predisposto per trattare il caso (liste di TLD
esterne al codice).
Non che ci sia da aspettarsi una esplosione selvaggia di nuovi TLD, IMHO...
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/

 IMHO...
Non lo so... sinceramente non lo so, per come la vedo io potrebbe
esserci un avvio lento, un'esplosione di una certa durata e poi una
certa fase di "stabilit�" (relativa)
in qualsiasi caso, grazie !

 un problema *enorme* ma potrebbe esistere
Se dovesse essere il caso, si troverebbe senza dubbio il modus tecnico
per automatizzare anche la lista di TLD in maniera affidabile e
scalabile, come si fa con tante altre cose.
Di certo, non appariranno TLD come oggi appaiono i domini.
I costi e i tempi impliciti nelle procedure di validazione dei nuovi
TLD, poi, continuano a farmi essere molto perplesso riguardo ad
eventuali "esplosioni"..


 perplesso riguardo ad eventuali "esplosioni"..
beh, credo che le "major" partiranno quasi sicuramente
con la registrazione dei propri TLD "brandizzati" ed a
quel punto credo che anche nomi "minori" si getteranno
nella mischia... sino a che passer� l'aria di "novit�" ed
il tutto torner� pi� o meno stabile ... spero :D

  o meno "a gratis"?
esatto, ora supponi che con la "liberalizzazione" del TLD
un "cantinaro" (ok, termine non corretto) permetta a chiunque
ed in modo facile/veloce di dare il via a TLD di terzo livello :)
a quel punto i  TLD *validi* da considerare per un check URIBL
aumenterebbe parecchio dato che non basterebbe un check
su (es.) ".pippo" ma dovresti anche controllare ".co.uk.pippo"
o quello che �, ed � questo che mi fa sorgere il dubbio sulla
quantit� di carico necessaria sia ai servers URIBL sia sul lato
client per "estrarre" un dato nome di dominio
spero di essere stato pi� chiaro ora; ripeto, � soltanto un dubbio
che mi � sorto leggendo quelle info a proposito dei "custom TLD"
ed al fatto che tali TLD potrebbero portare ad una proliferazione
incontrollata di "TLD" di secondo/terzo/... livello perfettamente
validi

 client per "estrarre" un dato nome di dominio
1) non cambia nulla (sostanzialmente) rispetto a ora: gi� adesso vale la
stessa cosa per i vari freehosters, per gli ISP, per i SLD "speciali"
(pensa ai domini geografici italiani) e per parecchie altre cose. Il
meccanismo � gi� l� ed � gi� usato, la possibilit� di TLD aggiuntivi non
cambia in maniera sostanziale il quadro, se non alla voce "numeri", in
modo peraltro tutt'altro che ingestibile
2) non necessariamente il parsing del domain boundary su cui effettuare
il lookup deve avvenire lato client. DBL � partita, fin dal primo
momento, come lista wildcarded. Se ricevi una mail linkante
www.blah.sprutz.co.uk
, puoi (dovresti) effettuare il lookup per
www.blah.sprutz.co.uk.dbl.spamhaus.org
, tutto intero: non ci si attende
che tu debba essere autonomo nell'estrazione dell'esatta stringa da
usare per la query, la logica relativa sta tutta nella zona DNS. SURBL
-e presumo anche URIBL- prima o poi seguir� la stessa strada (i problemi
nel farlo sono meramente tecnico-organizzativi, legati alla necessit� di
governare lo switch dal vecchio al nuovo sistema). In quel caso "il
problema" sparisce praticamente del tutto.


 necessit� di governare lo switch dal vecchio al nuovo sistema). In
banale imo, lasci in piedi la zona cosi come � ora e metti in piedi una
seconda zona con nome diverso che utilizzi il wildcarding; a questo
punto annunci una chiusura della vecchia zona ad una ben definita
data e via andare

 data e via andare
Questo � esattamente quello che si vuole evitare... :-P


 Questo � esattamente quello che si vuole evitare... :-P
posso capirne i motivi, per� credo sia l'unico approccio possibile
vedi, i veri "show stoppers" imHo sono non tanto coloro che usano
delle queries DNS dirette ma quelli che usano rsync ed una copia
locale della zona; questi ultimi nel caso di un cambio di "formato"
si troverebbero "a piedi" di botto mentre con un passaggio pi�
graduale, avrebbero il tempo di adeguare le proprie infrastutture
se poi al termine del "grace period" non lo avranno fatto... 'zzi
loro <g> - in compenso questo permetterebbe di partire "subito"
con il wildcarding, lasciare il tempo di aggiornare i sistemi e poi
una volta completato il passaggio, riportare le zone ai nomi
originali ed a quel punto "chi c'� c'�, chi non c'� si attacca" :D

 si troverebbero "a piedi" di botto mentre con un passaggio pi�
No. Il formato � sempre quello di rbldnsd, cambia "solamente" la
scrittura usata per le entry
non wildcarded:
baddomain.tld
wildcarded:
.baddomain.tld


 "solamente" la scrittura usata per le entry
Si ok, ma immagina qualcuno che stia facendo "rsync"
con i file e che abbia una versione (diciamo) "anziana"
di rbldnsd e si trovi a prelevare dei files che per un
motivo o l'altro gli "piantano" i daemons <g> ... sul serio
a parte l'ovvio sforzo a livello implementativo, dal
punto di vista di chi gestisce i servers non vedo grossi
problemi, tranne (ovviamente) l'aumento di "computational
resources" dovuto al "match" delle queries che a quel
punto invece di essere "ripulite" dai clients, sarebbero
ripulite dai servers

 ripulite dai servers
Le "computational resources" di rbldnsd non cambiano di una virgola.
Gli impatti, casomai, sono legati al fatto che svariati resolver in
circolazione tendono a trattare maluccio il caching di risoluzioni per
record wildcard, il che causa un aumento di traffico verso le istanze di
rbldnsd dell'infrastruttura pubblica. Tutt'altro che ingestibile, comunque.
