GSM Association and NeuStar Sign Agreement to Offer Root DNS Services

[Stephane Bortzmeyer]

It can be of operational interest or it can fuel a new flame about
alternative DNS roots.

http://www.neustar.com/pressroom/files/announcements/ns_pr_09282005.pdf

GSM Association and NeuStar Sign Agreement to Offer Root DNS Services
to More than 680 Global GSM Mobile Operators

...

NeuStar's Root DNS service will serve two functions: first, to
register domain names under the suffixes "gprs" and "3gppnetwork.org,"
which are used to register private domain names that allow operators
to retrieve routing information when a subscriber accesses data and
multimedia services on a roaming or home network. For example, a U.S.
mobile subscriber traveling on business in Singapore will be able to
access a video or audio file using their mobile device while roaming
on a local GSM network.

Additionally, NeuStar will operate the master DNS root server and
provide updates to GRX (GPRS Roaming Exchange) and MMS (Multimedia
Messaging Service) providers, allowing mobile operators to access
updated DNS routing information.

...

Re: GSM Association and NeuStar Sign Agreement to Offer Root DNS Services

[Randy Bush]

different meaning of 'root server'.  pretty surely written by a 
droid.

randy

Re: [Misc][Rant] Internet router (straying slightly OT)

[Sabri Berisha]

On Thu, Sep 29, 2005 at 05:39:30PM -0400, Mark Owen wrote:

> Any suggestions?

Start with the OSI[1] model to grasp the fundamentals, next make sure
you have a basic knowledge of how TCP/IP addressing works[2]. To get
an understanding of routing-protocols, begin with RIP[3] and perhaps
run your own RIP-lab by using Quagga[4] software on a Linux box. That
will get you off the streets for a weekend :)

Cheers,

-- 
Sabri

please do not throw salami pizza away

[1] http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/introint.htm
[2] http://www.networkclue.com/routing/tcpip/addressing.php
[3] http://www.livinginternet.com/i/iw_route_igp_rip.htm
[4] http://www.quagga.net

Re: Weird DNS issues for domains

[Peter]

Crist Clark <[EMAIL PROTECTED]> wrote:
[...]
> The problem I've seen is when an SMTP server does not accept emails
> which have non-resolvable MAIL FROM domain. When the sender is a
> dumb SMTP client, not an MTA, this can cause problems.

Well, that "dumb SMTP client" should stop pretending to be a MTA then.
If it can't queue and retry, it shouldn't even *think* about looking
for MX records.

Besides, what sort of "dumb SMTP client" did you have in mind?
Formmail scripts? Worms? Outlook Express? I can't say I'd miss mail
from any of those.

> (I noticed this happen to a high traffic customer who had both of
> their DNS servers in the same /24 located in Slidell, LA. Needless
> to say, they were down for more than a few hours when Katrina rolled
> through.)

Having reachable DNS isn't going to help anyway if the MX host is also
unreachable for an extended period. Mail is still going to bounce
after a few days if somebody doesn't fiddle with DNS.

-- 
'Twas a woman who drove me to drink, and I never had the courtesy to thank her
for it.
- W.C. Fields

Re: Weird DNS issues for domains

[Brandon Butterworth]

> Besides, what sort of "dumb SMTP client" did you have in mind?
> Formmail scripts? Worms? Outlook Express? I can't say I'd miss mail
> from any of those.

Pot, kettle...

Yours seem to have come via a train wreck of mua/mta's

> From [EMAIL PROTECTED]  Fri Sep 30 08:42:11 2005
> Delivered-To: [EMAIL PROTECTED]
> Delivered-To: [EMAIL PROTECTED]
> Delivered-To: [EMAIL PROTECTED]
> Delivered-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Path: not-for-mail
> From: [EMAIL PROTECTED] (Peter)
> Newsgroups: newsgate.nanog
> Date: Fri, 30 Sep 2005 07:41:26 + (UTC)
> Organization: cabal.org.uk listgate, Warwickshire, UK
> Lines: 27
> NNTP-Posting-Host: dopiaza.cabal.org.uk
> X-Trace: dopiaza.cabal.org.uk 1128066086 12308 82.71.81.27 (30 Sep 2005 
> 07:41:26 GMT)
> X-Complaints-To: [EMAIL PROTECTED]
> NNTP-Posting-Date: Fri, 30 Sep 2005 07:41:26 + (UTC)
> X-Newsreader: trn 4.0-test76 (Apr 2, 2001)
> Originator: [EMAIL PROTECTED] (Peter)
> X-SA-Exim-Connect-IP: 82.71.81.26
> X-SA-Exim-Mail-From: [EMAIL PROTECTED]
> X-Spam-Hammy-Tokens: 0.000-+--H*F:U*abuse, 
>   0.000-+--HX-Complaints-To:sk:usenet@, 0.000-+--H*M:cabal, 
>   0.000-+--H*M:dopiaza, 0.000-+--H*r:news
> X-Spam-Bayes-Score: 0.
> X-Spam-Spammy-Tokens: 0.994-8--formmail, 0.993-+--MAIL, 
>   0.954-+--H*r:sk:punt-1., 0.938-+--H*Ad:D*org.uk, 0.927-+--H*Ad:D*uk
> X-Spam-Score-Description: 
>   *  0.1 FORGED_RCVD_HELO Received: contains a forged HELO
>   * -1.3 BAYES_00 BODY: Bayesian spam probability is 0 to 1%
>   *  [score: 0.]
>   * -0.7 AWL AWL: From: address is in the auto white-list
> Subject: Re: Weird DNS issues for domains
> X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100)
> X-SA-Exim-Scanned: Yes (on punt-1.mooli.org.uk)
> X-Virus-Scanned: amavisd-new at merit.edu
> Sender: [EMAIL PROTECTED]

spam and virus rating on outgoing is pointless nobody in their
right mind is going to use them. 

> Path: not-for-mail

I agree, all that nntp stuff is pointless too

brandon

Re: Weird DNS issues for domains

[Simon Waters]

On Friday 30 Sep 2005 9:37 am, Brandon Butterworth wrote:
>
> spam and virus rating on outgoing is pointless nobody in their
> right mind is going to use them.

Whilst I think it is silly to do. 

Why not drop emails that claim to be viruses or spam?

Of course why anyone would allow their servers to send such is another 
question.

It would be silly to believe things that said "I'm not spam", but the opposite 
doesn't necessary apply.

Re: GSM Association and NeuStar Sign Agreement to Offer Root DNS Services

[Romeo Zwart]

Stephane Bortzmeyer wrote:
> It can be of operational interest or it can fuel a new flame about
> alternative DNS roots.

Another flame fest? Possibly, but only if caused by lack of understanding where 
the Neustar DNS root will be living. This DNS structure for GPRS roaming lives 
in its own separate universe. As GSM in general does. :) 

GPRS providers do (usually) offer a connected mobile handset the possibility to 
connect to TheInternetAtLarge -- no flames about walled gardens, please :) . 
For Internet access the mobile will query what you might call 'DNS-proper' ; 
i.e. the mobile's domain namespace is in the real Internet. 

The services provided by Neustar will live in the non-public IP space that 
connects the GPRS (and IMS, and MMS) infrastructure, which is separate from the 
end-user (mobile device) IP space. 

Cheers, 

Romeo 

> 
> http://www.neustar.com/pressroom/files/announcements/ns_pr_09282005.pdf
> 
> GSM Association and NeuStar Sign Agreement to Offer Root DNS Services
> to More than 680 Global GSM Mobile Operators
> 
> ...
> 
> NeuStar's Root DNS service will serve two functions: first, to
> register domain names under the suffixes "gprs" and "3gppnetwork.org,"
> which are used to register private domain names that allow operators
> to retrieve routing information when a subscriber accesses data and
> multimedia services on a roaming or home network. For example, a U.S.
> mobile subscriber traveling on business in Singapore will be able to
> access a video or audio file using their mobile device while roaming
> on a local GSM network.
> 
> Additionally, NeuStar will operate the master DNS root server and
> provide updates to GRX (GPRS Roaming Exchange) and MMS (Multimedia
> Messaging Service) providers, allowing mobile operators to access
> updated DNS routing information.
> 
> ...
> 
> 
> 

Re: [Misc][Rant] Internet router (straying slightly OT)

[Robert E . Seastrom]

Sabri Berisha <[EMAIL PROTECTED]> writes:

> To get
> an understanding of routing-protocols, begin with RIP[3] and perhaps
> run your own RIP-lab

necromancy will be severely punished.

---rob

Re: [Misc][Rant] Internet router (straying slightly OT)

[Valdis . Kletnieks]

On Fri, 30 Sep 2005 05:50:52 EDT, "Robert E.Seastrom" said:
> Sabri Berisha <[EMAIL PROTECTED]> writes:
> > To get
> > an understanding of routing-protocols, begin with RIP[3] and perhaps
> > run your own RIP-lab
> 
> necromancy will be severely punished.

