Newsgroup: it.comp.reti.ip-admin
Titolo: Interbusiness e zona inversa.

Ho un problemino con interbusiness, o meglio, penso di averlo:
il mio dns pubblico risolve correttamente la zona inversa, ma se richiedo
la risoluzione dei miei ip altrove, ciccia.
Posso presumere che interbusiness non mi demandi correttamente la zona,
ma non so come esserne sicuro. Qualcuno sa darmi la procedura corretta
per interrogare la mia zona inversa e vedere in quale punto della catena
si blocca il tutto?
PS: per esperienza altrui, per queste cose si contatta l'help dest IB,
immagino... non che io frema per farlo...
-- 
Emanuele Balla  aka Skull -  Public Key #661E5CBF on 
www.keyserver.com
+----------------------------------------------------------------------+
"And 1.1.81 is officially BugFree(tm), so if you receive any bug-reports
on it, you know they are just evil lies." (By Linus Torvalds)

 
Un mio amico ha lo stesso (credo) problema. Ha comprato un dominio (non da 
Interbusinnes) e lo ha associato all'IP pubblico datogli da Interbusinnes. 
I DNS in giro per il mondo risolvono correttamente i nomi delle sue
macchine, ma quando prova a risolvere da IP a nome, ritornano tipo
"
hostxxx-poolxxx.interbusinnes.it
".
In realta' e' corretto, perche' se lui ha registrato, diciamo, il dominio,
pippo.it
, e 
www.pippo.it
 ha IP 1.2.3.4, comunque non ha detto a nessuno 
che 1.2.3.4 e' sotto l'autorita' del suo DNS. Di fatto, Interbusinnes
e' autorevole sulla risoluzione inversa dei suoi indirizzi, e quindi 
da Internet le richieste continuano ad arrivare ai DNS di Interbusinnes,
che lo risolvono in base alle informazioni in loro possesso. .
Se la tua situazione e' la stessa, devi neccessariamente telefonare ad 
Interbusinnes e farti delegare le voci in-addr.arpa delle tue macchine.
Il problema e' quello.
Il mio amico non lo ha mai fatto pero'; non so quanto sia una menata.
Spero di esserti stato utile (e chiaro).
Ciao  

 richiedo la risoluzione dei miei ip altrove, ciccia.
Yup, IB non ti "mappa" i PTR automaticamente, devi esplicitamente
richiederlo; in pratica, supponi di avere il dominio "
skull.it
" ed aver
registrato l'host  
mail.skull.it
 presso IB, durante la registrazione *devi*
richiedere anche la registrazione di d.c.b.a.in-addr.arpa = 
mail.skull.it
dato che i bravissimi e capacissimi signori di IB altrimenti non la fanno
con grande gioia di chi deve inviare/ricevere posta da/a servers che
effettuano un controllo sul reverse-address :-)
Un consiglio; se possibile installati un tuo DNS visibile da internet poi
fatti delegare da IB il tuo dominio ed il tuo IPBlock cosě sarai in grado
di gestirti autonomamente tutte le registrazioni senza dover passare
attraverso il cosiddetto "helpdesk" (uh ovvio che il DNS pubblico lo
dovrai come minimo piazzare in DMZ altrimenti sono dolori)
Ciao
* ObiWan
DNS "fail-safe" for Windows 2000 and 9X clients.
http://ntcanuck.com
408 XP/2000 tweaks and tips
http://ntcanuck.com/tq/Tip_Quarry.htm

 pubblico lo dovrai come minimo piazzare in DMZ altrimenti sono dolori)
