% whois ripe.net
Reseaux IP Europeens - Network Coordinati on Centre (RIPE-DOM)
Singel 258
Amsterdam, NH 1016 AB
NL
Domain Name: RIPE.NET
Domain Status: On Hold <<<<<<------
...
Domain Name: RIPE.NET
Domain Status: On Hold <<<<<<------
This is apparently causing some routing problems; many ISPs (especially in
Europe) build their BGP filters from the data at whois.ripe.net at regular
intervals. No whois.ripe.net = no routing policy data = screwed up BGP.
Perhaps there should be a list of "sacred" domains that should never be
suspended no matter *how* long they go without paying their fees. I wonder
what happened in this case?
If the .NET TLD was still just for backbone infrastructure,
it'd make sense to do that. Perhaps RIPE qualifies for .INT?
No matter what it is, I agree...services like RIPE are way
too important to the everyday functioning of the Internet to
be turned off because of some NSI policy change.
So are forcing domain lookups for this kind of thing.
Karl Denninger wrote:
So are forcing domain lookups for this kind of thing.
Would you recommend hard-coding the IP number instead?
Ryan Brooks
ryan@inc.net
(not using RIPE to build anything)
Now that .NET is irrevocably a commercial top level domain, perhaps
organizations like RIPE should look at moving critical infrastructure
services (not the web server) to another TLD. Perhaps it should be
whois.ripe.int? Since the IPv6 equivalent of in-addr.arpa lives in .INT
this makes sense to me.
I think that placing such critical domain references under .INT is a
reasonable idea.
However, RIPE isn't a treaty organization and the rules for new .INT names
is pretty specific. And IANA is rather careful about following the rules.
Jon Postel's directive is that any proposal needs to have very precise
rules, so the first step in getting groups like RIPE authorized under .INT
is to write a set of rules that will mechanically determine who is authorized.
Perhaps a place to start is by qualifying any organization that has
administrative or operations responsibilities directly assigned by IANA.
d/
I think that placing such critical domain references under .INT is a
reasonable idea.
I suspect this could be controversial given .INT is supposed to be
administered by the ITU... 
Since we're already saddled with .arpa and it is already used for
(arguably) critical infrastructure goop, why not use it?
Cheers,
-drc
Such critical resources simply should not be under any non-operational
umbrella of any kind, and particularly not a treaty-driven one.
If there ever was an argument for a TLD for network-management resources
(such as whois servers and the like) this is it.
However, the nameserver infrastructure for such a TLD needs to go *far*
beyond *any* existing TLD's nameserver infrastructure. You're talking here
about things that need near, or even at, military-grade reliability levels
of service.
I wasn't trying to argue in favor of .INT, merely in favor of a rigorous
definition of who gets one of these ops-related registrations and who doesn't.
d/
One of the stated uses of .INT is for international databases and that
seems to be the reason that the reverse DNS for IPv6 is under .INT rather
than .ARPA. Of course it may not be too late for IPv6 to be changes and
for all important infrastructure info to be moved to .ARPA. We could even
rationalize things somewhat, i.e.
IN-ADDR.ARPA
IP6.ARPA
NET.ARPA for IP netblock whois info
ARIN.NET.ARPA |
RIPE.NET.ARPA |-queries to NET.ARPA will be redirected to one of these
APNIC.NET.ARPA |
RS.ARPA - route servers
IANA.ARPA - IANA databases such as MIBs, port assignments
Michael Dillon wrote:
One of the stated uses of .INT is for international databases and that
seems to be the reason that the reverse DNS for IPv6 is under .INT rather
than .ARPA. Of course it may not be too late for IPv6 to be changes and
for all important infrastructure info to be moved to .ARPA. We could even
rationalize things somewhat, i.e.IN-ADDR.ARPA
IP6.ARPA
NET.ARPA for IP netblock whois info
ARIN.NET.ARPA |
RIPE.NET.ARPA |-queries to NET.ARPA will be redirected to one of these
APNIC.NET.ARPA |
RS.ARPA - route servers
IANA.ARPA - IANA databases such as MIBs, port assignments
Quoted from RFC 1032:
"ARPA" is a temporary domain. It is by default appended to the
names of hosts that have not yet joined a domain. When the system
was begun in 1984, the names of all hosts in the Official DoD
Internet Host Table maintained by the NIC were changed by adding
of the label ".ARPA" in order to accelerate a transition to the
domain-naming system. Another reason for the blanket name changes
was to force hosts to become accustomed to using the new style
names and to modify their network software, if necessary. This
was done on a network-wide basis and was directed by DCA in DDN
Management Bulletin No. 22. Hosts that fall into this domain will
eventually move to other branches of the domain tree.
IN-ADDR.ARPA. is an obvious exception (reasoning in RFC 973), but I
think it's clear that the above info has no place being put in ARPA.
My vote's for NIC.INT. I'm still searching for the correct RFC on INT
rules to see if that's appropriate, however.
Stephen
What would be the utility of doing that? Shouldn't we first direct
effort towards making the ROOT servers that reliable? And then there's
always the networks used to *reach* these servers, which are often of
questionable reliability, especially when a MAE is involved.
Then again, that assumes that routers need military-grade DNS
capability, which is an absurd concept to begin with. The routers
should simply continue to operate normally (or slightly degraded) if DNS
isn't available. Any other design is doomed to horrible race
conditions.
Stephen
Karl Denninger wrote:
Well, my point, really, was that generating filter lists and *loading them*
while relying on things in the network which aren't reliable enough is
rather silly.
IF you're going to run an automated procedure with the *expectation* that
these operations (like a DNS lookup) won't fail, then you had better have
mil-grade reliability.
The *REAL* solution is <DON'T DO THAT>. I find it insane that folks were
auto-generating filter lists off RIPE's information, using DNS lookups,
without enough error checking to handle the case where the domain doesn't
resolve!
Actually, IMAO, the proper place to start is by stringing up whomeever
thought it would be a good idea to make .NET commercial by the balls,
and using it for what it was designed for.
Cheers,
-- jra
> Domain Name: RIPE.NET
> Domain Status: On Hold <<<<<<------This is apparently causing some routing problems; many ISPs (especially in
Europe) build their BGP filters from the data at whois.ripe.net at regular
intervals. No whois.ripe.net = no routing policy data = screwed up BGP.
BTW: Does anybody have public available scripts/tools to write filters
for cisco routes based on these data?
/Jesper