Sayeth RFC1925:

   (4)  Some things in life can never be fully appreciated nor
understood unless experienced firsthand. Some things in
networking can never be fully understood by someone who neither
builds commercial networking equipment nor runs an operational
network.

Just remember, all you dabblers - a properly designed lab environment is called
for, for the same reasons a pentagram is called for... :)



pgpTwEiKRTCxr.pgp
Description: PGP signature

Re: GSM Association and NeuStar Sign Agreement to Offer Root DNS Services

[Suresh Ramasubramanian]

On 30/09/05, Stephane Bortzmeyer <[EMAIL PROTECTED]> wrote:
>
> It can be of operational interest or it can fuel a new flame about
> alternative DNS roots.
>
> http://www.neustar.com/pressroom/files/announcements/ns_pr_09282005.pdf
>

It is not a public root and it is not available over the internet either

A closed service  available solely over  the gprs network

I guess gprs phones will query "real" dns to access real internet resources

--srs

--
Suresh Ramasubramanian ([EMAIL PROTECTED])

Re: GSM Association and NeuStar Sign Agreement to Offer Root DNS Services

[Brandon Butterworth]

> It is not a public root and it is not available over the internet either
> 
> A closed service  available solely over  the gprs network

Until the users want to access the same stuff from their
PC and they petition for it to be in the public root too

To the public if it looks like internet they expect it to
work like internet

brandon

The Cidr Report

[cidr-report]

This report has been generated at Fri Sep 30 21:45:58 2005 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org/as4637 for a current version of this report.

Recent Table History
Date  PrefixesCIDR Agg
23-09-05166976  112159
24-09-05167058  112019
25-09-05166953  112176
26-09-05167138  112254
27-09-05167216  112265
28-09-05167313  112503
29-09-05167013  112474
30-09-05167138  112512


AS Summary
 20489  Number of ASes in routing system
  8512  Number of ASes announcing only one prefix
  1494  Largest number of prefixes announced by an AS
AS7018 : ATT-INTERNET4 - AT&T WorldNet Services
  91327232  Largest address span announced by an AS (/32s)
AS721  : DLA-ASNBLOCK-AS - DoD Network Information Center


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 30Sep05 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 167182   1125265465632.7%   All ASes

AS18566  8578  84999.1%   COVAD - Covad Communications
AS4323  1171  379  79267.6%   TWTC - Time Warner Telecom
AS721   1074  314  76070.8%   DLA-ASNBLOCK-AS - DoD Network
   Information Center
AS4134   986  246  74075.1%   CHINANET-BACKBONE
   No.31,Jin-rong Street
AS7018  1494  979  51534.5%   ATT-INTERNET4 - AT&T WorldNet
   Services
AS22773  543   33  51093.9%   CCINET-2 - Cox Communications
   Inc.
AS3602   555  108  44780.5%   SPRINT-CA-AS - Sprint Canada
   Inc.
AS6197   943  545  39842.2%   BATI-ATL - BellSouth Network
   Solutions, Inc
AS17676  469  104  36577.8%   JPNIC-JP-ASN-BLOCK Japan
   Network Information Center
AS6467   394   55  33986.0%   ESPIRECOMM - e.spire
   Communications, Inc.
AS15270  338   28  31091.7%   AS-PAETEC-NET - PaeTec.net -a
   division of
   PaeTecCommunications, Inc.
AS4755   541  235  30656.6%   VSNL-AS Videsh Sanchar Nigam
   Ltd. Autonomous System
AS4766   597  293  30450.9%   KIXS-AS-KR Korea Telecom
AS14654  2936  28798.0%   WAYPORT - Wayport
AS812305   25  28091.8%   ROGERS-CABLE - Rogers Cable
   Inc.
AS9929   320   46  27485.6%   CNCNET-CN China Netcom Corp.
AS19916  369   99  27073.2%   ASTRUM-0001 - OLM LLC
AS6140   419  163  25661.1%   IMPSAT-USA - ImpSat
AS5668   490  237  25351.6%   AS-5668 - CenturyTel Internet
   Holdings, Inc.
AS1239   855  604  25129.4%   SPRINTLINK - Sprint
AS17488  335   84  25174.9%   HATHWAY-NET-AP Hathway IP Over
   Cable Internet
AS9583   796  551  24530.8%   SIFY-AS-IN Sify Limited
AS9498   341   99  24271.0%   BBIL-AP BHARTI BT INTERNET
   LTD.
AS6167   333   92  24172.4%   CELLCO-PART - Cellco
   Partnership
AS19115  264   25  23990.5%   CHARTER-LEBANON - Charter
   Communications
AS2386   921  685  23625.6%   INS-AS - AT&T Data
   Communications Services
AS18101  253   24  22990.5%   RIL-IDC Reliance Infocom Ltd
   Internet Data Centre,
AS6198   473  249  22447.4%   BATI-MIA - BellSouth Network
   Solutions, Inc
AS16814  298   84  21471.8%   NSS S.A.
AS11456  287   74  21374.2%   NUVOX - NuVox Communications,
   Inc.

Total  17314 64741084062.6%   Top 30 total


Possible Bogus Routes

24.246.0.0/17AS7018  ATT-IN

Re: GSM Association and NeuStar Sign Agreement to Offer Root DNS Services

[Niels Bakker]

It is not a public root and it is not available over the internet either
A closed service  available solely over  the gprs network


* [EMAIL PROTECTED] (Brandon Butterworth) [Fri 30 Sep 2005, 12:55 CEST]:
Until the users want to access the same stuff from their 
PC and they petition for it to be in the public root too


To the public if it looks like internet they expect it to 
work like internet


You are misunderstanding.  The data in .gprs is used by infrastructure 
in the GSM networks to decide where a user's home station is.  End users 
have no way of interacting with this infrastructure (beyond turning on 
their phones outside their home country).


When a user "surfs the internet" from their handheld device they get the 
real Internet, not some walled garden that has .gprs.



-- Niels.

Re: GSM Association and NeuStar Sign Agreement to Offer Root DNS Services

[Brandon Butterworth]

> You are misunderstanding.

I'm extrapolating, things rarely stay restricted to the
original use they existed for. At some point I expect
they'll put something on it that users become aware of
and think "it'd be much more convenient if we could
use the same on the internet"

> The data in .gprs is used by infrastructure 
> in the GSM networks to decide where a user's home station is.

If they restrict it to internal use then it's non news,
anyone can make up stuff with risk of later collision,
and isn't on topic here.

brandon

Re: [political pontification] Re: Turkey has switched Root-Servers

[Eric Brunner-Williams at a VSAT somewhere]

Vint,


I don't think I know any longer, if I ever did, what "IDN" means.


Alternatives to Unicode were proposed during the IETF IDN WG lifetime, both
as a single normative reference, and as a normative reference.


Likewise an intermediate tables redefinition of Unicode, mentioned in my
last pointless comment.


Then there is the possibility of research on the problems of character
repitoires and interoperable data exchange -- before engineering some
solution(s).


Proposed to the IRTF Chair and rejected.



Are there operational issues to attempt to make this thread remotely
on point for NANOG? Probably not. Its just bits, and whether the bits
are all 0x000 or quasi-random distributions between 0x000 and 0x177 is
water under somebody else's bridge. The constraint-space is "solve in
applications" and not "solve in infrastructure".


The question of semantic scope is interesting in theory, which was the
point of my note to Tony Li, if not tractible in a particular context.


Eric

[ON TOPIC] Was: Re: GSM Association and NeuStar Sign Agreement to Offer Root DNS Services

[James R. Cutler]

Management of Naming, Addressing, and the related directory service (DNS)
is properly part of Network Operations.  Thus, on topic for
NANOG.
At 9/30/2005 01:43 PM +0100, Brandon Butterworth wrote:

If they restrict it to internal use then it's non news,
anyone can make up stuff with risk of later collision,
and isn't on topic here.
brandon

-
James R. Cutler
[EMAIL PROTECTED]

Re: [Misc][Rant] Internet router (straying slightly OT)

[Randy Bush]

>> To get an understanding of routing-protocols, begin with RIP[3] and
>> perhaps run your own RIP-lab
> necromancy will be severely punished.

many hand-on routing workshops start with rip, though with the
warning "you will now learn why not to use rip."  it makes it
easy to teach poison reverse, ... in a relatively small setting.

randy

[Pr-plan] Public-Root resolution problems and UNIDT (fwd)

[Peter Dambier]

Statement of the Official Public-Root Representative

September 29, 2005

This communication is published on the Internet at URL:

http://www.cynikal.net/~baptista/P-R/2005-09-29%20Memo%20to%20the%20Internet%20Community.pdf

Memo to the Internet Community
Public-Root resolution problems

I in my capacity as the Official Public-Root Representative and
whistle-blower, asked Peter Dambier to publish to NANOG a notice that the
Public-Root had fractured. Namely, the root in Ankara operated by Celep
Bahadir who is also the UNIDT (www.unidt.com) representative to Turkey and
the Middle East.

