October 2004 - dns-wg - mailman.ripe.net

IPv6 access to K-root
by Andrei Robachevsky 28 Feb '05

28 Feb '05

Colleagues, K-root server has now IPv6 transport enabled. k.root-servers.net. AAAA 2001:7fd::1 A 193.0.14.129 This information is also available from www.root-servers.org webiste. Regards, Andrei Robachevsky RIPE NCC

10 17

Re: ORSN-SERVERS.NET
by Markus Grundmann/ORSN 25 Jan '05

25 Jan '05

>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'm very happy about this posting ;-) 76 copies of an single database source managed by an organization outside from europe and controlled by the U.S. DOC. Great! When it comes the master corrupt all AnyCast servers will use this information. Very great and very stable! ORSN is an DNS system with all the same information provided by ICANN. The difference: We have our own managed and independent database!!! In few days you will found an tool to compare the ORSN database with the ICANN root servers in realtime on our homepage. Some people wrote (not here): "ORSN is not transparently enough!" Sorry! But I must laughing about this words. We do provide all needed information for interested users. Peoples must read our homepage carefully before any can write this. Notice: The independent mode of ORSN was implemented to disable the automatic synchronization of the database. Regards, Markus Grundmann ORSN, Open Root Server Network Germany

10 13

ripe policy about reverse dns?
by Peter Gervai 01 Nov '04

01 Nov '04

Hello, I tend to remember that RIPE had a strict policy about delegated address space reverse DNS: adresses must have a valid reverse and delegated (sub) blocks must be registered in RIPE db. I wanted to refer to the document mentioning these requirements but I was not able to find them. Navigating on www.ripe.net helped nothing: reverse dns part shows the procedure, refers to a page "about ripe policies" which contains only links to RFC and other RIPE documents, which in turn are about the procedure and not any policy. Maybe there are any hidden one mentioning that "you should have reverse on your addresses" but I kindly ask your help where to look for it. If this requirement would have been dropped then I'd be extremely happy to know about it. Thank you, Peter ps: Reason is a(nother) big provider with many /19 and with no reverse or RIPE entry (other than the /19) whatsoever, and occasional spam from these reverseless and nameless blocks.

2 1

Re: [dns-wg] Re: ORSN-SERVERS.NET
by Jim Reid 28 Oct '04

28 Oct '04

>>>>> "Jon" == Jon Lawrence <jon(a)lawrence.org.uk> writes: Jon> Maybe I'm thick, but I still don't get it. What is the Jon> advantage of ORSN over the ICANN root ? I have no idea. However this list is not the place to discuss this topic further. It's essentially a local policy matter and is therefore inappropriate for the DNS WG. If someone wants to set up a mailing list to debate this, please go ahead and do so. Tell us where it is and how to subscribe and unsubscribe. Other than that, I would appreciate it if the discussion of alternate roots stopped in this list. Thanks.

2 1

Jumping the gun on SIDN!
by Pim van Pelt 28 Oct '04

28 Oct '04

Hi, With some relief and pride, I'd like to show you that the dutch registry SIDN has enabled their registrars to offer IPv6 glue. One can send in a request using a freeform ticket. I happen to have been the first, so since todays serial of 200410280, there are new records in the nl. zone. Yaay! ; <<>> DiG 9.3.0 <<>> @ns.domain-registry.nl NS bit.nl. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1989 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 6 ;; QUESTION SECTION: ;bit.nl. IN NS ;; AUTHORITY SECTION: bit.nl. 86400 IN NS nsauth1.bit.nl. bit.nl. 86400 IN NS nsauth2.bit.nl. bit.nl. 86400 IN NS nsauth3.bit.nl. ;; ADDITIONAL SECTION: nsauth1.bit.nl. 86400 IN A 213.136.12.51 nsauth2.bit.nl. 86400 IN A 213.136.12.59 nsauth3.bit.nl. 86400 IN A 212.204.192.11 nsauth1.bit.nl. 86400 IN AAAA 2001:7b8:3:2c::53 nsauth2.bit.nl. 86400 IN AAAA 2001:7b8:3:2d::53 nsauth3.bit.nl. 86400 IN AAAA 2001:898:1001:1003::53 ;; Query time: 46 msec ;; SERVER: 193.176.144.2#53(ns.domain-registry.nl) ;; WHEN: Thu Oct 28 13:04:59 2004 ;; MSG SIZE rcvd: 222 The dutch registry will implement and enable IPv6 in their infrastructure also, so I'm told by SIDN. -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E)

2 1

