[enum-wg] 9.3.e164.arpa down

John,

I'm sorry to say, but "asking an administration politely" might be
politically correct for RIPE NCC and other parties as things stand now -
as an answer to an operational problem it is insufficient and bound to
kill the trust of potential operators in the technology in the first place.

This is part of a real time service and operators rely on it today.
Hoping some administration can get their act together days later to
defibrillate a broken box is while dozens of operators have stuck boxes
denying service to *all* users (not just the folks calling to the
country with broken nameservers) is unacceptable. And note, this
particular ENUM delegee isnt even doing any service with his delegation
in the first place. Yes, it has to do with current SIP server technology
(thread starvation) - asynchronous DNS resolution and deadline
scheduling may alleviate the problem, but no, that is not the only thing
we can do except hope and pray.

The other part of the story is that ENUM delegations are currently made
not just for reasons of providing production service, but - let's be
frank - occupying a "national resource" by some party which is not
necessarily part of the Internet management culture, and intending,
willing and able to provide realtime service on a 7x24 basis.

What we as a community have failed to to is to attach appropriate rules
and strings to that step. I believe we need to do the following:

1.  trials need to be tagged so as not to interfere with production. It
is unacceptable already to mix production and trial fumbling in a single
tree. In the very minimum we need an automatic indication which tree is
live, which tree is not serviced, and what is experimental- This could
be an indicator record in the country code zone hinting on status, be it
"TXT "trial", and/or a formalized tag in the RIPE DB.

2.  we need to establish rules on what goes into e164.arpa which goes
beyond the regulator/ITU TSB loop. IMO there is no point in activating
NS delegations when the requesting  organisation isnt committed to *run
service*. Having some ministerial nameservers working on and off just so
the administration can display territorial behaviour is a vanity affair
where somebody else pays the bill.

3. "Pulling a delegation" and removing a "harm to the network" obstacle
are different things. If the nameservers arent reachable, a TXT record
saying "please call XXX" for details is fine.

It is time we need rules - if the "administration" cant fix such
problems within a reasonably time window, I have no understanding for
such abstinence on the community's part. Yes, we can have SLA's -
including towards governments entities which are blundering down the
"Internet governance" lane (btw an excellent proof why these guys should
keep out in the first place).

This is very much like somebody injecting bogus BGP routes, nobody
filtering them, and all hoping the bogus routes would just  somehow
disappear. How does the routing community deal with it? Well, clearly
not abstinent. Fortunately they have more fine-grained mechanisms to
deal with it, and probably we need to think about these as well.

On the client side I see some requirements - going mostly towards the
SER/OpenSER/Asterisk communities; here are some ideas:
- I guess we need a simple country code blacklist and/or whitelist
mechanism in these resolvers, so something can be done on the service
side while the ministerial Windows NT 3.51 jockey searches for his lost
default route.
- step 2 would be to evaluate timeout errors to drive a dynamic
blacklist mechanism, which could limit thread starvation.
- evaluating say "TXT trial" tags at the country code level could help.

-Michael


John C Klensin schrieb:
> --On Wednesday, 15 November, 2006 09:05 +0000 Jim Reid
> <jim at rfc1035.com> wrote:
>
>   
>> On Nov 15, 2006, at 08:47, Klaus Darilion wrote:
>>
>>     
>>> The Italian ENUM name servers are down/broken. This will
>>> cause lots   of trouble (long call setups) for ITSPs which
>>> perform ENUM lookups.
>>>
>>> How should we handle such situations? By RIPE (deleting the  
>>> delegation), by monitoring registries and skipping ENUM
>>> lookup for   certain countries?
>>>       
>> Klaus, this was discussed at the last RIPE meeting. What a
>> countrydoes with its ENUM name servers is a National Matter.
>> This is notsomething that RIPE NCC should interfere with and
>> it must NEVER pullan ENUM delegation unilaterally. A
>> delegation under e164.arpa shouldonly get deleted by the NCC
>> -- not RIPE! -- if instructed to do so bythe ITU or the
>> appropriate Administration. Read the IAB instructionsand ITU
>> MoU to the NCC for details of the scope of NCC's
>> ENUMresponsibilities.
>>
>> What we -- for some definition of "we" -- should do in this
>> situationis inform the Administration concerned and politely
>> ask them to fixthe problem. IMO this definition of "we" means
>> you and the ITSPs whoare having trouble. It doesn't mean RIPE
>> NCC unless the relevantAdministration has asked the NCC to
>> monitor their ENUM delegation.
>>
>>     
>>> AFAIR this is not the first problem with 9.3.e164.arpa
>>>       
>> If that's the case, perhaps ITSPs should reconfigure their
>> softwareuntil the DNS infrastructure for this domain is
>> reliable enough.
>>     
>
> of course, the other comment that could have been made here is
> that there is a reason for the long-standing rule that specifies
> that any domain have multiple servers (at least two) that do not
> fate-share.  In other words, there are suppose to be servers
> that are sufficiently separated physically and in terms of
> network connectivity that the odds of all of them being
> unavailable at once are low to none.
>
> To the extent to which properly-separated and adequately
> independent servers would have solved or prevented this problem,
> the affected parties should, as Jim suggests, inform the
> Administration concerned and offer some appropriate advice.
>
>     john
>
>
>
>
>