Salve,
sono un utente fastweb residenziale, e noto che dalla mia rete
domestica vengono effettuate molte query PTR per risolvere
ip interni a fastweb. Credo che i dns di fastweb
ricevano molte richieste di questo tipo, un po' da tutti i clienti.
Qual'è il problema? Che purtroppo nessun nameserver di fastweb sembra
essere autoritativo per le zone *.in-addr.arpa corrispondenti;
di conseguenza, qualora la risposta non fosse in cache, c'è il rischio
che la query venga inoltrata ai root servers generando traffico
inutile...
Insomma, mi chiedevo se per gli ip interni a fastweb non si ponesse
lo stesso problema già noto per il reverse mapping di
reti private (RFC1918) e indirizzi link local (169.254.0.0/16)
(si veda, ad esempio
http://www.chagreslabs.net/jmbrown/research/drafts/draft-brown-pvtipdns-01.html )
Ammesso che ce ne fosse bisogno, pensavo alle possibili soluzioni.
Chi gestisce un dns nella propria rete locale potrebbe renderlo
autoritativo, oltre che per la risoluzione degli indirizzi suddetti,
*anche* per zone come 1.in-addr.arpa
(MAN Fastweb di Milano), 39.in-addr.arpa (MAN di Napoli),
e così via per tutte le altre. [1]
Meglio ancora si potrebbe scrivere a Fastweb chiedendo che
configuri i propri nameserver e, magari già che c'è,
tiri su un bel sistema AS112... [2] però temo che quest'ultima
strada sia poco percorribile... [3]
Attendo commenti, domande, insulti: a richiesta posso anche
postare (o inviare privatamente) output di comandi e righe di
configurazione.
[1] Lo so, sono ip che Fastweb non dovrebbe usare perché potrebbero
essere instradati pubblicamente in futuro, e in pratica sto
proponendo di *adeguarci* alle sue scelte...
[2] http://www.as112.net/ e naturalmente
http://baol.linux.it/as112/, di cui fastweb è fra i migliori
"clienti".
[3] perché mi pare improbabile che un utente finale possa dire
ai sistemisti del proprio ISP come devono lavorare: e qua
non si tratta delle classiche segnalazioni tipo "non riesco
a navigare, non scarico la posta".
--
Guido De Rosa
gderosa at email it
Guido De Rosa ha scritto:
>
> sono un utente fastweb residenziale, e noto che dalla mia rete
> domestica vengono effettuate molte query PTR per risolvere ip interni
> a fastweb.
[...]
> Insomma, mi chiedevo se per gli ip interni a fastweb non si ponesse
> lo stesso problema giŕ noto per il reverse mapping di reti private
> (RFC1918) e indirizzi link local (169.254.0.0/16)
Il punto e' che, se vuoi risolvere la situazione, devi farlo tu in modo
autonomo impostando in tal senso il tuo DNS locale/LAN, come hanno fatto
p.es. le aziende che gestiscono il proprio server DNS.
Questo signfica configurare adeguatamente il tuo DNS per le zone
IN-ADDR.ARPA associate ai seguenti IP (che sono IANA reserved, ma che
FastWeb usa per identificare le varie MAN) :
==
- 1/8 -> IP assegnati alla MAN di Milano
- 2/8 -> IP assegnati alla MAN di Milano Hinterland NORD
- 5/8 -> IP assegnati alla MAN di Genova
- 14/8 -> IP assegnati alla MAN di Milano Hinterland SUD (*)
- 23/8 -> IP assegnati alla MAN di Roma
- 29/8 -> IP assegnati alla MAN del Triveneto (*)
- 31/8 -> IP assegnati alla MAN di Bari
- 37/8 -> IP assegnati alla MAN di Bologna
- 39/8 -> IP assegnati alla MAN di Napoli
- 41/8 -> IP assegnati alla MAN di Torino
- 42/8 -> IP assegnati alla MAN di Reggio Emilia
(*) Peraltro :
14/8 = IANA - Public Data Network
29/8 = Defense Information Systems Agency
> mi pare improbabile che un utente finale possa dire ai sistemisti del
> proprio ISP come devono lavorare
Mettiti in coda ;) = siamo ancora in attesa che FastWeb definisca il
reverse DNS non solo per gli indirizzi IP pubblici appartenenti ai pool
NAT-Residential (a-b-c-d.fastres.net), ma anche per quelli associati ai
pool Small-Business e connessioni LAN/WAN-Distretti Industriali.
--
|Ż \/Ż | /Ż\ /Ż__/Ż__|-<|> * FAQ 1.6 ITGF it.tlc.gestori.fastweb <|
|Ż|\/|Ż|/Ż_Ż\|(__\__ \-<|> * ----------------------------------- <|
|_| |_/_/ \_\___|___/-<|> * SITO: http://plany.fasthosting.it <|
|>Togli/Remove .INVALID<|> * SITO: http://www.gofastweb.cjb.net _<|
> Il punto e' che, se vuoi risolvere la situazione, devi farlo tu in modo
> autonomo impostando in tal senso il tuo DNS locale/LAN, come hanno fatto
> p.es. le aziende che gestiscono il proprio server DNS.
Ah, ma io l'ho già fatto :) Catturo le query della mia LAN, ma
se fastweb lo facesse coi suoi nameserver sarebbe molto meglio
per il DNS globale...
Stavo quasi pensando di offrire il servizio al resto della rete
fastweb, ma con l'hardware di un vecchio pc e senza UPS non posso
certo garantire un'alta disponibilità. Ad ogni modo, se qualcuno
volesse fare delle prove, l'IP è negli header...
> - 29/8 -> IP assegnati alla MAN del Triveneto (*)
Uh, il Triveneto mi mancava. Grazie!
/etc/init.d/bind9 reload
>Qual'è il problema? Che purtroppo nessun nameserver di fastweb sembra
>essere autoritativo per le zone *.in-addr.arpa corrispondenti;
Alcuni lo sono, o almeno lo erano una volta.
>Insomma, mi chiedevo se per gli ip interni a fastweb non si ponesse
>lo stesso problema già noto per il reverse mapping di
Si pone...
>Meglio ancora si potrebbe scrivere a Fastweb chiedendo che
>configuri i propri nameserver e, magari già che c'è,
>tiri su un bel sistema AS112... [2] però temo che quest'ultima
>strada sia poco percorribile... [3]
Ci si sta lavorando. :-)
--
ciao,
Marco
> In it.tlc.gestori.fastweb Guido De Rosa <anon...@universe.invalid> wrote:
>
> >Qual'è il problema? Che purtroppo nessun nameserver di fastweb sembra
> >essere autoritativo per le zone *.in-addr.arpa corrispondenti;
> Alcuni lo sono, o almeno lo erano una volta.
Quelli che mi fornisce fastweb con dhcp non lo sono di sicuro.
Trattasi di ns017dns e ns018dns.fastweb.it. Da ns001dns a ns016dns
mi restituiscono un REFUSED quindi non posso sapere (non sono nella
MAN giusta, evidentemente). dns1 e dns2.fastweb.it non fanno testo
perché il loro compito è essere autoritativi per fastweb.it.
> -snip-
> >Meglio ancora si potrebbe scrivere a Fastweb chiedendo che
> >configuri i propri nameserver e, magari già che c'è,
> >tiri su un bel sistema AS112... [2] però temo che quest'ultima
> >strada sia poco percorribile... [3]
> Ci si sta lavorando. :-)
Uhm, questo è interessante. Facci sapere come evolve la cosa :)
> --
> ciao,
> Marco