Questo è già. E' una zona di 32 ip. Il fatto è che a suo tempo le
registrazioni non le ho fatte io, sono arrivato dopo.
Ora ho (ovviamente) problemi di posta di vario genere e indagando sul
perchè ho trovato che IB non mi rigira la delegation.
Non che me lo risolvano come appartenente al loro domain. proprio il PTR
non esiste.
Non avendo ancora mai avuto a che fare con IB non ho idea se la
delegation la girino loro o se in qualche modo la delegation la rigiri
direttamente il RIPE per loro conto (ammesso che ciò sia possibile...).
Posso presumere, dal fatto che i miei ip *non* vengano risolti, che la
richiesta di delega sia stata effettivamente fatta (altrimenti mi
risolverebbero come hostxxx.xxx.xxx-interbusiness eccetera), ma che ora
(o forse fin dall'inizio, non lo so...) la delegation punti dalla parte
sbagliata, ma non so come fare a verificarlo... e il mio problema è qui:
prima di chiamare i simpatici signori dell'help desk interbusiness volevo
recuperare più info disponibili , ma non so come recuperarle...
si trattasse di una zona diretta le cose sarebbero più semplici, ma non
so come effettuare l'escalation dai root per una zona inversa...
peraltro la zona inversa del mio ns (interrogata da me che mi ci
appoggio) pare assolutamente ok...
consigli?


 registrazioni non le ho fatte io, sono arrivato dopo.
Hm .. per caso il dominio è 
skullkrusher.net
 ??
In questo caso ...
;; ANSWER SECTION:
skullkrusher.net
.       172800  IN      NS      
DNS.SATELGROUP.net
.
skullkrusher.net
.       172800  IN      NS      
NS36.WORLDNIC.COM
.
;; ADDITIONAL SECTION:
DNS.SATELGROUP.net
.     172800  IN      A       213.26.96.98
NS36.WORLDNIC.COM
.      172800  IN      A       216.168.225.166
ossia i due DNS per la zona sono quelli di cui sopra - secondo
un DNS di "nettuno"; ora se faccio una query sul primo DNS per
i servers DNS di 
skullkrusher.net
 ottengo
;; ANSWER SECTION:
skullkrusher.net
.       86400   IN      NS      
dns.satelgroup.net
.
skullkrusher.net
.       86400   IN      NS      
satsrv01.ud.satelgroup.net
.
;; ADDITIONAL SECTION:
dns.satelgroup.net
.     86400   IN      A       213.26.96.98
satsrv01.ud.satelgroup.net
. 86400 IN    A       217.57.198.162
il che non corrisponde .. mi sa che hai qualche casino galattico nella
config dei DNS che gestiscono il dominio .. bah, vediamo come va il
reverse lookup ... prima di tutto chiedo MX al dns di satelgroup ...
;; QUESTION SECTION:
;
skullkrusher.net
.              IN      MX
;; ANSWER SECTION:
skullkrusher.net
.       86400   IN      MX      10 
mail.ebravo.it
.
;; AUTHORITY SECTION:
skullkrusher.net
.       86400   IN      NS      
dns.satelgroup.net
.
skullkrusher.net
.       86400   IN      NS      
satsrv01.ud.satelgroup.net
.
;; ADDITIONAL SECTION:
mail.ebravo.it
.         86400   IN      A       217.57.198.166
dns.satelgroup.net
.     86400   IN      A       213.26.96.98
satsrv01.ud.satelgroup.net
. 86400 IN    A       217.57.198.162
come supponevo, i record MX puntano ad un'altro dominio
mamma che casino !! A questo punto, supponiamo di volere
il PTR di 
mail.ebravo.it
;; QUESTION SECTION:
;166.57.198.217.in-addr.arpa.   IN      PTR
;; AUTHORITY SECTION:
217.in-addr.arpa.       7200    IN      SOA     
ns.ripe.net
.
ops-217.ripe.net
. 2003041603 43200 7200 1209600 7200
TOMBOLA !


 
Hmm... le cose sono più incasinate di quello che sembra ;-) comunque il
problema non è legato a quella zona: se guardi il serial della zona sul
primario, vedi che è datata a oggi... il motivo delle discordanze che
trovi è dovuto al fatto che la variazione deve ancora propagare.
Se ti va di proseguire la discussione in privato, posso darti qualche
info in più... (anche se mi sa che ormai si fa domani, dato che mi tocca
uscire...).
Se sei disponibile, rispondi direttamente sulla email in testa, che è
buona...
THX...


 buona...
Beh, non so se avrò tempo, in ogni caso vedi i links sopra poi
fammi sapere, semmai ci si può sentire dopo che avrai fatto
le opportune verifiche ...


 
http://www.dnsreport.com/tools/dnsreport.ch?domain=skullkrusher.net+
[snap]
Conoscevo già... come da regolamento, l'unico segnale che mi dà è la
mancanza della risoluzione inversa :-/
ribadisco che il dominio oggetto del contendere *non* è 
skullkrusher.net
;-)
Sai dirmi come effettuare l'escalation a partire dalla root per la zona
inversa?
Dig dovrebbe essere sicuramente risolutivo, basta saperlo utilizzare.. e
se dig e host, come dicevo, mi sono risolutivi per quanto riguarda la
zona diretta, non ho idea di come usarli per scalare quella inversa...
Come dice la manpage di dig nella sezione "BUGS": probabilmente ci sono
troppe opzioni... :-P


 inversa...
Beh non è molto difficile; rovesci l'indirizzo e ci appicichi "in-addr.arpa"
poi inizi a richiedere la risoluzione ad uno dei root-servers (es. a.root-
servers.net
) e procedi usando via via i servers che vengono ritornati;
ad esempio, supponendo che l'IP da verificare sia 193.43.2.1 (a caso)
dig @
a.root-servers.net
 1.2.43.193.in-addr.arpa. IN PTR