There was an attempt by UNIDT to start a new root system called the
United-Root. Attempts by Ankara to test this root on l.public-root.net at
195.214.191.125 resulted in a fracturing of the public-root network.

The Ankara root injected a number of older records into the DNS resulting
in false answers to queries. Ankara was also listing as root servers some
DNS that pointed back to ICANN data and did not resolve the Public-Root.
This was very unprofessional behavior on behalf of UNIDT resulting in a
serious violation of their contractual obligations to the Public-Root.

I sent several email communications to UNIDT General Manager Mr. Marty
van Veluw pointing out the problem. I am pleased to announce the problem
is corrected now but no official response was received back from Mr. Van
Veluw. The last time Ankara was checked it was found the root server is
out of sync with the remaining Public-Root network. This is also very
unprofessional. I have sent email messages to Mr. van Veluw pointing out
the problem.

Unfortunately I consider UNIDT unstable and expect they may intentionally
jeopardize the root in order to break their contracts with us. Mr. Martijn
Burger the chair of INAIC and Public-Root has advised me Mr. van Veluw may
close down the Ankara server in the near future. This would also
constitute a violation of the contract between UNIDT and the Public-Root.

I continue to maintain my position that any administrator using the
public-root should select another root system during this period of
reorganization.

I also want to take this time to criticize NANOG (North American Network
Operators Group) and the inclusive and alternative namespace communities.
However, my main concern is NANOG. I find the fact the people of Turkey
are being the subject of technical jokes on NANOG appalling.

Anyone who understands the importance of root servers also understands the
fiduciary responsibilities that go with such an operation. The technical
problems with the public-root pale when one reviews the people involved. I
regret to say that hackers and criminals are behind the Public-Root.
Therefore, this is not a joke, this is a serious issue. The people of
Turkey and Tiscali users have been surfing the Internet using a system
that can compromise their security and privacy.

I hope in future the NANOG and root communities will be more responsive
and civil.

- 33 -

Joe Baptista, Official Public-Root Representative and Lobbyist to the
United States Congress and Senate / Tel: +1 (202) 517-1593

Public-Root Disclosure Documents: http://www.cynikal.net/~baptista/P-R/
Public-Root Discussion Forum: http://lair.lionpost.net/mailman/listinfo/pr-plan

Re: [Misc][Rant] Internet router (straying slightly OT)

[Joe Abley]

On 30-Sep-2005, at 09:32, Randy Bush wrote:


To get an understanding of routing-protocols, begin with RIP[3] and
perhaps run your own RIP-lab


necromancy will be severely punished.


many hand-on routing workshops start with rip, though with the
warning "you will now learn why not to use rip."  it makes it
easy to teach poison reverse, ... in a relatively small setting.


RIP also has the advantage that a worked, non-trivial example of the  
protocol can fit on a whiteboard, which makes it a reasonable way to  
teach the concept of a routing protocol to a classroom full of people  
who have never heard of such at thing.


Absolutely agreed, however, that such teaching also necessarily  
involves emphatic shouting of "YOU WILL NOT TURN THIS ON IN YOUR  
PRODUCTION NETWORK".


[ObAnecdote: I once heard of an airline reservations desk in Hong  
Kong which had a backup connection to the airline's main centre of  
operations far distant from Hong Kong, using dial-on-demand ISDN,  
circa 1995. The monthly invoice for international ISDN charges that  
followed a contractor's decision to "fix the router by turning on  
RIP" was apparently an impressive thing to behold, especially given  
the agressive ISDN idle tear-down configured on the router and  
minimum 1-minute billing per call.]



Joe

Re: [Misc][Rant] Internet router (straying slightly OT)

[Sabri Berisha]

On Fri, Sep 30, 2005 at 10:01:34AM -0400, Joe Abley wrote:

Hi,

> RIP also has the advantage that a worked, non-trivial example of the  
> protocol can fit on a whiteboard, which makes it a reasonable way to  
> teach the concept of a routing protocol to a classroom full of people  
> who have never heard of such at thing.

Which is exactly the reason why I mentioned RIP as a routing protocol to
start with. Using RIP instead of OSPF or IS-IS has 2 advantages: one is
the simplyness of the concept and the second one you already mentioned:
 
> Absolutely agreed, however, that such teaching also necessarily  
> involves emphatic shouting of "YOU WILL NOT TURN THIS ON IN YOUR  
> PRODUCTION NETWORK".

You learn why not to use RIP in an early stage of your career.

Mentioning the terms "router-lsa", "network-summary-lsa" or "nssa-lsa"
to a person who potentially does not even know the difference between a
distance-vector and a link-state protocol has no positive effect on the
learning curve.

-- 
Sabri

please do not throw salami pizza away

Re: GSM Association and NeuStar Sign Agreement to Offer Root DNS Services

[Sabri Berisha]

On Fri, Sep 30, 2005 at 02:33:13PM +0200, Niels Bakker wrote:
 
Hi,

> >To the public if it looks like internet they expect it to 
> >work like internet
> 
> You are misunderstanding.  The data in .gprs is used by infrastructure 
> in the GSM networks to decide where a user's home station is.  End users 
> have no way of interacting with this infrastructure (beyond turning on 
> their phones outside their home country).

He has a point. Remember "Het Net"* as it was before they proxiet to the
real internet. Users expected the internet and after a while, they got
it.

-- 
Sabri

please do not throw salami pizza away


* "Het Net", translated as "The Net" was an attempt by the dutch
national telco in the late 90's to come up with a big intranet where
users could dialup, using RFC1918 addresses and visit community and
commercial sites. After a few months, proxy-support to the real internet
was added and even later it was integrated into Planet.nl, a dutch
dsl-isp.

Re: [Pr-plan] Public-Root resolution problems and UNIDT (fwd)

[Valdis . Kletnieks]

On Fri, 30 Sep 2005 15:57:47 +0200, Peter Dambier said:

> http://www.cynikal.net/~baptista/P-R/2005-09-29%20Memo%20to%20the%20Internet%
20Community.pdf

> There was an attempt by UNIDT to start a new root system called the
> United-Root. Attempts by Ankara to test this root on l.public-root.net at
> 195.214.191.125 resulted in a fracturing of the public-root network.
> 
> The Ankara root injected a number of older records into the DNS resulting
> in false answers to queries. Ankara was also listing as root servers some
> DNS that pointed back to ICANN data and did not resolve the Public-Root.
> This was very unprofessional behavior on behalf of UNIDT resulting in a
> serious violation of their contractual obligations to the Public-Root.

I'm not sure whether to say "We told you so" or just "RFC2826".



pgpBWb2VtTEWZ.pgp
Description: PGP signature

Re: [Pr-plan] Public-Root resolution problems and UNIDT (fwd)

[Andy Davidson]

Peter Dambier wrote:

The Ankara root injected a number of older records into the DNS resulting
in false answers to queries. Ankara was also listing as root servers some
DNS that pointed back to ICANN data and did not resolve the Public-Root.
This was very unprofessional behavior on behalf of UNIDT resulting in a
serious violation of their contractual obligations to the Public-Root.


Sounds like chaos.  If only there was some way of co-ordinating a 
central root, managed by a trustworthy, established, stable main player.


A bit like an internationally organized, non-profit corporation that has 
responsibility for Internet Protocol (IP) address space allocation, 
protocol identifier assignment, generic (gTLD) and country code (ccTLD) 
Top-Level Domain name system management, and root server system 
management functions.


Has anyone considered this ?

Re: [Pr-plan] Public-Root resolution problems and UNIDT (fwd)

[Roy Arends]

On Fri, 30 Sep 2005, Peter Dambier wrote:

> Statement of the Official Public-Root Representative

> Public-Root resolution problems
>
> I in my capacity as the Official Public-Root Representative and
> whistle-blower, asked Peter Dambier to publish to NANOG a notice that the
> Public-Root had fractured. Namely, the root in Ankara operated by Celep
> Bahadir who is also the UNIDT (www.unidt.com) representative to Turkey and
> the Middle East.
>
> There was an attempt by UNIDT to start a new root system called the
> United-Root. Attempts by Ankara to test this root on l.public-root.net at
> 195.214.191.125 resulted in a fracturing of the public-root network.
>
> The Ankara root injected a number of older records into the DNS resulting
> in false answers to queries. Ankara was also listing as root servers some
> DNS that pointed back to ICANN data and did not resolve the Public-Root.
> This was very unprofessional behavior on behalf of UNIDT resulting in a
> serious violation of their contractual obligations to the Public-Root.

>From Life of Brian, scene 7.

