> => the merits are not only technical, the Internet simply
> doesn't work with an incoherent root zone.
I agree with you. I'm only an observer of what's happening.
> I think one needs to reflect on the implications that
> a few of the world's largest ISPs appear to have made
>
> => the I for these ISPs no more stands for Internet.
History is full of examples of ISPs (e.g. AOL) who attempted
to "garden wall" customers. Offering "enhanced" DNS is likely
to be just one more business tool they use. It's just an
observation - one may think it's wrong but that doesn't
necessarily stop them from doing it.
> If this percentage continues to grow, ICANN's ability to
> control what goes into the DNS would seem to be constrained.
>
> => as a French-speaker I have still troubles with the word control
> (French meaning is subtlely different)... So what is control
> in your statement?
It means that with any significant user base under an alternative
root TLD, ICANN may be constrained from entering that TLD in the
root - e.g., see http://www.wired.com/news/business/0,1367,42373,00.html
"During recent ICANN meetings, Cerf said that the existence of new
"unauthorized" domains could lead ICANN -- in order to reduce potential
ambiguity -- not to approve any similar domain name itself."
> => what about a parallel phone numbering system? (:-)
Sovereigns control the allocation of the E.164 numbering plan.
Robert
--
Robert Shaw <robert.shaw(a)itu.int>
ITU Internet Strategy and Policy Advisor
International Telecommunication Union <http://www.itu.int>
Place des Nations, 1211 Geneva, Switzerland
> Despite the stated technical merits of a single root,
> I think one needs to reflect on the implications that
> a few of the world's largest ISPs appear to have made
> a business decision to use a superset of the ICANN/US
> Department of Commerce's root zone.
>
> Which big ones? I've never seen any official message about this.
See www.new.net/about_us_partners.tp. Earthlink and Netzero
have been listed as the US' second and third largest ISPs
(according to http://www.ispworld.com/isp/TRI_census.htm).
That's not even counting Excite@Home.
>
> It's claimed that the US had about 100 million Internet
> users in December 2000. According to New.net's numbers
> (which needs to be confirmed), about 16% of those can now
> use their alternative root.
>
> I've seen various claims by various alternative root operators. None
> have been confirmed by independent research as far as I know.
New.net claims that 16 million users can resolve their TLDs based
on their partnerships with ISPs (like I said, this needs to be
confirmed independently).
16 million of 100 million is 16%.
Robert
--
Robert Shaw <robert.shaw(a)itu.int>
ITU Internet Strategy and Policy Advisor
International Telecommunication Union <http://www.itu.int>
Place des Nations, 1211 Geneva, Switzerland
Despite the stated technical merits of a single root,
I think one needs to reflect on the implications that
a few of the world's largest ISPs appear to have made
a business decision to use a superset of the ICANN/US
Department of Commerce's root zone.
It's claimed that the US had about 100 million Internet
users in December 2000. According to New.net's numbers
(which needs to be confirmed), about 16% of those can now
use their alternative root.
If this percentage continues to grow, ICANN's ability to
control what goes into the DNS would seem to be constrained.
Robert
--
Robert Shaw <robert.shaw(a)itu.int>
ITU Internet Strategy and Policy Advisor
International Telecommunication Union <http://www.itu.int>
Place des Nations, 1211 Geneva, Switzerland
>X-Recipient: <exp-nanog(a)ripe.net>
>Delivered-To: nanog-outgoing(a)merit.edu
>X-Sender: hank(a)max.ibm.net.il
>X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
>Date: Tue, 13 Mar 2001 10:03:14 +0200
>To: nanog(a)merit.edu
>From: Hank Nussbacher <hank(a)att.net.il>
>Subject: Statements against new.net?
>Sender: owner-nanog(a)merit.edu
>X-Loop: nanog
>
>
>Do any ISPs or web hosting companies have publically available statements on their web sites stating that they will not support the new new.net domains and why they won't? I am getting more requests from users to change our DNS root servers to support this and wanted to see what others tell their users. Any IETF/ICANN statement available?
>
>Thanks,
>Hank
>
>
Dear fellow WG members,
I have just submitted a new version of the "very long" document (the last in
our trilogy) to the Internet Drafts archive.
The name will be draft-koch-ripe-dns-setup-guide-01.txt. Please note that
the version currrently available with that name is only the expiration
notice for the "00" version submitted last February.
Until the document will have shown up at the ID-archive and its mirrors you'll
find a copy with this URL:
http://www.TechFak.Uni-Bielefeld.DE/~pk/dns/draft-koch-ripe-dns-setup-guide…
Changes are mostly editorial and filling some gaps (those marked TBD earlier).
I have now put in some words about IPv6, DNSSEC and IDN. The first three
sections should be complete now, some text is still missing for the
reverse mapping and 'popular mistakes' sections.
What I'd like to discuss next week (if there's a time slot available):
o Status of and further roadmap for the document
Especially in the light of DNSSEC and, even more, IDN, it seems a bit
difficult to prepare a single, fixed document to inform the target
audience. A living document, i.e. a ``web site'' would be better and
more up to date - if there's someone/somegroup periodically taking care.
I think the IETF's experience with the "weird" wg teach some lesson here.
On the other hand, just pointing everyone to the DNS resources directory
and the IETF to find ``everything'' is not a helpful advice IMHO.
o How to perform the "Grandma test"?
Should we decide to go on with this document it should be exposed to some
target audience people and *feedback* be collected and reported.
Volunteers?
Here are two further suggestions for the agenda:
o Review of RIPE 203
Has anyone successfully referred customers to this document?
Are their any changes suggested/needed?
o DNS traffic and ~ distribution
Does anyone have recent data on what percentage of backbone traffic is
DNS traffic and how this DNS share is split between e.g. RR types?
-Peter
We took it offline because IANA now has a more complete and
up-to-date data at http://www.iana.org/cctld/cctld-whois.htm.
We did the survey because so much stuff was out of date at
that time and in some cases, you couldn't even track down
who was running a ccTLD.
We gave all the survey data to IANA and it looks like they're
doing a good job at keeping it fresh.
Bob
--
Robert Shaw <robert.shaw(a)itu.int>
ITU Internet Strategy and Policy Advisor
International Telecommunication Union <http://www.itu.int>
Place des Nations, 1211 Geneva, Switzerland
> -----Original Message-----
> From: Robert F. Connelly [mailto:rconnell@psi-japan.com]
> Sent: Tuesday, November 07, 2000 7:18 AM
> To: Robert Shaw
> Cc: dns(a)iia.net.au; dns-wg(a)ripe.net; Barbara t.H. Farrell
> Subject: Re: PAB ISO 3166-based Top Level Domain Survey
>
>
> At 05:55 PM 6/19/98 +0200, Robert Shaw wrote:
> >At http://www.itu.int/net/cctlds/nics.htm is a preliminary survey
> >conducted by ITU of Internet ISO 3166-based top level domains.
>
> Dear Bob: Where has this file been moved? Regards, BobC
>
> .nt is not on this list but I know it exists.
If it does, it shouldn't. It's not part of the ISO 3166
standard. NT (Neutral Zone) is on the ISO 3166 transitional
reserved phase-out list which means don't use it.
Bob
Hi,
At http://www.itu.int/net/cctlds/nics.htm is a preliminary survey
conducted by ITU of Internet ISO 3166-based top level domains. The
material is in in draft form and is made available in order to solicit
public comment. Information includes all known URLs for registration.
While every attempt has been made to ensure accuracy, the information
cannot be considered authoritative as the Internet Assigned Numbers
Authority (IANA) is the authoritative source for ISO 3166-based
top level domain delegation information. All raw data gathered has
been and will continue to be provided to IANA.
Comments and/or corrections on these pages should be sent to
Ms. Asa Johansson at <asa.johansson(a)itu.int>.
Denominations and classifications employed in this publication do not
imply any opinion on the part of the ITU concerning the legal or
other status of any territory or any endorsement or acceptance of
any boundary.
Thanks,
Robert
--
Robert Shaw <robert.shaw(a)itu.int>
Advisor, Global Information Infrastructure
International Telecommunication Union <http://www.itu.int>
Place des Nations, 1211 Geneva, Switzerland
Dear working group members,
I apologize for sitting a bit too long on Vesna's draft minutes for the
Budapest session. Vesna did a really good job; please find the draft
below.
I'll wait for comments until Sept. 30th. So the draft is expected to become
final on October 1st.
I'm sorry that some problems in my day job escalated yesterday evening in
ways so that today in the early morning it turned out that there would be
no way to make the planned trip to Amsterdam safely and in time.
(There is a down side to having the conference locally - or "within short
driving distance":-(
I hope those attending the current meeting do have a good time;
looking forward to see you again at future meetings.
Regards,
Ruediger
Ruediger Volk
Deutsche Telekom AG -- Internet Backbone Engineering
E-Mail: rv(a)NIC.DTAG.DE
Phone: +49 251 7985 200 fax: +49 251 7985 109
DNS Working Group
RIPE #36, Budapest
18 May 2000
Chair: Rudiger Volk
Scribe: Vesna Manojlovic
Agenda:
0. Agenda bashing
1. David Conrad, ISC: BIND 9
2. Bill Manning: Preparing for DNS evolution
-=-
coffee break
-=-
3. Report from CENTR DNSSEC workshop
4. IETF - Randy Bush
5. AOB
5.1. Fernando - Document about re-delegation
5.2. RIPE documents published since the previous meeting
1. David Conrad gave quick update of current status of BIND
BIND9
* complete rewrite of code
* includes support for everything
- full IPv6 support
- DNSSEC support
- not supporting EDNS1
- multi-lingual support
- MS interoperablity
* RFC compliant (first time, cheers from the audience :)
- first time it has lots of documentation :)
* 1.2 mil $ to develop
* release - 30.6.
* availability now - beta
David was asking the audience for help :
- to support INN (BIND and DHCP are supported by Nominum)
- from people with NT experience to debug NT port of BIND 8.2.3
- to test BIND9
- performance
- IPv6 support in BIND 9
- DNSSEC
2. Bill Manning -- Wither DNS?
PPT presentation available on
http://www.ripe.net/ripe/meetings/archive/ripe-36/presentations/
Current assumptions:
- constant MTU
- ASCII
- BIND (UNIX based)
- single authority (server)
- hierarchy
- zone management
- static behaviour (client)
- merged server and resolver
- reachability: reliable network (up, end-to-end)
On the horizon:
DNSsec
IPv6
dynamic DNS
integration with other applications - database back-end
(LDAP,Oracle,mail) I18N (internationalisation)
DNS version diffusion survey Q&A session:
Q: how is this taken?
A: exhaustive search of inaddr tree.
Q: is it biased?
A (audience): it is security biased! they are not responding if
they are security conscious => shows higher % of vulnerable
Q: how big is the percentage of the servers that are blocked by
firewall and therefore not included?
A: few years ago - 20%. recently - 25%
Conclusion: people are moving into new code but not (as) fast (as ... )
Discussion about IPv6 inverse tree
Randy Bush: Is IPv6 inaddr tree going to be set-up separately?
(rfc 2826)
Bill: That is the suggestion (to use separate set of root nameservers)
Randy: That would cause technical and other problems. Other
possibility is to take one of existing root servers.
-= coffee break =-
3. Report from DNSSEC workshop
Workshop was initiated by CENTR, held in NLnet labs in Amsterdam.
One report was already done by Jaap Akkerhuis in CENTR DNR-wg;
technical report - here.
The goal was to check resources needed for introducing DNSSEC on the
level of TLD zones.
Result of the previous previous attempts was: it is still hard
work, not feasible at this time. This new workshop gave different
results.
In Europe, .de tld zone is chosen as the worst case. Experiment
was done with off-the-shelf PC, with extra large memory.
"Signer" software was provided by Nominum.
Two test runs were done:
1. on original data
signing -- ~ 14 hours CPU time
expansion factor of 4.4 (of adding all the dnssec data)
2. modified zone
(taken out mx & A records; left just ns)
runtime -- 3.2 hours of CPU time
117 mb -> 380 mb, so expansion factor a bit lower (3.2) for
smaller base data
Conclusion: you need some resources, but it's within the reach of
current hw and sw.
the few people with much larger zones will have more work -
but it can be assumed they'll have more revenues.
Q: Does it mean a recommendation to DEnic to get rid of mx only
domains?
A: yes
Q: Compared with Swedish workshops?
Liman: different, smaller results. Bigger times & data. Used
signer from bind8.
Q: What do you consider normal zones?
A: Less then a million records. (.de = 3,000,000 RR)
Liman: Does it make a difference if you have to include ns or mx/a
records?
David: Not significant.
David: Wildcards in the sign zone makes signing 2 orders of
magnitude more difficult. We don't support them!
Liman: Only in DNSSEC?
David: Yes, only if you try to sign them; we either ignore them or
generate an error.
4. Randy Bush: DNS from IETF perspective
What features are important?
For a log time, specifications were stable, code was fairly
unstable. Now we are in period when specifications are fairly
stable, and the code is little unstable.
The increased features that are being specified will cause code
instability that will last forever (you can't have all this sugar
and not be unhealthy).
Main new features: security / DNSSEC & multi-lingual support / IPv6
Security problem:
For example: the size of the root zone sign becomes larger then
bits in the MTU of the standard UDP packet and therefore all the
sessions will fall back to TCP and cause 6 times bigger amount of
traffic.
Multi-lingual problem:
It's not really the DNS problem, but application problem - what is
my web browser going to be able to read. i like to call it not
internationalisation but localisation, which can cause that our
customers not able to do e-commerce with Japanese customers
David: stability of the code: bind9 _designed_ and not _evolved_ ;
therefore more stable. architectured much better.
Bill: operational community has to find the way to provide the
feedback to engineering community. this forum might be a right
place for it.
Randy: yes - we need operators back in ietf. protocols became
designed without taking a consideration operational issues.
David(?): ietf is quite large cumbersome. having smaller groups of
operational people come to some consensus, and then having
spokesperson is probably a better solution.
Chair: in communities like this there is opportunity to keep
information flow in both directions.
The survey was conducted by Bill to check who is using which
version of BIND.
Results: [ ]
5.1. Document about re-delegation
Draft paper on how to help re-delegation was presented in RIPE #33
in Vienna by Fernando [ ].
Paper was describing the case of DNS transfer of customers from
one ISP to another - how that can be done without losing the
service, how to minimise problems, including variations of cases
of (non)cooperating ISPs.
Help is needed about transfer procedures in ccTLD zones other then
.es .
Question from the audience: Wouldn't CENTR think they should take
part in it? Since large amount of these re-delegations problems
are from ccTLD registrars.
Chair: Indication of involvement should come from CENTR. However,
administrative procedures in many registrars are much worse then
they should be; we should push CENTR in the right direction.
Liman: There should be one document describing technical issues
(in which order what.. ), which are the same all over the world;
then, what are the implications of administrative models; and in
the different part of the same document, point to possible
pitfalls.
ACTION on Fernando to sent index/draft to the DNS-WG mailing list;
make appendix about procedures in the registries/registrars that
we know about.
5.2. RIPE documents published since the previous meeting
- Recommendations for DNS SOA Values (RIPE-203)
- Simple DNS Configuration Example (RIPE-192)
There is work in progress on more detailed documentation. Peter
Koch was encouraged to work more on it.
Chair invited everyone to express their need for new documents.
Q: There is confusion about old and new minimum value in bind4
and bind8.
Liman: Dummy guide is meant for "the newest version of BIND".
Comments about other versions are welcome, but should be published
as separate document.
--==_Exmh_9077542070--
Hello all
In the last RIPE meeting I made a proposal for a document that would help
hostmasters to change domains between ISPs, carriers, etc.
Included in this message is a draft version of that document. Is not
perfect, but I think is a good starting point that can be completed by all
the members of the WG.
Regards, Fernando Garcia.
--------------------------------------------------------------------
Fernando Garcia | Email: fgarcia(a)eurocomercial.es
EuroIDT - Eurocomercial | Tel: +34 91 435 96 87
Internet Development Team | http://www.eurocomercial.es/
--------------------------------------------------------------------
