Re: Services and top-level DNS names (was: Re: Update of RFC 2606
--On Monday, 07 July, 2008 12:08 -0700 Bill Manning <[EMAIL PROTECTED]> wrote: > John, do you beleive that DNS host semantics/encoding that > form the bulk of the IDN work (stringprep, puny-code, et.al.) > are applicable -only- in the context of zone file generation > or are they also applicable inconfiguration and acess > control for DNS? I think I don't understand the question. RFC 3490 tries to make a distinction between IDNA-aware and IDNA-unaware applications and domain name "slots". The intent is, more or less, to permit a punycode-encoded string with the prefix (which the IDNA2008 drafts call an "A-label") to appear nearly anywhere in the DNS but to expect conversion to and/or from native characters only in contexts where IDNA is explicitly applied. Even in zone files, IDNA is generally applicable only to labels and not to data fields. > path/alias expansion/evaluation will be interesting if "." is > not what 7bit ASCII thinks of as "." RFC 3490 lists a series of other characters that are to be treated as label-separating dots if encountered in an IDNA context. That model causes a number of interesting problems in contexts where one has to recognize a string as a domain name, and possibly process it, without knowing anything about IDNA. The problems show up in situations as simple as conversions between label-dot-label-dot-label format and length-label list format, making it very important whether one identifies an FQDN as containing IDNA labels or converts it to length-label form first. IDNA2008 (see the IDNABIS WG and its documents and mailing list) does away with all of this as part of a general plan to do a lot less mapping of characters into other characters. So, for the proposed newer version the only label-separating dot permitted in the protocol is the character you know as 7bit ASCII "." (U+002E in Unicode-speak). Does that answer whatever the question was intended to be? 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
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 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 ?
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 ?
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 ?
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 ?
>
> --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 Tue, Jul 08, 2008 at 11:47:15AM +1000, Mark Andrews 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.
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."
--
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
pgp7sZhfU6SH5.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 ?
> 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 ?
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? pre- (And, by the way, an interesting question. It's probably why it would be good for someone to formulate a consensus opinion about current size and traffic limits on the current 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 ?
> 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. "tld"s 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 ?
> 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. :-) > > > > 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. 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). If you'd like to argue something more subjective like "confusing" or even "misleading," you'll find no resistance from me. -- 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 pgpNpu92ZVBiJ.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 ?
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 ?
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 ?
> > --===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 ?
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 ?
> 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). You still have the issue that "telnet host" will suddenly become "telnet tld" when "host" is not longer in the search list because it has been deprecated. This then lets "tld" harvest username / password pairs etc. Every protocol has its own set of gotchas. Email was just a example everyone should be able to recognise. Note: "tld" does not meet the requirements of a Hierarchical Names as specified in RFC 921. Hierarchical Names are what we now call globally unique names. Trying to treat "tld" as a heirachical name does not work. > I'm familiar with 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 -- 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 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 TXT"9.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 Monday, 07 July, 2008 15:03 -0700 Karl Auerbach <[EMAIL PROTECTED]> wrote: > > 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." yes. But six. He could then rest, rather than dealing with irate users. > 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"? Apropos to your opening comment, it is probably ultimately a matter of religion. And mine, FWIW, it that, in cases where it is hard or impossible to prove that their will be no ill-effects on that portion of the installed base that conforms to existing standards, I'm inclined to argue for a very high level of demonstration that there are no ways to do whatever is wanted within the existing models. Such demonstrations may be persuasive that problems that may be lying in wait for us are worth the risks. In their absence, it is hard for me --religiously or pragmatically-- to accept the view that possibly-significant risks are worth it. I note that, because of the caching issue as well as several others, I have never found the position that "we know that COM could be expanded well beyond original design expectations, therefore the root can be" particularly persuasive. Of course, if one is unpersuaded by the potential for risks to the installed base, then one would position oneself to try to get those who are concerned about those risks to prove that they exist. 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: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 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 ?
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 ?
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 ?
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 ?
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: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 TXT"9.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 ?
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 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 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 TXT"9.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 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: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: Response to appeal [...]
IESG Secretary wrote: > This is a response to that appeal. [...] > The IESG came to consensus that the use of non-example domain > names should not prevent publication of RFC2821bis, even though > the IESG finds this practice can cause harm. Good enough, hopefully the discussed examples are updated before publication. Not because they directly cause harm, but because thousands of 2821bis readers might read no other RFC (assuming that 2821bis is advanced to STD unmodified). > Community input is needed with respect to the application of > this policy to revision of specifications. Fixing known errata and nits, as well as clarifying or removing unused or non-interoperable features, is IMO the whole point of the maturity levels (in practice - in theory it means that we might soon see more than two implementations based on 2821bis instead of RFC 821, but that is obviously hilarious). If you consider the relevant IDnits as an "2606 implementation" it is IMHO fine -- everybody here knows that "recommended" and "required" are no synonyms. > it is normal, and indeed encouraged, to establish a dialog > between the holder of the DISCUSS, the document shepherd (see > RFC 4858), the authors, the working group, and the sponsoring > AD. There is apparently a bug in RFC 4858, it asks the shepherd to judge the WG consensus. But the shepherd is not necessarily a co-Chair or AD (see 3.e in 4858). Judging consensus is a task that cannot be delegated, the shepherd is no scapegoat. When you clarify those DISCUSS rules please make sure that it always means what the name says, a DISCUSS must not degenerate into a veto, only 1/3 or more ABSTAINs are a veto. Or in the opposite direction, if "discuss-discuss" is actually a "pseudo-DEFER" something with the DEFER rules is wrong. > One of the items that was felt important in improving this > process was that the role of the shepherds should be more > central than it currently is. Non-WG shepherds or non-Chair WG-shepherds are IMO volunteers for various non-critical tasks of sponsoring ADs or WG Chairs. But judging consensus is critical, it is one reason why there are WGs and an IESG at all. > The IESG Statement "DISCUSS Criteria in IESG Review" is > consistent in spirit with this request, noting that stylistic > issues and pedantic corrections are not appropriate for a > DISCUSS. I'm not exactly sure why stylistic issues cannot be discussed. As long as what happens really is a discussion, i.e. authors are free to say thanks for the feedback and do what they like. Maybe s/DISCUSS/OBJECTION/ and s/COMMENT/DISCUSS/ to get a clearer difference. With rules that a DISCUSS automatically turns into NO OBJECTION after a time out, while an OBJECTION automatically turns into an ABSTAIN after a generous time out. > the IESG does not agree that the interests of the IETF and > Internet community are always served by prohibiting changes > when documents advance. Good. I'm not aware that the appeal proposed something else. > The IESG continues to welcome feedback from the community on > its procedures. Nobody seriously wanted to replace RECOMMENDED by REQUIRED in 2606bis, as far as I can judge it from the feedback (thanks). 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 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 ?
> 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 ?
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: Services and top-level DNS names (was: Re: Update of RFC 2606
On Mon, Jul 07, 2008 at 12:25:09PM -0400, John C Klensin wrote: > > > --On Monday, 07 July, 2008 10:30 +1000 Mark Andrews > <[EMAIL PROTECTED]> wrote: > > >... > > If / when MIT stop using ai.mit.edu, "[EMAIL PROTECTED]" will not longer > > mean [EMAIL PROTECTED] This will mean that any configuration > > filethat has "[EMAIL PROTECTED]" will now, suddenly, get a different > > meaning.This is a latent security issue. > > Mark, > > While I'm basically sympathetic to the position you are taking > on this, we have recommended for years and years (since the CS. > incident, if not earlier), that things like configuration files > use FQDNs and only FQDNs. SMTP imposes the same requirement on > addresses in MAIL and RCPT commands. > > If [EMAIL PROTECTED] is in a config file with the intent of identifying > [EMAIL PROTECTED] then the config file is broken.Conversely, > if the config file format is intended to permit references to > TLDs, I would hope that it would be possible to write "ai." if > the TLD were intended. > > Personally, I'm very concerned about what users type and what > happens after that. For configuration files and the like, I > believe that we have a case of bad design if the interpretation > of the configuration is dependent on things outside the scope of > that file and, in particular, if there is a dependency on DNS > search procedures rather than one explicit FQDNs. > > Quoting from your comment about Firefox, "Two wrongs don't make > a right. They just make two things that need to be fixed." > > john > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf John, do you beleive that DNS host semantics/encoding that form the bulk of the IDN work (stringprep, puny-code, et.al.) are applicable -only- in the context of zone file generation or are they also applicable in configuration and acess control for DNS? path/alias expansion/evaluation will be interesting if "." is not what 7bit ASCII thinks of as "." -- --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: problem dealing w/ ietf.org mail servers
At 09:28 07-07-2008, Francis Dupont wrote: => according to Glen via RT (RT is a well known bug ticket system): "This check is in place at the direction of the IETF community, and has been discussed and debated at length." I don't recall seeing any community debate before this check was implemented. Can someone point me to that thread? 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 ?
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 ?
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 ?
--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 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 ?
>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 ?
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: problem dealing w/ ietf.org mail servers
=> according to Glen via RT (RT is a well known bug ticket system): "This check is in place at the direction of the IETF community, and has been discussed and debated at length." I don't recall the Last Call on that question, nor even the I-D. seems like this calls into question the competence of the people running IETF's servers. they really ought to know better than to accept random rumors as technical advice. Keith ___ 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)
In an earlier message, John C Klensin <[EMAIL PROTECTED]> wrote: Part of the problem in that case was that, because JANET used little-endian names internally, the big-endian foo.ucl.ac.uk (in DNS order) had to be be mapped into uk.ac.uck.foo (in JANET order) and vice versa. That mapping was trivial as long as one could run a simplistic "whichever end the TLD was on had to be the big side" test. When "CS" was introduced, blew up that simple test. In the JANET case, it failed since there were strings that could be TLDs at both ends of the string, i.e., in principle, cs.ucl.ac.uk could have been a string that was already in JANET order and that would appear in the DNS order as uk.ac.ucl.cs. I tried getting Peter Kirstein to comment on this, but he's unfortunately currently away, so I'll voice my own opinions here and please bear with me because Peter's knowledge far exceeds mine. After all, I was only a terrible teenager at the time. IMHO you cannot compare today's challenges with the way things were handled in 1989 or so... JANET was using NRS, not DNS. NRS was a static mapping of UK computer addresses in NRS format, ie. UK.AC.SOMEPLACE.SOMECOMPUTER to X.3 PAD numbers accessed over X.25. NRS pre-dated the DNS. Getting e-mail in and out of the UK made use of several gateways that on the UK side we need to know, and on the other end of the line people either needed to know, or you'd send to a gateway that would know. There were several gateways in the UK: EARN RELAY - located at Rutherford Appleton Labs as a path to BITNET (UKACRL node) EAN RELAY - to X.400 & other European Networks UK.AC.UCL.CS.NSS - the precursor to nsfnet-relay.ac.uk - satellite link to the Internet UK.AC.UKC - University of Kent at Canterbury's UUCP service Back in those days, you could route your email specifically - something which very few mailers allow today. For example, I could send email to an Internet address [EMAIL PROTECTED] as: To: [EMAIL PROTECTED] or to: [EMAIL PROTECTED] (this one crossing the pond via BITNET & bridging to the Internet via cuny) Note that the NSS Relay used to reverse the addressing automatically. In the early days, it used to try and check which way the addressing was. Then came CS and you are correct in saying that it caused problems. But the problems were not nearly as serious as you say. Rules were changed that you simply needed to write the address in the correct order for your email to be delivered. For those that have a historical interest (and would perhaps like to get inspired technically to resolve possible future problems with gTLDs), I suggest you read the excellent document written by Tim Clark of Warwick University back in those days. It used to be my email bible for quite a while and a few copies still float around the net. You can find a dusty copy here: http://iubio.bio.indiana.edu/soft/help/old/email-gateways.txt Last but not least, IMHO the issue of [EMAIL PROTECTED] is a non issue. I think we need to come to terms that the age of a resolver trying out every known local domain/sub-domain is dying out. From now on, you'll need to provide an exact host/domain name. It is not the first and not the last habit to die on the Internet. Take bang! paths, for example: dead. hostname.uucp - dead. And I also think that what web browsers try to do by suggesting a page when you just type "somefooplace" -> opens somefooplace.com is also a "feature" that will need to die to ensure stability. There are simply too many "somefooplace" on the internet, and now "somefooplace" might even be .somefooplace Or ISPs might even resolve locally "somefooplace" to "somefoobarplace" - clearly there is no limit to foo. Warm regards, Olivier -- Olivier MJ Crepin-Leblond, Ph.D. E-mail:<[EMAIL PROTECTED]> | http://www.gih.com/ocl.html http://www.nsrc.org/codes/country-codes.html ___ 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 therecent ICANN changes?)
At 9:25 AM -0700 7/7/08, [EMAIL PROTECTED] wrote: > > However, many concepts in modern Chinese >dialects require multiple syllables to express them and >therefore multiple characters to write them. So there isn't >really a one to one mapping of word, syllable, concept as >many people suppose. While there may not be a one-to-one mapping of word, character, and concept every time, there are many words and concepts which can be given (and commonly given) in a single character. Forcing those to use multiple characters to get around a policy limitation may introduce, rather than reduce confusion. Why would we want to insist on that? Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
In your previous mail you wrote: Specifically, the problem Dave encountered earlier was that the ietf mail server was rejecting mail without reverse dns, and since the ietf mail server and the mipassoc.org/dkim.org/bbiw.net mail servers all had ip6 addresses, and ip6 is used preferentially, and I hadn't set up reverse dns, they were dropping all mail. I fixed that, and things started working. => I had the same problem (IPv6, no reverse, dropped messages), I asked the IETF postmaster to fix it and it was (quickly, thanks) fixed. But I still believe this is a bad idea to check IPv6 reverse DNS, I reverved this topics for the plenary at Dublin but as you open it... PS -- I'm not sure this will actually make it to the ietf list :-) ... => according to Glen via RT (RT is a well known bug ticket system): "This check is in place at the direction of the IETF community, and has been discussed and debated at length." so as the IETF community voice is this list IMHO it is appropriate (until some authority delegates the issue to the v6ops WG?). Thanks [EMAIL PROTECTED] ___ 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 therecent ICANN changes?)
> 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 lest someone might think that this curiosity of single character words only applies to vowel sounds, in Russian, the Cyrillic letter equivalents of v, k and s, are also single letter words. > On the other hand, characters in ideographic scripts such as > Han are not mere sounds or glyphs; they represent one or more > concepts. Some people might dispute that and say that they represent syllables. Since the various Chinese dialects tend to have monosyllabic words, almost all possible syllables also represent a word or concept. However, many concepts in modern Chinese dialects require multiple syllables to express them and therefore multiple characters to write them. So there isn't really a one to one mapping of word, syllable, concept as many people suppose. It would be more defensible to disallow single codepoint labels where the code point represents a single consonant sound or a single vowel sound. That still leaves a grey area of syllabic symbol systems such as Hiragana, Inuit syllabics, etc. However, the number of people affected by a rule on syllabics is small enough that one could reasonably poll representatives of these language communities to see if a rule prohibiting single-syllable TLDs would cause hardship. Note that the current system allows both single syllable TLDs such as .to and single ideograph TLDs such as .sing when ASCII characters are used. Or if you want to include tones, then .sing4 would be a single ideographic codepoint. I think that it would be a good thing to update RFC 2606 to collect the various arguments and reasoning so that the ICANN experts have some guidance to work from. If we can't deal with all the corner cases in an updated RFC, then at least ICANN experts have a point of reference from which to depart, or not. --Michael Dillon ___ 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
--On Monday, 07 July, 2008 10:30 +1000 Mark Andrews <[EMAIL PROTECTED]> wrote: >... > If / when MIT stop using ai.mit.edu, "[EMAIL PROTECTED]" will not longer > mean [EMAIL PROTECTED] This will mean that any configuration > file that has "[EMAIL PROTECTED]" will now, suddenly, get a different > meaning. This is a latent security issue. Mark, While I'm basically sympathetic to the position you are taking on this, we have recommended for years and years (since the CS. incident, if not earlier), that things like configuration files use FQDNs and only FQDNs. SMTP imposes the same requirement on addresses in MAIL and RCPT commands. If [EMAIL PROTECTED] is in a config file with the intent of identifying [EMAIL PROTECTED] then the config file is broken.Conversely, if the config file format is intended to permit references to TLDs, I would hope that it would be possible to write "ai." if the TLD were intended. Personally, I'm very concerned about what users type and what happens after that. For configuration files and the like, I believe that we have a case of bad design if the interpretation of the configuration is dependent on things outside the scope of that file and, in particular, if there is a dependency on DNS search procedures rather than one explicit FQDNs. Quoting from your comment about Firefox, "Two wrongs don't make a right. They just make two things that need to be fixed." 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 ?
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: problem dealing w/ ietf.org mail servers
On 3 jul 2008, at 15:57, Jeroen Massar wrote: Which (autoconfig) you should either not be using on servers, or you should be configuring your software properly to select the correct outbound address. Is it the IETF's job to tell people how to run their networks? In my opinion, stateless autoconfig is a perfectly acceptable way to configure servers. SMTP shows that it is perfectly usable for these situations as it nicely rejects the message with a proper message automatically telling you on how to solve it. I ran into the issue with the non-existant IPv6 reverse mapping twice. I would prefered to have solved this by getting proper delegation from my ISP, but I haven't been able to get this done for years. Anyway, the first time I opened a ticket they told me it was fixed. Then the problem returned and they told me I was put on a whitelist. As this thread indicates, that's hardly a solution, especially since I was unable to get Sendmail to NOT use IPv6 without completely disabling the protocol on my system, making it completely impossible for me to deliver mail to the IETF servers. (Serves me right for running Sendmail I guess.) Those boxes are not set up correctly thus should not be sending email in the first place. For that matter you should actually be firewalling+logging port 25 outbound so you can monitor any host in your network doing illegal SMTP connects. In my opinion, filtering at layer 4 because a layer 7 protocol is broken is a bad idea. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
Ned Freed wrote: >> Spam filtering is sort of like chemotherapy, the difference between the good and the bad is pretty small, and the trick is to find measures that will kill the disease without killing the patient. It's entirely a matter of statistics, not fundamental design. And sort of not like it at all. For one thing, the mutation rate in the spam world is much higher. And that brings us to the real issue here: Whether or not a given technique, which was very effective indeed at one point, is effective enough now to continue using. At base, this requires distinguishing between techniques that are heuristics, and therefore fickle, versus techniques that can be stable over the long term. The former are used to detect bad actors. The latter can apply for handling good actors. The bad actors are indeed bright, well organized, aggressive and very, very adaptable. Any use of heuristics must therefore be extremely agile. The diligence and expertise this requires is onerous. Typically, only the largest services can afford to do this in-house. By contrast, a trust overlay, based on prior assessment of good actors, ought to be much lower overhead and much more stable. However we have less experience with this side of the equation. This defense definitely was very effective once upon a time, but the world has adapted. Exactly. Nor does continuing to use a technique that has outlived it's usefulness. Exactly. And in the specific case of the IETF, where we want to encourage people to use our servers to experiment with IPv6 and where there are bound to be a lot of PTR record issues, I think an absolute block on the basis of no PTR record is totally inappropriate +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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?)
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
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: se
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 dis
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: 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 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?
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: problem dealing w/ ietf.org mail servers
> >surely we in the IETF should be able to do better than to have our mail > >servers filter incoming mail based on completely irrelevant criteria > >like whether a PTR lookup succeeds! > Spam filtering is sort of like chemotherapy, the difference between > the good and the bad is pretty small, and the trick is to find > measures that will kill the disease without killing the patient. It's > entirely a matter of statistics, not fundamental design. And sort of not like it at all. For one thing, the mutation rate in the spam world is much higher. And that brings us to the real issue here: Whether or not a given technique, which was very effective indeed at one point, is effective enough now to continue using. > I can assure you that in the outside world, the amount of legitimate > mail that comes from no-PTR hosts these days is infinitesimal. And in my experience the amount of spam coming from such sources, while much greater, is now distinctly in the minority in terms of all incoming spam. More specifically, since rather than rejecting mail coming from IPs with no PTR entry I instead use this as a weighted factor in computing an overall spam score, I was able to examine today's spam to see to what extent this check is helping or hurting. Turns out it's doing neither - I could eliminate it entirely and my false negative rate would not go up by even a single message. And right now the weight is sufficiently low that it isn't causing any false positives either. This defense definitely was very effective once upon a time, but the world has adapted. In this particular case what seems to have happened is that because of various PTR record checks a lot of ISPs now unconditionally assign PTR records to every address, e.g., cpe-76-171-209-109.socal.res.rr.com and 173.sub-75-217-87.myvzw.com were associated with the last two dynamic IPs I've used. A few years ago it was common to get assigned IP with no PTR records at all, nowdays much less so. And this has now led to a new issue: We now have various systems out there that are now attempting to parse PTR results order to try and figure out the difference between static business addresses and dynamic residential addresses. And as you might expect, they often get it wrong. Now, of course one advantage of this check is that it can be done before you even accept the message. But the tradeoff then is that this is giving it infinite weight. > It's one of the filtering rules with the lowest false positive rates. > Other than temporary glitches like the 6-to-4 one, the only place > where I see problems is from auld pharts like us whose mail systems > have been working just fine since the 1980s, and who out of a weird > sort of principle refuse to make changes to bring them in line with > modern practice, even changes that are compatible with equally ancient > STD documents. > So, yeah, spam stinks, but it's not going away, and arguments that you > shouldn't use a technique today because it didn't work in 1998 don't > cut it. Nor does continuing to use a technique that has outlived it's usefulness. IMO the utility of this particular check peaked a few years ago and we're now on the down-slope in terms of utility. And in the specific case of the IETF, where we want to encourage people to use our servers to experiment with IPv6 and where there are bound to be a lot of PTR record issues, I think an absolute block on the basis of no PTR record is totally inappropriate unless it can be shown to be singularly effective in dealing with spam and that our spam would increase dramatically without the rule. I doubt very much this can be demonstrated. OTOH, using it as a component in computing an overall spam score may still make sense, especially if the use of IPv6 could also be factored in. Ned ___ 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
Historical note... To confirm this: The introduction of "cs" caused more general problems, unrelated to name ordering, because there were systems all over the network in computer science departments with FQDNs like host.cs.someuniversity.edu. It was common in many of those institutions to set up university-wide search rules so that a reference to host.cs would do the right thing, just like host.physics, host.philosophy, and so on. When "CS" was introduced as a TLD, "host.cs" suddenly became ambiguous (or at least dependent on exactly how the search rules were set up) as to whether it represented "host.cs." or "host.cs.someuniversity.edu.". Being at one of the major connections to JANET (mcvax was connected to Canterbury, which was the first gateway trying compensate for the JANET order (uk.ac.foo) I vividly remember the day that loads of traffic was forwarded to cs.vu.nl . And, that, if my memory is correct, was the beginning of our understanding that search rules needed to be used with great care, if at all, and that incomplete domain names should not be sent on the wire as part of protocols. Since that day I stopped using a search path for dns I could avoid it. jaap ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