BRIAN:
Are you the Judean People's Front?
REG:
Fuck off!
BRIAN:
What?
REG:
Judean People's Front. We're the People's Front of Judea! Judean
People's Front. Cawk.
FRANCIS:
Wankers.
BRIAN:
Can I... join your group?
REG:
No. Piss off.
BRIAN:
I didn't want to sell this stuff. It's only a job. I hate the Romans
as much as anybody.
PEOPLE'S FRONT OF JUDEA:
S. S. Shhh. Shh. S.
REG:
Schtum.
JUDITH:
Are you sure?
BRIAN:
Oh, dead sure. I hate the Romans already.
REG:
Listen. If you really wanted to join the P.F.J., you'd have to really
hate the Romans.
BRIAN:
I do!
REG:
Oh, yeah? How much?
BRIAN:
A lot!
REG:
Right. You're in. Listen. The only people we hate more than the Romans
are the fucking Judean People's Front.
P.F.J.:
Yeah...
JUDITH:
Splitters.
P.F.J.:
Splitters...
FRANCIS:
And the Judean Popular People's Front.
P.F.J.:
Yeah. Oh, yeah. Splitters. Splitters...
LORETTA:
And the People's Front of Judea.
P.F.J.:
Yeah. Splitters. Splitters...
REG:
What?
LORETTA:
The People's Front of Judea. Splitters.
REG:
We're the People's Front of Judea!
LORETTA:
Oh. I thought we were the Popular Front.
REG:
People's Front! C-huh.
FRANCIS:
Whatever happened to the Popular Front, Reg?
REG:
He's over there.
P.F.J.:
Splitter!
GOLIATH:
[pant pant pant] Ooh. Ooh. I-- I think I'm about to have a... cardiac
arrest. Ooh. Ooh.
SPECTATOR:
Absolutely dreadful. Hmm.
CROWD:
[cheering]
REG:
Yes, brother! Ha ha. What's your name?
BRIAN:
Brian. Brian Cohen.
REG:
We may have a little job for you, Brian.

Roy

Re: [Pr-plan] Public-Root resolution problems and UNIDT (fwd)

[Stephane Bortzmeyer]

On Fri, Sep 30, 2005 at 04:05:34PM +0100,
 Andy Davidson <[EMAIL PROTECTED]> wrote 
 a message of 19 lines which said:

> A bit like an internationally organized, non-profit corporation 
...
> Has anyone considered this ?

Yes, replacing the DoC puppet by an internationally organized
corporation would be a good idea.

Life of Brian, was Re: [Pr-plan] Public-Root resolution problems and UNIDT (fwd)

[Roy Arends]

On Fri, 30 Sep 2005, Peter Dambier wrote:

> Statement of the Official Public-Root Representative

> Public-Root resolution problems
>
> I in my capacity as the Official Public-Root Representative and
> whistle-blower, asked Peter Dambier to publish to NANOG a notice that the
> Public-Root had fractured. Namely, the root in Ankara operated by Celep
> Bahadir who is also the UNIDT (www.unidt.com) representative to Turkey and
> the Middle East.
>
> There was an attempt by UNIDT to start a new root system called the
> United-Root. Attempts by Ankara to test this root on l.public-root.net at
> 195.214.191.125 resulted in a fracturing of the public-root network.
>
> The Ankara root injected a number of older records into the DNS resulting
> in false answers to queries. Ankara was also listing as root servers some
> DNS that pointed back to ICANN data and did not resolve the Public-Root.
> This was very unprofessional behavior on behalf of UNIDT resulting in a
> serious violation of their contractual obligations to the Public-Root.

>From Life of Brian, scene 7.

BRIAN:
Are you the Judean People's Front?
REG:
F*** off!
BRIAN:
What?
REG:
Judean People's Front. We're the People's Front of Judea! Judean
People's Front. Cawk.
FRANCIS:
Wankers.
BRIAN:
Can I... join your group?
REG:
No. P*** off.
BRIAN:
I didn't want to sell this stuff. It's only a job. I hate the Romans
as much as anybody.
PEOPLE'S FRONT OF JUDEA:
S. S. Shhh. Shh. S.
REG:
Schtum.
JUDITH:
Are you sure?
BRIAN:
Oh, dead sure. I hate the Romans already.
REG:
Listen. If you really wanted to join the P.F.J., you'd have to really
hate the Romans.
BRIAN:
I do!
REG:
Oh, yeah? How much?
BRIAN:
A lot!
REG:
Right. You're in. Listen. The only people we hate more than the Romans
are the f*ing Judean People's Front.
P.F.J.:
Yeah...
JUDITH:
Splitters.
P.F.J.:
Splitters...
FRANCIS:
And the Judean Popular People's Front.
P.F.J.:
Yeah. Oh, yeah. Splitters. Splitters...
LORETTA:
And the People's Front of Judea.
P.F.J.:
Yeah. Splitters. Splitters...
REG:
What?
LORETTA:
The People's Front of Judea. Splitters.
REG:
We're the People's Front of Judea!
LORETTA:
Oh. I thought we were the Popular Front.
REG:
People's Front! C-huh.
FRANCIS:
Whatever happened to the Popular Front, Reg?
REG:
He's over there.
P.F.J.:
Splitter!
GOLIATH:
[pant pant pant] Ooh. Ooh. I-- I think I'm about to have a... cardiac
arrest. Ooh. Ooh.
SPECTATOR:
Absolutely dreadful. Hmm.
CROWD:
[cheering]
REG:
Yes, brother! Ha ha. What's your name?
BRIAN:
Brian. Brian Cohen.
REG:
We may have a little job for you, Brian.


Regards,

Roy

Re: [Misc][Rant] Internet router (straying slightly OT)

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, Randy Bush writes:
>
>>> To get an understanding of routing-protocols, begin with RIP[3] and
>>> perhaps run your own RIP-lab
>> necromancy will be severely punished.
>
>many hand-on routing workshops start with rip, though with the
>warning "you will now learn why not to use rip."  it makes it
>easy to teach poison reverse, ... in a relatively small setting.

And it's much easier to understand, at least for a beginner.

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

Paul Vixie serving ORSN

[Peter Dambier]

Interesting:

regards,
Peter and Karin

 Original Message 
From: Markus Grundmann/ORSN <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Date: Fri, 30 Sep 2005 14:03:56 +0200
Organization: ORSN, Open Root Server Network
Subject: [ORSN.TECH] We Are Complete
List-Archive: 

Dear Listmembers!

The ORSN project got two further members.
All 13 roots servers are now taken up in our data base.

The Family is complete :)

---
F.ORSN-SERVERS.NET was operated by:

Zen Systems ApS, http://www.zensystems.dk
Location: Denmark (Lyngby)
More details: http://european.de.orsn.net/hostdetails.php?serv=F

---
L.ORSN-SERVERS.NET was operated by:

   Paul Vixie, http://www.vix.com
   Location:  USA, San Jose (CA)
   More details: http://european.de.orsn.net/hostdetails.php?serv=L

   + Currently the configuration is not completed.
   + BIND didn't response to queries.


Regards,
Markus Grundmann
ORSN, Germany




__
ORSN, Public Mailing-List (Tech-Discussion)


--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason

Re: [political pontification] Re: Turkey has switched Root-Servers

[Eric Brunner-Williams at a VSAT somewhere]

> Are there operational issues to attempt to make this thread remotely on
> point for NANOG? Probably not. Its just bits, and whether the bits are all
> 0x000 or quasi-random distributions between 0x000 and 0x177 is water under
> somebody else's bridge. The constraint-space is "solve in applications" and
> not "solve in infrastructure".

s/0x177/0x377/. I'm such a dolt. ENOCOFFEE. The 8th bit is the point, for
some values of point.

> VC: yes, that's the current vector at any rate although I gather there is
> still effort being put into constraint rules at both infrastructure and
> application level?

Back when I still worked for a well-heeled, if only through pyramid-scams
on investers in the North American numbering and speculative DNS markets,
employer and could afford to go to IETF meetings, I did talk to people in
the MTA and other lines of work about foo-in-infrastructure.

One can hope that people do the correct things, but sometimes they need to
be reminded what "correct" and "do" mean.

I wonder what goodies and treats await me in this tasty tarball ... after 
all "sendmail X is 8 bit transparent" ...

ftp://ftp.sendmail.org/pub/sendmail/.beta/antry/smX-0.0.Beta2.0.tar.gz

Eric

Re: Paul Vixie serving ORSN

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, Peter Dambier writes:
>
>Interesting:
>

I don't regard this as good, but note this from the ORSN FAQ:

* Has ORSN additional TLDs like .DNS, .AUTO?

No. ORSN is a "Legacy Root" and 100% compatible with ICANN's
root zone.

and

Furthermore, no additional (alternative) top level domains
will be added to the ORSN root-servers like ORSC, NEW.NET,
public-root and other networks did it.

It is *not* the same as what you've been advocating.

