- dns-wg - mailman.ripe.net

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