<div dir='auto'>Ciao,<div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Ne avevo parlato a qualche martedì romano in hamburgeria.. ma secondo me la soluzione sono le view basate su IP destinazione e un caching resolver nel modem che viene riconfigurato al cambio utente, per puntare l'IP con le view giuste.</div><div dir="auto"><br></div><div dir="auto">Ovviamente se hai 7 categorie hai 2^7 viste e sono un po' troppe, quindi direi max 5 categorie che sono già 32 viste.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Il problema dello spreco di IP per le viste lo risolvi con:</div><div dir="auto"><br></div><div dir="auto">-IPv6 (sarebbe bello)</div><div dir="auto">-anycasting così metti X macchine (quante ne bastano per il tuo traffico) e tutte hanno gli stessi IP anycast</div><div dir="auto">-usando IP privati o similari (i vari testnet) solo nella tua rete per raggiungere i DNS (che poi in uscita andranno sul secondo livello di resolver con le blacklist obbligatorie o su internet diretto con altri IP Unicast).</div><div dir="auto"><br></div><div dir="auto">Anycast l'ho disegnato, usato e gestito per reti mobili di qualche milione di clienti e centinaia di migliaia di qps. Con macchine del 2008 ogni sito (4 server) arrivava a 200k QPS.</div><div dir="auto"><br></div><div dir="auto">Con il ferro attuale non è impossibile fare 1-2 milioni di qps in qualche unità rack.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div data-smartmail="gmail_signature" dir="auto">Sent from Android Phone</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">Il 28 lug 2023 18:19, Massimo Fontanive via itnog <itnog@lists.itnog.it> ha scritto:<br type="attribution" /><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<p>Ciao,</p>
<p>anch'io sto pensando ad una architettura simile, con alcune
variazioni.</p>
<p>Ad esempio, una ipotesi è una struttura a 3 livelli su almeno 2
resolver dedicati al Parental Control (primario/secondario). Ogni
resolver avrà questa struttura:<br />
</p>
<p>DNS PROXY/CACHE (load balancing sui 2 resolver) ---> DNS
RESOLVER LOCALE (con gestione Blacklist governative) --> COPPIA
DI DNS RESOLVER FILTRATO (servizio di terze parti)<br />
</p>
<p>In questo modo, ottengo una certa resilienza (coppia di DNS in
load balancing), sono complaint con le blacklist governative (ADM,
AGCOM, CNCPO, ecc) e mi svincolo dal problema di dover tenere
aggiornate delle liste scaricate chissà dove scaricando la
responsabilità su un terzo (basta dichiarare chi è il fornitore e
quali categorie si usano per filtrare, come da linee guida)</p>
<p>Inotre, ho un grosso risparmio di costi del fornitore, perchè
faccio cache locale e passo soltanto le richieste dei clienti che
hanno Parental Control attivo (quindi meno QPS).</p>
<p>L'unico problema che vedo è la granularità del filtro. C'è un
numero minimo di categorie che devono essere configurabili
dall'utente finale?</p>
<p>Se, come credo, non c'è ma la norma obbliga a rendere
configurabili le categorie opterei per definire un set minimo
(tipo 2/3 macro categorie) ed automatizzare questa configurabilità
da parte dell'utente. Ma questo nella prossima mail ;-)<br />
</p>
<p>Massimo<br />
</p>
<p><br />
</p>
<div>Il 28/07/2023 16:59, Matteo Sgalaberni
ha scritto:<br />
</div>
<blockquote>
<div style="font-family:'arial' , 'helvetica' , sans-serif;font-size:10pt;color:#000000">
<div>
<div>
<div>Ciao a tutti,</div>
<div><br />
</div>
<div>volevo condividere un'idea di architettura per
l'applicazione della 9/23/CONS (Parental control) che
allego.</div>
<div><br />
</div>
<div>L'ho costruita pensando di fare qualcosa di
semplice dal punto di vista architetturale e senza
dipendenze.</div>
<div><br />
</div>
<div>Se qualcun altro ha identificato soluzioni più
semplici e/o robuste e vuole condividere queste
informazioni, è il benvenuto.</div>
<div><br />
</div>
<div>Circa le liste da cui raccogliere l'elenco dei
domini da bloccare rimane un forte dubbio amletico. Io ho
provato a contattare anche C** di società di sicurezza che
offrono DNS as a service in EU e US, e mi è stato risposto
da tutti che non rivendono le loro liste, che non le
comprano da nessuno e che se le fanno trovando liste open
un po' di qua e un po' di la' senza grande "scienza"
dietro...</div>
<div><br />
</div>
<div>Un punto per ottemperare alla delibera sarebbe
comunicare anche da dove prendiamo le liste... non so se
dire "le ho trovate su google e github un po' a caso" sia
accettabile ;)</div>
<div><br />
</div>
<div>Qualcuno è riuscito a trovare qualche
fornitore di liste con cui si possa fare regolare
contratto?</div>
<div><br />
</div>
<div>Ciao!</div>
<div><br />
</div>
<div>Matteo Sgalaberni</div>
</div>
</div>
</div>
<br />
<fieldset></fieldset>
<pre>
</pre>
</blockquote>
<div>-- <br />
<font size="2" face="Verdana, Arial">---------------------------------------
</font>
<div><font size="2" face="Verdana, Arial"><b>Massimo
Fontanive</b><br />
Network operations<br />
</font></div>
<div><font size="2" face="Verdana, Arial"><br />
</font></div>
<div><img src="cid:part1.Um03kbpk.KQjzC36q@progetto8.net" alt="" width="144" height="50" /> <font size="1" face="Verdana, Arial">
<br />
</font></div>
<div><font size="1" face="Verdana, Arial">
Progetto 8 Srl <br />
Via XXI Aprile 76 <br />
29121 Piacenza <br />
Tel. 0523.1885611 <br />
Fax 0523.1880303 <br />
<a href="http://www.progetto8.net">www.progetto8.net</a></font></div>
</div>
</div></blockquote></div><br></div>