;; QUESTION SECTION:
;1.2.43.193.in-addr.arpa.       IN      PTR
;; AUTHORITY SECTION:
193.in-addr.arpa.       86400   IN      NS      
ns.ripe.NET
.
193.in-addr.arpa.       86400   IN      NS      
NS2.nic.fr
.
193.in-addr.arpa.       86400   IN      NS      
sec1.apnic.NET
.
193.in-addr.arpa.       86400   IN      NS      
sec3.apnic.NET
.
193.in-addr.arpa.       86400   IN      NS      
sunic.sunet.se
.
193.in-addr.arpa.       86400   IN      NS      
AUTH03.NS.UU.NET
.
193.in-addr.arpa.       86400   IN      NS      
tinnie.ARIN.NET
.
193.in-addr.arpa.       86400   IN      NS      
munnari.oz.au
.
;; ADDITIONAL SECTION:
ns.ripe.NET
.            172800  IN      A       193.0.0.193
NS2.nic.fr
.             172800  IN      A       192.93.0.4
sec1.apnic.NET
.         172800  IN      A       202.12.29.59
sec3.apnic.NET
.         172800  IN      A       202.12.28.140
sunic.sunet.se
.         172800  IN      A       192.36.125.2
AUTH03.NS.UU.NET
.       172800  IN      A       198.6.1.83
munnari.oz.au
.          172800  IN      A       128.250.1.21
ora ... prosegui utilizzando uno dei server elencati come DNS
ad esempio
dig @
ns.ripe.NET
 1.2.43.193.in-addr.arpa. IN PTR
;; QUESTION SECTION:
;1.2.43.193.in-addr.arpa.       IN      PTR
;; AUTHORITY SECTION:
2.43.193.in-addr.arpa.  432000  IN      NS      
dns.nettuno.it
.
2.43.193.in-addr.arpa.  432000  IN      NS      
dns2.nextra.it
.
beccato al secondo colpo .. ma questo era facile .. :-)
considera tra l'altro che tutto questo "lavoro" lo potresti
far fare direttamente a "dig" utilizzando il comando
dig +trace @
a.root-servers.net
 1.2.43.193.in-addr.arpa IN PTR
che fa tutto da solo .. beh .. più o meno ;-)


 dig @
a.root-servers.net
 1.2.43.193.in-addr.arpa. IN PTR
ecco.. qui stava il mio errore concettuale... pensavo di dover richieder
a pezzi.. tipo 
193.in-addr.arpa.
poi 
43.193.in-addr.arpa.
eccetera :-P
così è decisamente più comprensibile.. e alla fine non c'è gran
differenza con la zona diretta...
Hai un buon paper da consigliare in materia DNS?


> Hai un buon paper da consigliare in materia DNS?
Direi di iniziare da qui
http://dmoz.org/Computers/Internet/Protocols/DNS/
e poi fatti anche un bel giro sul newsgroup che trovi
"linkato" al sito sotto (vedi firma) .. magari ci trovi un
paio di dritte interessanti .. chissà :-)
Ciao


 
http://dmoz.org/Computers/Internet/Protocols/DNS/
per la cronaca... sono adesso al telefono con IB.. che mi ha rigirato su
fullcompany.. č dura avere a che fare con qualcuno che continua a dirti
"si, ma l'autoritativo per quella zona č xxx"
e continuare a ripetergli "le sto dicendo che il problema ce l'ho sulla
zona inversa, non sulla diretta" e capire che non capisce...
Si prospetta una lunga giornata telefonica...
Adesso mi aspetto che FullCompany mi dica che la zona inversa č di
interbusiness e quindi devo giocarmela con loro...


 interbusiness e quindi devo giocarmela con loro...
e infatti, come da manuale... :-P


 e infatti, come da manuale... :-P
Prova così
<-->
Hello .. I'm George W Bush, the US president; I need
your assistance to delegate the whitehouse subnet
block to our DNS servers; you have exactly 10 minutes
from now to accomplish the task after that time I'll be
forced to use cruise missiles to convince you
<-->
:-)

 si blocca il tutto?
Se il blocco di IP di cui vuoi fare reverse è minore di 255 non puoi farti
delegare direttamente tutta la classe C ma dovrai usare "l'escamotage" del
C-NAME
http://www.pmaco.com/policies/RFC2317.html
con un po' di fatica con IBS ho ottenuto ciò che volevo...per i miei 64
indirizzi IP
Ciao
--
Alex