Re: Update of RFC 2606 based on the recent ICANN changes ?
On Tue, Jul 08, 2008 at 02:34:59PM -0700, Ted Faber wrote: On Tue, Jul 08, 2008 at 05:11:35PM -0400, Keith Moore wrote: And vanity TLDs are going to be much more attractive if people think they can get single-label host names out of them. Of your concerns (which I don't have the relevant experience to comment on in detail), this seems to be fairly small and speculative to me. Time will tell. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG it is possible to have a host name also be a domain name. myself, i look forward to sending email to [EMAIL PROTECTED] -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Mark Andrews wrote: ... hk is not a legal fully qualified host name. Agreed. hk., however, is. No, it is not a legal hostname. RFC 952 explicitly excludes trailing periods. RFC 952 is not a standard. Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Wed, Jul 09, 2008 at 12:54:24PM +1000, Mark Andrews wrote: I don't want anything in this space. I don't care if the root's unchanged or as wide as .com. There was a clear decision to move from a single label hostnames to multiple label hostnames (RFC 921). You are attempting to reverse that decision. I've said everything I want to say about this topic, but I'd like to reiterate that I'm not attempting to reverse any decision. I have no hidden agenda and I am not advocating a policy position based on technical and conceptual feasibility (or anything else). I don't care which one the community picks here. I've now asserted it twice. I don't care which one the community picks here. Now it's true. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpsS9OgoRgOm.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
--On Monday, 07 July, 2008 18:14 -0700 Dave Crocker [EMAIL PROTECTED] wrote: John C Klensin wrote: What do you think would happen to that recommendation, and the benefits it affords, if the size of the root zone increased by an order of magnitude or so? 2 orders? 20K? No, sorry. Think 3-4 orders of magnitude. Really. Yes. I choose the smaller number because various folks around ICANN seem to be expecting a thousand applications or so. Unless the application fee turns into much more of a deterrent than I expect, I agree that this is likely to open the floodgates and that your estimate is more likely. While INAL and this is certainly not my area of expertise, a possible issue in the requirement to defend trademarks might act as a strong accelerator once one starts seeing individual enterprise TLDs (or even the suspicion of applications for them). Let me explain: I'm not against more TLDs. Quite the opposite. (I appointed by Postel to participate in the pre-ICANN committee tasked with increasing the number.) But there is a paradigmatic difference between a TLD defined and operated to mediate on behalf of a general and diverse population, versus one constrained to a narrow and controlled constituency, such as a single company. Indeed, although ICANN has already opened that door by allocating sponsored gTLDs to a few entities which have restricted membership that is smaller than the interest group associated with some larger companies. The number of the latter is quite large. And by that I mean *really* large. And all of the questions I asked 10 years ago said that TLDs on that latter scale would be problematic to the root. Yes. And, for large scale, our more complicated root environment (e.g., Anycast* and more local caching of root copies in the presence of a root that might, worst case, end up on the same order of magnitude in size, and with similar volatility, to .COM) may actually make that situation worse than it would have been in estimates of a decade ago. john * I am assuming that, while Anycast reduces the load on individual servers by making more of them, it does not reduce the total query load on the network and increases the amount of bandwidth used in distributing updates. The latter is presumably trivial as long as the refresh time for the root zone is fairly long and updates are infrequent (or incremental push update is used), but could get interesting if magnitudes evolved toward the current .COM situation. But that is clearly not an analysis based on actual data. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Jul 7, 2008, at 10:55 PM, Joe Abley wrote: On 7 Jul 2008, at 21:36, James Seng wrote: And all of the questions I asked 10 years ago said that TLDs on that latter scale would be problematic to the root. Was that pre-Anycast or post-Anycast? There are plenty of examples of people hosting large, infrastructure- type zones using servers and software that are conventional, commodity choices. NSD and BIND9 are both quite capable of hosting zones with single-digit millions of delegations without needing special care and feeding, for example. Whether the DNS service for a zone is anycast or not has some, but really not that much relevance when you're considering the risk of an engorged root zone. I don't read anything in the layer-9 musings I've seen so far to suggest that the bar to entry for new TLDs will be so low that we'll see widespread TLD tasting and churn, for example, sufficient to make far-flung anycast instances struggle to keep up. It seems to me that it might be better to turn that around : The new TLD system should not allow for widespread TLD tasting and churn. I worry about depending on artificial limits imposed by fees. ICANN will certainly be lobbied to lower their fees; what if the fee in 2012 is $ 100 not $ 100,000 ? Regards Marshall I'm not suggesting that growth should be allowed to happen without considering the technical consequences. However, I believe in practice with the headroom in systems and network that root server operators generally install anyway, there's considerable room for growth and the general argument that growth in the root zone will undermine stability sounds more like hysteria than science. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Tue, Jul 08, 2008 at 12:54:16PM +1000, Mark Andrews wrote: hk. is not a syntactically valid hostname (RFC 952). hk. is not a syntactically valid mail domain. Periods at the end are not legal. RFC 1035 has *nothing* to do with defining what is legal as a hostname. Fair enough. By RFC952 standards hk is a perfectly fine hostname. By RFC1035 standards, if you look it or any other DNS name up using the DNS resolver, that resolver will treat the name as relative unless it ends with a dot. Arguing that hk is an unreliable hostname if you look it up as a relative pathname is pretty much the same as arguing that www.isi.deterlab.net is an unreliable hostname. Both of them are subject to the search path without that trailing dot. So far, the only distinction between the two is that hk is short. I understand the assumption that getting a collision in the search path with a 2-letter name is higher than getting one with a 20-letter name. I believe that the 2-letter collisions are no harder to avoid in principle than the 20-letter ones, and no harder to create should an admin want to do so (e.g., to create local aliases). I think you believe that search path collisions for short names are inherently harder to avoid (and might rule out using the trailing dot notation in applications to avoid them). Is that basically what we disagree about? -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgplQaYvMPyNn.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Ted Faber wrote: On Tue, Jul 08, 2008 at 12:54:16PM +1000, Mark Andrews wrote: hk. is not a syntactically valid hostname (RFC 952). hk. is not a syntactically valid mail domain. Periods at the end are not legal. RFC 1035 has *nothing* to do with defining what is legal as a hostname. Fair enough. By RFC952 standards hk is a perfectly fine hostname. By RFC1035 standards, if you look it or any other DNS name up using the DNS resolver, that resolver will treat the name as relative unless it ends with a dot. Arguing that hk is an unreliable hostname if you look it up as a relative pathname is pretty much the same as arguing that www.isi.deterlab.net is an unreliable hostname. Both of them are subject to the search path without that trailing dot. RFC1035 may recognize the trailing dot, but (for better or worse) many applications do not recognize it, and some explicitly forbid it. So far, the only distinction between the two is that hk is short. I understand the assumption that getting a collision in the search path with a 2-letter name is higher than getting one with a 20-letter name. I believe that the 2-letter collisions are no harder to avoid in principle than the 20-letter ones, and no harder to create should an admin want to do so (e.g., to create local aliases). I think you believe that search path collisions for short names are inherently harder to avoid (and might rule out using the trailing dot notation in applications to avoid them). Is that basically what we disagree about? No. There's more to this than just the possibility of name collisions caused by the lookup using a search path. For instance, there are also applications that try to distinguish between an absolute DNS name and some other kind of name (DNS name relative to the search path, or a name in /etc/hosts, NetBIOS, NIS, ...) by checking to see whether the name contains a '.'. So for instance, if the domain name contains a '.', the search path function might be turned off during name lookup. This behavior isn't necessarily prescribed in any specification, but it's a useful heuristic - especially for an application (like email addresses or URLs) where it's important that domain names be unambiguous and location-independent. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Mon, Jul 07, 2008 at 11:28:05PM -0400, Keith Moore wrote: The site-dependent interpretation of the name is determined not by the presence of dot within the name but its absence from the end. not so. in many contexts the trailing dot is not valid syntax. Let me be precise. The resolver treats those names differently because it was handed a name that did or did not end in a dot - the resolver's syntax for absolute vs. relative pathname. I understand that may conflict with application syntax. Applications that do not support an explicit notation for absolute domain names will not be able to look them up when those names are masked by site-dependent resolution of relative names. Both hk and www.isi.deterlab.net are relative names and subject to masking. I understand that such maskings are more intuitive with short names like hk, but that limitation of the application interface applies to any relative domain name. I don't buy unreliable as a diagnosis for that state of affairs. hk operates exactly as any other DNS name with respect to search path. search path isn't the only factor here. Understood. It was the objection I was responding to, though. there are also protocol specifications that expect DNS names to have dots in them. One could argue that such protocols are not able to express all valid domain names, which may be a feature. :-) That's probably a longer discussion than I want to have though, so I agree that this is a stumbling block. there are also software implementations that use the presence/absence of a dot to distinguish a DNS name from some other kind of name. in any context where both a DNS name and something else can appear, it's useful to be able to distinguish the two - and the presence/absence of a dot is about the only test that works. I'm sure that there are plenty of apps that break here, and certainly some protocols that have been specified that way, and I feel the pain of backward compatibility. If I were running the website at hk, I'd publicize the conventional DNS names and not hk. I really didn't intend to get as deeply into this as I did. I was honestly intrigued by a 2-letter hostname and wanted to see if it really worked, as I could see no reason it wouldn't. For me it did. I understand that your resolver, server, and application may all prevent it. I also understand that using such names may sow confusion among those who don't care to examine the workings of their DNS set-up. And that any confusion about computers is set upon by the unscrupulous to gather money. Encouraging TLD hostnames as a matter of policy is more complex than noting that the DNS specifications allow such a thing. But it was pretty cool. :-) -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpDsbYVtxvai.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Keith Moore wrote: | | | Ted Faber wrote: | On Tue, Jul 08, 2008 at 12:54:16PM +1000, Mark Andrews wrote: | hk. is not a syntactically valid hostname (RFC 952). | hk. is not a syntactically valid mail domain. | Periods at the end are not legal. | | RFC 1035 has *nothing* to do with defining what is legal | as a hostname. | | Fair enough. | By RFC952 standards hk is a perfectly fine hostname. | | By RFC1035 standards, if you look it or any other DNS name up using the | DNS resolver, that resolver will treat the name as relative unless it | ends with a dot. Arguing that hk is an unreliable hostname if you | look it up as a relative pathname is pretty much the same as arguing | that www.isi.deterlab.net is an unreliable hostname. Both of them are | subject to the search path without that trailing dot. | | RFC1035 may recognize the trailing dot, but (for better or worse) many | applications do not recognize it, and some explicitly forbid it. RFC1043 defines the dot. The fact that some apps don't recognize it is a bug. Given its impact, let's not call it a feature or BCP. Joe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIc65GE5f5cImnZrsRApEwAKCBFc5Ss/pi7xbFpT8KOrt+35vQQACfYWBy 204MtY5DKH73CfaI4SEMbV4= =zH2v -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Ted Faber wrote: On Mon, Jul 07, 2008 at 11:28:05PM -0400, Keith Moore wrote: The site-dependent interpretation of the name is determined not by the presence of dot within the name but its absence from the end. not so. in many contexts the trailing dot is not valid syntax. Let me be precise. The resolver treats those names differently because it was handed a name that did or did not end in a dot - the resolver's syntax for absolute vs. relative pathname. I understand that may conflict with application syntax. Applications that do not support an explicit notation for absolute domain names will not be able to look them up when those names are masked by site-dependent resolution of relative names. It's more likely that the application (as specified) simply expects (implicitly or explicitly) absolute domain names. If and when relative domain names work, it's either by accident or a result of sloppy coding. Few applications are specified in such a way that relative DNS names make sense and there is a clear way to distinguish relative names from absolute DNS names. (Note that make sense generally includes converting relative names to absolute names in the context of whoever typed in the relative name - and dealing with the potential for skew over time between the relative name and absolute equivalent. in other words, this is not an easy thing to do well.) The problem is worsened because most APIs for name lookup are poorly designed in several ways. One of their problems is that they tend to do relative lookups by default even though often that's not desirable. Another problem is that they tend to do other kinds of lookups by default in addition to DNS (perhaps as a fallback) even in contexts where DNS lookups are required for interoperability. Applications may or may not work around these API problems, and to the extent they do, they probably don't do so consistently from one implementation to the next. I understand that such maskings are more intuitive with short names like hk, but that limitation of the application interface applies to any relative domain name. I'm not sure what intuitive means in this context. But the probability of collision is certainly larger for short names than for longer ones. I suspect it's also larger for single-label names than for multiple-label names, where each label is assigned by a different entity. And a higher probability of collision definitely translates to a lower degree of reliability. there are also protocol specifications that expect DNS names to have dots in them. One could argue that such protocols are not able to express all valid domain names, which may be a feature. :-) The notion of a single-label fully-qualified DNS name being valid is an odd one. DNS, as far as I can tell, was always intended to be federated, both in assignment and lookup. The notion of having terminal (basically, non NS) records at the root seems contraindicated by several of the DNS design goals. For example, at the time DNS was established, single label names like CMUA or MIT-AI were the norm. But those names were not incorporated into the root (even during a transition), nor were TLDs created for those zones - because DNS was not intended to work that way. The whole idea was to federate the name space, not to provide another way to look up single-label names. (Instead, the names were incorporated into the .ARPA TLD for a time, with CNAMEs pointing to the real names.) So I persist in thinking that single-label DNS names are not valid, and that to the extent they work at all, they work only by accident or as a result of poor specification or sloppy implementation. And given the recent interest in vanity TLDs and ICANN's apparent lack of willingness to run the DNS for the benefit of all, maybe it's time for IETF to remind people that single label TLDs are not actually supposed to work. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
RFC1043 defines the dot. The fact that some apps don't recognize it is a bug. not when the application explicitly specifies that FQDNs are to be used. in such cases the dot is superfluous. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Joe Touch wrote: Keith Moore wrote: | RFC1043 defines the dot. The fact that some apps don't recognize it is a | bug. | | not when the application explicitly specifies that FQDNs are to be used. | in such cases the dot is superfluous. Superfluous is fine. Prohibited is not. If the app inputs DNS names, then FQDNs should be valid, even if redundant. I don't think you get to revise a couple of decades of protocol design and implementation by declaring that RFC 1043's authors and process trump everything that's been done afterward. face it, there are large numbers of identifiers for which relative names are simply not appropriate - because they cannot be made to work well over the time frame that those identifiers need to be valid. email addresses and URLs are two obvious examples. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Keith Moore wrote: Joe Touch wrote: Keith Moore wrote: | RFC1043 defines the dot. The fact that some apps don't recognize it is a | bug. | | not when the application explicitly specifies that FQDNs are to be used. | in such cases the dot is superfluous. Superfluous is fine. Prohibited is not. If the app inputs DNS names, then FQDNs should be valid, even if redundant. I don't think you get to revise a couple of decades of protocol design and implementation by declaring that RFC 1043's authors and process trump everything that's been done afterward. I'll repeat: some app misbehaviors are just bugs not all app misbehaviors define new, acceptable behavior At some point we as a group decide what to accept as BCP, and what to just call a bug. This, IMO, falls squarely in the 'bug' bin. Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Joe Touch wrote: I don't think you get to revise a couple of decades of protocol design and implementation by declaring that RFC 1043's authors and process trump everything that's been done afterward. I'll repeat: some app misbehaviors are just bugs not all app misbehaviors define new, acceptable behavior At some point we as a group decide what to accept as BCP, and what to just call a bug. This, IMO, falls squarely in the 'bug' bin. IMO you are broadly overgeneralizing. For many apps (and certainly for the apps most widely used today), the ability to use relative names, even as an accident because the API allows them, is a bug. Many, many working groups have looked at the problems associated with relative names and determined that they're not acceptable. It's a bug that relative names are forbidden in these apps, nor that the final . is implicit and in many cases disallowed. These are carefully considered design features. (for instance, forbidding the final . makes it simpler to compare domain names for equivalence.) Ketih ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Mon, 7 Jul 2008, [EMAIL PROTECTED] wrote: So who's going to explain to the Vatican that, sorry, [EMAIL PROTECTED] doesn't work any more? Or will the US take issue when addresses @as, which is part of the US, don't work? Or France about @gp and @mq, which are as much part of France as Hawaii is part of the US? I'd be very surprised if any of these work as-is, with any reliability. They certainly won't work for email. The assumption that fully qualified domain names contain at least one '.' is widespread in both protocol specifications and implementations. I've been investigating this and I have discovered an oddity that I didn't expect: Exim on my FreeBSD workstation handles TLD MXs without a problem, but on my SuSE mail relays it fails. This is because of different behaviours between the resolver code in the FreeBSD and GNU C libraries. Both of them are based on the BIND resolver code so this is rather surprising! Exim uses res_search() to do DNS lookups. The postmaster can control the resolver's treatment of single-component names using Exim's qualify_single option, which controls the resolver's RES_DEFNAMES flag. GNU libc refuses to resolve a single component domain name unless there's a trailing dot (which there never is for a mail domain), or RES_DEFNAMES is set and . is on the search list. Our mail relays use Exim's own seach logic when looking up MXs so they switch RES_DEFNAMES off; therefore TLD MXs do not work on those machines. FreeBSD libc will resolve single-component names without trailing dots and without RES_DEFNAMES set, so TLD MXs would work on FreeBSD. However, FreeBSD's behaviour has varied in the past, and I suspect the same is true for the upstream BIND resolver code - though I haven't checked the history in detail. So the question of whether TLD MXs work depends on the interactions between lot of complicated option settings and software versions, and is likely in practice to work or fail unpredictably. Tony. -- f.anthony.n.finch [EMAIL PROTECTED] http://dotat.at/ TYNE DOGGER: WEST 4 OR 5, OCCASIONALLY 6, BECOMING VARIABLE 3 OR 4, THEN SOUTHEAST 4 OR 5 LATER. SLIGHT OR MODERATE. SHOWERS, RAIN LATER. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
So the question of whether TLD MXs work depends on the interactions between lot of complicated option settings and software versions, and is likely in practice to work or fail unpredictably. That sounds utterly reasonable. To me the bigger question is whether this failure scenario is something the IETF needs to address, or is it is sufficiently localized that it's something that just another thing a domain owner should deal with. Personally, I don't think that [EMAIL PROTECTED] - [EMAIL PROTECTED] is a major issue, because in recent years mail addressing has gotten rather flat, most DNS resolvers are configured via DHCP, and I don't get the impression that they have any search lists at all. Search lists were useful 15 or 20 years ago, but not now. It would be interesting to hear from people running mail systems who were NOT running them ten years ago, to avoid the selection bias of people whose configuration preferences were set on the T1 backbone. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor More Wiener schnitzel, please, said Tom, revealingly. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Many, many working groups have looked at the problems associated with relative names and determined that they're not acceptable. It's a bug that relative names are forbidden in these apps, nor that the final . is implicit and in many cases disallowed. These are carefully considered design features. (for instance, forbidding the final . makes it simpler to compare domain names for equivalence.) It's nonsensical for an application to decide that relative names are unacceptable, but to require users to input names as relative. it's nonsensical for you to unilaterally declare that such names are relative, when well over two decades of practice indicates otherwise. (and remember, some of these apps predate DNS and the whole notion of relative names) it's almost as if the very concept of relative names in DNS is itself a bug - especially if you insist that handling of DNS names be absolutely uniform from one app to the next. IMHO they cause far more problems than they're worth. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Keith Moore wrote: Many, many working groups have looked at the problems associated with relative names and determined that they're not acceptable. It's a bug that relative names are forbidden in these apps, nor that the final . is implicit and in many cases disallowed. These are carefully considered design features. (for instance, forbidding the final . makes it simpler to compare domain names for equivalence.) It's nonsensical for an application to decide that relative names are unacceptable, but to require users to input names as relative. it's nonsensical for you to unilaterally declare that such names are relative, when well over two decades of practice indicates otherwise. I didn't declare it; 1034 did. Apps misbehaving over arbitrary periods of time don't make it otherwise. (and remember, some of these apps predate DNS and the whole notion of relative names) Those apps bought into the DNS spec (or started violating it) when they tied into the DNS - regardless of what they did with names before. it's almost as if the very concept of relative names in DNS is itself a bug - especially if you insist that handling of DNS names be absolutely uniform from one app to the next. IMHO they cause far more problems than they're worth. I agree that relative names are probably not worth the trouble, but that doesn't mean that I shouldn't be allowed to type a . at the end of any DNS name. DNS names have a syntax; things that take DNS names as input and/or tie into the DNS protocol need to use that syntax, not presume to redefine it. Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Tue, Jul 08, 2008 at 02:17:57PM -0400, Keith Moore wrote: Ted Faber wrote: On Mon, Jul 07, 2008 at 11:28:05PM -0400, Keith Moore wrote: there are also protocol specifications that expect DNS names to have dots in them. One could argue that such protocols are not able to express all valid domain names, which may be a feature. :-) The notion of a single-label fully-qualified DNS name being valid is an odd one. DNS, as far as I can tell, was always intended to be federated, both in assignment and lookup. The notion of having terminal (basically, non NS) records at the root seems contraindicated by several of the DNS design goals. But there are no such non-NS records at the root. The A record for the host hk is on the .hk servers, not the root servers. Conceptually, the delegee controls the namespace at the root of the delegation. This is exactly analogous to the practice of assigning an address to the root of a delegated domain like isi.edu. There are NS records in edu pointing to isi servers and the A record for isi.edu lives inside the delegated namespace, which is entirely consistent with federation. And given the recent interest in vanity TLDs and ICANN's apparent lack of willingness to run the DNS for the benefit of all, maybe it's time for IETF to remind people that single label TLDs are not actually supposed to work. There are plenty of reasons to argue against using TLDs as hostnames, but I don't think consistency with the federation/delegation model is one. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpTZnTykoH6P.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
It's nonsensical for an application to decide that relative names are unacceptable, but to require users to input names as relative. it's nonsensical for you to unilaterally declare that such names are relative, when well over two decades of practice indicates otherwise. I didn't declare it; 1034 did. Yes - but you're the one declaring that 1034 trumps decades of later work. Normally the assumption would be that work can be revised as bugs are found or conditions change over time, and that things that had achieved IETF consensus since 1034 was published would be considered at least equal, and often superior, to earlier work. I don't think 1034 was handed down from a mountain on stone tablets. I believe it always was inevitable that different apps would use DNS (or any shared naming facility) in slightly different ways. Yes this is somewhat confusing, but DNS (like the rest of the Internet) has been stretched far beyond its original design goals or scale. For instance, we don't interpret DNS names as hostnames any more - because in the modern world the concept of host name is irrelevant in the vast majority of cases. And maybe this provides an illustration of how difficult it is for us to use service protocols consistently from one application to another (it's not hard to find other examples). But such difficulty is real and it reflects genuine differences in requirements from one app to the next. Arguably 1034 didn't even address the needs of apps existing at that time (email being one of those apps), much less apps that came later. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Keith Moore wrote: It's nonsensical for an application to decide that relative names are unacceptable, but to require users to input names as relative. it's nonsensical for you to unilaterally declare that such names are relative, when well over two decades of practice indicates otherwise. I didn't declare it; 1034 did. Yes - but you're the one declaring that 1034 trumps decades of later work. Normally the assumption would be that work can be revised as bugs are found or conditions change over time, and that things that had achieved IETF consensus since 1034 was published would be considered at least equal, and often superior, to earlier work. I don't think 1034 was handed down from a mountain on stone tablets. It was not. But when other programs started using the DNS, it was *they* that endorsed what the DNS as per that doc. I believe it always was inevitable that different apps would use DNS (or any shared naming facility) in slightly different ways. Yes. Some ways are compliant, others are not. Yes this is somewhat confusing, but DNS (like the rest of the Internet) has been stretched far beyond its original design goals or scale. For instance, we don't interpret DNS names as hostnames any more Who doesn't? If you're saying they could be more than one host, fine. If you're saying they're not hosts any more, I disagree. If you're intent on saying the Internet is whatever anyone says it is on any given day - as the above suggests - I appreciate your confusion. I prefer to consider the Internet as being based on standards, and reliably working when - and *because* - we adhere to them. Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Ted Faber wrote: On Tue, Jul 08, 2008 at 02:17:57PM -0400, Keith Moore wrote: The notion of a single-label fully-qualified DNS name being valid is an odd one. DNS, as far as I can tell, was always intended to be federated, both in assignment and lookup. The notion of having terminal (basically, non NS) records at the root seems contraindicated by several of the DNS design goals. But there are no such non-NS records at the root. The A record for the host hk is on the .hk servers, not the root servers. I should have been clearer. I meant the root of the name space, not the root zone. And given the recent interest in vanity TLDs and ICANN's apparent lack of willingness to run the DNS for the benefit of all, maybe it's time for IETF to remind people that single label TLDs are not actually supposed to work. There are plenty of reasons to argue against using TLDs as hostnames, but I don't think consistency with the federation/delegation model is one. I disagree. I think this puts more pressure on the root. It gives them a much larger, and more varied set of customers to deal with, when the root (i.e. ICANN) already has a fair amount of difficulty dealing with the ones it has. There's a fairly basic (if implicit) assumption of DNS (and hierarchical names in general) that each delegation level has some shared interest with the one above it. This shared interest helps to minimize conflicts and (more importantly) to keep those conflicts from affecting the rest of the net. However, the assumption of shared interest breaks down at the root. This has traditionally been dealt with by imposing constraints on the root for all parties. E.g. (a) keep the root minimal and make changes only with great care, (b) create TLDs that group together like interests and make it obvious where in the root a particular organization belongs (.COM, vs .ORG, vs .EDU) (c) after .COM was captured (with various ill effects) - provide a small number of alternative TLDs (and with multiple, competing registrars) so that owner of a single TLD cannot impose a barrier to acquiring a domain. Flattening the root (which is essentially what is being proposed) has the consequence that conflicts are more likely to affect parties not involved in the conflict. And vanity TLDs are going to be much more attractive if people think they can get single-label host names out of them. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Tue, Jul 08, 2008 at 05:11:35PM -0400, Keith Moore wrote: And vanity TLDs are going to be much more attractive if people think they can get single-label host names out of them. Of your concerns (which I don't have the relevant experience to comment on in detail), this seems to be fairly small and speculative to me. Time will tell. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpnFNUXS1fYz.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
I don't think 1034 was handed down from a mountain on stone tablets. It was not. But when other programs started using the DNS, it was *they* that endorsed what the DNS as per that doc. ...but they also profiled it in various ways for use with that specific app. Some apps define their own RRs, others use MX or SRV or TXT records, others restrict the syntax of allowable DNS names beyond the restrictions imposed by DNS itself. And IDNs have their own subtle (and not-so-subtle) effects which can also vary from one app to the next. It's really no different than a protocol specification saying (for example) this protocol is layered on top of TLS, but certain ciphersuites are not acceptable as they're not suitable for this case. I believe it always was inevitable that different apps would use DNS (or any shared naming facility) in slightly different ways. Yes. Some ways are compliant, others are not. Yes this is somewhat confusing, but DNS (like the rest of the Internet) has been stretched far beyond its original design goals or scale. For instance, we don't interpret DNS names as hostnames any more Who doesn't? If you're saying they could be more than one host, fine. If you're saying they're not hosts any more, I disagree. I'm saying that the mapping between a DNS name and a set of hosts is more-or-less arbitrary. It can be zero hosts, one host, many hosts. And with MX and SRV records, the mapping between the DNS name and the hosts that provide that service can differ from one application to the next. That's a long way from the traditional concept of host name where a host was a single box with a user community and a set of services that were all associated with that name. Nowdays we're much more likely to use a different DNS name for each service. The traditional notion of host as a box that you could log into is only one such service, and (for most users) a fairly minor one at that. If you're intent on saying the Internet is whatever anyone says it is on any given day - as the above suggests - I appreciate your confusion. I prefer to consider the Internet as being based on standards, and reliably working when - and *because* - we adhere to them. I often find myself *wishing* the Internet worked that way. Then we wouldn't have NATs, for instance. And I long for a day when we actually design protocols that use other protocols based on a careful consideration of well-known characteristics of those substrate protocols - much in the way that a structural engineer (say) designs structures based on the characteristics of load-bearing members and fasteners. But I don't think we're there yet. And even if we had been doing that all of these years, I doubt that we'd all be using DNS in the same way today. Rather, we'd have a dozen DNS-like systems, all slightly different from one another, with some degree of inconsistency in name assignment from one to the next. Because insisting on strict adherence to 1035 would not have removed the need for different protocols to use DNS in slightly different ways. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Ted Faber wrote: On Tue, Jul 08, 2008 at 05:11:35PM -0400, Keith Moore wrote: And vanity TLDs are going to be much more attractive if people think they can get single-label host names out of them. Of your concerns (which I don't have the relevant experience to comment on in detail), this seems to be fairly small and speculative to me. Time will tell. it is certainly speculative. but I do recall considerable past interest in keywords and a widespread desire to have DNS support them. I doubt that interest has waned. and I'm not very business minded - but I don't think I'd have much trouble finding a thousand different English words that would be worth far more than $100K each if I could arrange for people to be able to type those words into a browser and reliably get back a web page of my choosing. if it's a no-brainer for me, how much easier will it be for someone who actually cares about making lots of money and doesn't mind screwing up the DNS root? Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
--mvpLiMfbWzRoNl4x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 07, 2008 at 11:28:05PM -0400, Keith Moore wrote: The site-dependent interpretation of the name is determined not by the presence of dot within the name but its absence from the end.=20 =20 not so. in many contexts the trailing dot is not valid syntax. Let me be precise. The resolver treats those names differently because it was handed a name that did or did not end in a dot - the resolver's syntax for absolute vs. relative pathname. I understand that may conflict with application syntax. Applications that do not support an explicit notation for absolute domain names will not be able to look them up when those names are masked by site-dependent resolution of relative names. Both hk and www.isi.deterlab.net are relative names and subject to masking. The (some) resolver handles names differently if it contains a dot. pet.com is lookup up as pet.com FIRST then pet.search-element. pet is looked up as pet.search-element FIRST and pet LAST. The above heuristics worked reasonably well in a IPv4 only world where tld's weren't turning back the clock and trying to make make single label hostnames work in a global context. There is a good case to be made that pet should *never* be looked up as plain pet if there is not a match on the search list. There is a good case to be made that pet.com should never be looked up against the search list. I understand that such maskings are more intuitive with short names like hk, but that limitation of the application interface applies to any relative domain name. The only reason to want single labels to be looked up as is is reverse the clock and support deprecated naming schemes. I don't buy unreliable as a diagnosis for that state of affairs. hk operates exactly as any other DNS name with respect to search path.=20 =20 search path isn't the only factor here. Understood. It was the objection I was responding to, though. =20 there are also protocol specifications that expect DNS names to have=20 dots in them. One could argue that such protocols are not able to express all valid domain names, which may be a feature. :-) That's probably a longer discussion than I want to have though, so I agree that this is a stumbling block. =20 there are also software implementations that use the presence/absence of= =20 a dot to distinguish a DNS name from some other kind of name. in any=20 context where both a DNS name and something else can appear, it's useful= =20 to be able to distinguish the two - and the presence/absence of a dot is= =20 about the only test that works. I'm sure that there are plenty of apps that break here, and certainly some protocols that have been specified that way, and I feel the pain of backward compatibility. If I were running the website at hk, I'd publicize the conventional DNS names and not hk. =20 I really didn't intend to get as deeply into this as I did. I was honestly intrigued by a 2-letter hostname and wanted to see if it really worked, as I could see no reason it wouldn't. For me it did. I understand that your resolver, server, and application may all prevent it. I also understand that using such names may sow confusion among those who don't care to examine the workings of their DNS set-up. And that any confusion about computers is set upon by the unscrupulous to gather money. Encouraging TLD hostnames as a matter of policy is more complex than noting that the DNS specifications allow such a thing. It's clear that single label host names are not supposed to be used in a global context anymore. Just because nobody wrote down Don't add a A or MX record at the apex of a TLD doesn't mean that adding one was expected or desired. There are lots of things we do and don't expect infrastructure zone operators to do that differ from end user zones. Most of these are not codified. Mark But it was pretty cool. :-) --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --mvpLiMfbWzRoNl4x Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkhzo2wACgkQaUz3f+Zf+XsK4QCg2VpDMr/fF1VnBGzx7Pa4dRgs /0kAoJCVm5WBUIpZrAIvdIa3A2E1Gdtb =x6uM -END PGP SIGNATURE- --mvpLiMfbWzRoNl4x-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Wed, Jul 09, 2008 at 10:54:45AM +1000, Mark Andrews wrote: Let me be precise. The resolver treats those names differently because it was handed a name that did or did not end in a dot - the resolver's syntax for absolute vs. relative pathname. I understand that may conflict with application syntax. Applications that do not support an explicit notation for absolute domain names will not be able to look them up when those names are masked by site-dependent resolution of relative names. Both hk and www.isi.deterlab.net are relative names and subject to masking. The (some) resolver handles names differently if it contains a dot. The distinction that I have been unclearly stating is between absolute and relative names. RFC 1034 (i said 1035 earlier, but it's 1034) lays out a convention for specifying which one you want by appending the dot. As long as you tell the resolver which one you want, it matters little if the dot character is at the end or not. 1034/1035 compliant resolvers are allowed to do site dependent things to relative names and not to absolute ones. There is a good case to be made that pet should *never* be looked up as plain pet if there is not a match on the search list. There is a good case to be made that pet.com should never be looked up against the search list. I prefer the 1034/1035 view that this sort of decision is up to the application and the DNS admin and that the DNS simply provides the ability to do both. I understand that such maskings are more intuitive with short names like hk, but that limitation of the application interface applies to any relative domain name. The only reason to want single labels to be looked up as is is reverse the clock and support deprecated naming schemes. I don't want anything in this space. I don't care if the root's unchanged or as wide as .com. If I want those labels to work at all it's because their working reflects a clean DNS design. It (irrationally) warms my heart to see that they mostly do. I'm not extending my admiration of the design into an operational recommendation, no matter how much you'd like me to. The fact that the existing TLDs could do this would lead to a pretty boring flat name space - 110 names fit in /etc/hosts or equivalent just fine. A proliferation of TLDs is your problem, of course. I don't think that forcing the seekers of vanity TLDs to prepend www. to their webserver hostname is going to change anything. After all many browsers will add that for you. If you're worried about a flat namespace, attack the right problem - a proliferation of TLDs, not this business of the TLD having an A record at the top. For most uses, www.yournamehere is just as flat. And just as flat as yournamehere.com, I might add. There are lots of things we do and don't expect infrastructure zone operators to do that differ from end user zones. Most of these are not codified. If there are only a few TLDs I really fail to see how this one fits there and if there are a lot of TLDs I don't see how outlawing it helps you. But YMMV and I'm not running a TLD server, so my opinion matters little. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpq1g1Opiyjy.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
It's nonsensical for an application to decide that relative names are unacceptable, but to require users to input names as relative. it's nonsensical for you to unilaterally declare that such names are relative, when well over two decades of practice indicates otherwise. I didn't declare it; 1034 did. And RFC 1535 got resolvers to try search lists last if there was a period in the name. This removed the need for final periods for any legal fully qualified host name. hk is not a legal fully qualified host name. Demanding that applications support final dots to support uses that are outside of the original design scope is nonsensical. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
The (some) resolver handles names differently if it contains a dot. The distinction that I have been unclearly stating is between absolute and relative names. RFC 1034 (i said 1035 earlier, but it's 1034) lays out a convention for specifying which one you want by appending the dot. As long as you tell the resolver which one you want, it matters little if the dot character is at the end or not. in my experience, far too often applications don't tell the resolver which one they want. also, APIs can vary enough from one implementation to another that a portable application may behave differently depending on which API implementation it is using. 1034/1035 compliant resolvers are allowed to do site dependent things to relative names and not to absolute ones. for better or worse, application protocols and applications haven't strictly followed 1034/1035 in this regard. There is a good case to be made that pet should *never* be looked up as plain pet if there is not a match on the search list. There is a good case to be made that pet.com should never be looked up against the search list. I prefer the 1034/1035 view that this sort of decision is up to the application and the DNS admin and that the DNS simply provides the ability to do both. in general I agree, but I think we've learned a few things since then about the corner cases. (I would _almost_ agree that pet should never be looked up as plain pet - except that I think it should be possible to directly query a server to find out what RRs that server has (right or wrong) and I wouldn't want the server to lie or the API to prevent such queries. That's why I would rather forbid servers to forward single-label queries - and perhaps, to refuse to cache NS records for them.) If I want those labels to work at all it's because their working reflects a clean DNS design. Cleanliness is secondary to function. The purist in me likes regularity too. But even if the _protocol_ is the same at the root as for any other zone, the root of the _name space_ really is special, and inherently so (given that these labels have semantics associated with them). At a certain very technical level there is no difference between the root and any other zone. But at a different level the root has a special role and is different than the other zones. It is a single point of failure - not in the sense of a single server or a single network link but in the sense of a single organization running it whose mistakes affect the entire network. Also, the relationship between the root and its subdomains is likely to be very different than that between any other domain and its subdomains. If you're worried about a flat namespace, attack the right problem - a proliferation of TLDs, not this business of the TLD having an A record at the top. Vanity TLDs are indeed part of the problem. Without vanity TLDs there would be much less incentive to have single-label domain names. (I guess I need a better name than vanity TLDs for these - but I think you get what I mean.) Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
--5me2qT3T17SWzdxI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 09, 2008 at 10:54:45AM +1000, Mark Andrews wrote: Let me be precise. The resolver treats those names differently because it was handed a name that did or did not end in a dot - the resolver's syntax for absolute vs. relative pathname. I understand that may conflict with application syntax. Applications that do not support an explicit notation for absolute domain names will not be able to look them up when those names are masked by site-dependent resolution of relative names. Both hk and www.isi.deterlab.net are relative names and subject to masking. =20 The (some) resolver handles names differently if it contains a dot. The distinction that I have been unclearly stating is between absolute and relative names. RFC 1034 (i said 1035 earlier, but it's 1034) lays out a convention for specifying which one you want by appending the dot. As long as you tell the resolver which one you want, it matters little if the dot character is at the end or not. 1034/1035 compliant resolvers are allowed to do site dependent things to relative names and not to absolute ones. hk is not a legal absolute hostname. The current resolver code handles all legal absolute hostnames (has a dot in the middle). Tools that look in the DNS have to handle *more* than hostnames such tools may need to treat hk as absolute in which case hk. is reasonable. dig and nslookup are examples of such tools. Telnet is not a example of a tool that need to support hk. as it is expecting hostnames not arbitary domain names. Web browers are not tools that needs to support hk.. There is a good case to be made that pet should *never* be looked up as plain pet if there is not a match on the search list. =20 There is a good case to be made that pet.com should never be looked up against the search list. I prefer the 1034/1035 view that this sort of decision is up to the application and the DNS admin and that the DNS simply provides the ability to do both. You are wanting to extend the definition of a legal absolute hostname. I understand that such maskings are more intuitive with short names like hk, but that limitation of the application interface applies to any relative domain name. The only reason to want single labels to be looked up as is is reverse the clock and support deprecated naming schemes. I don't want anything in this space. I don't care if the root's unchanged or as wide as .com. There was a clear decision to move from a single label hostnames to multiple label hostnames (RFC 921). You are attempting to reverse that decision. Just because it is technically possible to add A records at the apex of a tld or to add A records to names with underscores in them doesn't change the fact that doing either of these is a bad idea. If I want those labels to work at all it's because their working reflects a clean DNS design. It (irrationally) warms my heart to see that they mostly do. I'm not extending my admiration of the design into an operational recommendation, no matter how much you'd like me to. No, it doesn't represent clean design. Making them work is outside of the design scope. Unqualified names being looked up against search lists was in the design scope. The official names of hosts having multiple labels was in the design scope. Single labels were explictly excluded from being official names in the design scope. Having single label hostnames match against the root is a clear implementation error. The fact that the existing TLDs could do this would lead to a pretty boring flat name space - 110 names fit in /etc/hosts or equivalent just fine. A proliferation of TLDs is your problem, of course. I don't think that forcing the seekers of vanity TLDs to prepend www. to their webserver hostname is going to change anything. After all many browsers will add that for you. =20 If you're worried about a flat namespace, attack the right problem - a proliferation of TLDs, not this business of the TLD having an A record at the top. For most uses, www.yournamehere is just as flat. And just as flat as yournamehere.com, I might add. There are lots of things we do and don't expect infrastructure zone operators to do that differ from end user zones. Most of these are not codified. If there are only a few TLDs I really fail to see how this one fits there and if there are a lot of TLDs I don't see how outlawing it helps you. But YMMV and I'm not running a TLD server, so my opinion matters little. --=20 Ted Faber
Re: Update of RFC 2606 based on the recent ICANN changes?
Is сом identical to com? (the first of these is U+0441 U+043E U+043C) The current principle is that it should be be a confusing string, which is vague enough to cover the case above (but perhaps not able to cover .co) Similarity can be defined and tested, by setting thresholds and the like, but confusing refers to a state of mind - something is confusing if the people who are likely to encounter it consider it to be confusing. There's no way to objectively define or test for confusing similarity without reference to how actual people respond to a particular string. That means either mining data collected from circumstances in which people have mistaken one string for another (perhaps a history of Google searches), or consulting a panel of real people whenever it is necessary to decide whether or not two strings are confusingly similar. (b) be identical to a Reserved Name; (c) consist of a single character; I've heard it argued repeatedly that this is an unreasonable rule for ideographic characters. I don't have an opinion, but hope that ICANN has considered that case in full details. This is where we dive into a discussion what is a character. In ideographic based language, there isnt a concept of a word. For example, Chinese, Japanese and Korean are actually phonetics language, and that ideograph characters are used to express the phonetics. A word or more accurately morphemes can be express in a single or more ideographs. A single latin character is unlikely to be useful by itself (except of a and i) but thats not the case in CJK. If the condition is that no single ASCII character, I may be neutral about it (since a single ideograph would never translate to a single ASCII character in the zonefile, due to the xn-- prefix) but if the character is defined more broadly to cover U-label character, then I would have strong objections. At the moment, the condition is no single Unicode code point. To the extent that a single CJK ideograph can be expressed using a single Unicode code point, this would represent the situation to which you say you would object. I will dig through my notes to find out why the single character condition was adopted - - Lyman ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
I understand the objection to MX records in TLDs based on the past history of how single label hostnames were (and, as Mark points out, undoubtedly still are) handled. If it were possible to put that aside, would you have any other objection to single label hostnames? I know that at least some of the interest in new gTLDs has been expressed by companies that like the idea of using a globally- recognized trademark as a TLD - for example, [EMAIL PROTECTED] (not to imply that IBM is one of the companies that has expressed this sort of interest). I'm familiar with draft-klensin-rfc2821bis-10.txt and understand the importance of using only FQDNs in SMTP exchanges given that [i]n the case of a top-level domain used by itself in an email address, a single string is used without any dots. What I'm interested in is any reason to proscribe the use of a TLD as a single label hostname (particularly for email addresses) other than the fact that there is software out there that will interpret it incorrectly - - Lyman On Jul 2, 2008, at 8:07 PM, Bernard Aboba wrote: Mark Andrews said: The Internet went to multi-label hostnames ~20 years ago.We added .ARPA to all the single label hostnames as partof that process. The only hold over is localhost andthat is implemeted locally, not in the global DNS. No sane TLD operator can expect http://tld; or [EMAIL PROTECTED]to work reliably. I suspect there are still mail configuationsaround that will re-write [EMAIL PROTECTED] to [EMAIL PROTECTED] we be writting a RFC which states that MX and addressrecords SHOULD NOT be added to the apex of a TLD zone? Should we be writting a RFC which states that single labelhostnames/ mail domains SHOULD NOT be looked up as is inthe DNS? Both sound like good ideas to me. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes?
seems odd to me too, James. vint On Jul 3, 2008, at 6:14 PM, James Seng wrote: At the moment, the condition is no single Unicode code point. To the extent that a single CJK ideograph can be expressed using a single Unicode code point, this would represent the situation to which you say you would object. I will dig through my notes to find out why the single character condition was adopted - Would you be able to explain why the condition is no single Unicode code point? Whats the technical basis for that? -James Seng ___ Idna-update mailing list [EMAIL PROTECTED] http://www.alvestrand.no/mailman/listinfo/idna-update ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Single-letter names (was: Re: Update of RFC 2606 based on the recent ICANN changes?)
John, To add to your point, one should also consider the question of embedded semantics in a single-character label. Alphabetic scripts such as Latin mostly represent sounds used to make up words. While one can certainly find some legitimate single-character words (such as the article a or the personal pronoun i) and dream up others, it would not be very convincing in the face of your explanation #3. On the other hand, characters in ideographic scripts such as Han are not mere sounds or glyphs; they represent one or more concepts. Therefore, a single-ideographic-character TLD label is certainly more justifiable. I would even go as far as to suggest that it is essential in many cases. For example, 猫 (U+ 732B) in both Simplified Chinese and Japanese means cat as in English, not the abbreviation for Catalan nor the UNIX command. The reverse translation of cat yields the exact character in Simplified Chinese, though in Japanese sometimes the Hiragana sequence ねこ is also used. One would be hard-pressed to come up with a different character to represent the same concept in Han, aside from the traditional Chinese counterpart �� (U+8C93). I don't know what the present thinking is on the idea of non-semantic TLDs, but IMHO the social expectations of DNS usage is cast in stone. Jon's idea would simply shift the semantics to the second level, thereby creating 24 roots instead of a single . =wil On Fri, Jul 4, 2008 at 1:50 PM, John C Klensin [EMAIL PROTECTED] wrote: Vint, In the ASCII space, there have been three explanations offered historically for the one-character prohibition on top and second-level domains. I've written variations on this note several times, so will just try to summarize here. Of the three, the first of these is at best of only historical interest and may be apocryphal and the second is almost certainly no longer relevant. The third remains significant. (1) Jon has been quoted as suggesting that we could have eliminated many of the problems we now face with TLDs and simultaneously made the no real semantics in TLD names rule much more clear had we initially allocated b..y as TLDs. Then, when someone asked for an assignment, it would have been allocated at random to one of those domains. While this has a certain amount of appeal, at least in retrospect, there is probably no way to get from where we are today to that model... unless actions taken in the near future so ruin the current DNS tree as a locus for stable and predictable references that we need to start over with a new tree. I don't think that a have to start over scenario is at all likely, but I no long believe it to be impossible. (2) There was an idea floating around for a while that, if some of the popular TLDs filled up, one could create single-letter subdomains and push subsequent registrations down the tree a bit. For example, if .COM were declared full, then a.com, b.com, etc., would be allocated and additional reservations pushed into subdomains of those intermediate domains rather than being registered at the second level. Until and unless the conventional wisdom that adding more names to .COM merely requires more hardware and/or bandwidth, that won't be a filled up point at which this sort of strategy could be triggered. Worse, trying to use single-letter subdomains as an expansion mechanism would raise political issues about putting latecomers at an advantage that would be, IMO, sufficient to completely kill the idea. In the current climate, I think the community would decide that it preferred a disfunctional DNS if that were ever the choice (see the start over remark above). (3) At least in the discussions that led up to RFC 1591, and probably much earlier, there were concerns about reducing the likelihood of false hits if the end user made single-character typing errors. With only 26 (or maybe 36) possible characters, it could just about be guaranteed that all of them would be registered and that _any_ typing error would yield a false match. That, in itself, has been considered sufficient to prohibit single-letter labels and, by extension, to be fairly careful about two-letter ones. There have been arguments on and off over the years as to whether this is a technical reason or an attempt to set policy. Even though the mismatches would obviously not cause the network to explode or IP to stop working, at least some of us consider the informational retrieval and information theoretic reasons to insist on more information in domain name labels in order to lower the risk of false positive matches to be fully as technical as something that would have obvious lower-level network consequences. Others --frankly especially those who see commercial advantage in getting single-letter names-- have argued that this position is just a policy decision in disguise. Note that, with slight modifications, the second and third arguments apply equally well to
Re: Single-letter names (was: Re: Update of RFC 2606 based on the recent ICANN changes?)
john, my reaction was specific to IDN single character TLDs. In some languages these are complete words. vint On Jul 4, 2008, at 1:50 PM, John C Klensin wrote: Vint, In the ASCII space, there have been three explanations offered historically for the one-character prohibition on top and second-level domains. I've written variations on this note several times, so will just try to summarize here. Of the three, the first of these is at best of only historical interest and may be apocryphal and the second is almost certainly no longer relevant. The third remains significant. (1) Jon has been quoted as suggesting that we could have eliminated many of the problems we now face with TLDs and simultaneously made the no real semantics in TLD names rule much more clear had we initially allocated b..y as TLDs. Then, when someone asked for an assignment, it would have been allocated at random to one of those domains. While this has a certain amount of appeal, at least in retrospect, there is probably no way to get from where we are today to that model... unless actions taken in the near future so ruin the current DNS tree as a locus for stable and predictable references that we need to start over with a new tree. I don't think that a have to start over scenario is at all likely, but I no long believe it to be impossible. (2) There was an idea floating around for a while that, if some of the popular TLDs filled up, one could create single-letter subdomains and push subsequent registrations down the tree a bit. For example, if .COM were declared full, then a.com, b.com, etc., would be allocated and additional reservations pushed into subdomains of those intermediate domains rather than being registered at the second level. Until and unless the conventional wisdom that adding more names to .COM merely requires more hardware and/or bandwidth, that won't be a filled up point at which this sort of strategy could be triggered. Worse, trying to use single-letter subdomains as an expansion mechanism would raise political issues about putting latecomers at an advantage that would be, IMO, sufficient to completely kill the idea. In the current climate, I think the community would decide that it preferred a disfunctional DNS if that were ever the choice (see the start over remark above). (3) At least in the discussions that led up to RFC 1591, and probably much earlier, there were concerns about reducing the likelihood of false hits if the end user made single-character typing errors. With only 26 (or maybe 36) possible characters, it could just about be guaranteed that all of them would be registered and that _any_ typing error would yield a false match. That, in itself, has been considered sufficient to prohibit single-letter labels and, by extension, to be fairly careful about two-letter ones. There have been arguments on and off over the years as to whether this is a technical reason or an attempt to set policy. Even though the mismatches would obviously not cause the network to explode or IP to stop working, at least some of us consider the informational retrieval and information theoretic reasons to insist on more information in domain name labels in order to lower the risk of false positive matches to be fully as technical as something that would have obvious lower-level network consequences. Others --frankly especially those who see commercial advantage in getting single-letter names-- have argued that this position is just a policy decision in disguise. Note that, with slight modifications, the second and third arguments apply equally well to TLD allocations and to SLD allocations, especially in popular domains. The reasoning associated with the third case also applies to any other script that contains a fairly small number of characters. One could manage a long philosophical discussion as to whether there are sufficient characters in the fully-decorated Latin-derived collection to eliminate the problem, but an analysis of keyboard and typing techniques/ input methods for that range of characters would, IMO, yield the same answer -- single-letter domains are just not a good idea and two-letter ones near the top of the tree should be used only with great caution. On the other hand, the same reasoning would break down when confronted with a script that contains thousands of characters, such as the ideographic ones. There are enough characters available in those scripts that one can presumably not worry about single-character typing errors (and one can perhaps worry even less if the usual input methods involve typing phonetically, using a different script, and then selecting the relevant characters from a menu -- in those cases, the phonetic representations are typically more than a character or two long and the menu selection provides an extra check about false matches). john --On Thursday, 03 July, 2008 19:04 -0400 Vint Cerf [EMAIL PROTECTED] wrote: seems odd to me too, James.
RE: Single-letter names (was: Re: Update of RFC 2606 based on the recent ICANN changes?)
Regarding single Unicode code-point labels at the TLD level, there was quite some discussion on this topic at the GNSO Reserved Names working group and then at the new gTLD discussion. The final recommendation from the GNSO was: Single and two-character U-labels on the top level and second level of a domain name should not be restricted in general. At the top level, requested strings should be analyzed on a case-by-case basis in the new gTLD process depending on the script and language used in order to determine whether the string should be granted for allocation in the DNS. Single and two character labels at the second level and the third level if applicable should be available for registration, provided they are consistent with the IDN Guidelines. As for ASCII, the recommendation was: We recommend reservation of single letters at the top level based on technical questions raised. If sufficient research at a later date demonstrates that the technical issues and concerns are addressed, the topic of releasing reservation status can be reconsidered. Edmon -Original Message- From: [EMAIL PROTECTED] [mailto:idna-update- [EMAIL PROTECTED] On Behalf Of Vint Cerf Sent: Saturday, July 05, 2008 3:33 AM To: John C Klensin Cc: James Seng; [EMAIL PROTECTED]; ietf@ietf.org; Lyman Chapin Subject: Re: Single-letter names (was: Re: Update of RFC 2606 based on the recent ICANN changes?) john, my reaction was specific to IDN single character TLDs. In some languages these are complete words. vint On Jul 4, 2008, at 1:50 PM, John C Klensin wrote: Vint, In the ASCII space, there have been three explanations offered historically for the one-character prohibition on top and second-level domains. I've written variations on this note several times, so will just try to summarize here. Of the three, the first of these is at best of only historical interest and may be apocryphal and the second is almost certainly no longer relevant. The third remains significant. (1) Jon has been quoted as suggesting that we could have eliminated many of the problems we now face with TLDs and simultaneously made the no real semantics in TLD names rule much more clear had we initially allocated b..y as TLDs. Then, when someone asked for an assignment, it would have been allocated at random to one of those domains. While this has a certain amount of appeal, at least in retrospect, there is probably no way to get from where we are today to that model... unless actions taken in the near future so ruin the current DNS tree as a locus for stable and predictable references that we need to start over with a new tree. I don't think that a have to start over scenario is at all likely, but I no long believe it to be impossible. (2) There was an idea floating around for a while that, if some of the popular TLDs filled up, one could create single-letter subdomains and push subsequent registrations down the tree a bit. For example, if .COM were declared full, then a.com, b.com, etc., would be allocated and additional reservations pushed into subdomains of those intermediate domains rather than being registered at the second level. Until and unless the conventional wisdom that adding more names to .COM merely requires more hardware and/or bandwidth, that won't be a filled up point at which this sort of strategy could be triggered. Worse, trying to use single-letter subdomains as an expansion mechanism would raise political issues about putting latecomers at an advantage that would be, IMO, sufficient to completely kill the idea. In the current climate, I think the community would decide that it preferred a disfunctional DNS if that were ever the choice (see the start over remark above). (3) At least in the discussions that led up to RFC 1591, and probably much earlier, there were concerns about reducing the likelihood of false hits if the end user made single-character typing errors. With only 26 (or maybe 36) possible characters, it could just about be guaranteed that all of them would be registered and that _any_ typing error would yield a false match. That, in itself, has been considered sufficient to prohibit single-letter labels and, by extension, to be fairly careful about two-letter ones. There have been arguments on and off over the years as to whether this is a technical reason or an attempt to set policy. Even though the mismatches would obviously not cause the network to explode or IP to stop working, at least some of us consider the informational retrieval and information theoretic reasons to insist on more information in domain name labels in order to lower the risk of false positive matches to be fully as technical as something that would have obvious lower-level network consequences. Others --frankly especially those who see commercial advantage in getting single-letter names
Re: Update of RFC 2606 based on the recent ICANN changes ?
Lyman Chapin wrote: If it were possible to put that aside, would you have any other objection to single label hostnames? I know that at least some of the interest in new gTLDs has been expressed by companies that like the idea of using a globally-recognized trademark as a TLD - for example, [EMAIL PROTECTED] (not to imply that IBM is one of the companies that has expressed this sort of interest). What will be the impact of having, perhaps, 1) millions of entries in the root servers, and 2) constant traffic banging on those servers? Historically, the view has been that bloating the root servers in that way would be very dangerous. Counter-claims observe that .com seems to have survived with a similar storage and traffic pattern, so why should there be a problem moving the pattern up one level? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Historically, the view has been that bloating the root servers in that way would be very dangerous. Counter-claims observe that .com seems to have survived with a similar storage and traffic pattern, so why should there be a problem moving the pattern up one level? because it makes the root more expensive to run, and thereby makes the root more vulnerable to capture by people bent on making money or wielding power (and all that that entails) rather than running it as a reliable service for the benefit of the entire network. indeed, the history of .com provides many instructive examples of why the root should NOT be run the same way. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
What will be the impact of having, perhaps, 1) millions of entries in the root servers, and Let's start by considering thousands of entries, since I see little reason to expect even that many from ICANN's current plans. 2) constant traffic banging on those servers? The latest CAIDA study says: * The overall query traffic experienced by the roots continues to grow. The observed 2007 query rate and client rate was 1.5-3X above their observed values in 2006 * The proportion of invalid traffic, i.e., DNS pollution, hitting the roots is still high, over 99% of the queries should not even be sent to the root servers. We found an extremely strong correlation both years: the higher the query rate of a client, the lower the fraction of valid queries. That suggests that if the legit traffic increased by an order of magnitude, it would still be down in the noise compared to the junk. Conversely, if root server traffic is an issue, getting networks to clean up their DNS traffic would be much more effective than limiting the number of TLDs. http://www.caida.org/research/dns/roottraffic/comparison06_07.xml R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
The latest CAIDA study says: * The overall query traffic experienced by the roots continues to grow. The observed 2007 query rate and client rate was 1.5-3X above their observed values in 2006 * The proportion of invalid traffic, i.e., DNS pollution, hitting the roots is still high, over 99% of the queries should not even be sent to the root servers. We found an extremely strong correlation both years: the higher the query rate of a client, the lower the fraction of valid queries. That suggests that if the legit traffic increased by an order of magnitude, it would still be down in the noise compared to the junk. Conversely, if root server traffic is an issue, getting networks to clean up their DNS traffic would be much more effective than limiting the number of TLDs. sounds good. and why wouldn't cleaning up DNS traffic include refusing to refer any single-label query (for any record type other than NS, say) to an upstream server? Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
--On Monday, 07 July, 2008 17:19 + John Levine [EMAIL PROTECTED] wrote: ... * The proportion of invalid traffic, i.e., DNS pollution, hitting the roots is still high, over 99% of the queries should not even be sent to the root servers. We found an extremely strong correlation both years: the higher the query rate of a client, the lower the fraction of valid queries. That suggests that if the legit traffic increased by an order of magnitude, it would still be down in the noise compared to the junk. Conversely, if root server traffic is an issue, getting networks to clean up their DNS traffic would be much more effective than limiting the number of TLDs. http://www.caida.org/research/dns/roottraffic/comparison06_07. xml John, While I find this interesting, I don't see much logical or statistical justification for the belief that, if one increased (by a lot) the number of TLDs, the amount of invalid traffic would remain roughly constant, rather than increasing the multiplier. And, of course, two of the ways of having networks [to] clean up their DNS traffic depend on local caching of the root zone (see previous note) and filtering out root queries for implausible domains. Both of those are facilitated by smaller root zones and impeded by very large ones. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
the junk. Conversely, if root server traffic is an issue, getting networks to clean up their DNS traffic would be much more effective than limiting the number of TLDs. While I find this interesting, I don't see much logical or statistical justification for the belief that, if one increased (by a lot) the number of TLDs, the amount of invalid traffic would remain roughly constant, rather than increasing the multiplier. As I recall from prior surveys, the invalid traffic is largely independent of valid domains, e.g., queries from RFC1918 space (4% of all traffic at one server), repeated queries for the same nonexistent name, dynamic rDNS updates from misconfigured Windows boxes, stuff like that. And, of course, two of the ways of having networks [to] clean up their DNS traffic depend on local caching of the root zone (see previous note) and filtering out root queries for implausible domains. Both of those are facilitated by smaller root zones and impeded by very large ones. Oh, I agree. But I really don't think there's much point in worrying about root zones with millions of domains. Nothing ICANN is likely to do would raise it above thousands, and a zone with a few thousand entries should be well within the capacity of any DNS server. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor More Wiener schnitzel, please, said Tom, revealingly. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
John Levine wrote: What will be the impact of having, perhaps, 1) millions of entries in the root servers, and Let's start by considering thousands of entries, since I see little reason to expect even that many from ICANN's current plans. When making a paradigm change to a core, infrastructure mechanism, it is best to assume the worst-case conditions, rather than best. For example, I can assure you from first-hand knowledge that US$ 100K cost for a domain name a company deems desirable is not all that rare. I would certainly not assume the global limit to be a few thousand. More generally, the difference between allowing unbounded TLDs, versus limiting them by a price, involves very different strategic decision-making. The former is massive and fundamental. The latter is rather minor and likely to be viewed as tweaking. So any analysis had better be made on the assumption that limits are from more natural and persistent characteristics, rather than from a current charging or operations constraints decision. 2) constant traffic banging on those servers? * The proportion of invalid traffic, i.e., DNS pollution, hitting the roots is still high, over 99% of the queries should not even be sent to the root servers. ... That suggests that if the legit traffic increased by an order of magnitude, it would still be down in the noise compared to the junk. Not if, for example, the 99% also grew with the added legitimate traffice. Again, the operations rule I've been taught is to base analyses based on the limit of worst-case scenarios that one can tolerate, not to make assumptions about reasonableness (other than there won't be any.) d/ ps. I assume (and hope) that the real DNS root experts will weigh in on this, here, soon... -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Conversely, if root server traffic is an issue, getting networks to clean up their DNS traffic would be much more effective than limiting the number of TLDs. sounds good. and why wouldn't cleaning up DNS traffic include refusing to refer any single-label query (for any record type other than NS, say) to an upstream server? I have to congratulate you on one of the most subtle proposals to destroy the Internet that I have seen in a long time. More on that in a moment. As I recall from prior root server surveys, the invalid traffic is unambiguously bogus, e.g., queries from RFC1918 space (4% of all traffic at one server), repeated queries for the same nonexistent name, dynamic rDNS updates from misconfigured Windows boxes, stuff like that where thre is no question it's wrong. But, wow, what a can of worms would be opened by making a subtle semantic change to root DNS resolution. As I presume everyone knows, the DNS is managed via a Mexican standoff among the root server operators, ICANN, and national governments. The root servers don't have to do what ICANN says, so ICANN has (to date at least) been very careful never to ask them to do anything they might not want to do. Governments assert control over their ccTLDs, so ICANN has carefully run IANA as a purely clerical operation, with policy decisions limited to verifying that updates are indeed from the relevant governments, and the root operators have always accepted the ccTLD delegations forwarded by IANA. Nobody knows exactly what authority various governments have over various root servers, which are located in many countries all over the world. So now ICANN and/or the root servers say, we changed our mind, we're not going to resolve names without dots. So who's going to explain to the Vatican that, sorry, [EMAIL PROTECTED] doesn't work any more? Or will the US take issue when addresses @as, which is part of the US, don't work? Or France about @gp and @mq, which are as much part of France as Hawaii is part of the US? What will Hong Kong or China do when the F and I roots in Hong Kong no longer resolve http://hk/? The Philipines when the I root in Manila doesn't resolve http://ph/? I'm impressed, it never occurred to me that one could cause this much damage with such an arcane change to name resolution. That was really diabolical. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
I have to congratulate you on one of the most subtle proposals to destroy the Internet that I have seen in a long time. More on that in a moment. Maybe you should read and understand the proposal before commenting on it. I realize that it's difficult to actually be sure you understand a single sentence before writing several paragraphs - but hey, it's not much to ask. (hint: It doesn't affect ICANN or the root servers at all.) So who's going to explain to the Vatican that, sorry, [EMAIL PROTECTED] doesn't work any more? Or will the US take issue when addresses @as, which is part of the US, don't work? Or France about @gp and @mq, which are as much part of France as Hawaii is part of the US? I'd be very surprised if any of these work as-is, with any reliability. They certainly won't work for email. The assumption that fully qualified domain names contain at least one '.' is widespread in both protocol specifications and implementations. I'm impressed, it never occurred to me that one could cause this much damage with such an arcane change to name resolution. If you can cite verifiable evidence that even a single case that works reliably now, will cease to work, I'll concede that there is at least a hint of merit to your argument. e.g. an actual email address or URL that uses a single-label domain name. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Mon, Jul 07, 2008 at 01:32:10PM -0700, [EMAIL PROTECTED] wrote: If you can cite verifiable evidence that even a single case that works reliably now, will cease to work, I'll concede that there is at least a hint of merit to your argument. e.g. an actual email address or URL that uses a single-label domain name. zod:~$ ping hk PING hk (203.119.2.28): 56 data bytes 64 bytes from 203.119.2.28: icmp_seq=0 ttl=243 time=183.582 ms 64 bytes from 203.119.2.28: icmp_seq=1 ttl=243 time=195.586 ms 64 bytes from 203.119.2.28: icmp_seq=2 ttl=243 time=196.055 ms 64 bytes from 203.119.2.28: icmp_seq=3 ttl=243 time=183.091 ms ^C --- hk ping statistics --- 5 packets transmitted, 4 packets received, 20.0% packet loss round-trip min/avg/max/stddev = 183.091/189.578/196.055/6.247 ms zod:~$ whost 203.119.2.28 203.119.2.28 www.hkdnr.hk zod:~$ cat /etc/resolv.conf search isi.edu nameserver 128.9.160.161 nameserver 128.9.64.64 -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpUQFJ0NE20m.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Mon, Jul 07, 2008 at 01:38:28PM -0700, Ted Faber wrote: On Mon, Jul 07, 2008 at 01:32:10PM -0700, [EMAIL PROTECTED] wrote: If you can cite verifiable evidence that even a single case that works reliably now, will cease to work, I'll concede that there is at least a hint of merit to your argument. e.g. an actual email address or URL that uses a single-label domain name. zod:~$ ping hk PING hk (203.119.2.28): 56 data bytes 64 bytes from 203.119.2.28: icmp_seq=0 ttl=243 time=183.582 ms Sorry. Typo. I mean: zod:/auto/boreas/jade/faber$ dig hk ; DiG 9.4.2 hk ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 34376 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 15, ADDITIONAL: 5 ;; QUESTION SECTION: ;hk.IN A ;; ANSWER SECTION: hk. 604392 IN A 203.119.2.28 ;; AUTHORITY SECTION: hk. 604392 IN NS ADNS2.BERKELEY.EDU. hk. 604392 IN NS TLD5.ULTRADNS.INFO. hk. 604392 IN NS TLD1.ULTRADNS.NET. hk. 604392 IN NS ADNS1.BERKELEY.EDU. hk. 604392 IN NS TLD6.ULTRADNS.CO.UK. hk. 604392 IN NS NS1.HKIRC.NET.hk. hk. 604392 IN NS B.DNS.TW. hk. 604392 IN NS NS3.CUHK.EDU.hk. hk. 604392 IN NS SEC3.APNIC.NET. hk. 604392 IN NS TLD2.ULTRADNS.NET. hk. 604392 IN NS TLD3.ULTRADNS.ORG. hk. 604392 IN NS NS2.CUHK.EDU.hk. hk. 604392 IN NS NS2.HKIRC.NET.hk. hk. 604392 IN NS TLD4.ULTRADNS.ORG. hk. 604392 IN NS NS-HK.RIPE.NET. ;; ADDITIONAL SECTION: TLD4.ULTRADNS.ORG. 36836 IN A 199.7.67.1 TLD4.ULTRADNS.ORG. 36836 IN 2001:502:100e::1 TLD3.ULTRADNS.ORG. 34966 IN A 199.7.66.1 TLD2.ULTRADNS.NET. 29696 IN A 204.74.113.1 TLD1.ULTRADNS.NET. 29696 IN A 204.74.112.1 ;; Query time: 4 msec ;; SERVER: 128.9.160.161#53(128.9.160.161) ;; WHEN: Mon Jul 7 13:43:55 2008 ;; MSG SIZE rcvd: 508 -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpJ89fJaKy6X.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Mon, Jul 07, 2008 at 01:38:28PM -0700, Ted Faber wrote: On Mon, Jul 07, 2008 at 01:32:10PM -0700, [EMAIL PROTECTED] wrote: If you can cite verifiable evidence that even a single case that works reliably now, will cease to work, I'll concede that there is at least a hint of merit to your argument. e.g. an actual email address or URL that uses a single-label domain name. zod:~$ ping hk PING hk (203.119.2.28): 56 data bytes 64 bytes from 203.119.2.28: icmp_seq=0 ttl=243 time=183.582 ms % ping hk. PING hk (203.119.2.28) 56(84) bytes of data. 64 bytes from www.hkdnr.hk (203.119.2.28): icmp_seq=1 ttl=238 time=265 ms 64 bytes from www.hkdnr.hk (203.119.2.28): icmp_seq=2 ttl=238 time=265 ms Not very reliably, I think. :-) - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Mon, Jul 07, 2008 at 01:44:28PM -0700, Ted Faber wrote: On Mon, Jul 07, 2008 at 01:38:28PM -0700, Ted Faber wrote: On Mon, Jul 07, 2008 at 01:32:10PM -0700, [EMAIL PROTECTED] wrote: If you can cite verifiable evidence that even a single case that works reliably now, will cease to work, I'll concede that there is at least a hint of merit to your argument. e.g. an actual email address or URL that uses a single-label domain name. zod:~$ ping hk PING hk (203.119.2.28): 56 data bytes 64 bytes from 203.119.2.28: icmp_seq=0 ttl=243 time=183.582 ms Sorry. Typo. I mean: zod:/auto/boreas/jade/faber$ dig hk ; DiG 9.4.2 hk ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 34376 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 15, ADDITIONAL: 5 ;; QUESTION SECTION: ;hk. IN A ;; ANSWER SECTION: hk. 604392 IN A 203.119.2.28 ;; AUTHORITY SECTION: hk. 604392 IN NS ADNS2.BERKELEY.EDU. hk. 604392 IN NS TLD5.ULTRADNS.INFO. hk. 604392 IN NS TLD1.ULTRADNS.NET. hk. 604392 IN NS ADNS1.BERKELEY.EDU. hk. 604392 IN NS TLD6.ULTRADNS.CO.UK. hk. 604392 IN NS NS1.HKIRC.NET.hk. hk. 604392 IN NS B.DNS.TW. hk. 604392 IN NS NS3.CUHK.EDU.hk. hk. 604392 IN NS SEC3.APNIC.NET. hk. 604392 IN NS TLD2.ULTRADNS.NET. hk. 604392 IN NS TLD3.ULTRADNS.ORG. hk. 604392 IN NS NS2.CUHK.EDU.hk. hk. 604392 IN NS NS2.HKIRC.NET.hk. hk. 604392 IN NS TLD4.ULTRADNS.ORG. hk. 604392 IN NS NS-HK.RIPE.NET. ;; ADDITIONAL SECTION: TLD4.ULTRADNS.ORG.36836 IN A 199.7.67.1 TLD4.ULTRADNS.ORG.36836 IN 2001:502:100e::1 TLD3.ULTRADNS.ORG.34966 IN A 199.7.66.1 TLD2.ULTRADNS.NET.29696 IN A 204.74.113.1 TLD1.ULTRADNS.NET.29696 IN A 204.74.112.1 ;; Query time: 4 msec ;; SERVER: 128.9.160.161#53(128.9.160.161) ;; WHEN: Mon Jul 7 13:43:55 2008 ;; MSG SIZE rcvd: 508 -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG also... % dig version.bind txt chaos @128.9.160.161 ; DiG 8.3 version.bind txt chaos @128.9.160.161 ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;; version.bind, type = TXT, class = CHAOS ;; ANSWER SECTION: version.bind. 0S CHAOS TXT9.4.2 ;; AUTHORITY SECTION: version.bind. 0S CHAOS NS version.bind. so - recent resolver code does this trick. ob. Unexpected attachment on this mail? - I was actually expecting an attachment that was not there. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
--On Monday, 07 July, 2008 09:24 -0700 Dave Crocker [EMAIL PROTECTED] wrote: Lyman Chapin wrote: If it were possible to put that aside, would you have any other objection to single label hostnames? I know that at least some of the interest in new gTLDs has been expressed by companies that like the idea of using a globally-recognized trademark as a TLD - for example, [EMAIL PROTECTED] (not to imply that IBM is one of the companies that has expressed this sort of interest). What will be the impact of having, perhaps, 1) millions of entries in the root servers, and 2) constant traffic banging on those servers? Historically, the view has been that bloating the root servers in that way would be very dangerous. Counter-claims observe that .com seems to have survived with a similar storage and traffic pattern, so why should there be a problem moving the pattern up one level? To answer your question with a question... At least one rather popular DNS server implementation on a popular platform now comes with initial configuration files that strongly suggest local caching of the entire root zone file. Although it may not be a universally good recommendation (and the config file is careful to note that), it is entirely reasonable and practical for many or most situations. What do you think would happen to that recommendation, and the benefits it affords, if the size of the root zone increased by an order of magnitude or so? Think ICANN (or anyone else) has done traffic projections on what would happen if the root zone were cached at many locations on the network but had, not only the same size but roughly the same volatility (e.g., updates due to changes in servers or services) as COM does today and, if so, what those analyses suggest? john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Mon, Jul 07, 2008 at 05:01:30PM -0400, Theodore Tso wrote: On Mon, Jul 07, 2008 at 01:38:28PM -0700, Ted Faber wrote: On Mon, Jul 07, 2008 at 01:32:10PM -0700, [EMAIL PROTECTED] wrote: If you can cite verifiable evidence that even a single case that works reliably now, will cease to work, I'll concede that there is at least a hint of merit to your argument. e.g. an actual email address or URL that uses a single-label domain name. zod:~$ ping hk PING hk (203.119.2.28): 56 data bytes 64 bytes from 203.119.2.28: icmp_seq=0 ttl=243 time=183.582 ms % ping hk. PING hk (203.119.2.28) 56(84) bytes of data. 64 bytes from www.hkdnr.hk (203.119.2.28): icmp_seq=1 ttl=238 time=265 ms 64 bytes from www.hkdnr.hk (203.119.2.28): icmp_seq=2 ttl=238 time=265 ms Not very reliably, I think. :-) Umm, hk. resolves to the same address from both our machines and is pingable (modulo a single packet loss from yours, depending on how your ping counts) from both. http://hk pulls up a web page on a machine with the same address. (www.hkdnr.hk is an alias for hk. - the same machine; you're not being redirected.) That's at least as reliable as my (multi-dotted) home domain. :-) I'm not sure what's not to like here. But then again, I may be blind. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpWT4maVlZLJ.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Mon, Jul 07, 2008 at 02:04:31PM -0700, Bill Manning wrote: On Mon, Jul 07, 2008 at 01:44:28PM -0700, Ted Faber wrote: On Mon, Jul 07, 2008 at 01:38:28PM -0700, Ted Faber wrote: On Mon, Jul 07, 2008 at 01:32:10PM -0700, [EMAIL PROTECTED] wrote: also... % dig version.bind txt chaos @128.9.160.161 ;; ANSWER SECTION: version.bind. 0S CHAOS TXT9.4.2 so - recent resolver code does this trick. Fair enough. Perils of working for ISI, I suppose - modern infrastructure. Not to argue with someone who's forgotten more about DNS than I know, but I was able to get it to work from zig.usc.edu as well. On zig (a Linux box talking to an ambiguously identified USC Bind 9x server) ping needed the trailing dot on hk. to work. And by got it to work, I mean typed ping. I also had no trouble on a FreeBSD machine talking to bind 9.3.3. It works at home, too, but that's also a 9.4.2 bind. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpx0LrLE3xNp.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Umm, hk. resolves to the same address from both our machines and is pingable (modulo a single packet loss from yours, depending on how your ping counts) from both. http://hk pulls up a web page on a machine with the same address. interesting. I had actually tried that URL before sending the last message, and from where I tried it, it failed. trying it again just now, from my home network, it works. so the sample size is small but I'm still in doubt that this works reliably. and even if there is a hint of merit to John's argument, John's claim that it would destroy the Internet, or even do it significant harm, seems utterly preposterous. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Mon, Jul 07, 2008 at 02:13:47PM -0700, Ted Faber wrote: On Mon, Jul 07, 2008 at 05:01:30PM -0400, Theodore Tso wrote: On Mon, Jul 07, 2008 at 01:38:28PM -0700, Ted Faber wrote: On Mon, Jul 07, 2008 at 01:32:10PM -0700, [EMAIL PROTECTED] wrote: If you can cite verifiable evidence that even a single case that works reliably now, will cease to work, I'll concede that there is at least a hint of merit to your argument. e.g. an actual email address or URL that uses a single-label domain name. zod:~$ ping hk PING hk (203.119.2.28): 56 data bytes 64 bytes from 203.119.2.28: icmp_seq=0 ttl=243 time=183.582 ms % ping hk. PING hk (203.119.2.28) 56(84) bytes of data. 64 bytes from www.hkdnr.hk (203.119.2.28): icmp_seq=1 ttl=238 time=265 ms 64 bytes from www.hkdnr.hk (203.119.2.28): icmp_seq=2 ttl=238 time=265 ms Not very reliably, I think. :-) Sorry, I cut and paste the wrong example. What I had meant to cut and paste: 5% ping hk PING hk.ibm.com (9.190.250.244) 56(84) bytes of data. ... - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Theodore Tso wrote: On Mon, Jul 07, 2008 at 02:13:47PM -0700, Ted Faber wrote: On Mon, Jul 07, 2008 at 05:01:30PM -0400, Theodore Tso wrote: On Mon, Jul 07, 2008 at 01:38:28PM -0700, Ted Faber wrote: On Mon, Jul 07, 2008 at 01:32:10PM -0700, [EMAIL PROTECTED] wrote: If you can cite verifiable evidence that even a single case that works reliably now, will cease to work, I'll concede that there is at least a hint of merit to your argument. e.g. an actual email address or URL that uses a single-label domain name. zod:~$ ping hk PING hk (203.119.2.28): 56 data bytes 64 bytes from 203.119.2.28: icmp_seq=0 ttl=243 time=183.582 ms % ping hk. PING hk (203.119.2.28) 56(84) bytes of data. 64 bytes from www.hkdnr.hk (203.119.2.28): icmp_seq=1 ttl=238 time=265 ms 64 bytes from www.hkdnr.hk (203.119.2.28): icmp_seq=2 ttl=238 time=265 ms Not very reliably, I think. :-) Sorry, I cut and paste the wrong example. What I had meant to cut and paste: 5% ping hk PING hk.ibm.com (9.190.250.244) 56(84) bytes of data. ... - Ted With your hk.ibm.com example, do you have any search lines in your /etc/resolv.conf file that would be automatically appending? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
I guess you've heard the old joke which asks How could God create the world in only seven days? - Because He had no installed base. If we move this thread up one level of abstraction much of the conversation is asking the question of how strongly we respect the installed base of software out there on the net. Do we have any principles we can use to guide our choice of where we put the needle along the continuum from no change, no way to any and every change is allowed? --karl-- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Mon, Jul 07, 2008 at 03:56:10PM -0600, Willie Gillespie wrote: With your hk.ibm.com example, do you have any search lines in your /etc/resolv.conf file that would be automatically appending? Of course! That was my point about why http://hk; or ping hk is not going to be terribly reliable. If you think people are going to type http://hk.;, I can probably come up with Web 2.0 startup that you could fund, if you're not interested in purchasing a certain bridge in New York City... :-) - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Mon, Jul 07, 2008 at 05:42:14PM -0400, Theodore Tso wrote: 5% ping hk PING hk.ibm.com (9.190.250.244) 56(84) bytes of data. ... I can do that with hk.com, too, as you know. I think it's a feature. YMMV. My point is that from my minimal sample, hk seems to work about the same as any other DNS name. I believe that was in dispute. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpJ2ZEDjEgl9.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Mon, Jul 07, 2008 at 02:25:31PM -0700, Ted Faber wrote: On Mon, Jul 07, 2008 at 02:04:31PM -0700, Bill Manning wrote: On Mon, Jul 07, 2008 at 01:44:28PM -0700, Ted Faber wrote: On Mon, Jul 07, 2008 at 01:38:28PM -0700, Ted Faber wrote: On Mon, Jul 07, 2008 at 01:32:10PM -0700, [EMAIL PROTECTED] wrote: also... % dig version.bind txt chaos @128.9.160.161 ;; ANSWER SECTION: version.bind. 0S CHAOS TXT9.4.2 so - recent resolver code does this trick. Fair enough. Perils of working for ISI, I suppose - modern infrastructure. Not to argue with someone who's forgotten more about DNS than I know, but I was able to get it to work from zig.usc.edu as well. On zig (a Linux box talking to an ambiguously identified USC Bind 9x server) ping needed the trailing dot on hk. to work. And by got it to work, I mean typed ping. I also had no trouble on a FreeBSD machine talking to bind 9.3.3. It works at home, too, but that's also a 9.4.2 bind. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG so... the point i was tryig to make was/is: simple queries only help if you know: ) the version of software running on your caching server and ) the search list defined by your resolv.conf zig.usc.edu, boreas.isi.edu, luna-base.org, ep.net, lcs.mit.edu, comcast.net, all run slightly different caching code and variable search lists. you, me, Ted, Keith, John, et.al. are going to see -slightly- different responses when presenting our individual local caching servers with non-terminated DNS strings. Japp and Karl both hinted at this problem - local policy is the worst policy, except for all the others. Your local DNS admin can (and occasionally they do) toss you into a random walled-DNS garden that has only a passing similarity to what you think of as the Internet. http://www.icann.org/committees/security/sac032.pdf is illustrative. -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Mon, Jul 07, 2008 at 03:49:53PM -0700, Bill Manning wrote: so... the point i was tryig to make was/is: simple queries only help if you know: ) the version of software running on your caching server and ) the search list defined by your resolv.conf Fair enough. (I did include the resolv.conf in the first example, but hadn't considered the caching server.) And I understand how a DNS name without a dot in it can be confusing. Even with a dot in there, DNS admins (or DHCP spoofers) can put you into a walled garden pretty easily, though. I'm not sure I see any great benefit to using the undotted names - the dot really indicates the Internet brand pretty strongly - but it seems to function in the environments I have easy access to. I was primarily responding to the fellow who doubted the practicality of the idea, not endorsing it. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpztwOP6Nr7P.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
--===1515233305== Content-Type: multipart/signed; micalg=pgp-sha1; protocol=application/pgp-signature; boundary=tsOsTdHNUZQcU9Ye Content-Disposition: inline --tsOsTdHNUZQcU9Ye Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 07, 2008 at 05:01:30PM -0400, Theodore Tso wrote: On Mon, Jul 07, 2008 at 01:38:28PM -0700, Ted Faber wrote: On Mon, Jul 07, 2008 at 01:32:10PM -0700, [EMAIL PROTECTED] wr= ote: If you can cite verifiable evidence that even a single case that works reliably now, will cease to work, I'll concede that there is at least a hint of merit to your argument. e.g. an actual email address or URL that uses a single-label domain name. =20 zod:~$ ping hk PING hk (203.119.2.28): 56 data bytes 64 bytes from 203.119.2.28: icmp_seq=3D0 ttl=3D243 time=3D183.582 ms =20 % ping hk. PING hk (203.119.2.28) 56(84) bytes of data. 64 bytes from www.hkdnr.hk (203.119.2.28): icmp_seq=3D1 ttl=3D238 time=3D= 265 ms 64 bytes from www.hkdnr.hk (203.119.2.28): icmp_seq=3D2 ttl=3D238 time=3D= 265 ms =20 Not very reliably, I think. :-) Umm, hk. resolves to the same address from both our machines and is pingable (modulo a single packet loss from yours, depending on how your ping counts) from both. http://hk pulls up a web page on a machine with the same address. (www.hkdnr.hk is an alias for hk. - the same machine; you're not being redirected.) That's at least as reliable as my (multi-dotted) home domain. :-) I'm not sure what's not to like here. But then again, I may be blind. The point is that it is NOT reliable. Whether it works depends apon what names are matched in the search list. It does work for some people some of the time. It does not work for all of the world all of the time. hk is not globally unique. bsdi# ping hk PING hk.dv.isc.org (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.148 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.170 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.172 ms ^C --- hk.dv.isc.org ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.148/0.163/0.172/0.011 ms bsdi# --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --tsOsTdHNUZQcU9Ye Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkhyhwsACgkQaUz3f+Zf+Xu/JQCg0bBCl+ufJrXaLx7X+qsE3Jfk nhUAoKdEtfZ+47v4Uu+MCHng2R+A5anJ =Xp3s -END PGP SIGNATURE- --tsOsTdHNUZQcU9Ye-- --===1515233305== Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf --===1515233305==-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Bill Manning wrote: http://www.icann.org/committees/security/sac032.pdf is illustrative. | entrusted agents should provide opt-out mechanisms that | allows clients to receive the original DNS answers to | their queries. [...] | Organizations that rely on accurate NXDomain reporting | for operational stability should choose an entrusted | agent that asserts it will not modify DNS responses in | its terms of service. Certainly illustrative , but not affecting 2606bis ;-) Frank ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
John C Klensin wrote: What do you think would happen to that recommendation, and the benefits it affords, if the size of the root zone increased by an order of magnitude or so? 2 orders? 20K? No, sorry. Think 3-4 orders of magnitude. Really. Let me explain: I'm not against more TLDs. Quite the opposite. (I appointed by Postel to participate in the pre-ICANN committee tasked with increasing the number.) But there is a paradigmatic difference between a TLD defined and operated to mediate on behalf of a general and diverse population, versus one constrained to a narrow and controlled constituency, such as a single company. The number of the latter is quite large. And by that I mean *really* large. And all of the questions I asked 10 years ago said that TLDs on that latter scale would be problematic to the root. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
And all of the questions I asked 10 years ago said that TLDs on that latter scale would be problematic to the root. Was that pre-Anycast or post-Anycast? -James Seng ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Tue, Jul 08, 2008 at 10:18:25AM +1000, Mark Andrews wrote: That's at least as reliable as my (multi-dotted) home domain. :-) =20 I'm not sure what's not to like here. But then again, I may be blind. =20 The point is that it is NOT reliable. Whether it works depends apon what names are matched in the search list. It does work for some people some of the time. It does not work for all of the world all of the time. hk is not globally unique. That statement is also true for hk.com, ibm.com, google.com, or any other relative DNS name. The site-dependent interpretation of the name is determined not by the presence of dot within the name but its absence from the end. hk. is as global as hk.com. with respect to the search list; hk and hk.com are both relative names and their resolution is resolver dependent. I don't buy unreliable as a diagnosis for that state of affairs. hk operates exactly as any other DNS name with respect to search path. An incautious user or clever DNS administrator can create a confusing state of affairs with or without the interior dot. (As Bill Manning hinted, there may be other parts of the resolution code that are less reliable for names without a dot in them. That I might buy as an argument for unreliability).=20 If you'd like to argue something more subjective like confusing or even misleading, you'll find no resistance from me. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG The point of going to heirachical names (RFC 921) is to remove abmiguity. tlds don't meet the definition of a heirachical name. It is time that tld operators stopped mis-using the zones they operate. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
The site-dependent interpretation of the name is determined not by the presence of dot within the name but its absence from the end. No. Please go and re-read RFC 921. hk. is as global as hk.com. with respect to the search list; hk and hk.com are both relative names and their resolution is resolver dependent. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
--YD3LsXFS42OYHhNZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 08, 2008 at 11:47:15AM +1000, Mark Andrews wrote: =20 The site-dependent interpretation of the name is determined not by the presence of dot within the name but its absence from the end. =20 No. Please go and re-read RFC 921. What a charming document. I don't see anything in it that indicates a hierarchical name can't consist of one level, though I see plenty of examples of 2-level names. If you see text in there that I missed, I'm all ears. I do see this in RFC 1035, though: When a user needs to type a domain name, the length of each label is omitted and the labels are separated by dots (.). Since a complete domain name ends with the root label, this leads to a printed form which ends in a dot. We use this property to distinguish between: - a character string which represents a complete domain name (often called absolute). For example, poneria.ISI.EDU. - a character string that represents the starting labels of a domain name which is incomplete, and should be completed by local software using knowledge of the local domain (often called relative). For example, poneria used in the ISI.EDU domain. Relative names are either taken relative to a well known origin, or to a list of domains used as a search list. Relative names appear mostly at the user interface, where their interpretation varies from implementation to implementation, and in master files, where they are relative to a single origin domain name. The most common interpretation uses the root . as either the single origin or as one of the members of the search list, so a multi-label relative name is often one where the trailing dot has been omitted to save typing. That sounds a lot to me like hk. is as global as hk.com. hk. is not a syntactically valid hostname (RFC 952). hk. is not a syntactically valid mail domain. Periods at the end are not legal. RFC 1035 has *nothing* to do with defining what is legal as a hostname. Mark --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On 7 Jul 2008, at 21:36, James Seng wrote: And all of the questions I asked 10 years ago said that TLDs on that latter scale would be problematic to the root. Was that pre-Anycast or post-Anycast? There are plenty of examples of people hosting large, infrastructure- type zones using servers and software that are conventional, commodity choices. NSD and BIND9 are both quite capable of hosting zones with single-digit millions of delegations without needing special care and feeding, for example. Whether the DNS service for a zone is anycast or not has some, but really not that much relevance when you're considering the risk of an engorged root zone. I don't read anything in the layer-9 musings I've seen so far to suggest that the bar to entry for new TLDs will be so low that we'll see widespread TLD tasting and churn, for example, sufficient to make far-flung anycast instances struggle to keep up. I'm not suggesting that growth should be allowed to happen without considering the technical consequences. However, I believe in practice with the headroom in systems and network that root server operators generally install anyway, there's considerable room for growth and the general argument that growth in the root zone will undermine stability sounds more like hysteria than science. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
The site-dependent interpretation of the name is determined not by the presence of dot within the name but its absence from the end. not so. in many contexts the trailing dot is not valid syntax. I don't buy unreliable as a diagnosis for that state of affairs. hk operates exactly as any other DNS name with respect to search path. search path isn't the only factor here. there are also protocol specifications that expect DNS names to have dots in them. there are also software implementations that use the presence/absence of a dot to distinguish a DNS name from some other kind of name. in any context where both a DNS name and something else can appear, it's useful to be able to distinguish the two - and the presence/absence of a dot is about the only test that works. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Joe, On 2008-07-08 14:55, Joe Abley wrote: ... I'm not suggesting that growth should be allowed to happen without considering the technical consequences. However, I believe in practice with the headroom in systems and network that root server operators generally install anyway, there's considerable room for growth 'Considerable' isn't science. How many orders of magnitude do we have good reason to believe is OK? and the general argument that growth in the root zone will undermine stability sounds more like hysteria than science. No, it sounds like an absence of science. All we know is that we are somewhere between 'considerable room for growth' and 'undermining stability.' Frankly I don't think we have any more idea of the answer to that than we did on 23 Feb 1998 when the IAB wrote to Ira Magaziner (http://www.ietf.org/mail-archive/web/ietf/current/msg04154.html): On the other hand, a very large increase in the total number of gTLDs (say to thousands) would lead us into technically unknown territory. I suggest that there is some urgency in conducting a data-based study of where the limit to stability lies. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Jul 7, 2008, at 10:49 AM, John C Klensin wrote: --On Monday, 07 July, 2008 17:19 + John Levine [EMAIL PROTECTED] wrote: John, While I find this interesting, I don't see much logical or statistical justification for the belief that, if one increased (by a lot) the number of TLDs, the amount of invalid traffic would remain roughly constant, rather than increasing the multiplier. And, of course, two of the ways of having networks [to] clean up their DNS traffic depend on local caching of the root zone (see previous note) and filtering out root queries for implausible domains. Both of those are facilitated by smaller root zones and impeded by very large ones. Agreed. This is happening while some email providers suggest widespread adoption of MX resource records targeting roots to signify opting-out. Not only does this form of email opt-out unfairly burden the victim, this scheme also victimizes roots. Are roots really inexhaustible and capable of sustaining high levels of horizontal growth, and ever greater levels of DNS misuse while adopting an additional security layer? How will roots be able to block abuse once it proves destructive? From the human aspect, the list of common file extensions is mind- numbingly long. With a changing TLD landscape, one will no longer be sure whether a reference is to a file or to an Internet host. This becomes critical since automation is often used to fully construct links. Will obvious names be precluded such as .C0M, or those less obvious having international domain names? While this might help ICANN raise money, their profit seems destine to come at the expense of those currently supporting existing infrastructure. If domain tasting is an example of governance, then how can ICANN be trusted to operate in the greater interest of the Internet? It seems more reasonable to extend ccTLDs into a comparative list of international domain names where desired, and then wait a decade to measure its impact and to allow wider deployment of DNSsec. Smaller steps rather faith in ever greater capacity seems more appropriate. If DNS were to approach the ability of roots to respond, then DDoS attacks take on truly global proportions. -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
--On Tuesday, 08 July, 2008 11:47 +1000 Mark Andrews [EMAIL PROTECTED] wrote: The site-dependent interpretation of the name is determined not by the presence of dot within the name but its absence from the end. No. Please go and re-read RFC 921. This is the same RFC 921 that * is listed in the RFC Index as Status: UNKNOWN * was not even examined in the requirements review that led up to RFC 1123 and is not referenced there. * primarily talks about an implementation schedule and transition plan, not about long-term stable interpretations. ?? Isn't claiming that as an authority in 2008 a bit of a stretch? Especially since, as Ted Farber points out, text in 1035 itself seems to contradict your reading of that particular section? I believe that 952 is almost equally irrelevant wrt this argument. YMMD, of course. As Keith points out, there are lots and lots of reasons to avoid believing that dot-less strings will be interpreted as domain names consistently and in the way that users will expect. Most of them have to do with handling of names in applications, which tends to get strange in edge cases and stranger when one relies too much on having specific contents in resolver configuration files. The mere fact of inconsistent (but valid) interpretations in different applications or configurations (or even implementations of the same application) may be more than enough reason to avoid these things, or at least be very careful about them. But claiming 921 as an authority isn't one of the reasons, IMO. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
--On Tuesday, 08 July, 2008 11:47 +1000 Mark Andrews [EMAIL PROTECTED] wrote: The site-dependent interpretation of the name is determined not by the presence of dot within the name but its absence from the end. No. Please go and re-read RFC 921. This is the same RFC 921 that * is listed in the RFC Index as Status: UNKNOWN Unknown doesn't mean irrelevent. * was not even examined in the requirements review that led up to RFC 1123 and is not referenced there. RFC 1123 - RFC 952 - RFC 921 * primarily talks about an implementation schedule and transition plan, not about long-term stable interpretations. Isn't claiming that as an authority in 2008 a bit of a stretch? No. Old does not mean irrelevent. Especially since, as Ted Farber points out, text in 1035 itself seems to contradict your reading of that particular section? No. RFC 1035 applies to domain names, not hostnames. I believe that 952 is almost equally irrelevant wrt this argument. YMMD, of course. RFC 952 is the latest rfc which defines the syntax of a hostname. As Keith points out, there are lots and lots of reasons to avoid believing that dot-less strings will be interpreted as domain names consistently and in the way that users will expect. Most of them have to do with handling of names in applications, which tends to get strange in edge cases and stranger when one relies too much on having specific contents in resolver configuration files. The mere fact of inconsistent (but valid) interpretations in different applications or configurations (or even implementations of the same application) may be more than enough reason to avoid these things, or at least be very careful about them. But claiming 921 as an authority isn't one of the reasons, IMO. john -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Services and top-level DNS names (was: Re: Update of RFC 2606 based on the recent ICANN changes ?)
--On Friday, 04 July, 2008 09:14 +1000 Mark Andrews [EMAIL PROTECTED] wrote: Mark Andrews wrote: The Internet went to multi-label hostnames ~20 years ago. As noted in RFC 2821 as one dot required syntax, also mentioned in RFC 3696. Recently *overruled* by 2821bis. There is a difference between allowing protocol to be used in a local only mode (single label) and a global mode (multi-label) and saying you must support single label in a global context. Single label names are local in scope. Attempting to use them in a global context does not work. As the names in . get more interesting the probability of collisions with existing names goes up. Not many people choose two letter labels for the least significant parts of their host names unless they are choosing their initials. Museum on the other hand is a real English word. I'm sure you will find lots other uses of museum in the DNS. The same thing will happen with other TLD's as the rules are relaxed. Single label hostnames are not globally unique. They SHOULD NOT be used in a context where globally unique names are required. Mark, With the understanding that I agree with everything you say above, there are some interesting problems with SMTP (and maybe some other protocols) as well as with how ICANN is proceeding. In no particular order... (1) ICANN is well aware of the problem you mention with museum and presumably with coop, jobs, name, and maybe some others I've forgotten at the moment. As I understand it, they have explicitly decided to ignore that problem except for names of countries. The problem also gets orders of magnitude worse as we move to IDNs, especially it we also consider transliterations of non-ASCII strings into scripts other than the those to which the relevant word is native (whatever that means -- the concept is extremely dubious for some languages). Whether the decision to enable the searching risks associated with the use of names, rather than short mnemonics of pre-specified length, is the result of realizing that the problem is hopelessly intractable (it is) or the result of rampant commercialism is probably in the eye of the beholder. (2) Regardless of what some of us may think about the desirability (or not) of associating services with TLD names, as soon as we accept the idea that top-level domain names have semantic content and are associated with fields of endeavor, types of organizations or enterprises, etc., the desire to associate, e.g., directory services or help functions with the TLD follows almost naturally. For years, we managed to dodge that problem with conventional subdomains (e.g., nic.example.), but we have not, to my knowledge, ever promoted those uses via, e.g., a BCP that strongly recommends them (unlike the email case, where RFC2142 does just that). In the absence of reserved-name recommendations strong enough to substitute for services associated with TLDs (and the horse has probably let the barn on doing that), I think it is inevitable that we will see more and more demand for the functionality implied by some-protocol://TLD-name./ (with or without that trailing dot). Some sort of directory service for the domain is the obvious case, but there are others. I can think of only three ways to get that functionality: (i) Associate services with the TLD in the DNS. (ii) Install a TLD wildcard that points to the relevant services (and pray that it doesn't point to anything else) (iii) Reserve conventional subdomain names so that an application can turn some-protocol://TLD-name/ into, e.g., some-protocol://some-protocol.TLD-name/ But, as discussed above, I believe we have waited much too long to do anything effective about the third possibility. And simply saying this is a bad way to use the DNS is clearly not going to get us anywhere in the current environment, even if it were true. (3) SMTP does not permit an explicit trailing period in addresses on the wire, so RCPT TO:[EMAIL PROTECTED] is a syntax error. RFC 2821 permitted it (as Frank points out), unlike RFC 821 (which, I think, predated the discovery that being able to explicitly specify the root was sometimes important). Discussion about 2821bis concluded that permitting the trailing period caused more problems than it solved, so we are back to not permitting it. What 2821bis says in essence is that it is the responsibility of the sending application to figure out whether, if a user presents [EMAIL PROTECTED], that implies the example TLD or an invitation to start searching. The application is expected to provide local syntax when necessary to assist in making that distinction. So, much as I'd like it if we could say Single label names are local in scope...does not work, I fear that it is
Re: Update of RFC 2606 based on the recent ICANN changes ?
There is a difference between allowing protocol to be used in a local only mode (single label) and a global mode (multi-label) and saying you must support single label in a global context. If a protocol is used in a global mode, the problem with trying to use it in a tailored, local mode is that the various defaults of the local context are not carried with the data that escapes into the global context. There must be perfect gatewaying between the two contexts and this almost never achieved. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Services and top-level DNS names (was: Re: Update of RFC 2606 based on the recent ICANN changes ?)
Single label names are local in scope. Attempting to use them in a global context does not work. As the names in . get more interesting the probability of collisions with existing names goes up. Not many people choose two letter labels for the least significant parts of their host names unless they are choosing their initials. Single label hostnames are not globally unique. They SHOULD NOT be used in a context where globally unique names are required. Mark, With the understanding that I agree with everything you say above, there are some interesting problems Referring to the point Mark is making as a problem is a bit like saying that someone attempting to sell the Brooklyn Bridge has a problem. While the potential bridge purchaser may in fact very much desire to own the bridge, the problem is that the seller may not in fact have the right to sell it. That's really at the core of what Mark is arguing -- that various RFCs allocate single-label names for local use, and therefore that ICANN may not possess the right to sell that property to another party. (1) ICANN is well aware of the problem you mention As I understand it, they have explicitly decided to ignore that problem... Someone attempting to sell the Brooklyn Bridge can also explicitly decide to ignore the problem of whether they in fact own it. That won't make the problem go away. In this particular case, we are talking about RFCs that are included as requirements for purchase worth billions of dollars annually, as well as local names currently in local use by hundreds of millions of people. So we're not talking about selling a single Brooklyn Bridge here, but many. (2) Regardless of what some of us may think about the desirability (or not) of associating services with TLD names The issue is not desirability. Someone might very much desire to purchase the Brooklyn Bridge. It has many excellent qualities -- it is used by many people over the course of a day, it is a registered historical site making it of great interest to tourists, etc. The problem is whether the seller can establish title. So, much as I'd like it if we could say Single label names are local in scope...does not work Mark's point is that several RFCs already say this. So what we have here isn't really an technical argument or one about desirability -- it's a property rights argument. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Single-letter names (was: Re: Update of RFC 2606 based on the recent ICANN changes?)
Vint, In the ASCII space, there have been three explanations offered historically for the one-character prohibition on top and second-level domains. I've written variations on this note several times, so will just try to summarize here. Of the three, the first of these is at best of only historical interest and may be apocryphal and the second is almost certainly no longer relevant. The third remains significant. (1) Jon has been quoted as suggesting that we could have eliminated many of the problems we now face with TLDs and simultaneously made the no real semantics in TLD names rule much more clear had we initially allocated b..y as TLDs. Then, when someone asked for an assignment, it would have been allocated at random to one of those domains. While this has a certain amount of appeal, at least in retrospect, there is probably no way to get from where we are today to that model... unless actions taken in the near future so ruin the current DNS tree as a locus for stable and predictable references that we need to start over with a new tree. I don't think that a have to start over scenario is at all likely, but I no long believe it to be impossible. (2) There was an idea floating around for a while that, if some of the popular TLDs filled up, one could create single-letter subdomains and push subsequent registrations down the tree a bit. For example, if .COM were declared full, then a.com, b.com, etc., would be allocated and additional reservations pushed into subdomains of those intermediate domains rather than being registered at the second level. Until and unless the conventional wisdom that adding more names to .COM merely requires more hardware and/or bandwidth, that won't be a filled up point at which this sort of strategy could be triggered. Worse, trying to use single-letter subdomains as an expansion mechanism would raise political issues about putting latecomers at an advantage that would be, IMO, sufficient to completely kill the idea. In the current climate, I think the community would decide that it preferred a disfunctional DNS if that were ever the choice (see the start over remark above). (3) At least in the discussions that led up to RFC 1591, and probably much earlier, there were concerns about reducing the likelihood of false hits if the end user made single-character typing errors. With only 26 (or maybe 36) possible characters, it could just about be guaranteed that all of them would be registered and that _any_ typing error would yield a false match. That, in itself, has been considered sufficient to prohibit single-letter labels and, by extension, to be fairly careful about two-letter ones. There have been arguments on and off over the years as to whether this is a technical reason or an attempt to set policy. Even though the mismatches would obviously not cause the network to explode or IP to stop working, at least some of us consider the informational retrieval and information theoretic reasons to insist on more information in domain name labels in order to lower the risk of false positive matches to be fully as technical as something that would have obvious lower-level network consequences. Others --frankly especially those who see commercial advantage in getting single-letter names-- have argued that this position is just a policy decision in disguise. Note that, with slight modifications, the second and third arguments apply equally well to TLD allocations and to SLD allocations, especially in popular domains. The reasoning associated with the third case also applies to any other script that contains a fairly small number of characters. One could manage a long philosophical discussion as to whether there are sufficient characters in the fully-decorated Latin-derived collection to eliminate the problem, but an analysis of keyboard and typing techniques/ input methods for that range of characters would, IMO, yield the same answer -- single-letter domains are just not a good idea and two-letter ones near the top of the tree should be used only with great caution. On the other hand, the same reasoning would break down when confronted with a script that contains thousands of characters, such as the ideographic ones. There are enough characters available in those scripts that one can presumably not worry about single-character typing errors (and one can perhaps worry even less if the usual input methods involve typing phonetically, using a different script, and then selecting the relevant characters from a menu -- in those cases, the phonetic representations are typically more than a character or two long and the menu selection provides an extra check about false matches). john --On Thursday, 03 July, 2008 19:04 -0400 Vint Cerf [EMAIL PROTECTED] wrote: seems odd to me too, James. vint On Jul 3, 2008, at 6:14 PM, James Seng wrote: At the moment, the condition is no single Unicode code point. To the extent that a single CJK ideograph
RE: Services and top-level DNS names (was: Re: Update of RFC 2606 based on the recent ICANN changes ?)
--On Friday, 04 July, 2008 10:49 -0700 Bernard Aboba [EMAIL PROTECTED] wrote: Single label names are local in scope. Attempting to use them in a global context does not work. As the names in . get more interesting the probability of collisions with existing names goes up. Not many people choose two letter labels for the least significant parts of their host names unless they are choosing their initials. Single label hostnames are not globally unique. They SHOULD NOT be used in a context where globally unique names are required. Mark, With the understanding that I agree with everything you say above, there are some interesting problems Referring to the point Mark is making as a problem is a bit like saying that someone attempting to sell the Brooklyn Bridge has a problem. While the potential bridge purchaser may in fact very much desire to own the bridge, the problem is that the seller may not in fact have the right to sell it. That's really at the core of what Mark is arguing -- that various RFCs allocate single-label names for local use, and therefore that ICANN may not possess the right to sell that property to another party. (1) ICANN is well aware of the problem you mention As I understand it, they have explicitly decided to ignore that problem... Someone attempting to sell the Brooklyn Bridge can also explicitly decide to ignore the problem of whether they in fact own it. That won't make the problem go away. In this particular case, we are talking about RFCs that are included as requirements for purchase worth billions of dollars annually, as well as local names currently in local use by hundreds of millions of people. So we're not talking about selling a single Brooklyn Bridge here, but many. (2) Regardless of what some of us may think about the desirability (or not) of associating services with TLD names The issue is not desirability. Someone might very much desire to purchase the Brooklyn Bridge. It has many excellent qualities -- it is used by many people over the course of a day, it is a registered historical site making it of great interest to tourists, etc. The problem is whether the seller can establish title. So, much as I'd like it if we could say Single label names are local in scope...does not work Mark's point is that several RFCs already say this. So what we have here isn't really an technical argument or one about desirability -- it's a property rights argument. Not really. ICANN isn't selling single-label domains. They are selling (and I believe selling is probably now the correct term) plain, ordinary, TLD delegations. If I get one of those and populate the TLD zone only with delegation records, there are no problems with what ICANN has done at all, whether you describe it a property rights or in some other way. On the other hand, if they delegate one and the enterprise that buys it chooses to populate the zone with service records, then ICANN's position will certainly be that any inability to use those service records isn't ICANN's problem -- any more than difficulties using .museum or .aero were ICANN's problem when those to whom those domains were delegated discovered that a lot of applications software thought that the one TLD label of more than three characters was ARPA. So the problem isn't whether some string not listed in 2606 can be allocated, it is how it is used after it is allocated. And _that_ situation has a lot more to do about buyer beware and understanding of conflicting expectations about use than it does about ownership. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Services and top-level DNS names (was: Re: Update of RFC 2606 based on the recent ICANN changes ?)
Not really. ICANN isn't selling single-label domains. They are selling (and I believe selling is probably now the correct term) plain, ordinary, TLD delegations. If I get one of those and populate the TLD zone only with delegation records, there are no problems with what ICANN has done at all, whether you describe it as a property right or in some other way. Agreed. On the other hand, if they delegate one and the enterprise that buys it chooses to populate the zone with service records, then ICANN's position will certainly be that any inability to use those service records isn't ICANN's problem -- any more than difficulties using .museum or .aero were ICANN's problem when those to whom those domains were delegated discovered that a lot of applications software thought that the one TLD label of more than three characters was ARPA. Is generic buyer beware disclaimer really sufficient here? The problem isn't just inability to use -- it's that other parties exist who may claim the usage right, and provide citations to RFCs to back up their claim. For example, typing http://brooklynbridgepark/ into a browser utilizing a resolver compliant with RFC 1536 will bring you to the web site of Brooklyn Bridge Park Conservancy, assuming that .org is in your searchlist. If ICANN sells the brooklynbridgepark TLD delegation to another party who populates the zone with service records, should that party expect that http://brooklynbridgepark/ will now resolve to their site? RFC 1536 says no. Similar problems will occur when the party purchasing the brooklynbridgepark TLD attempts to use the single-label name brooklynbridgepark for other uses, such as network access. And _that_ situation has a lot more to do about buyer beware and understanding of conflicting expectations about use than it does about ownership. Today there is a distinction between types of property rights - surface, subsurface, or rights to the air above a property. As noted at http://geology.com/articles/mineral-rights.shtml this was not always the case: If we go back in time to the days before drilling and mining, real estate transactions were fee simple transfers. However, once subsurface mineral production became possible, the ways in which people own property became much more complex. If the analogy holds (and I'm not a lawyer, so I have no idea if it does), then we could be talking about a fee simple transfer in a situation where sub-rights may be claimed to belong to someone else. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Services and top-level DNS names (was: Re: Update of RFC 2606 based on the recent ICANN changes ?)
So the problem isn't whether some string not listed in 2606 can be allocated, it is how it is used after it is allocated. And _that_ situation has a lot more to do about buyer beware and understanding of conflicting expectations about use than it does about ownership. john I really wish it was *just* buyer beware. If http://museum/ only works for some clients and not other then there really isn't a problem. By works here I mean connects to 83.145.59.103 or nowhere. The problem is that it isn't just buyer beware. If the buyer adds any records are looked up by search mechanisms as a part on normal application activity, A, and MX are simple examples, then *ALL* the users of the Internet need to be aware that they are there. This is a security problem, not a buyer beware problem. This is a namespace clash and namespace clashes are bad for many reasons. Now as far as I can see there are two solutions which attack the problem from different ends. 1. ban the adding of any records which meet the above criteria. 2. rewrite resolvers to not lookup single labels against the root. Note banning would have to be described is a manner that didn't preclude the negative advertisement of a service. It would also have to be writen to exclude records that a looked up with a prefix added. Also what is the penalty for adding banned records? Mark ; DiG 9.3.4-P1 museum ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 61108 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 0 ;; QUESTION SECTION: ;museum.IN A ;; ANSWER SECTION: museum. 86034 IN A 83.145.59.103 ;; AUTHORITY SECTION: museum. 22099 IN NS ns-ext.vix.com. museum. 22099 IN NS ns1.getty.edu. museum. 22099 IN NS nic.icom.org. museum. 22099 IN NS ns.icann.org. museum. 22099 IN NS nic.museum. ;; Query time: 3 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Jul 5 08:22:30 2008 ;; MSG SIZE rcvd: 162 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Services and top-level DNS names (was: Re: Update of RFC 2606 based on the recent ICANN changes ?)
Bernard, I'm going to try to respond to both your note and Mark's, using yours as a base because it better reflects my perspective. Before I go on, I think the three of us are in agreement about the situation. The question is what can (or should) be done about it. --On Friday, 04 July, 2008 13:52 -0700 Bernard Aboba [EMAIL PROTECTED] wrote: Not really. ICANN isn't selling single-label domains. They are selling (and I believe selling is probably now the correct term) plain, ordinary, TLD delegations. If I get one of those and populate the TLD zone only with delegation records, there are no problems with what ICANN has done at all, whether you describe it as a property right or in some other way. Agreed. On the other hand, if they delegate one and the enterprise that buys it chooses to populate the zone with service records, then ICANN's position will certainly be that any inability to use those service records isn't ICANN's problem -- any more than difficulties using .museum or .aero were ICANN's problem when those to whom those domains were delegated discovered that a lot of applications software thought that the one TLD label of more than three characters was ARPA. Is generic buyer beware disclaimer really sufficient here? The problem isn't just inability to use -- it's that other parties exist who may claim the usage right, and provide citations to RFCs to back up their claim. For example, typing http://brooklynbridgepark/ into a browser utilizing a resolver compliant with RFC 1536 will bring you to the web site of Brooklyn Bridge Park Conservancy, assuming that .org is in your searchlist. We agree so far, but let me note that 1536 is an informational document. We generally don't claim that systems are expected to be compliant with those. If ICANN sells the brooklynbridgepark TLD delegation to another party who populates the zone with service records, should that party expect that http://brooklynbridgepark/ will now resolve to their site? RFC 1536 says no. Similar problems will occur when the party purchasing the brooklynbridgepark TLD attempts to use the single-label name brooklynbridgepark for other uses, such as network access. Yes. And what I fear is that some applications and implementations will support services on brooklynbridgepark as a TLD and others will start searching. Yes, that goes well beyond buyer beware. And _that_ situation has a lot more to do about buyer beware and understanding of conflicting expectations about use than it does about ownership. Today there is a distinction between types of property rights - surface, subsurface, or rights to the air above a property. As noted at http://geology.com/articles/mineral-rights.shtml this was not always the case: If we go back in time to the days before drilling and mining, real estate transactions were fee simple transfers. However, once subsurface mineral production became possible, the ways in which people own property became much more complex. Sure. But I know who to call --title insurance companies, lawyers, judges, etc.-- when your mineral rights intrude on my surface building rights or vice versa. If the analogy holds (and I'm not a lawyer, so I have no idea if it does), then we could be talking about a fee simple transfer in a situation where sub-rights may be claimed to belong to someone else. But this gets back exactly to both the rude comments I've been making about ICANN and the example I tried to construct (not carefully enough) about a Microsoft TLD. Let's take the second one first. Suppose that Microsoft, at a high corporate level, decided that they wanted to have a TLD called microsoft and that they wanted to attach services to it. You would advise against that. I would advise against that. So would others. We would cite 1535, a number of other RFCs, and general bad taste. My assumption is that Microsoft would give it up -- even if they wanted the domain, they wouldn't expect to locate services at the top level. But suppose some marketing force took over and overwhelmed those arguments. The thing that makes Microsoft relevant to this example is that the company distributes a very popular browser and a couple of very popular email clients. Were a corporate decision to be made to support services on a TLD, at least services on that one special-case TLD, than that decision could extend to modifications to those application programs that would permit access to those services. Again, I don't expect that to happen, but it carries over directly into the main point I'm trying to make, which is that property rights are a relevant metaphor for this situation only if there is some basis or authority for enforcing those rights. As I've pointed out in other contexts recently, the last few times I've tried to call the Protocol Police, they didn't answer. Ultimately, I'm concerned about what the IETF can usefully do
RE: Single-letter names (was: Re: Update of RFC 2606 based on the recent ICANN changes?)
I feel that Edmon's report of the ICANN/GNSO point of view and the positions of James Seng are shared by most of the groups we relate with (Internet @large, open roots, ISO lobbies, Multilinc, MINC, Eurolinc, ISOC France, ccTLDs, etc.). If this WG does not think they are technically adequate there would certainly be a real urgency to document why, to have it confirmed by the IAB, and disseminated. This is due to the constraints a change would introduce outside of the Internet community and the général awareness of this debate after the Paris meeting. This WG needs to speak up now, or status quo will be considered as definitly settled. I expect one single sign (logo) gcTLDs [geocultural] to be documented this year for multilingual information machines (airports, transports, health, kids, disabled). BTW this is also why I would recommend to refer to the semiotic rather than to the semantic aspects. jfc At 01:33 05/07/2008, Edmon Chung wrote: Regarding single Unicode code-point labels at the TLD level, there was quite some discussion on this topic at the GNSO Reserved Names working group and then at the new gTLD discussion. The final recommendation from the GNSO was: Single and two-character U-labels on the top level and second level of a domain name should not be restricted in general. At the top level, requested strings should be analyzed on a case-by-case basis in the new gTLD process depending on the script and language used in order to determine whether the string should be granted for allocation in the DNS. Single and two character labels at the second level and the third level if applicable should be available for registration, provided they are consistent with the IDN Guidelines. As for ASCII, the recommendation was: We recommend reservation of single letters at the top level based on technical questions raised. If sufficient research at a later date demonstrates that the technical issues and concerns are addressed, the topic of releasing reservation status can be reconsidered. Edmon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
John C Klensin wrote: http://[10.0.0.6]/ anyone? My bastard browser from hell eats http://[208.77.188.166]/ It's certainly no STD 66 URL. But it won't surprise me if the URL-bis, charset-bis, net_2.0-bis, MIME-bis, XHTML-bis, (etc. ad nauseam) effort styling itself as HTML5 decrees that this is as it should be based on current practice in the browser industry. That would be also the moment where I'd welcome a new TLD 6] just to prove a subtle technical point. the IETF has a lot of trouble making clear decisions when those sorts of politics start to intrude. So far nobody disagreed with RFC 1123 erratum 1335. FWIW that also eliminates 6] from the list of potential TLDs. Frank -- Repost, apparently my first attempt didn't make it. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Thu, Jul 03, 2008 at 09:23:58AM +1000, Mark Andrews [EMAIL PROTECTED] wrote a message of 32 lines which said: No sane TLD operator can expect http://tld; or [EMAIL PROTECTED] to work reliably. [Mark, you used non-RFC2606 names, the IESG will put a DISCUSS against you.] I agree but it is not the point: an email adress like [EMAIL PROTECTED] is legal and works but not reliably (there are many stupid broken Web forms which refuse it and tell me it's not valid). http://example is legal and should work. If it does not, it may indicate a broken implementation. I suspect there are still mail configuations around that will re-write [EMAIL PROTECTED] to [EMAIL PROTECTED]. There are many broken mail configurations. Should we be writting a RFC which states that MX and address records SHOULD NOT be added to the apex of a TLD zone? No. A TLD is a domain like any other and we should not write special rules for them. Should we be writting a RFC which states that single label hostnames/mail domains SHOULD NOT be looked up as is in the DNS? I hate special cases. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Hi Mark, At 21:48 02-07-2008, Mark Andrews wrote: The key word word is reliably. http://museum/ can never be guarenteed to work. I saw the key word and I agree with you. Someone out there thought that it was a good idea or else we wouldn't be discussing about this. Your technical arguments are sound but they are unfortunately being overridden by other considerations. There are currently 22 TLDs with MX records, 16 TLDs with address records and 11 TLDs with wildcards. The notion that different domains would be run in different ways --albeit within the broad contexts of public service on behalf of the Internet community and trustee... for the global Internet community-- was considered a design feature and a safeguard against a variety of potential abuses. Obviously the world has changed in many ways (since then) ... Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Thu, Jul 03, 2008 at 09:23:58AM +1000, Mark Andrews [EMAIL PROTECTED] wrote a message of 32 lines which said: No sane TLD operator can expect http://tld; or [EMAIL PROTECTED] to work reliably. [Mark, you used non-RFC2606 names, the IESG will put a DISCUSS against you.] I agree but it is not the point: an email adress like [EMAIL PROTECTED] is legal and works but not reliably (there are many stupid broken Web forms which refuse it and tell me it's not valid). http://example is legal and should work. If it does not, it may indicate a broken implementation. But where should it resolve to? example.example.net. or example.? Under what circumstances? I suspect there are still mail configuations around that will re-write [EMAIL PROTECTED] to [EMAIL PROTECTED]. There are many broken mail configurations. Should we be writting a RFC which states that MX and address records SHOULD NOT be added to the apex of a TLD zone? No. A TLD is a domain like any other and we should not write special rules for them. Names with and without dots already have different semantics. Should we be writting a RFC which states that single label hostnames/mail domains SHOULD NOT be looked up as is in the DNS? I hate special cases. TLDs are already a special cases in so many ways. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
John C Klensin wrote: http://[10.0.0.6]/ anyone? My bastard browser from hell eats http://[208.77.188.166]/ It's certainly no STD 66 URL. But it won't surprise me if the URL-bis, charset-bis, net_2.0-bis, MIME-bis, XHTML-bis, (etc. ad nauseam) effort styling itself as HTML5 decrees that this is as it should be based on current practice in the browser industry. That would be also the moment where I'd welcome a new TLD 6] just to prove a subtle technical point. the IETF has a lot of trouble making clear decisions when those sorts of politics start to intrude. So far nobody disagreed with RFC 1123 erratum 1335. FWIW that also eliminates 6] from the list of potential TLDs. Frank ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Mark Andrews wrote: The Internet went to multi-label hostnames ~20 years ago. As noted in RFC 2821 as one dot required syntax, also mentioned in RFC 3696. Recently *overruled* by 2821bis. No sane TLD operator can expect http://tld; or [EMAIL PROTECTED] to work reliably. Certainly not expect, but some gave it nevertheless a try. My bastard browser from hell let's me say http://museum./ (note trailing dot). I suspect there are still mail configuations around that will re-write [EMAIL PROTECTED] to [EMAIL PROTECTED]. They didn't note that RFC 2821 upgraded the 821 examples, sh*t happens... eg Should we be writting a RFC which states that MX and address records SHOULD NOT be added to the apex of a TLD zone? No, there are enough TLDs disagreeing with this idea... Should we be writting a RFC which states that single label hostnames/mail domains SHOULD NOT be looked up as is in the DNS? ...the 2821bis Last Call ended months ago, and one dot required was discussed long enough. Change this again, and I'll scream. Frank ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes?
On Thu, Jul 3, 2008 at 7:01 AM, John C Klensin [EMAIL PROTECTED] wrote: Any proposal for a new gTLD must satisfy a number of string criteria that will be specified explicitly in the RFP, including the requirements that the U-label must not: (a) be identical to an existing TLD; Is сом identical to com? (the first of these is U+0441 U+043E U+043C) The current principle is that it should be be a confusing string, which is vague enough to cover the case above (but perhaps not able to cover .co) (b) be identical to a Reserved Name; (c) consist of a single character; I've heard it argued repeatedly that this is an unreasonable rule for ideographic characters. I don't have an opinion, but hope that ICANN has considered that case in full details. This is where we dive into a discussion what is a character. In ideographic based language, there isnt a concept of a word. For example, Chinese, Japanese and Korean are actually phonetics language, and that ideograph characters are used to express the phonetics. A word or more accurately morphemes can be express in a single or more ideographs. A single latin character is unlikely to be useful by itself (except of a and i) but thats not the case in CJK. If the condition is that no single ASCII character, I may be neutral about it (since a single ideograph would never translate to a single ASCII character in the zonefile, due to the xn-- prefix) but if the character is defined more broadly to cover U-label character, then I would have strong objections. Incidentally, I remember it is a standing tradition that labels may not be a single ascii character. But is there any technical reason we should forbid it? (e.g. 6.cn have not kill any kittens yet) -James Seng ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes?
James Seng wrote: if the character is defined more broadly to cover U-label character, then I would have strong objections. +1 And fortunately it's not our job to figure out what a term like IDN ccTLD actually means, where that might be important. I remember it is a standing tradition that labels may not be a single ascii character. IIRC SC SLDs were recently permitted. In this acronym soup that's single character second-level domains affecting TLDs with a contract not permitting such beasts. ASCII characters, [0-9A-Za-z]. No TLD is forced to adopt this idea, and many TLDs have their own rules. But is there any technical reason we should forbid it? (e.g. 6.cn have not kill any kittens yet) It is certainly an obstacle for *simple* definitions of what constitutes confusingly similar or typo resistent. But I guess there is no *simple* definition also covering typos in IDN A-labels, so maybe that point is moot. Unrelated: The 2606 thread on the general list so far was about many interesting topics, notably about toplabels, but not about the 2606bis draft. For the 3920bis-06 draft I sent this comment to the author: You claim to import idnlabel from RFC 3490, but there is no idnlabel in RFC 3490. Besides you don't want only xn-- labels, you want ldh-label not limited to xn--. How about this, based on latest RFC 1123 toplabel erratum: | domain = fqdn / address-literal | fqdn = *(ldhlabel .) toplabel | ldhlabel = letdig [*61(ldh) letdig] | toplabel = ALPHA *61(ldh) letdig | letdig = ALPHA / DIGIT | ldh = ALPHA / DIGIT / - Frank ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes?
At the moment, the condition is no single Unicode code point. To the extent that a single CJK ideograph can be expressed using a single Unicode code point, this would represent the situation to which you say you would object. I will dig through my notes to find out why the single character condition was adopted - Would you be able to explain why the condition is no single Unicode code point? Whats the technical basis for that? -James Seng ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Update of RFC 2606 based on the recent ICANN changes ?
Lyman said: I'm familiar with draft-klensin-rfc2821bis-10.txt and understand the importance of using only FQDNs in SMTP exchanges given that [i]n the case of a top-level domain used by itself in an email address, a single string is used without any dots. What I'm interested in is any reason to proscribe the use of a TLD as a single label hostname (particularly for email addresses) other than the fact that there is software out there that will interpret it incorrectly - Potential problems with global use of single-label names go beyond SMTP. For example, RFC 4282, which defines the Network Access Identifier (NAI), does not permit the use of single-label names. From Section 2.1: realm = 1*( label . ) label As a result, someone purchasing the example TLD and using the NAI [EMAIL PROTECTED] in order to obtain access to the network, might well discover that this would not work. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
RFC 4282 defined label = let-dig *(ldh-str) which means a single-label Unicode string would be absolutely fine since it translate to xn--gibberish. A shorter gibberish of cos, but still longer than a single character. -James Seng Potential problems with global use of single-label names go beyond SMTP. For example, RFC 4282, which defines the Network Access Identifier (NAI), does not permit the use of single-label names. From Section 2.1: realm = 1*( label . ) label As a result, someone purchasing the example TLD and using the NAI [EMAIL PROTECTED] in order to obtain access to the network, might well discover that this would not work. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Oops, ignore my email :P My reading comprehension is bad in the morning. -James Seng On Fri, Jul 4, 2008 at 6:31 AM, James Seng [EMAIL PROTECTED] wrote: RFC 4282 defined label = let-dig *(ldh-str) which means a single-label Unicode string would be absolutely fine since it translate to xn--gibberish. A shorter gibberish of cos, but still longer than a single character. -James Seng Potential problems with global use of single-label names go beyond SMTP. For example, RFC 4282, which defines the Network Access Identifier (NAI), does not permit the use of single-label names. From Section 2.1: realm = 1*( label . ) label As a result, someone purchasing the example TLD and using the NAI [EMAIL PROTECTED] in order to obtain access to the network, might well discover that this would not work. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Mark Andrews wrote: The Internet went to multi-label hostnames ~20 years ago. As noted in RFC 2821 as one dot required syntax, also mentioned in RFC 3696. Recently *overruled* by 2821bis. There is a difference between allowing protocol to be used in a local only mode (single label) and a global mode (multi-label) and saying you must support single label in a global context. Single label names are local in scope. Attempting to use them in a global context does not work. As the names in . get more interesting the probability of collisions with existing names goes up. Not many people choose two letter labels for the least significant parts of their host names unless they are choosing their initials. Museum on the other hand is a real English word. I'm sure you will find lots other uses of museum in the DNS. The same thing will happen with other TLD's as the rules are relaxed. Single label hostnames are not globally unique. They SHOULD NOT be used in a context where globally unique names are required. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Mark Andrews wrote: The Internet went to multi-label hostnames ~20 years ago. As noted in RFC 2821 as one dot required syntax, also mentioned in RFC 3696. Recently *overruled* by 2821bis. There is a difference between allowing protocol to be used in a local only mode (single label) and a global mode (multi-label) and saying you must support single label in a global context. Single label names are local in scope. Attempting to use them in a global context does not work. As the names in . get more interesting the probability of collisions with existing names goes up. Not many people choose two letter labels for the least significant parts of their host names unless they are choosing their initials. Museum on the other hand is a real English word. I'm sure you will find lots other uses of museum in the DNS. The same thing will happen with other TLD's as the rules are relaxed. Single label hostnames are not globally unique. They SHOULD NOT be used in a context where globally unique names are required. Mark Additionally we have RFC 1535 warning about the consequences of treating global address as local in a addition to choosing a bad definition of local for a search list. The reverse is equally true. Mail that was intended for a local receipient may end up being delivered globally. Not everyone in a organisation tracks the comings and goings of local addresses. The sender may not even be local if a .forward contains [EMAIL PROTECTED] and tld goes away locally. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
In a more sane world, no one rational would want to build a business or other activity around a TLD named local. But this is demonstrably not a sane world. Right. I can see the business case for this. :-( But at least in the first round, the barrier to entry is so high that I don't see that sort of thing as being viable. The figure $100K for a TLD application is what is floating around at the moment, though that number is not nailed down definitively. For much of the domain tasting related activities, a fundamental premise was that the cost of using a name was very low (i.e., zero, while the AGP was being leveraged). Thomas ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Which brings up a question can a TLD be used like a domain name? not just http://microsoft/ but [EMAIL PROTECTED] will likely to fail to. james 2008/7/2 Hallam-Baker, Phillip [EMAIL PROTECTED]: Another like restriction that might be investigated is whether http://microsoft/ or other similar corporate TLDs would work as intended with deployed legacy browsers. I suspect (but have not tried) that if you simply type 'Microsoft' into the address bar of some browsers you might have the keyword immediately interpreted as a search term, not an address to visit. I also suspect that if we actually read the technical specs being proposed we might find that some of these issues have already been anticipated in them and addressed. From: [EMAIL PROTECTED] on behalf of Dave Crocker Sent: Tue 7/1/2008 12:44 PM To: Tony Finch Cc: IETF Discussion Subject: Re: Update of RFC 2606 based on the recent ICANN changes ? Tony Finch wrote: Speaking technically, how would you distinguish the top-level domain 127.0.0.1 from the IP address 127.0.0.1? A word while passing here: is there a document (RFC, Posix standard, whatever) which says which is the right result in such a case? RFC 1123 section 2.1, especially the last sentence. Interesting. I hadn't noticed the implication of that, before, but it seems to be a pretty clear technical specification that a top-level domain is not allowed to be a decimal number. Ever. That's a concrete constraint on what ICANN is permitted to authorize. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes?
blush Thanks! Steve On Jul 1, 2008, at 6:36 PM, John Levine wrote: This does not mean that ICANN won't listen to the IETF; it means that there will be voices more familiar to ICANN saying things different than we are. One of the few ICANN committees that actually works is the SSAC, the Security and Stability Advisory Committee. It includes a lot of people we know, starting with Steve Crocker, the chair. I cannot ever recall a time when ICANN acted contrary to the advice of the SSAC. So although I agree that there's a lot not to like about ICANN, the chances that they will do technically dangerous things are low. http://www.icann.org/committees/security/ R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
(It's always a bummer when ietf-general turns into ICANN-general, but in this case it seems like a useful discussion because the IETF will probably be asked policy questions for various proposed TLDs.) At 10:17 AM -0400 7/2/08, Thomas Narten wrote: In a more sane world, no one rational would want to build a business or other activity around a TLD named local. But this is demonstrably not a sane world. Right. I can see the business case for this. :-( But at least in the first round, the barrier to entry is so high that I don't see that sort of thing as being viable. Then you're not being creative enough. The figure $100K for a TLD application is what is floating around at the moment, though that number is not nailed down definitively. ...nor justified financially... For much of the domain tasting related activities, a fundamental premise was that the cost of using a name was very low (i.e., zero, while the AGP was being leveraged). If that was true, then a domain that was popular but lost its name due to negligence in renewal should be able to buy it back from the taster for a few hundred bucks. Instead, the price I have heard more than once is tens of thousands of dollars. Without doing a lot of business research and probably some traffic capture, you can't estimate the value of .local or a TLD that is a typo but not really infringing of a popular search term. We scoff at people who say it would be easy to just add privacy to that protocol; they should scoff at us for making wild guesses about values in a huge, unregulated business that is less than ten years old. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