As for why it's not good -- at least one query ('dig ns .') will
yield different answers,  I also note that it's now operating in
"independent mode", which (according to the FAQ) happens if the owners
of ORSN think there's some danger to the ICANN roots.  Since the
danger is explicitly listed as the "political situation of the world",
I am concerned that OSRN is reserving to itself the right to diverge
from ICANN if they perceive that ICANN is making political decisions
under the influence of the U.S administration.  (I also note that the
OSRN is explicitly European-based, which is not that much of an
improvement over the US-based ICANN, and plans to put most of its
servers in Europe.  5 of the 13 official root servers have at least
partial presence outside the US -- not as many as there should be,
but better than having them all on one continent.

209.68.1.140 (209.68.1.0 /24) blocked by bellsouth.net for SMTP

[Eadi Gvron]

I don't understand why there's all these flame wars and pissing contests or 
people unhappy with the noise I've added to this mailing list... all this 
debate about what is or isn't on topic,  Oy Vey!  You'd think this list 
existed for years before I learned about it and decided to spew my wisdom or 
something.


We have a saying for that:
nucking few guy nas ho lue.   It means:
FNG has no clue.


--
My blog: http://blogs.securiteam.com/?author=6

"The third principle of sentient life is the capacity for self-sacrifice
--- the conscious ability to override evolution and self-preservation
for a cause, a friend, a loved one."
  -- Draal, "A Voice in the Wilderness", Babylon 5.

_
On the road to retirement? Check out MSN Life Events for advice on how to 
get there! http://lifeevents.msn.com/category.aspx?cid=Retirement

Re: Weird DNS issues for domains

[Crist Clark]

Peter wrote:

Crist Clark <[EMAIL PROTECTED]> wrote:
[...]


The problem I've seen is when an SMTP server does not accept emails
which have non-resolvable MAIL FROM domain. When the sender is a
dumb SMTP client, not an MTA, this can cause problems.



Well, that "dumb SMTP client" should stop pretending to be a MTA then.
If it can't queue and retry, it shouldn't even *think* about looking
for MX records.


Sorry, I guess I was not clear. The dumb client is not pretending
to be an MTA. The dumb client is sending to its "smart host." The
MTA, the smart server for the dumb clients, does a "reality check"
on the envelope sender. (This is not unusual.) A dumb client tries
to send,

MAIL FROM:<[EMAIL PROTECTED]>

Via the MTA, but the MTA rejects this because it cannot resolve the
domain. Now even if our MTA does the right thing and rejects with
a 4xx error, a dumb client may not be equipped to handle this well.


Besides, what sort of "dumb SMTP client" did you have in mind?
Formmail scripts? Worms? Outlook Express? I can't say I'd miss mail
from any of those.


Well, the reality check on the sender domain is meant to stop a lot
of traffic from some of those sources, so I won't miss that either.
However, due to the nature of our business, we have lots of people
with very, uh, "interesting" SMTP clients. I know of a few who have
integrated PPP/IP/TCP/SMTP stacks for custom hardware, i.e. they wrote
network code for a device with less CPU and RAM horsepower than your
modern wrist watch to only send email. They tend not to handle
exceptional conditions well (and sometimes have cool features like
the sender address is hardcoded, hardcoded in NVRAM, or hardcode the
IP address of the smart host which is fun when we move those or bring
one down for maintenance).


(I noticed this happen to a high traffic customer who had both of
their DNS servers in the same /24 located in Slidell, LA. Needless
to say, they were down for more than a few hours when Katrina rolled
through.)



Having reachable DNS isn't going to help anyway if the MX host is also
unreachable for an extended period. Mail is still going to bounce
after a few days if somebody doesn't fiddle with DNS.


But even if the destination MTA is reachable, the mail was not going
through since the MAIL FROM domain was unresolvable. The mail would
have been delivered promptly had the sender's DNS been available. The
sender's MX MTA never enters into the picture.
--
Crist J. Clark   [EMAIL PROTECTED]
Globalstar Communications(408) 933-4387

Re: Paul Vixie serving ORSN

[Paul Vixie]

> I don't regard this as good, but note this from the ORSN FAQ:
> 
>   * Has ORSN additional TLDs like .DNS, .AUTO?
> 
>   No. ORSN is a "Legacy Root" and 100% compatible with ICANN's
>   root zone.
> 
>   and
> 
>   Furthermore, no additional (alternative) top level domains
>   will be added to the ORSN root-servers like ORSC, NEW.NET,
>   public-root and other networks did it.
> 
> It is *not* the same as what you've been advocating.

indeed, it is not.  anyone who shows fealty to the universal IANA namespace
can count on my support.  when i read the above FAQ, i volunteered the same
hour.  note that this is me acting personally, and not in my capacity as an
employee of ISC or any other entity.

> As for why it's not good -- at least one query ('dig ns .') will yield
> different answers,

this is the other reason why i took an interest in ORSN.  the trinity of
ICANN/VeriSign/US-DoC has spent far more good will than they've brought in,
and many folks around the world seem now to be looking for ways to take
their fate in their own hands.  ORSN shows fealty to the universal IANA
namespace, and edits the ". NS" RRset of "their" zone only because there is
no other way to accomplish their independence goals.  by helping them, i
can learn more about how this works out in practice.  by operating a server,
i can measure and contemplate the traffic.

for the record, i won't be switching any of my own recursive nameservers
over to ORSN.  i'm very satisifed with the service i receive from the IANA
nameservers.

> I also note that it's now operating in "independent mode", which
> (according to the FAQ) happens if the owners of ORSN think there's some
> danger to the ICANN roots.  Since the danger is explicitly listed as the
> "political situation of the world", I am concerned that OSRN is reserving
> to itself the right to diverge from ICANN if they perceive that ICANN is
> making political decisions under the influence of the U.S administration.

i'm indifferent to their reasons, as long as they don't add any new TLD's or
otherwise display the kind of piracy or foolishness i have so often decried
among new.net, unidt, united-root, public-root, alternic, open-rsc... and i
forget how many others.

> (I also note that the OSRN is explicitly European-based, which is not
> that much of an improvement over the US-based ICANN, and plans to put
> most of its servers in Europe.  5 of the 13 official root servers have at
> least partial presence outside the US -- not as many as there should be,
> but better than having them all on one continent.

with or without the approval or participation of the folks who started it all,
and those who wrote most of the code and specifications and those who are now
working hard to keep it running, the world is going to pursue autonomy and
independence.  the internet allows, among other things, not having to care
very much what other people think about what ought, or ought not, to be done.

however, there's still a chance to encourage responsible independence, which
i think ORSN is demonstrating, as opposed to piracy and foolishness, such as
those who falsely respond to queries sent to the IANA root server addresses,
or those who shortsightedly add TLD's that only their own customers can see...
the list goes on.  (in fact, the list is only getting started.)
-- 
Paul Vixie

Weekly Routing Table Report

[Routing Table Analysis]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.
Daily listings are sent to [EMAIL PROTECTED]

If you have any comments please contact Philip Smith <[EMAIL PROTECTED]>.

Routing Table Report   04:00 +10GMT Sat 01 Oct, 2005

Analysis Summary


BGP routing table entries examined:  171014
Prefixes after maximum aggregation:   97564
Unique aggregates announced to Internet:  82650
Total ASes present in the Internet Routing Table: 20600
Origin-only ASes present in the Internet Routing Table:   17917
Origin ASes announcing only one prefix:8499
Transit ASes present in the Internet Routing Table:2683
Transit-only ASes present in the Internet Routing Table: 74
Average AS path length visible in the Internet Routing Table:   4.5
Max AS path length visible:  28
Prefixes from unregistered ASNs in the Routing Table:20
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space: 12
Number of addresses announced to Internet:   1427924992
Equivalent to 85 /8s, 28 /16s and 104 /24s
Percentage of available address space announced:   38.5
Percentage of allocated address space announced:   58.0
Percentage of available address space allocated:   66.4
Total number of prefixes smaller than registry allocations:   81421

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:35620
Total APNIC prefixes after maximum aggregation:   15642
Prefixes being announced from the APNIC address blocks:   33451
Unique aggregates announced from the APNIC address blocks:16498
APNIC Region origin ASes present in the Internet Routing Table:2368
APNIC Region origin ASes announcing only one prefix:695
APNIC Region transit ASes present in the Internet Routing Table:365
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 17
Number of APNIC addresses announced to Internet:  201486848
Equivalent to 12 /8s, 2 /16s and 114 /24s
Percentage of available APNIC address space announced: 74.8

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911
APNIC Address Blocks   58/7, 60/7, 124/7, 126/8, 202/7, 210/7, 218/7,
   220/7 and 222/8

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes: 90868
Total ARIN prefixes after maximum aggregation:55367
Prefixes being announced from the ARIN address blocks:70939
Unique aggregates announced from the ARIN address blocks: 26417
ARIN Region origin ASes present in the Internet Routing Table:10236
ARIN Region origin ASes announcing only one prefix:3781
ARIN Region transit ASes present in the Internet Routing Table: 952
Average ARIN Region AS path length visible: 4.3
Max ARIN Region AS path length visible:  17
Number of ARIN addresses announced to Internet:   270880512
Equivalent to 16 /8s, 37 /16s and 79 /24s
Percentage of available ARIN address space announced:  67.3

ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
   3354-4607, 4865-5119, 5632-6655, 6912-7466
   7723-8191, 10240-12287, 13312-15359, 16384-17407
   18432-20479, 21504-23551, 25600-26591,
   26624-27647, 29696-30719, 31744-33791
   35840-36863
ARIN Address Blocks24/8, 63/8, 64/6, 68/7, 70/6, 74/7, 76/8,
   198/7, 204/6, 208/7 and 216/8

RIPE Region Analysis Summary


Prefixes being announced by RIPE Region ASes: 33185
Total RIPE prefixes after maximum aggregation:22519
Prefixes being announced from the RIPE address blocks:30235
Unique aggregates announced from the RIPE address blocks: 20199
RIPE Region origin ASes present in the Internet Routing Table: 7153
RIPE Region origin ASes announcing only one prefix:3781
RIPE Region transit ASes present in the Internet Routing Table:1185
Average RIPE Region AS path length visible: 5.1
Max RIPE Region AS path length visible:  28
Number of RIPE addresses announced to Inter

Re: [Misc][Rant] Internet router (straying slightly OT)

[Marshall Eubanks]

On Thu, 29 Sep 2005 17:39:30 -0400
 Mark Owen <[EMAIL PROTECTED]> wrote:
> 
> On 9/29/05, Warren Kumari <[EMAIL PROTECTED]> wrote:
> > I have met "Senior Network Engineers" who don't understand longest
> > match rule ("The traffic will take 10/8 instead of 10.0.0.0/24
> > because it has a better admin distance", "I can override these 300
> > OSPF routes with a single static supernet", etc), who believe that
> > routers will not route between directly connected interfaces without
> > putting them into a routing protocol, that transit networks don't
> > need a full mesh of iBGP[1] because "you can just redistribute BGP
> > into [OSPF/IS-IS/IGP of choice], that ICMP uses TCP as a transport,
> > etc.
> 
> In a similar note, I Do care about networks and the like but fail to
> fully understand the extensive details of how it all works.  I do not
> proclaim myself to be an engineer and try to stick with what I do
> well.  I read rfc, wikipedia, etc but just don't know what /to/ read. 
> I had never heard of iBGP, OSPF, IS-IS untill today.  What I need, and
> I'm sure quite a few others who listen to this list for insight, is a
> good reference to pick up and read that will cover said topics and
> beyond.  I finally got the basic concept to CIDRs and how they work
> thanks to this list and Google.
> 
> I know this message is slightly off topic from NANOG, but kinda fits
> in response to parent and am hoping not to get flamed.

FWIW, I would suggest ISP Survival Guide: Strategies for Running a Competitive 
ISP (Paperback)
by Geoff Huston - ISBN: 0471314994, which does a good job with the basics, and 
is pretty
easy to read.

Regards
Marshall Eubanks



> 
> Any suggestions?
> 
> 
> A Padawan,
> Mark Owen

Re: [eng/rtg] changing loopbacks

[Sean Figgins]

On Fri, 30 Sep 2005, Christopher L. Morrow wrote:

> ospf doesn't, for router-id on cisco's atleast, as Warren pointed out :(
> however! switching from ospf to 'another igp' (ISIS would work well) would
> avoid that, slide off ospf and onto ISIS, kill ospf when all next-hops
> switch, which should be 'as soon as isis converges'.

It is a good reason to assign seperate router IDs, rather than rely on the
OSPF implementation to decide which IP is the one it will use.  Of course
not all vendors support this.  The major router vendors do, though.

 -Sean

Re: Paul Vixie serving ORSN

[Roy Arends]

On Fri, 30 Sep 2005, Paul Vixie wrote:

>
> > I don't regard this as good, but note this from the ORSN FAQ:
> >
> > * Has ORSN additional TLDs like .DNS, .AUTO?
> >
> > No. ORSN is a "Legacy Root" and 100% compatible with ICANN's
> > root zone.
> >
> > and
> >
> > Furthermore, no additional (alternative) top level domains
> > will be added to the ORSN root-servers like ORSC, NEW.NET,
> > public-root and other networks did it.
> >
> > It is *not* the same as what you've been advocating.
>
> indeed, it is not.  anyone who shows fealty to the universal IANA namespace
> can count on my support.  when i read the above FAQ, i volunteered the same
> hour.  note that this is me acting personally, and not in my capacity as an
> employee of ISC or any other entity.
>
> > As for why it's not good -- at least one query ('dig ns .') will yield
> > different answers,
>
> this is the other reason why i took an interest in ORSN.  the trinity of
> ICANN/VeriSign/US-DoC has spent far more good will than they've brought in,
> and many folks around the world seem now to be looking for ways to take
> their fate in their own hands.  ORSN shows fealty to the universal IANA
> namespace, and edits the ". NS" RRset of "their" zone only because there is
> no other way to accomplish their independence goals.  by helping them, i
> can learn more about how this works out in practice.  by operating a server,
> i can measure and contemplate the traffic.

I don't get this. You pretend there is a difference between
ICANN/VeriSign/US-DoC and universal IANA namespace. They are one and the
same. If you trying to seperate the infrastructure from the namespace,
imho the infrastructure _is_ independent. I don't see ISC nor RIPE getting
approval from ICANN/VeriSign/US-DoC whenever they deploy a new any-cast
instance of a root-server, and prolly because there is no such
requirement. So that argument is out the door.

Anyway, let me attach a response I send last year about ORSN. The
stats may be a little out of date, but the general tone is still valid.

Regards,

Roy

Date: Wed, 13 Oct 2004 13:20:50 +0200 (CEST)
From: Roy Arends <[EMAIL PROTECTED]>
To: Stephane Bortzmeyer <[EMAIL PROTECTED]>
Cc: Yiorgos Adamopoulos <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: [dns-wg] Re: ORSN-SERVERS.NET

On Wed, 13 Oct 2004, Stephane Bortzmeyer wrote:

> On Wed, Oct 13, 2004 at 10:28:57AM +0200,
>  Roy Arends <[EMAIL PROTECTED]> wrote
>  a message of 19 lines which said:
>
> > Please read RFC 2826
>
> Please read about ORSN
> (http://european.nl.orsn.net/faq.php#opmode). ORSN is *not* an
> alternative root.

I did.

It is an alternative root, since it is not sanctioned nor supported
by ICANN.

The main reason for the ORSN is outlined in the about page at their site.
IMHO, their reasons (a lesser dependency on non-european instances of
authoritative root-servers, but correct me if I'm wrong) are less valid
nowadays, since some of the ICANN root-server operators chose to use
anycast as a viable means to spread the load on the root-zone.

f.root-servers.net: 26 sites, (5 in EU, 4 in US)
i.root-servers.net: 17 sites, (11 in EU, 2 in US)
j.root-servers.net: 13 sites, (3 in EU, 7 in US)
k.root-servers.net: 6 sites, (5 in EU and 1 in Qatar)
m.root-servers.net: 3 sites, (1 in EU)
The rest of roots: 11 sites in US.

In total 76 instances of a root-server of which are 25 in the
EU, 26 in the US, and 50 outside EU/US.

And this network is growing and growing.

I can recommend any organisation who has the resources (skill and
infrastructure) that would like to help to spread the load of the
root-servers to contact the anycast-enabled root operators (ISC,
Autonomica/Nordunet, RIPE).

In comparison, there are 13 ORSN servers based in europe, of which are 2
unused, and 1 has errors.

I do understand the effort ORSN is trying to make. If it is to spread load
and create less dependency, they are obviously not up to par with the
ICANN root-server network. If they effort is merely a political protest,
that is a different layer I know nothing about.

Roy

Re: Paul Vixie serving ORSN

[Paul Vixie]

# > > It is *not* the same as what you've been advocating.
# >
# > indeed, it is not.  ...
# 
# I don't get this. You pretend there is a difference between ICANN / VeriSign
# / US-DoC and universal IANA namespace.  They are one and the same.

you must have misread me.  see http://fm.vix.com/ today.

Re: Paul Vixie serving ORSN

[Roy Arends]

On Fri, 30 Sep 2005, Paul Vixie wrote:

>
> # > > It is *not* the same as what you've been advocating.
> # >
> # > indeed, it is not.  ...
> #
> # I don't get this. You pretend there is a difference between ICANN / VeriSign
> # / US-DoC and universal IANA namespace.  They are one and the same.
>
> you must have misread me.  see http://fm.vix.com/ today.

I've read it. Twice now. I'd like some help on what part I've misread ?

I don't think the independence argument holds, as explained by my previous
message, therefor, one of ORSN's main argument: resilience; How is the
community served better by converging from a set of 75+ roots deployed
worldwide to a set of 13 roots european based. Or are you trying to give
US based ORSN clients better proximity :)

Roy

Re: Paul Vixie serving ORSN

[Paul Vixie]

# > you must have misread me.  see http://fm.vix.com/ today.
# 
# I've read it. Twice now. I'd like some help on what part I've misread ?

"i'm indifferent to their reasons, as long as they don't add any new TLD's..."

# I don't think the independence argument holds, as explained by my previous
# message, therefor, one of ORSN's main argument: resilience; How is the
# community served better by converging from a set of 75+ roots deployed
# worldwide to a set of 13 roots european based. Or are you trying to give US
# based ORSN clients better proximity :)

it's enough for me that they're going to do it no matter what you (or i) say,
and that they're doing it responsibly (without any namespace pollution).  if
ORSN is afraid war is going to break out somewhere and that ICANN might delete
the ccTLD's for countries that are part of the "axis of evil", then ORSN is
probably just confused -- i don't think that's what would happen.  but as i've
said, i'm indifferent to their reasons, since they only publish data that was
at one time or another published by IANA.

and note, i won't be switching my own recursive lookups over to ORSN, since
i'm completely satisfied with the performance IANA servers, and i do not share
ORSN's concerns about "unsound zone changes".

Re: Paul Vixie serving ORSN

[Roy Arends]

On Fri, 30 Sep 2005, Paul Vixie wrote:

>
> # > you must have misread me.  see http://fm.vix.com/ today.
> #
> # I've read it. Twice now. I'd like some help on what part I've misread ?
>
> "i'm indifferent to their reasons, as long as they don't add any new TLD's..."

I understood that you're indifferent to _their_ reasons. I'm curious
about _your_ reasons. Solely to learn and for the stats? I couldn't deduct
that from fm.vix.com.

Roy

Re: Paul Vixie serving ORSN

[Paul Vixie]

# I understood that you're indifferent to _their_ reasons. I'm curious about
# _your_ reasons. Solely to learn and for the stats? I couldn't deduct that
# from fm.vix.com.

internet governance ain't what it will be.  anyone who wants to keep name
universality in place as the system evolves, can ask or expect help from me.

Re: Paul Vixie serving ORSN

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, Paul Vixie writes:

>it's enough for me that they're going to do it no matter what you (or i) say,
>and that they're doing it responsibly (without any namespace pollution).  if
>ORSN is afraid war is going to break out somewhere and that ICANN might delete
>the ccTLD's for countries that are part of the "axis of evil", then ORSN is
>probably just confused -- i don't think that's what would happen.  but as i've
>said, i'm indifferent to their reasons, since they only publish data that was
>at one time or another published by IANA.
>

Paul, if we ever get DNSSEC deployed, what will/should OSRN return for

dig ns .


--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

.iq [ was: Re: Paul Vixie serving ORSN ]

[Eric Brunner-Williams at a VSAT somewhere]

> it's enough for me that they're going to do it no matter what you (or i) say,
> and that they're doing it responsibly (without any namespace pollution).  if
> ORSN is afraid war is going to break out somewhere and that ICANN might delete
> the ccTLD's for countries that are part of the "axis of evil", then ORSN is
> probably just confused -- i don't think that's what would happen.  but as i've
> said, i'm indifferent to their reasons, since they only publish data that was
> at one time or another published by IANA.

I suppose I should mention that ICANN redelegated .iq for some mumble
reason, compare, .pn.

For those who care about excesses of zeal, the Elashi brothers (operators
as well as sponsor delagees of .iq) of someplace in Texas, were charged with  
giving money to Hamas or a charity linked to Hamas, and sending a PC to Syria,
and parts of a PC -- perhaps a mouse pad -- to Libya.

The latter acts nominally violate export regulations intended to prevent the
acquisition of supercomputers by several states for the purposes of preventing
nuclear proliferation, and the government obtained a conviction on the Syrian
export count. Export control violations universally result in fines, except
in the case of the Elashi brothers, who are still in Federal custody.

People who live in Damascus routinely drive to Beruit to buy computers, so
the rationality of all this is an exercise left to the reader.

It did result in the seizure of the .iq name servers, and has kept .iq dark
for three years.

No part of this was necessary, or could not have been solved by a trustee
pending the eventual outcome of the USG's complaints, and the possible
counter-complaints by the Elashis.


The US has not yet, after three years, brought the giving money to Hamas
issue to trial.

Not that it matters, but Hamas is the government of parts of Palestine,
no matter how much heartburn this gives some people, and the Elashis are
diaspora Palestinians.


Eric

Re: Paul Vixie serving ORSN

[Paul Vixie]

# Paul, if we ever get DNSSEC deployed, what will/should OSRN return for
# 
#   dig ns .
# 
#   --Steven M. Bellovin, http://www.cs.columbia.edu/~smb

i don't know ORSN's plans.  i believe that the standard testbed methodology
(and bill manning would be the one to correct me here, if i'm wrong) is to
re-sign the zone with a key trusted by your client populations.  this would
not have been practical in the era before DS RRs, but as things stand, any
root zone signed by IANA will be verifiable by testbed operators, who can
re-sign the zone, including the DS RRs, and for the resulting population,
everything will "just work".  note, though, that i'm merely speculating --
it's possible that ORSN would just strip out the DNSKEYs and RRSIGs and
DS's, and publish a zone that was free of DNSSEC metadata.  i have no idea.

Re: .iq [ was: Re: Paul Vixie serving ORSN ]

[Bill Woodcock]

  On Fri, 30 Sep 2005, Eric Brunner-Williams wrote:
> I suppose I should mention that ICANN redelegated .iq for some mumble
> reason, compare, .pn.
> Not that it matters, but Hamas is the government of parts of Palestine,
> no matter how much heartburn this gives some people, and the Elashis are
> diaspora Palestinians.

...whereas post-redelegation, .iq is administered by the Iraqi 
communications ministry from Bhagdad, rather than by Palestinians from 
Texas.  Seems like a clear improvement to me.

-Bill

Re: .iq [ was: Re: Paul Vixie serving ORSN ]

[Dan Hollis]

On Fri, 30 Sep 2005, Eric Brunner-Williams at a VSAT somewhere wrote:

For those who care about excesses of zeal, the Elashi brothers (operators
as well as sponsor delagees of .iq) of someplace in Texas, were charged with
giving money to Hamas or a charity linked to Hamas, and sending a PC to Syria,
and parts of a PC -- perhaps a mouse pad -- to Libya.


http://www.usdoj.gov/usao/txn/PressRel04/Elashi.pdf

Re: [Pr-plan] Public-Root resolution problems and UNIDT (fwd)

[Todd Vierling]

On Fri, 30 Sep 2005, Peter Dambier wrote:

> I also want to take this time to criticize NANOG (North American Network
> Operators Group) and the inclusive and alternative namespace communities.
> However, my main concern is NANOG. I find the fact the people of Turkey
> are being the subject of technical jokes on NANOG appalling.

Not jokes, my dear Mr. Baptista, what we've been saying is "We told you so"
in about 200 different forms.  Chaos is not unexpected from an alternate
root system, though we more expected the problems to start with technical
barriers, before financial or personal ones flared up.

The problem with alternate roots carrying non-universal data was documented
in several RFCs with very sound technical merit, going all the way back to
the Jim Fleming/AlterNIC/PacRoot heyday of alternate root servers.  After
all this time has passed, you willfully ignore established technical and
operational facts about how global reachability is compromised by the snake
oil you're peddling.

Just the term "inclusive namespace" is a political PR spin term that is
misleading at best, and coupled with the name "Public-Root", downright
deceptive in practice.  (I have to hand it to you, though; that kind of word
play could earn you an official position in Washington.  Oh, I see you have
a "lobbyist" title already.  Oy vey.  8-)

And based on the previous paragraph, I can only conclude that Public-Root is
not meant to take away ICANN's stranglehold -- rather, it's meant to line
the Public-Root group's pockets.  Unlike ORSN, which is currently being
discussed on NANOG as well, Public-Root is actually *selling something*, not
simply acting benevolently in the best interest of the Internet.

Public-Root may be operating DNS servers that serve up a root zone, but it
is not operating an "inclusive namespace", nor "Internet" root DNS servers.
In reality, the term "Internet" itself was coined to identify a network of
*globally universal* protocols and their trimmings (which came to include
the DNS).  Now, the Public-Root is actively working to reduce global
reachability.  That's not "inclusive"; it's *exclusive*.

I'm probably taking to a brick wall here, but here I have tried to appeal to
your sense of technical sanity to drop the facade and work to do the Right
Thing, not the profitable thing.

(Note:  All this comes from someone who actually used AlterNIC's roots for
about 13 months back in "the day" -- and finally realized what a bunch of
crap the whole situation was.  I don't necessarily expect you to come to the
same realization, but I can still try to echo a common sentiment directly to
you, rather than through a third party such as Mr. Dambier.)

-- 
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: .iq [ was: Re: Paul Vixie serving ORSN ]

[Eric Brunner-Williams at a VSAT somewhere]

Bill,

Have you got an opinion on .mm? Last December (when Vint and I did exchange
notes on getting India to allow relief workers into the Andaman and Nicobar
Islands, and some British embassy in Baghdad guy who wanted to get .iq for
the Occupation regime-de-jour) it so happened that all their servers (in the
UK, which isn't part of Burma, or Burma Shave, or ...) were dark.

If those facts were present today, would you be ready to delta dot?

Eric

Re: .iq [ was: Re: Paul Vixie serving ORSN ]

[Bill Woodcock]

> Have you got an opinion on .mm? Last December it so happened that 
> all their servers (in the UK, which isn't part of Burma, or Burma 
> Shave, or ...) were dark.  If those facts were present today, would 
> you be ready to delta dot?

My inclination has been to solve problems rather than burn things down...  
Changing the root doesn't solve the problem of all someone's servers being 
down.  Getting a useful (first priority: up, second priority: in and by 
the country of service) set of servers into the root does solve the 
problem.

I think that we (PCH) and ICANN, and RIPE, and Randy Bush, among many 
others, have all put quite a bit of work into trying to see that happen.  
Starting over doesn't build a better system, just a less trusted one.

-Bill

Re: .iq [ was: Re: Paul Vixie serving ORSN ]

[Eric Brunner-Williams at a VSAT somewhere]

> > For those who care about excesses of zeal, the Elashi brothers (operators
> > as well as sponsor delagees of .iq) of someplace in Texas, were charged with
> > giving money to Hamas or a charity linked to Hamas, and sending a PC to 
> > Syria,
> > and parts of a PC -- perhaps a mouse pad -- to Libya.
> 
> http://www.usdoj.gov/usao/txn/PressRel04/Elashi.pdf


Thanks Dan, I've read it, several times, and the prior and subsequent
filings, and the referenced export regs as well.

It all comes down to pretending a PC is a supercomputer, pretending that
ordinary Syrians, let alone nuclear weapons proliferating Syrians, didn't,
in this period, routinely drive from Damascus to Beruit, and an untested
claim of money laundering, and a lot of highly excited politically
ambitious people in North America.

The Elashis didn't run a great cctld before the present excitement, but
a lot of cctld operators could then be, and can now be, similarly
characterized.

Eric

Re: .iq [ was: Re: Paul Vixie serving ORSN ]

[Eric Brunner-Williams at a VSAT somewhere]

Bill,

I forgot to mention that the idiot Brit who wanted .iq was going to run
it -- all of it -- off of generators  from inside the Green Zone.

I don't know if my notes made a bit of difference, but I advised that
ICANN not redel and open the adverse redel can unnecesarily.

I'm not sure if I understand your note, but since you seem to be making
a pragmatic "it works better" observation (and I don't know that it does)
for one 3166 code point, why not another?

Eric

Re: .iq [ was: Re: Paul Vixie serving ORSN ]

[Eric Brunner-Williams at a VSAT somewhere]

> And they did violate US laws in the US.

An export regulation, one normally punished by a fine.

> Ah well, maybe they will get deported when they get released from prison, 
> just like their wives.

There is an interesting register of export violaters, and quite a few are
foreign nationals, and quite a few are also ... obscure ... like arguing
that a Pentium processor constitutes a nuclear proliferation asset. Over
the past three years, only one violation has ressulted in the seizure  of
all business assets and business records.

As I pointed out to Vint some months ago, if the same standards were
applied to Worldcom's Bernie the Bandit, Vint could have been in the
pokey too, and even his Worldcom pencil sharpener would have a DOJ do
not remove under penalty of law seal on it.

Eric

Re: .iq [ was: Re: Paul Vixie serving ORSN ]

[David W. Hankins]

On Fri, Sep 30, 2005 at 08:38:43AM -0400, Eric Brunner-Williams at a VSAT 
somewhere wrote:
> It all comes down to pretending a PC is a supercomputer,

An ordinary PC, by today's standards average, is defined by US law as
a supercomputer, legally a munition ("weapon of war").  Wether you
yourself believe the object defined by the pouplar term "supercomputer"
is required to habitate a substantially larger space, or substantially
larger number of computrons is irrelevant.

There is no pretense here, just that I suspect you misunderstand that
the term 'supercomputer' is being used as a legal term, not the common
term you use in casual language.

> pretending that
> ordinary Syrians, let alone nuclear weapons proliferating Syrians, didn't,
> in this period, routinely drive from Damascus to Beruit,

That you might be able to buy a cannister of napalm from the grocery
store in [Insert random location], doesn't mean the US has to hold all
exports of napalm into that location as immune from export controls.

Again, there is no pretense here, and there is no need for it.

-- 
David W. Hankins"If you don't do it right the first time,
Software Engineer   you'll just have to do it again."
Internet Systems Consortium, Inc.   -- Jack T. Hankins


pgp0C38nwHSi5.pgp
Description: PGP signature

Re: .iq [ was: Re: Paul Vixie serving ORSN ]

[Eric Brunner-Williams at a VSAT somewhere]

David,

Before turning to your certainty that laws are self-explanitory and not
nuanced, I should mention soething I forgot.

The Elashi case rattled the Export Controls Defense bar, because the Elashis
didn't actually send anything to Libya, their buyer was some computer broker
in Malta, and that's who sent the export controlled material on to a state
on the restriced list.

The Elashi case established the precedent that a buyer's actions could
transfer export control liability to the seller.

Turning to your certainty, the original language has been modified to put
a Moore's Law (my shorthad) COLA-like MIPS excalator, and modified again
to replace "proliferation" (which has a rational relationship with MIPS)
with "terrorism", which has no computational characteristics known to me.


I don't know why the Elashi's attorney entered a plea on the export issue,
as the cost for agreement to a plea appears to be indeffinite sentancing,
rather than an ordinary rational cost of business fine.


Cheers,
Eric

Re: [eng/rtg] changing loopbacks

[Austin]

It's worth noting that C's don't need actual IP address space assigned to 
the router-id for OSPF. It's just an arbitrary value; it's probably better 
karma to set it to whatever you want (maybe something that doesn't look 
like an IP address).


RFC 2328:

   Router ID
   A 32-bit number assigned to each router running the OSPF
   protocol.  This number uniquely identifies the router within
   an Autonomous System.



CCO:


Usage Guidelines

You can configure an arbitrary value in the IP address format for each 
router. However, each router ID must be unique.


If this command is used on an OSPF router process which is already active 
(has neighbors), the new router-ID is used at the next reload or at a 
manual OSPF process restart. To manually restart the OSPF process, use the 
clear ip ospf command. 

Re: .iq [ was: Re: Paul Vixie serving ORSN ]

[william(at)elan.net]

On Fri, 30 Sep 2005, Bill Woodcock wrote:


...whereas post-redelegation, .iq is administered by the Iraqi
communications ministry from Bhagdad,


Current Iraq government exists because there is substantial US military
presence in the country. Lets assume that at some future point US gets
tired in spending billions on dollars on such operation and that some
time later on the Iraq government is overthrown and fled the country
(taking dns servers for .iq TLD along with them) and establishes 
"government in exile" headquartered in Texas :) The new Iraq government 
after period of civil war then requests redeligation of .iq domain from 
IANA. What actions will they take if US still recognizes old government?


BTW - Also think about what makes current Iraq government legitimate as
opposed to say representative of the old one (which lucky for US did
not establish official government in exile after start of occupation).

--
William Leibzon
Elan Networks
[EMAIL PROTECTED]

Re: .iq [ was: Re: Paul Vixie serving ORSN ]

[Sam Hayes Merritt, III]

Not that it matters, but Hamas is the government of parts of Palestine,
no matter how much heartburn this gives some people, and the Elashis 
are diaspora Palestinians.


And they did violate US laws in the US.

Ah well, maybe they will get deported when they get released from prison, 
just like their wives.



sam

IP Database

[Kevin Billings]

Title: IP Database






I am looking for an IP database for our Company that can be used from a service provider needs and also from an Enterprise that will need to track IP's down to the host level. Also need to have RWhois integration for ARIN swip's.   Does anyone have any suggestions or recommendation? I have looked at two.  ipplan which is a free open source and TCAM/ECAM by Parabola IP Solutions.  Has anyone used either of these two system and what did you think of them.


Thanks


Kevin Billings

Sr Network Engineer

Spirit Telecom

Re: IP Database

[Bruce Pinsky]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Kevin Billings wrote:
> I am looking for an IP database for our Company that can be used from a
> service provider needs and also from an Enterprise that will need to
> track IP's down to the host level. Also need to have RWhois integration
> for ARIN swip's.   Does anyone have any suggestions or recommendation? I
> have looked at two.  ipplan which is a free open source and TCAM/ECAM by
> Parabola IP Solutions.  Has anyone used either of these two system and
> what did you think of them.
> 

Lucent VitalQIP might fit the bill.

http://www.lucent.com/products/solution/0,,CTID+2020-STID+10439-SOID+1068-LOCL+1,00.html

- --
=
bep

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (MingW32)

iD8DBQFDPiOgE1XcgMgrtyYRAiheAJ9umlMj+20m5r28dPNX2/bQLU/4XgCeNh9m
jM31c0vJ1WtT2FFyBCSdpLI=
=k+2N
-END PGP SIGNATURE-