Re: [dns-wg] Re: ORSN-SERVERS.NET
by JFC (Jefsey) Morfin 28 Oct '04

28 Oct '04

At 21:57 24/10/2004, Jay Daley wrote: >Markus >Markus wrote on 22/10/2004 12:26:13 pm: > > > We are only the > > european (independent) copy of the stable ICANN root server system :-)) > >I really do not understand this. How are you in anyway more independent >than k-root or i-root? Jay, I will try to review this key point for the internet development. what ORSN does is risk containment. Suppose the ICANN/NTIA root is hacked. The ORSN file is not affected. This provides a protection. Now, obviously, if the delay in updating the ORSN file is too long it is going to pollute the namespace with old data. This is why trouble shouting calls for a report on possible differences. Such report must be taken both ways: - a way to know that ORSN is outdated - an alarm that the ICANN/NTIA root may be hacked. This kind of issue has been identified by the dot-root project of a DNS test bed we carried last years. This has lead us to work on local roots concepts and eventually on the authoritative root matrix (which is not documented, but implemented in reality through the additional name servers entered in the top level through ccTLD db.files for example). This also lead to the AFRAC project (http://afrac.org) to unlock root files (like the ICANN/NTIA root file) as this is true for any other application root file, through contextual root files for what we named "externets" (ie an external global view of the internet). For example, a Japanese externet can be all the users and hosts which freely chose to belong to it. End to end relations may then be limited to these externet members (only people able to read Japanese). You can belong to many externets. In the case of a nation, we identified that a national externet is a regalian duty. What does that mean? It means that many things may happen which affect your sure national use of the DNS. In 99.99% of the case that you use an US, a French, an European or a East-Timor root server is the same. But in critical occasions you will want to use a nameserver which will follow the rules which protect your skin. We developed this kind of thinking in parallel to the White House - we proposed ICANN to work on an "ICP-4" document on netsecurity in December 2001 at the DNSO/BC with a few large operators and corporations,. We then introduced the dot-root project to work on this along the lines of the ICP-3 document which investigates the possible end of an authoritative file and defines the conditions for test bedding we stick to [we added a few]). The White House (Dick Clarke) worked along the same lines after 9/11 and came with a very powerful evaluation showing that the internet represented a nuclear equivalent risk to the USA through the vulnerability of critical infrastructures and the impact on the US economy and way of life of a major dysfunction. We could measure it through the impact of the East Coast Black Out - should it have happened in Feb blizzard, the impact would have been devastating. This eventually lead to the http://whitehouse.gov/pcipb national strategy, the first visible impact we all know is the DoD IPv6 commitment. Let imagine that a terrorist atomic bomb blows Washington-West (the top worldwide target and an US working hypothesis). The propagation through the internet would be times devastating than the bomb itself on the USA. Regalian US duty will be to reserve most of the remaining internet bandwidth to civil security information and economy protection. P2P, adult, etc. traffic will not be a priority. The DNS is the control tool. We do not want to suffer from that in Europe or in the rest of the world, because there is no reason and because it would propagate the terror (and make the attempt more attractive and therefore more likely). So an European regalian duty is DNS risk containment, to protect us from the results of an attack of the US and to protect the US from being attacked. This is a very common strategy in network security. This means that every Gov has a regalian duty, not to load the ICANN/NTIA file, but to copy it like ORSN does. This copying must be carried with a take-over procedure to cope with a special national situation. A critical problem may be local. Or there may be an external attack. Let for example consider the Iraq invasion and the ".iq" management. The USA attacked ".iq" through spam DoS and lead Iraq to stop all their servers. An Iraqi externet would have made the Iraqi machine to switch to the Iraqi root they could have build the way they wanted (this same externet reasoning applies to IPv6 addresses and national numbering zones we support and document for years and the ITU now openly investigates - please remember that ITU is not an "internet opponent" but the Rep of regalian concerns). A very common hypothesis is a "Tchernobyl" like incident. TV waves pollution will make ADSL screens the best way to inform and calm the people through stable screams, with a major user demand peak. The control of the DNS would be vital. Another interesting point is that published reports are that only 2.5% of the root calls are legitimate, addressing based externets are a way to protect users at peak critical times. Their support in IPv6 numbering plan is a regalian demand that we should see develop in the coming months. It is also a network security issue to avoid pollution of the DNS in such cases. Obviously this is not the only resulting user architectural changes implied by the ICANN ICP-3 and WSIS real world consequences, as some mails documented it about DNS database usages. jfc morfin

6 5

Re: [dns-wg] Re: ORSN-SERVERS.NET
by Jim Reid 28 Oct '04

28 Oct '04

>>>>> "JFC" == JFC (Jefsey) Morfin <jefsey(a)jefsey.com> writes: JFC> what ORSN does is risk containment. Suppose the ICANN/NTIA JFC> root is hacked. The ORSN file is not affected. This provides JFC> a protection. Could I please have some of whatever drugs you're taking? :-) IIUC this ORSN nonsense uses the root zone file as a starting point. So presumably any errors that get introduced there will be passed on to ORSN and its fellow travellers, no? JFC> Let imagine that a terrorist atomic bomb blows JFC> Washington-West (the top worldwide target and an US working JFC> hypothesis). The propagation through the internet would be JFC> times devastating than the bomb itself on the USA. First of all, I think most people would accept that any loss of life is far, far more devastating than the ability to route packets and make DNS lookups. Secondly, the root zone doesn't change much: TLDs renumber one of their servers now and again. Even if a major catastrophe destroyed the ability to change the root zone for a while -- I very much doubt that -- this would at worst be a minor inconvenience for TLD operators and the DNS in general. Good TLD managements will keep the old name servers running for at least a month or two after a renumbering. In fact a strong case can be made for NOT changing the root zone after such an event for stability reasons. Finally, suppose Something Bad has happened and the root can't be changed. Why would a TLD then choose to update their info in this bogus ORSN root while the info in the real root was unchanged? Wouldn't that lead to precisely the sort of inconsistency and network partitioning that the ORSN people claim they want to avoid?

2 1

Analysis of NSD
by Jim Reid 28 Oct '04

28 Oct '04

>>>>> "Stephane" == Stephane Bortzmeyer <bortzmeyer(a)nic.fr> writes: >> Well, for NSD, using large zones will cause it to eat memory >> exponentially. Stephane> Here is the NSD maintainer's analysis: Stephane> http://open.nlnetlabs.nl/pipermail/nsd-users/2004-October/000276.html While there is no reason to dispute the analysis from NSD's authors, I do think it would be nice if there was an independent analysis of NSD. And other DNS implementations for that matter. The work Brad did a couple of years ago was a step in that direction. I would also encourage operators to share their experiences of different name server implementations here: performance, protocol compliance, features, management & support issues, SLAs with hosting providers, etc, etc. Capturing and documenting this anecdotal information would be very useful.

5 9

Re: [dns-wg] Re: Elimination of 2nd level ccTLD domain names
by Piet Beertema 28 Oct '04

28 Oct '04

> > I think that's the scale of problem that is facing us with a flat > > .eu zone, and far more rapidly than anyone here is giving credit. > >my impression is we're about to enter an infinite loop. That in fact is the case already. >While still you might be right, we would now have to discuss growth >rates based on market potential etc. Now you hit upon an interesting issue. In NL we were more or less forced a couple of years ago to open up registration for private persons too, the reasoning behind it being 'fixed' e-mail addresses even when people moved to another ISP, which happened frequently. Initially we 'solved' this by introducing numeric SLD's (123.nl), under which they could register names. That was not a success, to put it mildly: all in all we registered less than 1000 domains of that kind. Main reason: people didn't like the numeric "extension". More recently .NL itself was opened up for private persons too, but now we see a vastly different situation from a couple of years ago: because of the massive amounts of spam 'fixed' addresses are not en vogue anymore and lots of people have loads of addresses. Which is just one reason why I don't expect TLD's to explode and a good example of a problem that solves itself. Piet

2 1

NOTIFY
by Jim Reid 28 Oct '04

28 Oct '04

>>>>> "Johan" == =?ISO-8859-1?Q?Johan Ihr=E9n?= <ISO-8859-1> writes: Johan> i.e. that way you compromise synchronicity (is Johan> there such a word?) There is. It means to agree in time or to have the property of agreeing in time. The extract from Wikipedia is appropriate: For the album by The Police see Synchronicity. Synchronicity is a term that was used by the Swiss psychologist Carl Jung to describe the alignment of universal forces with one's own life experience. Jung believed that some (if not all) coincidences were not mere chance, but instead a literal "co-inciding", or alignment of forces in the universe to create an event or circumstance. For most of the people here, I suppose their life experiences are aligned with the universal, not mere chance forces of consistent DNS data. :-) Johan> PS. I choose the word synchronicity rather than coherence, Johan> because as long as each slave publish exactly the same data Johan> for the same SOA serial they are technically coherent (to Johan> the version of the data they *have*) although they may be Johan> temporarily out of sync (with slaves having acquiered more Johan> recent data). Hmmm. Your suggestion of synchronicity works given the definition above. However I would have called that coherence: two or more servers publishing identical data for a given SOA serial. The name servers would be consistent if they all had the same data and SOA serial. But consistency usually has another meaning in the DNS: the same query always gets the same answer no matter where the query is made from. So perhaps strict consistency could mean when all authoritative servers have identical data for some zone. It doesn't really matter what terminology we use. Just as long as we agree on its meaning. "When I use a word, it means what I want it to mean." The quote's from Alice in Wonderland I think.

1 0

NOTIFY
by Jim Reid 28 Oct '04

28 Oct '04

>>>>> "Peter" == Peter Koch <pk(a)TechFak.Uni-Bielefeld.DE> writes: >> As it happens we use probing not NOTIFY since it gives a >> greater level of control over the number of secondaries being >> updated at once (and the Peter> NOTIFY already specifies precautions against a 'rush', Peter> although implementations may differ and depending on the Peter> size of the zone 'at once' may have different meanings. Yes. But BIND's implementation of this feature is meant for the case when there are lots of zones that get changed and reloaded. [And there are no control hooks for setting the delay interval IIRC.] The server staggers the sending of NOTIFYs to reduce the potential for an axfr storm. The feature doesn't really help when there's a huge zone. Like co.uk... >> bandwidth) and the order in which they are updated. This does >> rely on strict calculations of the timings of changes and >> probes but that is fairly easy to do. Peter> How about sending the NOTIFY messages out of band instead Peter> of relying upon retry (and not refresh?)? There's a little Peter> 'DoS' potential, though. How about rndc refresh or rndc retransfer in 9.3? It's not really an out of band NOTIFY, though the effect is the same. Note the new Subject since this thread isn't talking abouut an analysis of NSD any more.

1 0

Elimination of 2nd level ccTLD domain names
by Hank Nussbacher 27 Oct '04

27 Oct '04

I'm new to this particular WG but I'd like to raise an issue that I feel is best discussed in a European DNS forum. It has to do with .eu: <http://europa.eu.int/information_society/newsroom/cf/itemlongdetail.cfm?ite…> According to my understanding, there will be direct 2nd level domains - like ibm.eu or ripe.eu or even tonyblair.eu. Up till now, most countries employed a hierarchical structure such as ac.xx or co.xx or org.xx. What do we lose by eliminating 2nd level domains? Since .eu is a totally new TLD - perhaps not much, but what happens to countries that then decide to follow the same path as Singapore recently did (they are cc'ed to this email): http://www.nic.net.sg/newsroom/20040816030345.html Are there any limitations to what a 2nd level domain name can be (not referring to trademarks)? I.e. would a single digit or letter be allowed? Would co.sg be allowed (up till now com.sg was the main commercial 2nd level domain)? Are other countries considering following the same path? Thanks, Hank

14 29

name servers with database back-ends
by Jim Reid 27 Oct '04

27 Oct '04

>>>>> "Jaap" == Jaap Akkerhuis <jaap(a)NLnetLabs.nl> writes: Jaap> The drawback of using a direct database back-end is that Jaap> this means that are close ties between the nameserver and Jaap> the database. If one of the two fails, you have a problem. Indeed. The database back-end becomes a SPoF. To some extent that can be mitigated by the fancy high-availability replication techniques that the likes of Oracle & Sybase offer. For a fancy price of course. Since SPoFs in the DNS are bad, I would hope important zones ran on homogeneous DNS implementations with identical hardware, OS and system administration. So if a TLD did use a name server with a database back-end, I hope they'd couple that with something like dynamic updates to a DNS hosting provider that ran a different implementation. And maybe did anycasting as well. I compare loading Gb-sized text zone files to teaching an elephant to ballet dance. It can be made to work if sufficient energy is expended though the results are not pretty.

1 1

Re: [dns-wg] Announcement: "DNSSEC HOWTO"
by Jim Reid 27 Oct '04

27 Oct '04

Olaf, thanks very much to you and your colleagues for producing this. I wonder if it would be appropriate to have this published as a RIPE document. Any comments from the WGs?

1 0

Announcement: "DNSSEC HOWTO"
by Olaf M. Kolkman 27 Oct '04

27 Oct '04

Dear Colleagues, [Apologies for duplicates] We are happy to announce the availability of a "DNSSEC HOWTO" at: http://www.ripe.net/disi/dnssec_howto/ (html) http://www.ripe.net/disi/dnssec_howto/dnssec_howto.pdf (pdf) The document forms part of a RIPE NCC project on the deployment of DNSSEC and describes how to set up DNSSEC. The HOWTO covers the following topics: * Part I, 'Securing DNS data', about the aspects of DNSSEC that deal with data security. * Part II, 'Securing communication between Servers', covering aspects that deal with server to server security and transaction security. The document is based on the so-called DNSSEC-bis specifications that where finalized by the IETF and are now in the RFC editors queue [I-D.ietf-dnsext-dnssec-intro, I-D.ietf-dnsext-dnssec-protocol and I-D.ietf-dnsext-dnssec-records]. This document will be subject to change. Please regularly check for new versions at: http://www.ripe.net/disi. Your corrections and additions are appreciated. ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC

1 0

Re: [dns-wg] Elimination of 2nd level ccTLD domain names
by Jim Reid 27 Oct '04

27 Oct '04

>>>>> "Tim" == Tim Deegan <tjd-dnswg(a)phlegethon.org> writes: Tim> No, but it's relevant. The reason for refusing to register Tim> two-letter SLDs is to avoid having SLDs that are the same as Tim> existing or future (cc)TLDs, which would aggravate the Tim> search-list problem: Tim> "This is clearly unacceptable. Further, it could only be Tim> made worse with domains like COM.EDU, MIL.GOV, GOV.COM, etc." In that case, perhaps someone could start a thread on Why Search Lists Are Evil? Maybe then we could finally bring this discussion to a close. As Peter already said, how a TLD structures its name space (or not) and determines what names can be registered there is a local policy issue. It is not an appropriate topic for this list or the WG. Let's suppose the WG considered this subject, reached consensus and published a RIPE document. [Yes, I know this is fantasy but bear with me.] Would any TLD care? Would they annoy their users by forcing them to rename already registered domains to comply with this document? The reality is there already are lots of SLDs in use today that have labels that are TLDs. <TLD>.com exists for just about every TLD, including com.com. (Sigh.) If this creates problems for broken resolvers and unwise search lists, then the way to fix that is to solve the underlying misconfigurations. Tinkering with the name space or treating some labels as "special" is the wrong approach. I now ask everyone to please stop posting on this thread. The discussion is not appropriate for this list and isn't a suitable subject for the WG. If you disagree with this, please send mail to dns-wg-chair(a)ripe.net -- not this list! -- explaining why the discussion should continue and its relevance to the WG.

1 0

Re: [dns-wg] Elimination of 2nd level ccTLD domain names
by Jim Reid 27 Oct '04

27 Oct '04

>>>>> "Jay" == Jay Daley <td(a)nominet.org.uk> writes: >> However the trend seems to be for using database back-ends to >> feed the name servers: BIND-DLZ, UltraDNS, ATLAS, ANS, >> PowerDNS, etc, etc. A database is the right solution for this >> problem when there's lots of data to look after. Most >> registries are already using a database for their customer data >> so it should be a no-brainer to couple that to their name >> servers. Just think of all the legacy perl and SQL scripts that >> could be eliminated..... Jay> I'm not so sure that I agree with this. I think there is Jay> quite a lot to think about here and databases are not Jay> necessarily the best solution. Jay, I think you have misunderstood me. Or I didn't make myself clear enough. You're quite right. Using a database back-end for DNS service introduces a lot of interesting issues such as throughout, how replication gets done, consistency between the database and any in-core cache, the database becoming a SPoF, etc, etc. However the initial discussion was about restructuring the name space because large flat zone files were felt to be harder to manage than introducing second- or third-level domains. In that context the problem is essentially one of data management. Which would already be handled by the database that any sizeable registry will be using for their customer data. That said, I do believe that huge text files for zone files and name server configurations will eventually move to some sort of database back-end. This is the direction that most DNS implementations seem to be moving towards. Some TLDs have already adopted this approach and I'd be surprised if others didn't follow.

2 1

Re: [dns-wg] Elimination of 2nd level ccTLD domain names
by Piet Beertema 27 Oct '04

27 Oct '04

>COMMISSION REGULATION (EC) No 874/2004 of 28 April 2004 >http://europe.eu.int/cgi-bin/eur-lex/udl.pl?REQUEST=Seek-Deliver&LANGUAGE=e… > >where - amongst other names - the 2 character codes of existing countries >(article 8) are blocked Which is short-sighted. What's the use of blocking only *existing* ccTLD codes, when nobody can foresee what new ccTLD codes may come to exist in the future? We've seen enough recent examples... Piet

7 18

Re: [dns-wg] Re: Elimination of 2nd level ccTLD domain names
by Jim Reid 26 Oct '04

26 Oct '04

Brad, this discussion is not achieving anything. Please stop. If/when zones get to the size that they present operational or management problems, solutions to those issues will be available, They are already available today. [Moore's law will mean cheaper and bigger RAM chips (and CPUs), 100Gb+ disks are becoming the norm and there are plenty of 64-bit architectures and Operating Systems.] Which solution or solutions a TLD registry adopts will be their decision. Having a structured name space won't make much difference: it just moves or defers the pain points.

1 0

Re: [dns-wg] Elimination of 2nd level ccTLD domain names
by Jim Reid 25 Oct '04

25 Oct '04

>>>>> "Brad" == Brad Knowles <brad(a)stop.mail-abuse.org> writes: >> # perl fpdns.pl udns1.ultradns.net udns2.ultradns.net >> fingerprint (udns1.ultradns.net, 204.69.234.1): UltraDNS v2.7.0.2 -- 2.7.3 >> fingerprint (udns2.ultradns.net, 204.74.101.1): UltraDNS v2.7.0.2 -- 2.7.3 Brad> That doesn't necessarily mean anything. If they had Brad> been a large customer of Nominum, they could easily be Brad> running code that generated a different fingerprint. Nope. Roy and Jakob's tool can already fingerprint Nominum's DNS implementations. And just about anyone else's for that matter. Besides, I very much doubt if anyone would create a code fork and all the aggravation flowing from that -- support overheads, regression testing, documentation, software maintenance, etc -- just to confuse a fingerprinting tool. And of course the tool could easily be updated to take account of any obfuscation like that. Why would anyone choose to enter that zero-sum game? Brad> When it comes to this sort of thing, I trust Brad> information from people who have extensive background Brad> information (such as Jim) than I do fingerprints. You'll be much better off to trust this fingerprinting tool than depend on my memory. :-)

2 1

Re: [dns-wg] Elimination of 2nd level ccTLD domain names
by Jim Reid 25 Oct '04

25 Oct '04

>>>>> "Brad" == Brad Knowles <brad(a)stop.mail-abuse.org> writes: Brad> I have been talking about nothing *but* ccTLDs in Brad> Europe, and how this flat namespace model will not continue Brad> to scale. Brad, you're being silly. The only real constraint on scaling will be the availablity of names to register. That is inherently self-correcting by the market place. People will register names in a given TLD for as long as they perceive those registrations to have some meaning and value. Whether that limit is reached after 1 name or 1 billion names is irrelevant. Sure, as the registrations increase, the operational problems and data management issues for the registry will increase. But so too will the amount of money and other resources needed to solve those problems. >> Plus the fact that a generic, worldwide and *flat* TLD like >> .com still hasn't grown such as to become unmanageable? Brad> It has grown to the point where it is not manageable. Brad> It was unmanageable a long time ago, and things have been Brad> going further down the toilet ever since. This will come as a big surprise to the tens of thousands of people who register or renew .com domain names every day. And to the folk at Verisign's registry. FYI, the gtld-servers.net run ATLAS, Verisign's own DNS implementation. It has a database back-end and does multi-site replication. Rapid propagation of changes is easy. Verisign no longer generate a 1-2 Gb zone file and load it into BIND servers twice a day. If they did, your point about the manageability of .com might have some credence. Brad> And you're going to have a problem that will be an Brad> order of magnitude larger than .com. So what? To get to that problem, the zone would have to have an order of magnitude more registrations than .com has today. Assuming .eu was ever be that popular, which is at best a highly debatable assumption. Let's do some back of the envelope calculations. A zone that was an order of magnitude as big as .com would have around 200M entries. At 5 Euro/registration/year -- comparable to the wholesale prices most TLD registries charge today -- this would yield an annual income of 1B Euro. With that amount of money at the .eu registry's disposal, any hardware or software limitations in their DNS (related) operations could be solved from petty cash. I can't be alone in wanting to have as little as 1% of that sort of budget to solve DNS problems. :-)

1 0

Re: [dns-wg] Elimination of 2nd level ccTLD domain names
by Jim Reid 25 Oct '04

25 Oct '04

>>>>> "Brad" == Brad Knowles <brad(a)stop.mail-abuse.org> writes: Brad> Oh, wait -- they bought the business from Nominum, who Brad> was using ANS for their customers, and UltraDNS almost Brad> certainly still using ANS today.... Sorry Brad you are quite wrong. UltraDNS have never used Nominum's ANS. However there was a brief transition period after the GNS hosting business was sold when GNS customers still used its ANS-based service until they got migrated to the UltraDNS platform. Even then, I'm fairly sure that Nominum remained in control of the GNS infrastructure throughout that migration exercise. My understanding was that UltraDNS was primarily interested in the GNS customer base. Besides, since they already had their own DNS implementation they had no real need for Nominum's ANS. UltraDNS didn't need the GNS infrastructure either, since they already had their own. To the best of my knowledge UltraDNS has always run its hosting service on its own DNS implementation.

2 1

Fwd: Mail delivery failed: returning message to sender
by Piet Beertema 24 Oct '04

24 Oct '04

No comment... Piet ----- Forwarded Message ----- This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: jim(a)rfc1035.com SMTP error from remote mailer after MAIL FROM:<Piet.Beertema(a)cwi.nl>: host gromit.rfc1035.com [195.54.233.67]: 550 5.0.0 Mail from spammers is refused - get lost. ----- End of Forwarded Message -----

1 0

HEAnet comments on Future of RIPE Hostcount Document
by Brian Nisbet 22 Oct '04

22 Oct '04

Hi, These are some comments that HEAnet would like to submit on the "Future of the RIPE Hostcount" Document presented at RIPE 49. - perhaps the paper should refer to the current distributed nature of the host count; this is something which might or might not be possible with the alternatives suggested - the current host count also gathers the numbers of SOAs, also a measure of the size and growth of the Internet - and the host count also generates an error file per TLD; this could be useful in maintaining the integrity of the DNS - in #2.1, I think attribution should be made to the author of the host program, the late Erik Wassenaar. - in #2.2, it should be said that the RIPE host count is used as a metric of Internet size, and an index of its growth. Certainly, we use it in HEAnet. - it might be argued that the host count also could provide some KPIs (key performance indicators) for RIPE NCC, its members, and other bodies - in #2.3, it mentions used addresses not entered in the DNS. The converse also occurs i.e. A records for hosts which are not reachable. We know that some people use the DNS as a database and that it often includes firewalled machines and even rfc-1918 addresses - in #3, another possibility to estimate the size of the Internet is to measure the number of domains. This might be done by the CC TLDs in Europe, for example Regards, Brian. -- Brian Nisbet, HEAnet, Brooklawn Hse, Crampton Ave, Shelbourne rd, Dublin 4. Tel:+35316609040/Fax:+35316603666 email:brian.nisbet@heanet.ie

2 1

Re: ORSN-SERVERS.NET
by Marco Huggenberger 22 Oct '04

22 Oct '04

Hi Folks! Markus Grundman, founder of the ORSN project has asked me to post the following: "Dear list members! ORSN is not transparently enough? Sorry! But I must laughing about this posting. We do provide all needed information for interested users. You must read our homepage carefully before you can write about our project. The independent mode of ORSN was implemented to disable the automatic synchronization of the database. Regards, Markus Grundmann ORSN, Open Root Server Network Germany" A detailed view about network/server transparency is and was always available at: http://european.ch.orsn.net/servers.php If you have any questions about ORSN, please feel free to contact us directly on our mailinglist: http://european.ch.orsn.net/lists.php Cheers Marco Huggenberger Init Seven AG, Switzerland AS13030 Operator of the ORSN Root Server H

1 0

Re: ORSN-SERVERS.NET
by Marco Huggenberger 22 Oct '04

22 Oct '04

Hi Folks! Markus Grundman, founder of the ORSN project has asked me to post the following: "Dear list members! ORSN is not transparently enough? Sorry! But I must laughing about this posting. We do provide all needed information for interested users. You must read our homepage carefully before you can write about our project. The independent mode of ORSN was implemented to disable the automatic synchronization of the database. Regards, Markus Grundmann ORSN, Open Root Server Network Germany" A detailed view about network/server transparency is and was always available at: http://european.ch.orsn.net/servers.php If you have any questions about ORSN, please feel free to contact us directly on our mailinglist: http://european.ch.orsn.net/lists.php Cheers Marco Huggenberger Init Seven AG, Switzerland AS13030 Operator of the ORSN Root Server H

1 0

Re: [dns-wg] Re: ORSN-SERVERS.NET
by Jim Reid 14 Oct '04

14 Oct '04

>>>>> "Steffen" == Steffen Reithermann <dns-wg(a)Reithermann.de> writes: Steffen> Don't get me wrong ... I don't say ICANN's decisions are Steffen> transparent all or even most of the time. Some Steffen> independence of Europe regarding DNS and other critical Steffen> Internet infrastructure is a creditable goal, but I think Steffen> it needs a stronger basis and a broader support in the Steffen> ISP community than ORSN seems to have currently. Personal opinion: People who are unhappy with ICANN -- and who isn't? -- should be working to reform it from within. ICANN's processes are open and everyone is free to participate. [Sort of.] Supporting or encouraging efforts like alternate DNS roots undermines ICANN. That could lead to the replacement of ICANN with something even less palatable to Internet people: internet governance by international civil servants through some part of the United Nations.

1 0

ORSN-SERVERS.NET
by Yiorgos Adamopoulos 13 Oct '04

13 Oct '04

[ Sorry if this has been discussed before ] Recenlty I came across ORSN <http://www.orsn.net/>. Soonafter I discovered that one of our peers is using their rootzone (and we are forwarding queries to them). So, the question is: What do you think of this effort? o any members of the group use the ORSN-SERVERS.NET root instead of the traditional one? If so why? If not why? TIA, -Yiorgos.

10 17

Re: [dns-wg] ORSN-SERVERS.NET
by Jim Reid 13 Oct '04

13 Oct '04

>>>>> "Jeroen" == Jeroen Massar <jeroen(a)unfix.org> writes: Jeroen> RFC's are still Request For Comments, not Standards, Some RFCs *are* standards and get labelled as such. Sadly 2826 isn't one of them. :-( Jeroen> nevertheless anyone can choose to use any infrastructure, Jeroen> rootserver, firewalling policies, routing policies and a Jeroen> whole lot of other politics that that person/organisation Jeroen> whishes to follow. For that matter if someone would setup Jeroen> his/her/it's own RIR and started giving out IPv4 or IPv6 Jeroen> addresses, who is going to stop you? That it won't Jeroen> interoperate with what most of the people on this globe Jeroen> call 'the internet' is another question, but isn't that Jeroen> their problem? Not really. Granted, they have the lion's share of the problems. But those problems won't stop at the boundary of their net. For example, a bogus TLD will leak out to people on the real internet, links on web pages can't be resolved (or point elsewhere), users get confused, mail gets bounced or treated as spam, etc, etc. Once that happens, bogus root servers and suchlike become a serious problem for the helpdesks and support people at ISPs on the real internet. If only there was a Protocol Police to deal with these impostors.

2 1

Re: [dns-wg] blackhole-*.iana.org gone ?
by James Aldridge 06 Oct '04

06 Oct '04

Dave Knight wrote: > At 19:36 01/10/2004 +0200, Dave Knight wrote: > >Hi, > > > >The RIPE NCC AS112 server, as112.ripe.net [195.69.144.39] is up and > >running again and is advertising the 192.175.48.0/24 network. > > As we are continuing to have issues with this machine and have decided > to take it offline until they are definitively fixed. We plan to replace > the hardware and bring it back online next week. Since around 13:00 UTC yesterday afternoon, as112.ripe.net has been running on new hardware (with a software upgrade at the same time for good measure). Regards, James

1 0

Reverse delegation checks: call for discussion
by Peter Koch 04 Oct '04

04 Oct '04

Dear DNS wg, from http://www.ripe.net/ripe/wg/dns/action-list.html you can see action item 48.3: Send to the mailing list (a pointer to) the current list of checks applied to IN-ADDR.ARPA zones before reverse delegation is activated or updated. Initiate review of those checks and propose, if necessary, updates and/or additional tests. Olaf sent the requested information to this list early September: http://www.ripe.net/ripe/mail-archives/dns-wg/2004/msg00172.html During the Action Item Review in Manchester it was decided to take this item to the list with a six week comment period. Anyone interested in changing the currently applied tests (i.e. the set of checks or a particular one) is invited to discuss this on the list or approach the WG co-chairs until November, 5th. Action Item 48.3 will be closed after that date unless tangible proposals have been made. Of course, there's always the opportunity to address this issue in the future should the need arise. Please expect the action item list to be updated after the minutes of RIPE 49 have been circulated. -Peter

1 0

blackhole-*.iana.org gone ?
by Pim van Pelt 01 Oct '04

01 Oct '04

Hi, The nameserver on blackhole-[12].iana.org does not seem to reply queries for me. $ dig @blackhole-1.iana.org PTR 1.0.0.10.in-addr.arpa. ; <<>> DiG 8.3 <<>> @blackhole-1.iana.org PTR 1.0.0.10.in-addr.arpa. ; (1 server found) ;; res options: init recurs defnam dnsrch ;; res_nsend: Connection refused I am in AS12859. Is anybody else experiencing this problem ? -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E)

5 8