Re: [enum-wg] Italian Nameservers for 9.3.164.arpa. dead?

[Marco Sommani <marco.sommani@localhost]

What Bernie is saying is correct: whatever RIPE does with the Italian
delegation, there will be no negative consequences for ENUM users.

This morning I have found that the two Italian DNS servers are still up and
alive. The problem is that their name is no longer dns.istsupcti.it and
dns2.istsupcti.it, as indicated in the delegation, but dns.isticom.it and
dns2.isticom.it. If you send a query about 9.3.e164.arpa directly to one of
those two servers, you get the correct answer. I do not know why they
decided to change their domain name, as the name of the institution is still
"Istituto Superiore delle Comunicazioni e delle Tecnologie
dell'Informazione", as it used to be. Anyway, the domain istsupcti.it is
dead: even www.istsupcti.it is not responding anymore, whereas
www.isticom.it does.

A further problem is due to the fact that the contact person that is
mentioned in the RIPE database, Luisa Franchina, left the Ministry of
Communications more than one year ago.

This being said, I do not know what is the right procedure to follow in
these cases. Maybe RIPE should ask the ITU the permission to change
appropriately the domain names in the DNS delegations?

Marco   

On 23-01-2008 11:40, "Bernie Hoeneisen" bhoeneis@localhost wrote:

> Hi John et al.
> 
> I agree with most of your statements. Comments inline.
> 
> On Tue, 22 Jan 2008, John C Klensin wrote:
> 
>> (3) Before contemplating any steps beyond that,
>> carefully consider the question of who is being harmed.
>> Bernie, no matter how much your users are being
>> inconvenienced, the real harm is being done to their
>> correspondents in Italy.
> 
> As far as I know 9.3.e164.arpa has never been populated and so far there
> has been no intension to actually establish an ENUM service within
> 9.3.e164.arpa. (Therefore, my collegues in Italy from the Research and
> Education community are using the nrenum.net tree as an interim solution
> until an ENUM service in 9.3.e164.arpa. becomes available).
> 
> Thus, the only ones suffering from this particular problem are the calling
> users (due to timeouts).
> 
>>       it is time to route around the problem
> 
> Usually I tackle problems at the source...
> 
> But you are right, in this case it is worth considering a workaround e.g.
> modify some software or configuration, to prevent queries for
> 9.3.e164.arpa. at all.
> 
>> rather than trying to figure out how to punish them.
> 
> If my assumptions stated above are correct, I don't see any punishment
> in case the delegation for 9.3.e164.arpa. would be removed.
> (However, I see the point that removing a zone is a rather
> problematic and slippery way to address this issue.)
> 
> 
> cheers,
>   Bernie
> 

-----------------------------------------------
Marco Sommani
Consiglio Nazionale delle Ricerche
Istituto di Informatica e Telematica
Via Giuseppe Moruzzi 1
56124 Pisa - Italia
work: +390503153815 (PSTN and nrenum.net)
mobile: +393487981019 (PSTN and e164.org)
fax: +390503153273
sip:marco.sommani@localhost