Re: [DNSOP] dns interface to whois? (Re: Taking Back the DNS )
yeah, i saw marc's comment too. in the ecology of tasted domains who's seo value is tending towards the do-not-renew cost point, there exists a reservoir of aged domains. ergo, any scheme to use domain age to differentiate domains acquired for spam, maleware, ... purposes, if effective, will result in the use of marginal seo assets as spam, maleware, ... assets, limiting the utility of an age-aware spam, maleware, ... mitigation scheme. a closer correlation to seo assets is the registrar and name server association, and where slower-than-real-time and cached responses are of use, the automated detection of type of value capture at the resolved resource, e.g., ppc. there are other reasons for attempting, as policy, of avoiding delivering to the end user a resolution that has some property known in advance. -e ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] dns interface to whois? (Re: Taking Back the DNS )
From: John L. Crain john.cr...@icann.org Date: Sun, 21 Nov 2010 09:51:45 -0800 Why would we do this, who gains by adding this? I don't see the benefit. i think it's so that folks can refuse e-mail from domains under N days old where N is a local policy decision. i have no direct use for it so i'm sort of guessing here. Was the use case outlined? no. i'm guessing it's a way to do http://www.support-intelligence.com/dob/ that does not require downloading TLD zone files every day and diffing them. --- noting that the race to register domains as fast as possible and as many of them as possible has primarily benefitted spammers not their victims, the good guys have built a magnificient system whose highest and best use is against our own interests, and that kind of folly produces requests such as this one -- stuff that in a better overall system would not be asked for. less controversially, the data is already public, the question is whether a standard dns schema as another interface into this public data would be useful to enough people. as to whether some registries might be forced to support it when they don't see a need, that's a governance question not a technology question, and it is: is more transparency better? re: http://www.circleid.com/posts/20100728_taking_back_the_dns/#7331 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] dns interface to whois? (Re: Taking Back the DNS )
On Sun, Nov 21, 2010 at 05:33:12PM +, Paul Vixie wrote: how would the registry system implement something like this? I would argue that they shouldn't. i know there are a lot of related proposals in XML. that's another topic. No, it isn't. It's one thing to say, Go look over here for IRIS. It's quite another to try to duplicate all that in the DNS itself. Why do that? A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] dns interface to whois? (Re: Taking Back the DNS )
An interesting idea -- just thinking out loud... On Nov 21, 2010, at 7:51 AM, John L. Crain wrote: how would the registry system implement something like this? could we define another SRV-like schema like: If we were go to this route, I'd think defining RRs for each tag would be the way to go instead of using TXT. Why would we do this, who gains by adding this? If it allows us to finally kill off whois, everyone in the universe (:-)). For example, as part of the RR definition process, the encoding of the value part of the tag/value pair could be explicitly defined. As a registrant, registrar or registry I have access to that data. True, if you can figure out which whois server to query, that whois server is actually up, and the data is actually fetchable from the whois server. The advantage of binding the registration information into the DNS along with the name being registered is the removal of a notoriously broken part of the name registration system and simplification of deriving from where you actually get the registration data. As a person (or client) resolving a name at a specific point in time I don't see how this data would be relevant. What do people use registration data for now? Oh, and if the data is DNSSEC-signed, you could actually verify it hadn't been altered by a MITM attack (if that actually occurs). Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] dns interface to whois? (Re: Taking Back the DNS )
On 21 nov 2010, at 22.27, Andrew Sullivan wrote: My point is that if there were some reason to have this data available in a convenient machine readable format, then iris would already be deployed. There is no reason. Noone is asking strong enough to get correct data from the whois service. Instead, ICANN is asking to have the whois protocol available, and on top of that money is spent on anonymous registration (2nd hand registration) etc. So as long as that is what people ask for, you will not see iris. That there's no uptake seems to me to be an indication that registries don't want additional costs. Registries do only implement what people ask for. Patrik ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] whois: the protocol that can't be killed even though it must
On 21 Nov 2010, at 22:20, Patrik Fältström wrote: Noone is asking strong enough to get correct data from the whois service. Instead, ICANN is asking to have the whois protocol available, and on top of that money is spent on anonymous registration (2nd hand registration) etc. So as long as that is what people ask for, you will not see iris. I'm not sure anyone is actually asking for the current horror story that is whois. We've just hit a stalemate in this trench warfare where no progress can ever be made because everyone has settled for the status quo: the least worst option that the majority of players will grudgingly accept. That there's no uptake seems to me to be an indication that registries don't want additional costs. Registries do only implement what people ask for. Or what they're compelled to implement. In theory ICANN could get every gTLD to use IRIS overnight by the stroke of a pen. It's just a teeny change to the registry contracts, right? :-) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-liman-tld-names-04
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/17/2010 01:19, Stephane Bortzmeyer wrote: | On Thu, Nov 11, 2010 at 01:42:24PM -0500, | Joe Ableyjab...@hopcount.ca wrote | a message of 15 lines which said: | | http://www.ietf.org/id/draft-liman-tld-names-04.txt | | is the latest iteration of an effort started quite some time ago to | clarify the somewhat vague inference in RFC 1123 and create a more | precise specification for the syntax of TLD labels in the DNS. | | Nice attempt but, as I have already said | http://www.ietf.org/mail-archive/web/dnsop/current/msg07058.html, | there is zero technical reason to limit the TLD to alphabetic | characters and therefore, the rule: | | traditional-tld-label = 1*63(ALPHA) | | is both a new rule (it was not in RFC 1034 or 1035) and a bad one. | | I object to the creation of new rules disguised as clarifications. Fully agree with Stephane on this. That bit needs to be changed to the ABNF equivalent of the same LDH rules we use for hostnames. I've also attached a diff with some related edits. More importantly it's worth correcting the IANA section to make it clear that the IANA does not create policy. To amplify my agreement with Stephane, we have already added LDH labels to the top level, and the sky did not fall. Therefore the only valid clarification from a _technical_ perspective is that the aside in 1123 was never a protocol restriction. Anything else is layer 9, and specifically not our problem. I also agree with Stephane and Andrew that there are poorly written programs in the world that will have problems with TLD names that start with a non-alphabetic. We already lived through the drama that new TLDs caused 10 years ago (been there, done that), and I agree with Stephane that whatever drama ensues from a TLD that starts with a digit is unlikely to cause the network to melt down tomorrow. Doug - -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJM6elBAAoJEFzGhvEaGryEvggH/jSdN63R0n3bqoDbtXtViYKW BkiPKyoIoltG4n8lbTB0CClqqsije1ZMoUmuYpXfhMxv2P+qerlg2WmnEcnrzsJL lomuU7Lwkb6jeff1KkuQXaVYrTCOlkdMghWyPJFsm6nCDE0cx0WFshVCMHiImkGn mkXcYoE20ae7Sj6uAyHowIxW3r0aJlpNJgAPNf5EtQfHWDdLEsyNJDp+oEGlh/4e dtAU7d2Sdy0erXX6PLK3OpJVBrG/9G1QUdd4+zPamC+dNXHu5OfGqysA6QVswfwK O7FtIA/QYkLW+aTgXIxxc33xK5ZpK74GQcL9nIJq/VIa1vQ+ujJJEWI64kFumsI= =QprP -END PGP SIGNATURE- --- draft-liman-tld-names-04-orig.txt 2010-11-21 18:51:33.0 -0800 +++ draft-liman-tld-names-04.txt2010-11-21 19:30:48.0 -0800 @@ -255,24 +255,24 @@ #.#.#.#, since at least the highest-level component label will be alphabetic.' [Section 2.1] - Some implementers may have understood the above phrase 'will be + Some implementers may have incorrectly understood the above phrase 'will be alphabetic' to be a protocol restriction. Neither [RFC0952] nor [RFC1123] explicitly states the reasons for these restrictions. It might be supposed that human factors were a consideration; [RFC1123] appears to suggest that one of the reasons was to prevent confusion between dotted-decimal IPv4 addresses and - host domain names. In any case, it is reasonable to believe that the - restrictions have been assumed in some deployed software, and that - changes to the rules should be undertaken with caution. + host domain names. The Internationalised Domain Names in Applications 2008 specification (IDNA2008) [RFC5891] [RFC5892] provides a protocol for encoding Unicode strings in DNS-Labels. The Unicode string used by applications is known as a U-Label; its corresponding encoding in the - DNS is known as an A-Label. The terms A-Label and U-Label are used - in this document as defined in [RFC5890]. Valid A-Labels always - contain non-alphabetic characters. + DNS is known as an A-Label. + In addition to alphabetics valid A-Labels may contain + digits and always contain the minus sign. For example at the time + of this writing XN--P1AI is the Country-code top-level domain + designated for Russian Federation. @@ -454,7 +454,7 @@ While this document makes no requests of the IANA, management of the root zone is an IANA function. This document expands the set of strings permitted for delegation from the root zone, and hence - establishes new limits for the corresponding IANA policy. + establishes new limits for the corresponding IANA procedures. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-liman-tld-names-04
Eric Brunner-Williams wrote: With the original subject, let's discuss examples with Latin characters only. i think the fundamental issue here is not to accept meaningless, or meaning-loosing reasonings by imagined similarity. Unless the reasonings are formerly described, it is impossible to operate international zones, especially root zones. Note also that, just as a meaningless label is accepted today, a label with 20 characters of 'y' with dieaeresis will be acceptable, which causes exponential explosion. case is not a property of han script(s). when non-specialists imagine that han script(s) have a case-like property and then try to reason about han script(s), error arises. Beyond simple case but still within ASCII, how about Dutch example where IJ and 'Y' are equivalent? Is a label YYY equivalent to IJIJIJ ? This case should be resolved in a way compatible to the current rules for ASCII-only labels. But, we do need precise definitions on character/string equivalences. And, the definition used for TLDs must be international one. while this sounds nice, in practice it means that the operators of the two constellations of name servers that support two mostly identical views of . must agree, Not necessarily. An international definition could be a transitive closure of equivalences of all the possible locales. and from november 2001 to the very recent present, there was a substantial area of disagreement between these two operator communities over a charset issue. I don't know what is the disagreement but I know it is not an issued to be resolved here. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
