Hi Jim Thanks for confirming this. On Mon, 21 Jan 2008, Jim Reid wrote:

Same as it's always been Bernie. The Tier 1 registry for +39 should beef up its DNS infrastructure, for example by buying DNS service from a reliable hosting provider.

Would Ripe have the possibility to (temporarly) remove the delegation, if such situations occur? Unfortunately, it happens quite often with Italy....:-(

It is particularly disappointing that the 9.3.e164.arpa zone seems to delegated to just two name servers that live on the same subnet. RFC2182 advised against this 11 years ago.

Could it even be that these two IP addresses point to the same (physical) host? (Both IPs report at the same time nameserver down, but hosts up.) cheers, Bernie

--On Monday, 21 January, 2008 17:55 +0100 Bernie Hoeneisen <bhoeneis@switch.ch> wrote:

On Mon, 21 Jan 2008, Jim Reid wrote:

...

Same as it's always been Bernie. The Tier 1 registry for +39 should beef up its DNS infrastructure, for example by buying DNS service from a reliable hosting provider.

Would Ripe have the possibility to (temporarly) remove the delegation, if such situations occur? Unfortunately, it happens quite often with Italy....:-(

...

It is particularly disappointing that the 9.3.e164.arpa zone seems to delegated to just two name servers that live on the same subnet. RFC2182 advised against this 11 years ago.

Hi. Under principles that go back much longer than even RFC 2182 (as does the principle of separated name servers -- 2182 just reaffirmed an old principle and stated it more clearly), a registry should be able to remove a zone if it is consistently poorly administered. Given the circumstances of e164.arpa, I think actually doing that would require a discussion between RIPE NCC and the IAB. But I see no reason why it should not be possible to reach consensus on a mechanism for notifying a Tier 1 registry that, if they do not manage to establish servers that do not fate-share, the zone delegation will be removed until they develop and implement a plan. john

--On Monday, 21 January, 2008 19:14 +0000 Jim Reid <jim@rfc1035.com> wrote:

... BTW, does anyone ask Verisign to pull the plug on lamedelegation.com (say) because its broken delegation is causing operational problems for their mail server? If not, why is a different approach necessary in e164.arpa for ENUM-aware SIP servers?

Jim, While I'm not sure that pulling delegations in e164.arpa is a good idea -- I'm merely suggesting that it is feasible if the community wants it-- I don't think the above analogy applies at all. If someone goes to a registrar and registers a label to be placed in COM, no assertion at all is being made (any more) about what that label points to (or doesn't). The assumption is that, if the label lasts long enough, the registrant will pay some token amount of money, but that is about it. The other assumption is that there is nothing sparce, in the technical sense, about the namespace. You can probably remember when the NIC would threaten to pull delegations for sufficient misbehavior, but those days are long past. By contrast, e164.arpa was rather carefully constructed on the theory that the namespace was highly restricted and tied to some very specific concepts and rules. There was a recent thread about labels in the zone that didn't represent E.164 codes. Whether those that represent an administrative convenience are worth the trouble it would take to eliminate them remains a question, but there is no question that they are invalid as the zone is formally designed and specified. The whole purpose of having e164.arpa involved having a validated set of operators whose validation included national signoff about appropriateness and involved that in order that users and systems could trust (modulo the issues that DNSSEC is supposed to address) what they found in that zone. Put differently, the registrants in e164.arpa are there because they are validated and authorized, while a registrant in COM is there because they promise to put a few currency-units on the table. It seems to me that the same things that drive a "validated and authorized" model into e164.arpa could be used to justify a somewhat stronger set of rules to protect the user base than has generally been the expectation for ICANN-delegated gTLDs. For many of the same reasons, I could imagine IAB and RIPE NCC imposing a _requirement_ for signed zones on Tier 1 delegates from e164.arpa, making schedules in conjunction with some consensus among the Tier 1 registries, and holding those registries to those schedules. Again, whether there is consensus for doing any of these things, and whether they are a good idea, are separate issues. But analogies with what a registry does or does not do in a gTLD don't help illuminate the issues, IMO. john

On 2008/01/21 20:01, Richard Shockey <richard@shockey.us> wrote:

I agree completely ... we've been there - done that. Even thinking of opening up that can of worms means someone gets to camp in Geneva for the duration and it isn't going to be me. There will be enough problems/issues when the Infrastructure ENUM documents arrive in Geneva shortly.

Btw, what is holding up these documents? They've been in the "AD Evaluation::AD Followup" state since Vancouver. /ol -- // Otmar Lendl <lendl@nic.at>, T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg

On 2008/01/21 20:01, Jim Reid <jim@rfc1035.com> wrote:

On Jan 21, 2008, at 16:55, Bernie Hoeneisen wrote:

...

Would Ripe have the possibility to (temporarly) remove the delegation, if such situations occur?

Personally speaking, I think this a very bad idea.

I'm very reluctant to go that route, too.

As John says, a mechanism could be developed to notify a Tier-1 registry (and ITU?) about a broken ENUM delegation. But this is probably a discussion for the Powers That Be. It wouldn't hurt I suppose for this WG to suggest a suitable mechanism. Any volunteers?

From the top of my head, I'd go for a procedure something like this::

* RIPE NCC monitors the nameservers it delegates to. * If serious troubles are spotted, RIPE NCC will notify the Tier1 registry using the email addresses listed as contacts. * If the communication attempts are not answered or the addresses bounce, then RIPE NCC will notify ITU about this fact. * ITU should then basically redo the verification step, asking the local authorities whether the delegation is ok (incl. giving the option for an update to the contact info). If the answer is yes, keep the delegation, if no, instruct RIPE to yank it. * If the Tier1 operators answer, but don't manage to fix theír nameservers within a longer interval, then also invoke the ITU as above. ---- ÍMHO active monitoring and alerts on troubles should be trivial to set up. No special NCC magic dust is needed for that at all, basically anybody could do that. There is no private data involved. Making sure that the contact information is valid should also a no-brainer. In this case, most other registries reserve the right to yank the delegation, so there are precedents here. But in this case, redoing the ITU loop is IMHO the best way to balance national sovereignty with some semblance of "we care for the DNS quality under e164.arpa". /ol -- // Otmar Lendl <lendl@nic.at>, T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg

...

... From the top of my head, I'd go for a procedure something like this::

Otmar,

First, if you haven't read Patrik's note yet, please do so first. He and I are in complete agreement, I think.

John we are all in agreement here. The first

stages of getting one of these problems straightened out are to notice the problem, remind the registrant, and then notify whomever requested the delegation. All of that is the fairly ordinary behavior of a registry that is behaving responsibly. And, as others have pointed out, it can be done simply by RIPE NCC sending out a note offering to do these checks as a service, turning things into opt-in. I don't think that requires any approval from anyone.

Exactly.

Two observations inline...

...

* If the communication attempts are not answered or the addresses bounce, then RIPE NCC will notify ITU about this fact.

* ITU should then basically redo the verification step, asking the local authorities whether the delegation is ok (incl. giving the option for an update to the contact info).

First, remember that RIPE NCC is formally responsible to the IAB for e164.arpa, not to ITU-T. It is not clear that RIPE NCC can ask ITU to review a delegation without authority to do so from the IAB and agreement from the ITU to receive such a request and act on it.

Of course, as soon as anyone starts asking ITU-T questions that are not covered exactly by the current procedures, the risks of falling into the trap that Richard Shockley warns about are also very large. We can decide what questions we would like to ask and what actions we would like to request, but only they can decide what questions they are willing to answer and how they are going to interpret them. As Richard says "been there - done that"... and some of us will carry the scars for life.

<sigh> This is one of those issues where "let sleeping dogs lie".

...

If the answer is yes, keep the delegation, if no, instruct RIPE to yank it.

* If the Tier1 operators answer, but don't manage to fix the�r nameservers within a longer interval, then also invoke the ITU as above.

But remember that ITU-T is, traditionally (and appropriately) extremely reluctant to give answers to questions that involve a Member State without explicit instructions from the Member State. The original ENUM agreement was written in terms of timeouts that would permit registrations if the Member State did not respond. In practice, ITU-T modified that agreement to create a "nothing happens until the country affirmatively responds" situation by issuing objections to any action for which they did not have such a response.

Exactly

If those precedents are followed, there will never be a "no" answer unless a country is inclined to make a formal announcement that it has lost interest in and wishes to abandon its ENUM delegation. Instead, one could reasonably expect ITU-T to ping the country and ask for confirmation for an update (or for server updates) but then to wait, very patiently and for a very long time if necessary, for an answer.

What to do here, if anything, is entirely up to this group, RIPE NCC, and the IAB although, if it involves asking ITU-T to adopt any procedures that are not now in place, I wouldn't hold my breath waiting for them to agree, nor would I predict that they would agree to whatever was asked of them without putting their stamp on it. I would give the following advice if anyone asked me:

(1) It is fine to encourage RIPE NCC to make periodic checks of server configuration and accessibility. If the results of those checks are not satisfactory, the delegated party should be notified and ask to fix things.

(2) If the delegated party does not respond, it would be fine for RIPE NCC to notify the entity that requested and/or signed off on the delegation and make sure they are aware of the problem and its implications to accessibility and usability of the domain they requested. We have that contact information; using it doesn't need to involve the ITU.

(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 Richard points out, ENUM has not been the universal "one single tree in which to look" success we had hoped for and any infrastructure approach will make things worse. Given that, one has to be prepared today for other trees anyway. Perhaps, if the delegated administrators for Slobbovia can't run a domain and/or won't accept suggestions for external secondaries, it is time to route around the problem rather than trying to figure out how to punish them. One such workaround would be to establish enum-slobbovia-workaround.net (or elsewhere) and start accepting free registrations in it by anyone who thinks that they are being hurt. It may be that would send a clear message that the choices are between running the domain better and facing "competition" over which the national telcom entities can not exert any control. That might be enough to get things fixed. If not, it might provide a plausible alternative.

Ultimately, if a country-approved entity decides that it doesn't want to offer good DNS service (ENUM or otherwise), energy is probably better put into workarounds than into trying to figure how to punish them or to force them to behave better.

Right and if you want real problems ICANN will probably want to stick their nose into all of this and that is the LAST thing anyone wants. IAB or ITU.

john

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@switch.ch> 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@iit.cnr.it mailto:marco.sommani@iit.cnr.it

Suggestions from the bad idea fairy: Anyway, the domain istsupcti.it is dead: even www.istsupcti.it is not responding anymore, whereas www.isticom.it does. According to http://www.nic.it/cgi-bin/Whois/whois-eng.cgi, the domain still exists. That is it didn, what one you could do is to register the domain istsupcti.it. Then you can take over the delegation. The domain expires 2008-09-20, so after that date it is free game. jaap

Dear ENUM colleagues, Patrik Fältström wrote on 21 Jan 2008:

[...]

That said, maybe we in this wg should finalize the document that recommend a registry to "keep track of their delegation -- for example via an opt-in mechanism that check the delegation"?

Carsten, was this on your table, or do I remember wrong?

this eventually has now happened - as per Mark Dranse's email of 17 April 2008 to the NCC Services WG list and the RIPE list: http://www.ripe.net/ripe/maillists/archives/ncc-services-wg/2008/msg00015.ht... the RIPE NCC has extended its DNSMON service to also any Tier-1 ENUM domain (cf. RIPE-429, attached). Any ENUM Tier-1 registry that wishes to do so can now opt-in to have their delegation monitored. The question is: shall we leave it at this stage or shall we try to take it further? I reckon the former from the tone of the majority of contributions here on this list about three months ago. OTOH, this is (also) an operational topic and thus (still) an appropriate item of discussion for this WG. That is why we (the Co-Chairs, Niall and me) slotted in 15 min for such a discussion during the upcoming WG session. Please consider this email a "Heads Up" for voicing ideas, approaches etc. onsite as well as here on the list. A way forward MIGHT be along the lines of what John wrote here: === Subject: Re: [enum-wg] Italian Nameservers for 9.3.164.arpa. dead? Date: Tue, 22 Jan 2008 15:29:37 -0500 From: John C Klensin <john+ietf@jck.com> To: Otmar Lendl <lendl@nic.at>, enum-wg@ripe.net [...] What to do here, if anything, is entirely up to this group, RIPE NCC, and the IAB although, if it involves asking ITU-T to adopt any procedures that are not now in place, I wouldn't hold my breath waiting for them to agree, nor would I predict that they would agree to whatever was asked of them without putting their stamp on it. I would give the following advice if anyone asked me: (1) It is fine to encourage RIPE NCC to make periodic checks of server configuration and accessibility. If the results of those checks are not satisfactory, the delegated party should be notified and ask to fix things. (2) If the delegated party does not respond, it would be fine for RIPE NCC to notify the entity that requested and/or signed off on the delegation and make sure they are aware of the problem and its implications to accessibility and usability of the domain they requested. We have that contact information; using it doesn't need to involve the ITU. [...] === I am hoping for fruitful discussions - and I of course also hope to see you next week in Berlin. Best, Carsten Schiefner RIPE ENUM WG Co-Chair DNS Monitoring Service for Infrastructure Domains / Mark Dranse, RIPE NCC / Document ID: ripe-429 Date: 17 April 2008 Updates: ripe-342 ------------------------------------------------------------------------ Since 2004, DNSMON has provided a comprehensive and independent overview of the quality of the service provided by infrastructure-level Domain Name System (DNS) servers. The background and history of the service can be found in "RIPE 342" [1], which this document obsoletes. DNSMON is built on top of the Test Traffic Monitoring (TTM) network [2], and it uses the same probes for its measurements. Measurements are carried out by sending normal DNS queries to monitored servers at regular intervals. All results are available to the public. The RIPE NCC's DNSMON measurements benefit the entire Internet community by providing an objective and impartial global overview of TLD-level DNS operations. As part of this service, we monitor some interesting infrastructure domains, including the root, free of charge. If requested by the operators, we will also configure monitoring for the DNS servers of: * Any TLD (ccTLD, gTLD etc) * Any Tier-1 ENUM domain (for example, 1.3.e164.arpa) Fees are charged for this service on a cost-recovery basis. Subscribers receive additional benefits, which may change from time to time. These are documented within the DNSMON operational service documents [3]. ------------------------------------------------------------------------ [1] ftp://ftp.ripe.net/ripe/docs/ripe-342.pdf [2] http://www.ripe.net/ttm [3] http://dnsmon.ripe.net/