% 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? -- Andrew Crawford Operations Engineer, Nildram Ltd
Perhaps the policy should be No whois.ripe.net = no rebuild of BGP filters
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.
On 04/07/98, Andrew Crawford <andrewc@nildram.net> wrote:
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. -- J.D. Falk <jdfalk@vix.com> Vixie Enterprises http://www.vix.com/
On Tue, Apr 07, 1998 at 01:38:03PM -0700, J.D. Falk wrote:
On 04/07/98, Andrew Crawford <andrewc@nildram.net> wrote:
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.
-- J.D. Falk <jdfalk@vix.com> Vixie Enterprises http://www.vix.com/
So are forcing domain lookups for this kind of thing. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
On Tue, 7 Apr 1998, Andrew Crawford wrote:
Domain Name: RIPE.NET Domain Status: On Hold <<<<<<------
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?
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. -- Michael Dillon - Internet & ISP Consulting http://www.memra.com - E-mail: michael@memra.com
At 11:44 PM 4/7/98 -0700, Michael Dillon wrote:
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/ ________________________________________________________________________ Dave Crocker Brandenburg Consulting +1 408 246 8253 dcrocker@brandenburg.com 675 Spruce Drive (f) +1 408 249 6205 www.brandenburg.com Sunnyvale, CA 94086 USA
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
At 07:41 AM 4/8/98 +0800, David R. Conrad wrote:
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?
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/ ________________________________________________________________________ Dave Crocker Brandenburg Consulting +1 408 246 8253 dcrocker@brandenburg.com 675 Spruce Drive (f) +1 408 249 6205 www.brandenburg.com Sunnyvale, CA 94086 USA
On Wed, 8 Apr 1998, David R. Conrad wrote:
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?
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 - Internet & ISP Consulting http://www.memra.com - E-mail: michael@memra.com
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 -- Stephen Sprunk "Oops." Email: sprunk@paranet.com Sprint Paranet -Albert Einstein ICBM: 33.00151N 96.82326W
On Wed, Apr 08, 1998 at 08:30:07AM -0700, Dave Crocker wrote:
At 11:44 PM 4/7/98 -0700, Michael Dillon wrote:
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/ ________________________________________________________________________ Dave Crocker Brandenburg Consulting +1 408 246 8253 dcrocker@brandenburg.com 675 Spruce Drive (f) +1 408 249 6205 www.brandenburg.com Sunnyvale, CA 94086 USA
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. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
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:
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.
-- Stephen Sprunk "Oops." Email: sprunk@paranet.com Sprint Paranet -Albert Einstein ICBM: 33.00151N 96.82326W
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! -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost On Wed, Apr 08, 1998 at 06:33:47PM -0300, Stephen Sprunk wrote:
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:
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.
-- Stephen Sprunk "Oops." Email: sprunk@paranet.com Sprint Paranet -Albert Einstein ICBM: 33.00151N 96.82326W
On Wed, Apr 08, 1998 at 08:30:07AM -0700, Dave Crocker wrote:
At 11:44 PM 4/7/98 -0700, Michael Dillon wrote:
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.
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 -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com
And first domain in this list should be internic.net -:) Good idea, btw. On Tue, 7 Apr 1998, Andrew Crawford wrote:
Date: Tue, 7 Apr 1998 20:17:21 +0100 (BST) From: Andrew Crawford <andrewc@nildram.net> To: nanog@merit.edu Subject: Re: oh, for goodness' sake.
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?
-- Andrew Crawford Operations Engineer, Nildram Ltd
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
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 -- Jesper Skriver (JS249-RIPE), Network manager Tele Danmark DataNet, IP section (AS3292) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them.
Jesper, Jesper Skriver writes:
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?
You might want to check out RtConfig which is part of the RAToolSet. Please check out: http://www.isi.edu/ra/ for more information. David K. ---
participants (14)
-
Alex P. Rudnev -
Andrew Crawford -
Danny O'Brien -
Dave Crocker -
David R. Conrad -
davidk＠ISI.EDU -
J.D. Falk -
Jay R. Ashworth -
Jesper Skriver -
jzeeff＠verio.net -
Karl Denninger -
Michael Dillon -
Ryan Brooks -
Stephen Sprunk