Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Tue, Feb 04, 2014 at 12:01:10AM -, John Levine wrote: > Not really, because what you get by squatting on a TLD is nothing like > what you get if you rent it from ICANN. Squats are all local > (mis-)use, with names only leaking onto the public Internet by > accident. That actually depends on what you're doing with the name. In the case of the names discussed in the chapin draft, that is true. It's less true in all cases. Best, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
On Mon, Feb 03, 2014 at 04:56:38PM -0500, Ted Lemon wrote: > This is a useless discussion. Recriminations do not change the past. True, but effectively what you're saying is that this special-use registry could be used by anyone who's prepared to [squat|use a TLD without registering it] in the right ways to get around the ICANN allocation procedures. I think that's spelled "moral hazard" in economics. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] More keys in the DNSKEY RRset at ., and draft-ietf-dnsop-respsize-nn
On Tue, Jan 14, 2014 at 01:54:56PM -0500, Joe Abley wrote: > It's interesting to see that what was actually built in 2009/2010 is > largely compatible (at the high-level diagram level) with what was > proposed I thought that was interesting too. > However, each RKO you add increases the operational risk that an SKR > from that RKO might not be obtained within the required window, > which puts zone publication in jeopardy. Good point. I think the idea is that this is a feature, because it's supposed to be the Mutually-Assured Destruction threat that will prevent the USG from unilaterally removing some country from the root zone (that seems to be the threat people are worried about. Why is left as an exercise for the reader. Note that I do not promise there is a solution to this exercise). > [If validators took the approach of installing trust anchors from > each and every RKO to mitigate this possibility, then they are > effectively saying "I'm happy so long as at least one RKO is happy > even if all the others are deeply miserable", which doesn't sound > like it achieves the document's objectives.] It _might_, if the idea were instead that validators used n of m. Ben Laurie had a not-completely-dissimilar idea for root TA distribution entered in the "rollover" competition back in 2006 or so. See http://tools.ietf.org/html/draft-laurie-dnssec-key-distribution-02. Thanks for the observations, which I think are quite helpful. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] More keys in the DNSKEY RRset at ., and draft-ietf-dnsop-respsize-nn
Dear colleagues, For my sins, I have been following some of the recent discussions about "Internet governance". One of the discussions over on the "1net" list (http://1net-mail.1net.org/mailman/listinfo/discuss) is about the control by one particular government of the DNS root zone, and how uncomfortable that makes some other governments. The consequence has been renewed discussion on a somewhat older proposal for splitting up the management of the root zone keys. The proposal can be found at http://www.internetgovernance.org/wordpress/wp-content/uploads/SecuringTheRoot.pdf. The proposal has the appealing property that nobody can "hijack" the root, and if you don't trust any particular actor then the approach ensures that it is at least technically difficult (or detectable) that someone has acted alone. But it has always seemed to me that the approach would result in a very great increase in the size of the root key RRset as well as the RRSIGs necessary at least over the DNSKEY RRset. One response to this (http://1net-mail.1net.org/pipermail/discuss/2014-January/001057.html) is, "So what? It's the root. It'll be widely cached, and TCP is a small price to pay for this on the occasions it's needed." I am not sure I am so sanguine, but this put in my mind the draft-ietf-dnsop-respsize draft, which I now realise was never published as an RFC. I'd like this thread to discuss the "so what, use TCP!" remark. I'd also like to ask either the chairs or the WG whether draft-ietf-dnsop-respsize-14 needs revision and, if so, what revision to be publishable, because I think it's needed advice. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] On squatting and draft-grothoff-iesg-special-use-p2p-names
On Mon, Jan 06, 2014 at 12:56:53PM -0800, Nicholas Weaver wrote: > > You'd like to think that, but sorry no. They are seen all the time: No, that's different. Now you're saying that sometimes people use these for purposes other than what's documented, so they hand them around. If _that's_ the case, then on top of everything else the documentation in this case is wrong, and therefore the argument for the allocation is bad. Look, I'm not opposed to these allocations in principle, but if we're going to have two completely different ways of registering top level domains and they're going to be responsible to two completely different allocation bodies until the actual moment of registration with IANA, then we are going to have to be _extremely careful_ with how we do this. It's true that .local was sort of a prior example, but as Paul already pointed out there are quite significant differences in the way that emerged. Not the least of the differences is that .local got going in an environment in which most of us were in a position to assume the root zone was fairly small and fairly stable. Those assumptions are now violated, and the plans for that violation were announced a few years ago. Conditions are different, and I think it appropriate therefore to respond differently. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] On squatting and draft-grothoff-iesg-special-use-p2p-names
On Mon, Jan 06, 2014 at 01:48:04PM -0500, Ted Lemon wrote: > It seems to me that TOR is a pretty vital application, even if it's > not as popular as .local (which, let's be honest, is almost never > seen, much less typed, by an end user). Addresses in ".onion" are opaque, non-mnemonic, alpha-semi-numeric hashes corresponding to an 80-bit truncated SHA1 hash over a given Tor hidden service's public key. I'm pretty sure things in .onion are never supposed to be seen, much less typed, by an end user too. > I am deeply skeptical of > the idea that the only relevant factor here is how widespread the > squatting is on a particular top-level special-use domain. I have never suggested that's the only relevant factor. But I have suggested that the argument, "This needs to be a TLD that steps on the standard ICANN allocation mecahnism because it's already widely deployed," needs some evidence of that wide deployment. In the case of .onion, for instance, it is very far from obvious to me that the name needed to have been allocated directly beneath the root (as opposed to, say, inside .arpa); but if Tor is already widely deployed, the argument in favour of allocating that string in the root due to practical side effects is made stronger. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] On squatting and draft-grothoff-iesg-special-use-p2p-names
On Mon, Jan 06, 2014 at 09:47:04AM +0100, Stephane Bortzmeyer wrote: > > Yes, Apple did so. Exactly. It may be true that RFC 6761 was in effect created in order to regularlize the .local use, but my claim is that the .local use was more akin to the current issues with .corp and .home than like these cases, where penetration is quite a bit smaller. (I realise that .onion is important to Tor, but I am sceptical that Tor has the Internet penetration that Bonjour did long before 6761 was published. Certainly Namecoin use is insignificant compared to what Bonjour was.) A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] More complete review of draft-grothoff-iesg-special-use-p2p-names-01
On Mon, Jan 06, 2014 at 09:39:32AM +0100, Stephane Bortzmeyer wrote: > reasonable (it would be better to have "stable" references) but it is > a "nice to have", it is not mandatory in IETF processes here (RFC > 6761, section 4 does not require it I think I disagree. 6761 section 4 says If it is determined that special handling of a name is required in order to implement some desired new functionality, We need some way to make that determination, or else there's no reason to allocate the labels. In order to make such a determination, we'd need either a stable reference or else details in the draft that wants to allocate the new label. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] On squatting and draft-grothoff-iesg-special-use-p2p-names
On Thu, Jan 02, 2014 at 10:30:04PM +0100, Christian Grothoff wrote: > Didn't Apple squat on ".local" and get it reserved using RFC 6761? Not exactly, no. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] More complete review of draft-grothoff-iesg-special-use-p2p-names-01
ere. Then you could have i2p.localdef.arpa. Applications that don't know about localdef.arpa still won't block because .arpa is a perfectly good domain. Applications that do will know to strip off localdef.arpa and do stuff according to their magic label. This is _still_ not using the DNS. It's just living comfortably inside the DNS namespace, which is not what setting up random TLDs does. > Given that the code is GPL, why do you then allude to the fact > that it might make lots of money for someone else? It seems pretty clear that most of the alternative-currency systems tend to attract speculators at the beginning. I note that namecoin attempts to blunt this compared to bitcoin, but new currencies are _always_ the domain of speculators at the beginning. To someone interested in the new-TLD business (and I assure you that neither my employer nor I are), that could look like someone trying to make money without "paying their dues". I don't know how far I buy this argument; I'm just trying to point out the collision here between the IETF allocation procedure and the regular TLD allocation procedure at ICANN. (I freely admit that the problem is caused at least partly by the somewhat dubious "cost recovery" amount of US$185,000. If I were boss of the world, there'd be a lot of things I'd change. You may imagine that ICANN's rules would not make my first pass :-). ) > get the value they (presumably) wanted. However, you're right that > this turns the "recursive DNS resolver" into a "recursive resolver". > I'm not exactly sure why you think this would be so terrible, but > I'm happy to debate this issue (I don't even have a particularly > strong opinion). Unfortunately, many people have had the bright idea of injecting things into "the recursive server" in order to "satisfy user expectations". This causes a number of (widely-documented) problems, and in any case relies on a faulty picture of the real data paths for DNS data. It's true that the model is mostly ok for >90% of all traffic, but the problems show up in the minority. Even a very small minority of problems turns into a major headache for help desks -- usually not the help desk of whever had the bright idea. So, the IETF cannot responsibly suggest yet another class of positive answer be added to these intermediate resolvers. NXDOMAIN seems to be harmless. Everything else seems to cause trouble. > > Quite apart from what happens in the presence of DNSSEC (I think it's > > "fails completely"), I think it is in general bad advice to tell > > people to populate their DNS caches with data from outside the DNS. > > Well, it'd be a "resolver cache", not a "DNS cache" at this point ;-). So what happens when that resolver gets a query from an end system that is doing its own validation? What if the CD bit is set on that query? Now, what if different applications on the same end system have different resolver libraries, and one is asking for DNSSEC and the other isn't? Won't that be kinda confusing? All this would need to be spelled out in detail for an intermediate multimode resolver that might synthesize DNS responses. Yes, these are corner cases. Those furry blobs you see in the corners of the DNS are not dust bunnies. They're monsters, and they bite. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] More complete review of draft-grothoff-iesg-special-use-p2p-names-01
here be > > used interchangeably. > > I don't quite see why this would not work in principle, assuming your > mail client is configured to route SMTP over Tor and the specified > exit supports exiting on port 25 to gnu.org. Because the [ ] notation signals that what's in there is an IP address, not a name. > I guess the question is what you define as "DNS resolver". For example, > is the "dns2gns" proxy --- which speaks DNS (to applications) and then > forwards > ".gnu" and ".zkey" to GNS and everything else to DNS --- a "DNS resolver"? Only partly. This is similar to the confusion we had about recursive resolvers and caching name servers. In the DNSSEC documents, you can see discussion about "the resovler side of a recursive name server" and "the name server side of a recursive name server" (or something similar). Your example is of a general-purpose resolver system that does both DNS and GNS. For the purposes of protocol, then, you have something like (ASCII art, sorry): resolver > DNS > DNS resolver ---> DNS |-> GNS ---> GNS resolver ---> GNS For the purposes of implementation, these may well all be the same code. But for the purposes of the protocol, we need to distinguish them. > (browsers, wget, telnet, etc.) for GNS do not need to be modified at > all, or for other pTLDs the modifications are limited to the addition > or configuration of SOCKS support. Ok, that is probably important to make clearer; probably the each-name-gets-own-question-answers will do that. > I think you're mis-reading the point here, as the Namecoin block chain > is not obtained using the usual DNS protocol from some authority. So > DNS server operators that wanted to do this would NOT go out to some > IP address of a TLD operator that was granted ".bit" operation from > ICANN to fetch the block chain; instead, they'd have to participate > in the Namecoin network to observe block chain updates (a rather > daunting process, so this "MAY" is one that I personally don't expect > to see happening anytime soon by any major ISP). This is an even worse idea. What you're suggesting there is that recursive name server operators should add the .bit name to the answers they give out; but they don't get that answer from the DNS. Quite apart from what happens in the presence of DNSSEC (I think it's "fails completely"), I think it is in general bad advice to tell people to populate their DNS caches with data from outside the DNS. > I expect them to be handed around by end-users and within applications. > I do not expect them to be handed around within UDP packets on port 53 > (with the exception of ".bit"). But they will be: > I expect that this MAY happen, but if the draft is accepted, one > of our goals is to explicitly authorize DNS operators to prevent > this. You can't "prevent it". You can just have them swallowed somewhere else in the DNS system. They _will_ get passed around on port 53. Therefore, > > "resolved or did not". But perhaps what you are saying is that these > > ought to be added to the list in RFC 6303, and that they should always > > answer NXDOMAIN? I could certainly live with that. > > Yes, exactly. The formulation did end up a bit unclear and should > be fixed. Our intention was exactly to allow servers to immediately > return NXDOMAIN without going to the root. what I'd do is take a page out of RFC 6303, or follow the text in question 4 in the RFC 6761 discussion of .test: 4. Caching DNS servers SHOULD recognize test names as special and SHOULD NOT, by default, attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve test names. Instead, caching DNS servers SHOULD, by default, generate immediate negative responses for all such queries. […] > Again, thanks for your comments, we'll try to address those in the > next iteration, many of these were really helpful. Glad to be of help. Best regards (and happy 2014), A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] More complete review of draft-grothoff-iesg-special-use-p2p-names-01
.exit]? I bet not. It's simply not true that names and numbers can everywhere be used interchangeably. 2. Application Software MAY pass requests to any of the six proposed pTLDs for normal DNS resolution if A/ records are desired. If available, the local DNS resolver MUST intercept such requests within the respective operating system hooks and behave like DNS. That is a _very very_ bad idea. Either these are special names that aren't part of the DNS, or they're not. If they _are_ part of the DNS because you sometimes want to get DNS data associated with them, then they're DNS names and there's no excuse for this special registration. Go apply to ICANN. If they're not, then you can't have this. But I think what this actually means is, "If these are passed to a DNS resolver, the DNS resolver will follow the usual DNS semantics to resolve them. That should result in RCODE=3 (Name Error) because the TLD labels should never appear in the root of the DNS. I don't like the bits in this section that suggest "the resolver" can do different things, depending. What is really meant is that a resolver call on a system might be resolving in more than one name space. It so happens that a non-DNS resolver might use these name spaces as triggers to do something. In any case, if this owner name reaches the DNS resolver, then the expected outcome is RCODE=3. In addition, I wonder whether this means that these ought to be set up as "default local zones" the way certain other ones are. See below. 4. […] But given that ".bit" users have no special privacy requirements, and those names are globally unique, caching DNS servers MAY choose to treat them as regular DNS names, and cache the responses obtained from the Namecoin block chain as if they were resolved from the regular DNS tree. This is, bluntly, a reason to refuse the .bit registration. If .bit wants a TLD, then let them get it. Otherwise, this is a special name and shouldn't be in the DNS, period. 6. DNS Server Operators MAY choose to resolve ".bit" names using the Namecoin block chain, and if they do so SHOULD treat such domains like they would regular DNS names. Same here. Also, DNS Server Operators SHOULD treat requests to the other five considered pTLDs as typos, for correct installations MUST NOT allow such P2P requests to escape to DNS. This is ridiculous. The _whole point_ of these special TLDs is that you expect to hand these names around as though there's nothing special about them. In that case, you absolutely must expect that these names are going to get to the global DNS (if you think they won't, then I urge you to consider how much .local traffic makes it to the root). Because they don't exist in the root zone, they will be cached for the negative TTL in the root zone's SOA (currently 1 day, if memory serves). So, first, that certainly has effects on DNS operators. Second, there's no such thing as "considering a label a typo" except in the most egregious abuses of the DNS. What we have is "resolved or did not". But perhaps what you are saying is that these ought to be added to the list in RFC 6303, and that they should always answer NXDOMAIN? I could certainly live with that. Best regards, Andrew -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [internet-dra...@ietf.org: I-D Action: draft-grothoff-iesg-special-use-p2p-names-00.txt]
On Fri, Dec 06, 2013 at 10:29:44AM +0100, Stephane Bortzmeyer wrote: > There is no such thing as DNS name. We talk about domain names here, > domain names exist outside of the DNS (LDAP, mDNS and other resolution > protocols). MDNS names are _not_ domain names, sorry. They look like domain names, admittedly, but they're names in a different protocol. The trick of mDNS is to make a protocol that looks almost exactly like DNS to a user but that works differently under the hood. That's a trick, however, and it depends on a separate name space. The elephant in dnssd WG's room -- and the very careful scoping of dnssd's charter -- is exactly this issue; it's why internationalization in the DNS using IDNA and internationalization in mDNS is not interoperable. Best, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [internet-dra...@ietf.org: I-D Action: draft-grothoff-iesg-special-use-p2p-names-00.txt]
On Thu, Dec 05, 2013 at 10:02:18AM -0500, Warren Kumari wrote: > > Sure -- I don't think that the string itself is important, but rather, in the > words of Connor MacLeod: There can be only one! > The difficulty is in the claim that these names are already "out there". If that is in fact true -- that these are names that are being handed around and potentially will get into protocol slots -- then as a matter of prudence we should put all the strings in the special-use registry, and treat them all as .invalid is. Best, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [internet-dra...@ietf.org: I-D Action: draft-grothoff-iesg-special-use-p2p-names-00.txt]
On Tue, Dec 03, 2013 at 06:10:31PM +0100, Stephane Bortzmeyer wrote: > > Indeed, .onion, .zkey and .gnu do not use the DNS at all. They need > domain names but not the DNS. Nonsense. The very abstract says, "[C]ompatibility with applications using DNS names is desired…." The hard lesson of mDNS and all these other semi-successful attempts to glue into DNS space without tripping over all the same old DNS limitations is that, once you offer people domain names, you convince them they have a name that they can use in a protocol slot, and they will. It's clear to me, however, that I'm going to have to read the referenced documents more closely. I have a sneaking suspicion that the names actually _aren't_ like DNS names in some ways, and that they won't work if they're used in DNS protocol slots. But if the goal really is to reserve the namespace and _never_ have DNS for these things, then the special handling in draft-grothoff-iesg-special-use-p2p-names-00 is wrong. It ought instead to be a mirror of the handling of .invalid in RFC6761. I'd be way less concerned about proceeding with these registrations if that were the goal. Nobody can reasonably object to avoiding colliding namespaces, given what's already going on with the "name collision" work in this round of TLD expansion. Best, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [internet-dra...@ietf.org: I-D Action: draft-grothoff-iesg-special-use-p2p-names-00.txt]
On Mon, Dec 02, 2013 at 12:44:48PM -0500, Ted Lemon wrote: > > If special-use names are at the top, then you can just look at the terminal > label to see that you need to use a different protocol to resolve names under > the special-use name. If special-use names are not at the top, then you have > to have special code that grovels through the labels doing pattern matches. This is a bizarre argument. Once you're using DNS names, you need code that handles names label by label anyway (and copes with all the brain-death from the search path and the difference between FQDN-in-URI vs. FQDN-in-DNS and all that). So you're going to have to cope with the label-by-label rules, and at that point I find it hard to believe that the number of labels makes a really big difference to complexity. If your argument is instead that implementers are just going to pop off the last label and look at it, well, then they need some namespace other than the DNS anyway, because that's not how the DNS works. Assuming that you can just pop the right-most label off some putative domain name and assess that without going through all the DNS matching rules, in fact, strikes me as dangerous. And once you've shifted into .arpa. space, at least you know you're supposed to be dealing with infrastructure. Also, partly echoing what Joe argued, the .local case is special because (1) Apple implemented and released it first and then documented; (2) the original plan was to treat those names as part of the same port-53 protocol with locally-scoped semantics; (3) then the plan became to run a perfectly parallel namespace for another protocol; and (4) in any case, the idea was to hide from the user that the names were in some way different. (We can see the nasty side effects of 2-4 in the current discussions in DNSSD, by the way.) It does not appear in this case, at least as near as I can tell from my admittedly less-than-careful read so far, that the plan is to be quite so similar to DNS, so I'm actually not sure that what's needed here is the DNS at all. I'm in fact reminded of a widely-worn t-shirt[1]. I think this conversation is useful, but I really think it's premature to be talking about TLDs. [1] http://www.cafepress.com/nxdomain.624728706 Best, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [internet-dra...@ietf.org: I-D Action: draft-grothoff-iesg-special-use-p2p-names-00.txt]
On Sun, Dec 01, 2013 at 12:35:44PM -0500, Paul Wouters wrote: > > It would make more sense to me to reserve something like .alt where > people can plugin onion.alt, gnu.alt, etc, and are guaranteed that > the .alt domain will never actually be delegated by the root. And, behold, we have .arpa already. We could just create anything we wanted under there. I don't get why some new TLD is needed. > And once you go that way, one can wonder why not use the already > existing .local for that? Perhaps avoid talking to different protocol > software is a good enough reason not to re-use .local. Certainly do not re-use .local for this. The reason mDNS needed a different TLD is (to drastically oversimplify) because it uses the TLD as a protocol-shift token: when you're in .local, you're actually using a different protocol, and this is a way to keep the otherwise parallel name-space aligned. (This is the fourth extension mechanism we have in the DNS: we have RRTYPEs, CLASSes, underscore labels, and TLDs. Hurray!) > The traditional reasons for not using any non-IN class is that a lot > of software would not work well with that, but in these cases, the > consumers aren't actually interested in real DNS anyway, and using > a URI that indicates a different class should not be too hard to plug > into existing browsers? The last such proposal was a mechanism to use a new CLASS for IDN support. It turned out it wouldn't work because (among other reasons) there were too many resolvers that spit up on any CLASS other than IN. I am dubious that has improved, though I'd be prepared for evidence that it had. Best, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Moving parent-child-update documents forward
Dear colleagues, On Wed, Nov 06, 2013 at 05:49:54AM -0800, Dan York wrote: > I don't see why we can't adopt the CDS/CDNSKEY and CSYNC drafts as working > group documents and continue to move them along - we've had significant > discussion on these over the past several meetings and also on the lists: There is, of course, no reason why people can't just work on these documents without any magic bits about WG adoption. Indeed, if recent history is any guide, it might be that getting adopted by DNSOP is a good way to ensure a document never actually emerges from being a draft. It seems to me that this list is reasonably chartered to address this issue. If the chairs disagree, there is another list still around that can also be used. In any case, what's more important is that the work gets done, and not that we manipulate all the process levers in the IETF machinery. Best, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CDS and/or CDNSKEY
On Wed, Oct 09, 2013 at 10:13:53AM +1100, Mark Andrews wrote: > I would use whois for this discovery but the response is free form > text and you have the whole whois server discovery problem to deal > with. This sounds like an excellent reason to contribute to the rapid specification and deployment of WEIRDS. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt
On Mon, Jul 08, 2013 at 06:49:53PM +, Dickson, Brian wrote: > > Thoughts? My immediate thought is, "What problem is this trying to solve?" In the DNSSSEC case, the problem is that you're trying not to break the chain of trust, and you need a mechanism that is cryptographically securable to make the communication. This is made harder in some sense by the fact that the DS and DNSKEY RRsets are authoritative on different sides of the zone cut. In the NS case, because the child side RRset is the really authoritative one, that's the one that generally gets cached. Since both sides of the cut have the same RRTYPE, and since only one of the RRsets can be cached, you end up with only one such set and it's the one that gets used. It's it possible to bollocks this so that resolution fails? Yes. But that's not a result of disagreement between two different RRsets, so in this case having the additional communication path (especially inside the DNS) is less necessary. Best, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Thoughts on CDS
On Tue, Apr 23, 2013 at 04:55:44PM -0700, Wes Hardaker wrote: > arguments are always well thought out and well stated. The only > argument I have against Ed in this particular discussion is that the > resulting solution will be harmful to him since he can simply "not use > it". I confess that I haven't been following this discussion as closely as I ought (every time I start to try to read the thread, I feel like the thread gets longer). But in the little I've managed to read, it seemed to me that the points Ed was making were (1) that this is an important additional move on the supposed insignificance of the SEP bit, and that is worrisome and (2) if this mechanism were altered slightly, then it could be more generic and therefore more useful. Those both seem to me to be substantive and important points that ought to give us pause about the existing proposal. If I had a hope of getting through Zeno's mail thread this week, I'd try to read it all and respond. Instead I'm just pointing out that a dismissal along the lines of "just don't use it" seems to ignore at least part of the point of reviewing things in the IETF. Best, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] summary (was: RE: new version of IPv6 rDNS for ISPs)
On Fri, Nov 30, 2012 at 04:37:52PM +1100, Mark Andrews wrote: > Yes. They do TSIG signed DNS updates. They do direct them to a > update server using a in zone SRV record rather than the nameservers > that are serving answers to the world but otherwise it is bog > standard UPDATE + TSIG. Well, yes, but the plain fact is that if you want all Dyn's features, you have to use the webby API. Also, not every customer has access to UPDATE + TSIG. Full disclosure: Dyn gives me money, and I give them some of my feeble brain. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new version of IPv6 rDNS for ISPs
On Wed, Nov 21, 2012 at 06:07:23PM +, Paul Vixie wrote: > consumer grade and business grade internet connections. since consumer > grade connectees should really not be connecting to SMTP servers on > other networks I do not accept this premise, and I don't see any argument in favour of it. What evidence does "willing to pay more for the same lousy service" provide with respect to "is not sending outbound crap"? > to give it up, the tail would be very long. i'm going to treat this as > an unavoidable universal mistake that all of us will have to live with, > forever, period. There, we agree. > network operators should provide PTR RR's for specific addresses which > have real names. Also here. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC draft-ietf-dnsop-dnssec-key-timing-03.txt until 2012-09-14
Dear colleagues, On Thu, Aug 23, 2012 at 11:49:24PM +0200, Peter Koch wrote: > Dear DNSOP WG, > > this is to initiate a working group last call (WGLC) for > > "DNSSEC Key Timing Considerations" > draft-ietf-dnsop-dnssec-key-timing-03.txt > <http://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing/> > I have read draft-ietf-dnsop-dnssec-key-timing-03. I have some comments. I'll send additional comments containing nits to the draft editors. On the whole, I think the draft is a little complicated for operators to follow easily. I nevertheless think we should publish it: we offer today _no_ guidance to operators on these matters, and people I work with, at least, want such guidance. I know there's another draft floating about, but if we take as long to reach agreement on that draft as we took to review this one, we'll never publish anything. In section 1.2, it would be helpful to observe that, as a matter of deployment, the KSK might also be the ZSK. I'm aware that the document is assuming a sharp distinction, but by noting they could be the same key and leaving the working out of the implications for the reader, the document will be made more useful. Section 1.4 includes the RFC 2119 language, but in some places I notice "must" (in lower case) used. I find this a little hard to work with, and I know that at least one AD is quite exercised about this issue, so I think someone needs to go through the document and restate such uses. I also find it mystifying why some but not all of the definitions are moved to an appendix, although I don't really care about this. Section 3.1 has this definition: Published The DNSKEY record - or information associated with it - is published in the zone, but predecessors of the key (or associated information) may be held in caches. I think this isn't quite right, because the predecessors of the key (i.e. other keys) might also be Published, no? It's predecessors of the relevant RRsets that might still be in caches, I think, no? In section 3.2.2, the text, "The successor is key is now active and the current key is said to be retired," is a little strange (it's odd that the "current key" is the retired one and the "successor key" is active). I understand the text given the context, but I wonder whether this would be better phrased in terms of Key N and Key N+1. It took me a minute to understand Section 3.2.3, Event 4. Perhaps it could be clarified this way: There is now a delay while RRSIGs that were only generated using Key N expire from caches. This interval is given by the expression: Dprp + TTLsig After that interval, all caches that have any RRSIG will have the RRSIGs generated by both Key N and Key N-1. Or something like that? Best regards, Andrew -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-ietf-dnsop-dnssec-key-timing
Dear colleagues, In Vancouver, according to the DNSOP minutes, participants were to expect a WGLC "soon" on the subject Internet Draft. In the archives since the meeting, I observe some comments at http://www.ietf.org/mail-archive/web/dnsop/current/msg09783.html. But I do not observe the announcement of a WGLC. I am wondering when we might expect that call. Best regards, Andrew -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on "Negative Trust Anchors"
On Thu, Apr 12, 2012 at 08:27:21AM -0600, Stephan Lagerholm wrote: > Specifically in this case, you are assuming that the parent knows the > algorithms used for the DS record. He would have to in order to > validate. That might not always hold true. Additionally, the record is > not 'yours', it is just parked in your zone by the child. For the parent > to Tamper with either the NS or DS is IMHO not a good practice. The DS is _not_ parked in the parent zone by the child. Unlike the NS record, the DS record is authoritative data at the parent, and never at the child. As I read the RFCs, the DS record is fully and completely parent-side data, and is the parent's assertion of its relationship to the child. I really think we have to get over the idea that the DS record is somehow "the child's data" that is merely represented in the parent side. That way of thinking about this is a good way, IMO, to get failed chains across the zone cut. IMO it is better to think of the DS/DNSKEY pair as a way of expressing accord across a zone cut, with each side contributing a portion of the effort and holding a portion of the responsibility. Best, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
On Wed, Feb 29, 2012 at 10:22:55AM +0100, Shane Kerr wrote: > Paul, > > On Tuesday, 2012-02-28 18:40:30 +, > Paul Vixie wrote: > > i'd start over with a new port number first. dns wire encoding is > > already wildly complicated. > The main (only?) advantage of doing it with EDNS is that you can work > with existing name servers. It means adding more logic to our already > fabulously complicated resolvers to get full benefit, but nobody ever > said DNS was easy. It seems to me that, from the point of view of "dns-ng" and interoperation with dns, there are three possibilities: 1. End points use dns-ng. 2. End points use dns, but intermediate resolvers do dns-ng. 3. Everyone except authority servers do dns, and the authority server does dns-ng. Your suggestion is, in effect, a way of doing (2). But (3) isn't interesting (if nobody else uses dns-ng, then the authority servers aren't talking to anyone); and (1) is the actual goal we want, I think. If dns-ng is a superset of useful dns functionality, but cleans up certain issues with dns, then the intermediate resolvers in (2) can as easily use a new port as they can use more complicated dns handling. So I have to agree with Paul Vixie: if we're going to work on replacing the protocol, let's replace it for real. (FWIW, I think this is a noble goal doomed to failure. But I've been wrong before. Probably three times just this morning.) Best, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] ICANN variant project update
Dear colleagues, Apologies in advance for duplicate postings. I didn't cross-post because of the difficulty that sometimes causes if people follow up on list to discuss issues. Many of you will be aware that ICANN undertook the IDN Variant Issues Project last year. (Full disclosure: I was involved in the project.) On 23 December 2011 the report was posted for public comment, and I realise that I have been remiss in drawing people's attention to it. This message is to fix that. You can see the public announcement at http://www.icann.org/en/announcements/announcement-2-23dec11-en.htm. That's also a good place to start in order to submit comments if you have them. The pubic comment period closes at the end of January 2012. ICANN is eagerly soliciting comments, and I hope that those of you interested in this topic will take the time to read the report and send your observations. Having been a participant in this particular sausage-making exercise, I will say that I am sure there are things that need improvement, expansion, or more careful statement. I'm aware that the report as it stands is rather long, and I appreciate the difficulty in finding the time to read, digest, and comment on all of it. Given the importance of the topic, however, I think it's worth it. It might be tempting to discuss the document on this list, but I think it would be better to take such discussion either to the project list (which is still, as far as I know, open -- v...@icann.org, list info at https://mm.icann.org/mailman/listinfo/vip) or to use the public-comment links in the announcement to send such comments. That way, ICANN staff are sure to see the comments. Thanks and best regards, Andrew -- Andrew Sullivan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] bare names (was: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document)
Note: I trimmed the cc:s down to just the lists, but if we're going to pursue this dicussion we probably ought to follow up in mif, since that's where the draft comes from. That's why I set reply-to. Also, I sent this first from the wrong address, so apologies to those who see it twice. On Wed, Oct 19, 2011 at 07:23:15AM -0400, Keith Moore wrote: > I don't see why IETF should give a flying *#&(*#$ what the owners of > brand-name gTLDs want. Brand-name gTLDs are an exceedingly stupid > idea, and treating single label names as anything other than local > abbreviations flies in the face of 25+ years of practice. If you said, "25+ years of practice illustrating how broken the search-path mechanism is," I'd agree with you. I think it is largely true that single-label domain names are going to fail to work in all sorts of amusing ways that will surprise gullible people who forked over a pile of cash for the privilege of registering them. Nevertheless, the search path mechanism has never worked very well and is notoriously unreliable in the face of split-brain DNS. Still, too many people continue to rely on the search path for this document to be the place to deprecate it. But I agree with Ray (and apparently Paul Vixie) that the mechanism ought to go away. Now that Ray has mentioned it, however, perhaps a sentence along these lines in the second paragraph of 4.6 would be useful: It should be noted that the DNS search list mechanism may cause surprising results when used with more than one network at a time. That addresses the other point that Ray was making: search list-style bare names are often broken if you're not on the right network, and the point of this draft is precisely that you're _not_ on only one network, so it isn't clear what "the right network" is. > The best thing that IETF could do is to make sure that use of > single-label gTLDs is so unreliable that no megacorporation would > dare use them. And clearly that will work, because the IETF has a long record of success of standing before the tide and telling it to stop. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] bare names (was: [mif] [dnsext] 2nd Last Call for MIF DNS server selection document)
Note: I trimmed the cc:s down to just the lists, but if we're going to pursue this dicussion we probably ought to follow up in mif, since that's where the draft comes from. That's why I set reply-to. On Wed, Oct 19, 2011 at 07:23:15AM -0400, Keith Moore wrote: > I don't see why IETF should give a flying *#&(*#$ what the owners of > brand-name gTLDs want. Brand-name gTLDs are an exceedingly stupid > idea, and treating single label names as anything other than local > abbreviations flies in the face of 25+ years of practice. If you said, "25+ years of practice illustrating how broken the search-path mechanism is," I'd agree with you. I think it is largely true that single-label domain names are going to fail to work in all sorts of amusing ways that will surprise gullible people who forked over a pile of cash for the privilege of registering them. Nevertheless, the search path mechanism has never worked very well and is notoriously unreliable in the face of split-brain DNS. Still, too many people continue to rely on the search path for this document to be the place to deprecate it. But I agree with Ray (and apparently Paul Vixie) that the mechanism ought to go away. Now that Ray has mentioned it, however, perhaps a sentence along these lines in the second paragraph of 4.6 would be useful: It should be noted that the DNS search list mechanism may cause surprising results when used with more than one network at a time. That addresses the other point that Ray was making: search list-style bare names are often broken if you're not on the right network, and the point of this draft is precisely that you're _not_ on only one network, so it isn't clear what "the right network" is. > The best thing that IETF could do is to make sure that use of > single-label gTLDs is so unreliable that no megacorporation would > dare use them. And clearly that will work, because the IETF has a long record of success of standing before the tide and telling it to stop. Best regards, A -- Andrew Sullivan a...@crankycanuck.ca ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] ICANN Variant Issues Project case study reports
Because I am a moron, I forgot to include the links to the reports. They are as follows: Arabic: <http://www.icann.org/en/announcements/announcement-3-07oct11-en.htm> Chinese: <http://www.icann.org/en/announcements/announcement-03oct11-en.htm> Cyrillic: <http://www.icann.org/en/announcements/announcement-06oct11-en.htm> Devanagari: <http://www.icann.org/en/announcements/announcement-2-03oct11-en.htm> Greek: <http://www.icann.org/en/announcements/announcement-07oct11-en.htm> Latin: <http://www.icann.org/en/announcements/announcement-2-07oct11-en.htm> On Tue, Oct 11, 2011 at 11:08:21AM -0400, Andrew Sullivan wrote: > Dear colleagues, > > I'm going to send related messages to four IETF lists where I suspect > there might be people who are interested: dnsext, dnsop, apps-discuss, > and idna-update. My apologies to those of you who get it more than > once. > > For those of you who have been following or otherwise interested in > the ICANN Variant Issues Project, the case study reports are up. The > public comment period is open until 14 November. The Project is aimed > at sorting out, for some scripts, what people mean when they talk > about "variant names" in the DNS. > > For this WG, it seems to me that some of the techniques people seem to > be desiring involve potential effects for DNS operation. One group in > particular appears to be suggesting one or more DNAMEs for potentially > every delegation from the root zone when that script is used. The > operational implications lower in the tree might be worth considering. > > As a matter of full disclosure, I point out that I have been involved > with these reports, providing some observations about the (technical) > feasibility of various things people wanted to do. I provided advice, > but of course the teams actually responsible for the reports were free > to do as they wished with my advice (including ignore it). > > I encourage those of you who are interested in the topic to read the > reports and make any comments you think are useful in the public > comment forum, or (for that matter) by discussing things on the open > ICANN list devoted to the project > (https://mm.icann.org/mailman/listinfo/vip). Note that the usual > ICANN processes don't include the discussion on the mailing list as > public comments, so if you want your comments to be considered > formally, you'll need to post them in the appropriate area. > > Best regards, > > Andrew > > -- > Andrew Sullivan > a...@anvilwalrusden.com > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Andrew Sullivan a...@crankycanuck.ca ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] ICANN Variant Issues Project case study reports
Dear colleagues, I'm going to send related messages to four IETF lists where I suspect there might be people who are interested: dnsext, dnsop, apps-discuss, and idna-update. My apologies to those of you who get it more than once. For those of you who have been following or otherwise interested in the ICANN Variant Issues Project, the case study reports are up. The public comment period is open until 14 November. The Project is aimed at sorting out, for some scripts, what people mean when they talk about "variant names" in the DNS. For this WG, it seems to me that some of the techniques people seem to be desiring involve potential effects for DNS operation. One group in particular appears to be suggesting one or more DNAMEs for potentially every delegation from the root zone when that script is used. The operational implications lower in the tree might be worth considering. As a matter of full disclosure, I point out that I have been involved with these reports, providing some observations about the (technical) feasibility of various things people wanted to do. I provided advice, but of course the teams actually responsible for the reports were free to do as they wished with my advice (including ignore it). I encourage those of you who are interested in the topic to read the reports and make any comments you think are useful in the public comment forum, or (for that matter) by discussing things on the open ICANN list devoted to the project (https://mm.icann.org/mailman/listinfo/vip). Note that the usual ICANN processes don't include the discussion on the mailing list as public comments, so if you want your comments to be considered formally, you'll need to post them in the appropriate area. Best regards, Andrew -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Do negative cache entries have to be consistent ?
On Wed, Apr 13, 2011 at 06:04:31PM -, John Levine wrote: > Since the TTL on a negative cache entry comes from the TTL on the SOA > returned with the NXDOMAIN, this means that they'll be returning SOAs > with different TTLs on different responses. This strikes me as > something that's not technically illegal, but that people who write > DNS caches didn't anticipate. Is it likely to break anything? Strictly, the TTL on a negative cache entry comes from the minimum of the TTL of the SOA and the SOA.MINIMUM subfield. So the strategy won't work if the latter is too low. I'll ignore that and just assume you're dealing with it. In principle, a cache will need to be able to cope with the possibility that the TTL will change on a record in between times the cache looked. That's for two reasons: the authoritative server's records could change, or there could be a cache in between. It strikes me that a cache might not actually overwrite its negative cache for a zone if it already has a negative TTL longer than the one it gets in a given answer, on the grounds that having been given the longer TTL before it is permitted to continue using that. So I think you'll probably need to test widely in order to learn whether your strategy will actually work in practice. > Bonus question: with DNSSEC, a cache can use NSEC info to synthesize > NXDOMAIN responses for nearby addresses. Will inconsistent TTLs break > anything then? I think you'd have to ask implementers of such synthesizing caches. But I can't see how. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-savolainen-mif-dns-server-selection-06.txt
On Mon, Jan 17, 2011 at 08:54:05AM -0500, Ted Lemon wrote: > Hm. Okay, so the reason this is an issue is that I'm assuming the > resolver doesn't do its own validation. And you're right that if it > doesn't do its own validation, it's not much worse off using this > option than not using it; the degree to which its worse off is that > this option allows the attacker to deterministically attack certain > domains, whereas without the use of this option the attacker would, > in a best-case scenario, be relying on chance to succeed in its > attack. If the resolver doesn't do its own validation, then it is not allowed to treat the AD bit as meaningful unless it can trust the DNS server handing it that bit: In any case, a security-aware stub resolver MUST NOT place any reliance on signature validation allegedly performed on its behalf, except when the security-aware stub resolver obtained the data in question from a trusted security-aware recursive name server via a secure channel. (RFC 4035, section 4.9.3). Presumably, then, the stub needs somehow to have authenticated the DNS server in question otherwise before accepting the claims about signature validation. I can't think of any way to do this under DHCP, but maybe I don't know the protocol well enough. > I think you also need to document the signing architectures that > will work with this option: either don't sign the zone that contains > referrals for the internal zone, or else sign two copies of the > zone; one that's visible from outside and contains no referrals, and > a second one that's visible from inside, and contains referrals. This is the point I was trying to make over on mif: I think that there's a potential issue here with "closest TA" validation strategies, but I suspect that we're going to need different TAs for these "internal zone" cases. Or something like that. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-savolainen-mif-dns-server-selection-06.txt
On Mon, Jan 17, 2011 at 10:29:45AM +, teemu.savolai...@nokia.com wrote: > That particular case I have been told is protected against by using DNSSEC, > which ensures the host will detect the fraudulent answer to this directed > attack and will fall back to use other DNS server (or fail)... > Right. But I guess I'm confused: I thought you were arguing that DNSSEC wasn't needed. > If the host would have been single-homed, it would have send all its queries > to the interface this attacker has control over. Correct. -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-savolainen-mif-dns-server-selection-06.txt
On Fri, Jan 14, 2011 at 04:01:35PM +, teemu.savolai...@nokia.com wrote: > > E.g. by definition. Implement this only if you are a CPE or if you > are 3GPP handset and then only for this class of interface. Or > such. Those two scenarios are my main focus. Not believe what > CoffeeShopFreeAP tells. And why, if you are a CPE, should you believe what you get via DHCP either? Lord knows I have seen rogue DHCP announcements on cable modems. Moreover, even supposing that's solved, how is the device supposed to know when it is attached to CoffeeShopFreeAP and when it's attached to SuperGoodWellMaintainedISPNet? Isn't it completely ignorant at this point? > Well, if the host is openly multihomed and somewhere comes name > "server", you could append it with all suffixes you know of and try > resolve then all in parallel, connect in order of successful > resolution:) .. if you don't know any difference between your > interfaces. My first response is ick, but that's my first response to all barename resolution answers[1], so that's not a good test. I think this is an area where text is undoubtedly needed. I'll think about it more, but I urge others to do the same. A [1] The right answer is, of course, "Stop that," but the horse has fled, the barn burned down, and the horse died years ago. -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-savolainen-mif-dns-server-selection-06.txt
On Fri, Jan 14, 2011 at 03:53:25PM +, teemu.savolai...@nokia.com wrote: > > Shouldn't we work e.g. on securing all DHCPv6 signaling? I would say so, yes. But note that this particular option makes it easier to target one domain in particular. That's a more directed attack, so it seems to me to be a little more serious than "capture all the traffic". It's hard to spoof the entire Internet. It might not be so hard to spoof mycompany.com. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-savolainen-mif-dns-server-selection-06.txt
On Fri, Jan 14, 2011 at 03:09:21PM +, teemu.savolai...@nokia.com wrote: > > You can ignore the option and talk to the DNS server of your preference. You > can also choose to listen for the option only from one or more trusted > sources. > I'm really unclear about this "trusted sources" thing, though. Is that "trust only if you're on a trusted network"? Because I think the problem basically is that there's no sDHCP, right? > A bare name would unlikely find match from the suffix list. You could ask > resolution for the bare name from your favorite default. > > After appending the bare name with some suffix from your search list you > could look for match from DNS server selection list. > > Of course there could be multiple search list from different interfaces. In > such case you could prioritize the search lists by some means and start > walking through the suffixes when resolving bare name. > This is all a little hand-wavy. "Some means" sounds like the road to user-surprise-perdition. Bare names are already a bugbear, and I don't think we want to make them even more surprising. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-liman-tld-names-04
On Mon, Nov 29, 2010 at 10:03:22AM -0500, Eric Brunner-Williams wrote: > there exist rules, much earlier than 1123, about "-" as the initial, or Yes. They're the hostname rules. RFC 1035 has this to say about them, in section 2.3.1: The DNS specifications attempt to be as general as possible in the rules for constructing domain names. The idea is that the name of any existing object can be expressed as a domain name with minimal changes. However, when assigning a domain name for an object, the prudent user will select a name which satisfies both the rules of the domain system and any existing rules for the object, whether these rules are published or implied by existing programs. For example, when naming a mail domain, the user should satisfy both the rules of this memo and those in RFC-822. When creating a new host name, the old rules for HOSTS.TXT should be followed. This avoids problems when old software is converted to use domain names. The following syntax will result in fewer problems with many applications that use domain names (e.g., mail, TELNET). [. . . ] The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less. Now, we have considerable discussion in the first part of that passage that explains why the restrictions that are being introduced are so introduced, despite the fact that the protocol itself happens not to have such restrictions. So, are those rules "merely" allocation policy, or not? I can't tell, and I say you can't either. We don't even have the proto-2119 lanuage here that we see in RFC 1123, so we can't tell whether the "The labels must follow" in the last paragraph is a protocol restriction or a consequence of following the "prudent user" advice that immediately preceeds it. It might be policy, and it might not be. One way to figure out whether this is "mere" policy or whether it is in fact protocol is to ask people. It turns out, however, that different people have responded differently to this. Some people have responded by putting eight-bit labels in the public DNS. I claim, therefore, that regardless of whether the rule in RFC 1123 is or is not clearly policy, we should document that we explicitly permit, as a matter of protocol, certain characters in the top level. The draft as written carefully points out that there are lots of things that are policy and not the domain of the IETF. This just states that, in case anyone thinks there is a problem with top level IDNA2008 labels, there isn't. And I say again (for the last time, since I think I'm just repeating myself now), if one thinks that the restriction in 1123 is clearly not a protocol restriction, then there is nothing to say and we can be quiet. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-liman-tld-names-04
On Mon, Nov 29, 2010 at 10:17:39AM +1100, James Mitchell wrote: > 1. Requirements on composition of TLDs > no requirements over and above normal host names > i.e. can be 1*63 [a-z] [0-9] and hyphen, cannot start or end with hypen etc.. > [I think we can all agree that the internet will not break if ".8-ball" was > added to the root, as to whether it works...] > It seems to me we can all agree that the Internet will not break if you register a domain name o'reilly.com, either. But you're not allowed to, not because of the DNS rules but because of the hostname rules and a suggestion in the DNS specification that things will go better if you follow the hostname rules too. Why not relax that restriction? Why should we be beholden to old-timey restrictions? > For IDNs, must be valid a-label and u-label Why? That seems like it's "just" a policy preference. Why should the IETF have anything to say about it? Why shouldn't the top level labels also conform to JFC Morfin's Intersem plans, using multiple [a-z][a-z]-- prefixes? What basis do we have for telling ICANN what valid DNS labels they're allowed to pick? > 2.1 RFC1123 > application developers may have made assumptions about composition of domain > names; applications may not recognise new TLD. this has been seen with > .museum.. > > 2.2 Confusion with IP Addresses > TLDs that begin with a digit may be confused with IP addresses > TLDs that begin with 0x may be confused with IP addresses > TLDs that are 0-255 may be confused with IP addresses and thus never looked > up in DNS as suggested in RFCxxx > [perhaps some of these points become restrictions on the composition of TLDs] Or perhaps, in the interests of making changes near or at the root incrementally, we adopt the restrictive proposal in the draft and then write a subsequent one, informed perhaps by more study, that opens the door wider. > 3. Validation of TLDs > Application developers should not make assumptions about the composition of > TLDs, or the frequency in which they are allocated. if validation is required > then looking up the entry in the DNS is a foolproof way to know if a TLD has > been allocated. Consideration should be made to reduce queries to the root. > Static lists should be avoided. > Note that we already have an RFC that says roughly what (3) says, and so we don't need to say it again. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-liman-tld-names-04
On Fri, Nov 26, 2010 at 02:15:38PM -0800, Doug Barton wrote: > Ah, now I get it. You're arguing that the protocol restriction did exist > in the past, and now we're relaxing it, but only slightly. No, I'm arguing, just as the document does, that some people may have understood this to be a protocol restriction because the document was not crystal clear about what was policy and what was not. My personal view is that it _was_ policy, that it was called out as such, and that if things break then that's a pity. But as an IETF geek, I'm concerned about interoperability. And so since the protocol/policy line was not always drawn as brightly in the past as it maybe could have been, let's explicitly say that certain things are just hunky dory. In my opinion, the alternative to this is to say nothing. If you are right and there never was any protocol issue here, then ICANN has taken over that problem and we don't have to solve it. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-liman-tld-names-04
On Thu, Nov 25, 2010 at 05:37:08PM +, Tony Finch wrote: > Yes, but I think that the document should make it abundantly clear that > this restriction arises from the TLD allocation policy (NOT the protocol) > and this policy is subject to change, as in the introduction of long TLDs > and IDNS TLDs. So what aside from It is carefully noted that the specification in this document is not the only factor in choosing suitable TLD DNS-Labels, and that many considerations external to the IETF are included in that wider policy. See Section 5 for more discussion of policy considerations. do you want? It seems to me that those who don't like the document aren't actually offering text that they'd like to see in the document. (The exception to this of course are those who say the document should not be published, period.) A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-liman-tld-names-04
On Wed, Nov 24, 2010 at 10:48:19AM -0800, Doug Barton wrote: >> IETF is supposed to be about interoperability, and if stuff breaks >> because we have decided, "We don't care lalalalalala I can't hear >> you there isn't a problem," then we ought to be ashamed of ourselves. > > I am rather specifically NOT claiming that there is no problem, and your > attempt here to paint me (and others who agree with this view) as > childish/foolish is a borderline ad hominem attack. You have claimed that there is not a technical problem here, but "merely" a policy one. I am arguing that, given that some people apparently read 1123 differently than you do, we have a technical problem in the narrowest meaning of that term, and that we therefore ought to address it. Also, if you're going to start throwing around complaints about fallacies, you'll want to describe them correctly. If you really think I'm misdescribing your position, it's not an _ad hominem_ anyway. It's a straw person. Moreover, while we're talking about fallacies . . . > I will once again point out that if your criteria is "We can never > deploy anything new in DNS because something in the installed base will > break" then the issue with this draft is moot. We simply will not do > IDNs at all, and therefore there is no need for the draft to clarify > anything. Oh and btw, are you going to notify Jari and Ralph that we're > closing down dnsext, or would you like me to do it? . . . this is just a slippery slope argument, and not a very good one. Engineering decisions involve trade-offs. It is quite correct that there may well be deployed software that will break when exposed to on-the-wire DNS top-level labels that don't strictly conform to the RFC 1123 "alphabetic" description. That doesn't mean that we don't deploy such labels: it means we have to make a decision about whether the feature is worth the potential cost. I think it is, and I also think that the right thing to do is to specify exactly what we are changing and how so that, if something breaks, people have something they can read in order to understand what is going on. Moreover, the class of applications that might be using the heuristic about the top-level labels extends far beyond just those things actually talking to the DNS. It's actually that class of software I am most concerned about. That's what makes me think it is worth specifying first the smallest variation from historical practice that we can specify while still permitting the new use. > I've already lodged this objection more than once, but since you have > repeated your side again, I'll do the same. We do not have a protocol > restriction now, and your attempt to assert one in a "clarify" draft is > at best, bogus. Well, I'm not attempting anything: I didn't write the draft. But I think the draft tries to say that the 1123 language may be interpreted (by some) as entailing a restriction, not that there is in fact such a restriction: Some implementers may have understood the above phrase 'will be alphabetic' to be a protocol restriction. It seems to me that if you want to make clearer that the text of 1123 ought not to be so interpreted, you could send text to that effect. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-liman-tld-names-04
On Wed, Nov 24, 2010 at 01:15:23PM +1100, James Mitchell wrote: > If deployed software does not work with a TLD, it is the TLD owner who loses. I'm sorry, but that claim is arrant nonsense. We _all_ lose. The IETF is supposed to be about interoperability, and if stuff breaks because we have decided, "We don't care lalalalalala I can't hear you there isn't a problem," then we ought to be ashamed of ourselves. I think Joe's pragmatic approach is the right one: document right now that whatever the restrictions might historically have been, we are quite explicitly going to permit at the very least one class of labels. If people feel strongly that in fact the TLD label restriction never was there and should not be, then once this document is published you all can go out and write the draft, "TLD label character restrictions considered harmful", and pursue the publication of that as an RFC. In the meantime, we have at least a technical document that makes clear that certain things are permitted. 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 )
No, iris has not been widely deployed. 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. That there's no uptake seems to me to be an indication that registries don't want additional costs. So they won't sign up to expand their dns operation costs for these purposes either. If they _will_ spend on this, then it seems to me the deployment cost for an existing protocol will be lower than for one we still have to invent. A -- Andrew Sullivan On 2010-11-21, at 13:13, Lawrence Conroy wrote: > Hi Andrew, folks, > Does anyone actually use IRIS? > Telling someone to "go look over here for IRIS" seems like telling them > everything has to be in XML (only squared). > DNS provisioning and lookup for TXT in "srv-like" sub-domains is easy and > cheap (for implementers). > Provisioning, querying and parsing and IRIS data is not, I'd venture. > > So ... is your comment "Why do that?" really meant as "Why make life easier > for malcontents and spammers"? > > all the best, > Lawrence > > On 21 Nov 2010, at 17:41, Andrew Sullivan wrote: >> 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 > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ 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] draft-liman-tld-names-04
On Tue, Nov 16, 2010 at 08:15:06AM -0500, Eric Brunner-Williams wrote: > well, there are issues that the original idn, and the later idnabis > working groups didn't examine as exhaustively as others, and to assume > that every issue related to i18n and/or l10n on or off the wire was > adequately addressed by one or both is very, very generous. I don't think that anyone was supposing that. I was simply arguing that we can't re-open the entire protocol every time someone wants to write something that depends on it. If one thinks that IDNA2008 is broken or otherwise wrong, the right thing to do is to go write the IDNA2008 Considered Harmful draft, not to try to sneak those criticisms in through the back door of a pure clean-up document designed only to permit the use of IDNA2008 in the top level. If there is such a Considered Harmful draft floating about, then ICANN has the obligation to make decisions about whether to form its policy in light of that document. The IETF is about protocol, and all this document is trying to do -- and it is explicit about this -- is to relax (carefully) a restriction that may or may not have been understood somewhere as a protocol restriction. > That one was surfaced at the Mexico ICANN, with some bright young thing > dreaming of ".4u", presenting at least two problems in presumed policy > land. Note that .4u is still simply not allowed by RFC 1123 or by this draft. That is an all-ASCII label, not a U-label, and it is not alphabetic. Therefore, not allowed. If someone at ICANN wants to change that, s/he will need to write a draft. Or, of course, ignore the RFCs published by the IETF. I'm sure the people at the ITU would be happy with that latter outcome. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-liman-tld-names-04
On Thu, Nov 18, 2010 at 09:55:02PM +0900, Masataka Ohta wrote: > > As is explained in wikipedia > >http://en.wikipedia.org/wiki/Arabic_alphabet > > arabic letters have four forms, "isolated", "end", "middle" > and "beggining" and the form is determined by the location > of a letter within a word. Thus, they are not different > from Latin distinctions of capital/small letters, which is > determined by the location of a letter within a sentence. I don't see how any of the above (or any of the rest of the message, which I clipped but which betrays a misunderstanding of nuances of writing systems more or less as complete as the misunderstanding demonstrated above) has anything at all to do with the current draft. I think Ohta-san has made it clear that he thinks IDNA is broken. Point noted. But there's a whole list devoted to the topic of IDNA, and I don't believe it's in scope for this draft. The draft accepts IDNA as a foundation, and proceeds from there. IDNA2008 is a standards track IETF project, and it is therefore legitimate for an I-D to start with that specification as a starting point. If one thinks the standards track IDNA2008 specification is wrong or won't work (I suggested this before), one can go write a draft that says so. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-liman-tld-names-04
On Wed, Nov 17, 2010 at 09:54:30AM -0500, Eric Brunner-Williams wrote: > A reasonable observation. The responsibility to ensure that the nuances > of dependency were correctly noted in the past, or are correctly noted in > the present, remain. If only every "i" had been correctly crossed, every > "t" correctly dotted... If that's the issue, then we're in very deep water indeed. RFCs 1034 and 1035 are not without ambiguity. > Loosely speaking, there is something that superficially resembles an > obligation I meant it in the simple sense that, given that they're the people making the policies, they have the responsibility to do certain work. It's only that sort of implicit obligation, and I'll cheerfully (well, glumly, but I'm not exactly Tigger) concede that legal ones are probably not there. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-liman-tld-names-04
This is on dnsop, but just to be clear: for this and all the other messages I've sent in this thread, no hat. On Thu, Nov 18, 2010 at 12:08:13AM +1100, James Mitchell wrote: > Do we really want to say to 3com (probably a bad example, but go > with the concept) that they cannot have a TLD when their competitors > can? That is None Of Our Business. What this draft does is expand the previous rules about TLDs in the DNS in the absolute minimum way necessary to allow new TLDs using IDNA2008. It won't allow every possible TLD, in exactly the way that every possible LDH TLD is maybe or maybe not permitted by the RFC. The only avenue open to people who think this draft should not be published is to claim that the "will be alphabetic" claim in RFC1123 is not and never was an assertion to the rest of the network about what assumptions they might legitimately make about TLDs. In other words, you have to argue that the assertion "will be alphabetic" was (only) a statement of policy in force at the time; that such policy was clearly defeasible; and that the policy has been quite plainly overtaken by a new policy as determined by the relevant policy makers. I'm actually mostly comfortable with such an argument, but there are plenty of people who aren't. I say "mostly" because I don't think the policy people at ICANN have made anything about this topic even remotely clear, including that they think they are changing a rule in RFC 1123 and that they're doing it deliberately. (This is not to attack ICANN: they have their own problems, and I'm sympathetic.) Note that some people in this thread are making that argument quite clearly; I think it's an entirely reasonable position to take, though I don't happen to share it. If you think that we do in fact need an update to 1123 to clarify things, then there is nothing at all wrong with publishing this document right now, in order to allow the minimum necessary, and then revisiting the question more completely (ideally, suggesting to ICANN participants or staff that clear claims about the boundary between policy and protocol here from their quarter would also be useful, recognizing that there will be some disagreements and need to work things out). When 1123 was written, the Internet was in the early phases of the commercial explosion. We're past that now, and conditions are obviously different. But we have to deal with the fact that we have a deployed system with a lot of different things dependent on the historical behaviour. Part of our responsibility, _particularly_ in the operations end of the IETF "technical community", is to recommend prudent and cautious development of the operational conventions on the network: the line between policy and protocol has not always been bright. The closer we get to the thing that everyone depends on (and the contents of the root zone are surely within spitting of "everyone"), the more conservative we have to be. And yes, that sometimes means that we need to recommend prudence even if it isn't desirable to particular interests. > As a thought, consider names written in the Arabic script. Being a > cursive script, how is a TLD applicant expected to separate 'words' > in a top level domain without the use of a hyphen or > equivalent. They already have a problem, because DNS labels aren't words. They're mnemonics, perhaps, but not words. The publisher, O'Reilly, isn't going to be able to get .o'reilly either, no matter what we do: it's not allowed by the traditional LDH rule and it doesn't fall under IDNA2008. Is this discrimination? Only in the traditional meaning of "applying correct discernment", I say. Regards, A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-liman-tld-names-04
On Tue, Nov 16, 2010 at 01:00:10AM +, Richard Clayton wrote:
> Anyway... since we're meant to be discussing the document, I admit to
> being entirely puzzled by this section:
>
>A Restricted-A-Label is a DNS-Label which satisfies all the following
>conditions:
>
>1. the DNS-Label is a valid A-Label according to [RFC5890];
>
>2. the derived property value of all code points, as defined by
>[RFC5890], is PVALID;
>
>3. the general category of all code points, is one of { Ll, Lo, Lm,
>Mn }.
>
> The reason I'm puzzled is that RFC5890 doesn't discuss what "property"
> is and PVALID seems to be in a table in a different document (and so
> doesn't appear in RFC5890 at all). ie: I think the reference to RFC5890
> in #2 may be a typo.
Yeah, I was afraid of this when I saw it before. You've confirmed my
fear. The references to IDNA2008 in section 1 of the draft should be
to the entire document set (RFC 5890, RFC 5891, RFC 5892, and RFC
5893). Also, the text should undoubtedly refer specifically to
IDNA2008 rather than just "IDNs"; and the spelling of
"Internationalized" should revert to its American version, no matter
how one feels that is wrong, because the reference is usually to the
title of the document set and it's spelled with the "z" there. The
reference in item 2 needs to be changed, because the derived property
value is defined by RFC 5892:
This document reviews and classifies the collections of code points
in the Unicode character set by examining various properties of the
code points. It then defines an algorithm for determining a derived
property value. It specifies a procedure, and not a table, of code
points so that the algorithm can be used to determine code point sets
independent of the version of Unicode that is in use.
As an aside, I'll note that this sort of picky editorial issue is, to
me, yet another indication that the document is actually basically
ready to ship.
> I would also like to know where I'd go to look up what a category is ...
The category is a property of each Unicode code point. I think you
can probably get enough to understand the current draft by reading all
of the IDNA2008 documents (if you go to the RFC Editor search page and
just use "IDNA2008" as your search string, you'll get them all. But
they're RFCs 5890 through 5894, with the latter being non-normative
informational material. You might want to have a look at 5895 too.
But if that's not enough, you'll need to read the Unicode
specification. The whole thing is available from unicode.org.
> ... I think what this is intending to say is that you can have a TLD of
> ".2go" but only if there's an xn-- at the front of the whole thing :)
I think what you mean is that xn--2go would be a valid U-label, and
therefore would be a possible label under the rules in the draft, but
that "2go" itself is not a label permitted under these rules because
it fails the traditional "will be alphabetic" restriction in the
discussion in RFC 1123 (and it is not a possible U-label because it is
all ASCII). If so, then yes, exactly right.
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-liman-tld-names-04
On Wed, Nov 17, 2010 at 11:20:56AM +, Tony Finch wrote: > I believe that no requirement needs to be relaxed to allow A-labels. A > clarification might be helpful. If no requirement is needed, then no document is needed, because the policy realm was ceded to ICANN some years ago. We can remain quiet and wait for someone at ICANN to write a document somewhere that clarifies that they have changed the policy that used to be expressed in RFC 1123. > That is blatantly broken. There is no need for any heuristic to tell IP > addresses and host names apart. This kind of code should be mocked, not > accommodated. To my mind, this is a way of saying that anyone who has to live with broken implementations by people who half-understand the huge volume of DNS-related RFCs is just sweet out of luck. Too bad for them. Is that really what we want to say? A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-liman-tld-names-04
On Tue, Nov 16, 2010 at 04:06:37PM +, Tony Finch wrote: > According to my reading of RFC 1123 it is allowed, and IDNA depends on it > being allowed. The normative text says that anything that isn't a dotted > quad IP address should be treated as a domain name. Define what you mean by "normative text". You're quite right that the "will be alphabetic" restriction is in the Discussion, and therefore can be construed as not actually part of the protocol (that's actually how I read it). But the argument has been that the Discussion segment amounts to a constraint on the protocol, or anyway may well have been interpreted that way in running code. We don't know. (And of course, as usual in the DNS, we don't have any way of checking.) You're quite right that the "will be alphabetic" stricture has to be released for TLDs to be able to do IDNA at all: every one of them contains "--" and that's not alphabetic. So I read the document as trying to relax that rule just exactly enough to allow A-labels in the TLDs, without relaxing everything. The "don't relax everything" goal is to make the smallest change needed so that if there are any bad effects, they're not magnified more than they ought to be. Given what I have seen in other TLD-checking type code, I'd bet a pretty good lunch that anything _starting_ with a digit in the top level will run into all sorts of troubles. There's probably some heuristic software out there that checks the top-most label, looks for a digit in the first character, and treats the set of labels as an IP address if there is one. To me, the justification for the U-label having to be a letter, then, is that such a label could get passed in as a U-label form, and if the carelessly-written code is running in a Unicode environment it will do exactly the same thing as I just described. So the draft seems to me to make the most conservative change it can. Even if I don't like it, the top level is different from other levels in the DNS, and we need to be careful there. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-liman-tld-names-04
On Tue, Nov 16, 2010 at 07:46:08AM +0900, Masataka Ohta wrote:
> I already gave an example of capital form of 'c' with cedille is
> often plain 'C' without cedille and seldom 'C' with cedille, even
> though tools of ISO 8859/1 and Unicode support 'C' with cedille.
Changing the example does not make your case any stronger. (And
actually, you're now well into the land already staked by
J.F.C. Morfin and his crowd of adherents. In my opinion, Jefsey's
understanding of how French works is not exactly in line with what
l'Académie says, but you're welcome to go and read his views for
yourself.)
> That is, people affect the tools.
If course they do. And the tools affect the people. Technology
shapes us even as we shape it. English speakers have learned that,
for comparison purposes, EXAMPLE and example match, but it's not
actually quite as simple as that. For instance, there is a sorting
rule in English that sorts capital letters before lower case; so if
you had a list with EXAMPLE, Example, and example in it, they would
sort in that order. And sometimes case is important, as when you are
correcting the spelling of something that ought to be capitalized in
some cases and not others. ("The University's Senate made a statement
that the role of the university in the modern context has changed."
Case can change meaning.) Not all of this can be captured in the DNS,
either, but competent speakers of the language have learned how to
move around in this context.
> Now, may I ask where are facts supporting *YOUR* assumptions?
I'm not sure which assumptions you're talking about. If you're
talking about the one in which I was arguing that technology shapes us
just as surely as we shape it, then I'm afraid the demonstration of
that is altogether off topic for this list. But if you don't believe
me, I can suggest some elementary reading for you. You may find her
totally inaccessible, but I find Donna Haraway on cyborgs to be an
excellent place to start.
Anyway, you have not demonstrated even a little bit that all of this
needs to be included in the document, since it does not pertain
directly. You don't even appear to be trying to make such an
argument, so I think you're just ranting because you don't like IDNA.
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-liman-tld-names-04
On Tue, Nov 16, 2010 at 06:49:32AM +0900, Masataka Ohta wrote: > > If your local encoding is ISO 8859/1, you can input 'Y', but not > 'Y' with diaeresis. > > If your local encoding is Unicode but you are accustomed to ISO > 8859/1 environment, you will input 'Y', but not 'Y' with diaeresis. > > It does not affect abstract definitions of IDNA2008 but does > affect DNS operations. Everyone who ever makes this kind of remark seems to imagine that the tools that they are using never affect the people using them. This is a preposterous assumption, akin to maintaining that it was impossible to learn to drive a car because horses don't have steering wheels. Of course it is true that different people in different environments have a hard time spelling things in another language. That is simply not an argument that localization can't possibly work. It is instead an argument that localization in a globalized system brings with it a bunch of challenges that cause users some difficulty. It is then a matter of trading off the difficulty of communicating when there are different ways of spelling "the same thing" (e.g. an ASCII-based one and, say, a Han-based one) against the difficulty for a user who just doesn't have an ASCII keyboard or even a left-to-right user input context. Of course that is hard. Nobody ever said it wasn't. But there is a gap between "hard" and "totally impossible", and I do not see any advantage in pretending that such a gap doesn't exist. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-liman-tld-names-04
On Tue, Nov 16, 2010 at 06:07:28AM +0900, Masataka Ohta wrote: > IT'S ENOUGH THAT YOU ADMIT "IT DEPENDS". Remember that you wrote > "Because the matching function can not be changed." in your > mail on November 13. It seems to me that screaming on the list and taking two different phrases out of context and mashing them together is a demonstration that you are not interested in good faith conversations. Moreover, > And, under ISO 8859/1, it does not even depend, ISO 8859-1 is completely irrelevant here, because how you get to the point of having a U-label is totally out of scope for the IDNA2008 specification. But whatever you do to get to that point, the U-label has nothing whatever to do with ISO 8859-1. > Then, we have agreed that localized domain names in IDNA2008 can > not handle case insensitivities. It is certainly true that the DNS-protocol case preservation but case insensitivity matching rules are not internationalized exactly as one might like in IDNA2008. Without DNSng, I have no idea how to solve that. But you seem to be willfully ignoring that IDNA2008 actually does address this, although in an uncomfortable and somewhat unsatisfying way. One could be forgiven for imagining that you haven't bothered to read the RFCs you are insisting don't address the issue you're talking about. The draft does not need to address this point, because the point is addressed elsewhere. Every draft on internationlization is not an opportunity to re-explore the rathole down which the IDNABIS working group laboured for several years. IDNA is shipping. All the current draft does is permit TLDs that are in conformance with IDNA2008, except that it attempts to make the change as small as possible in order to try to minimise the possibility of surprises from software that had understood RFC 1123 as protocol and not policy. I think the document should be shipped as soon as possible. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] On resolver priming
Hi all, The last discussion of signing ROOT-SERVERS.NET involved the arguments that there's no real value in signing the zone and that there is a non-zero cost to doing so. I agree with both of those arguments, but I wonder whether it might not be a better sales job if we just accepted it maybe ought to be signed anyway. I'm aware that it runs against the grain to do something purely for theatrical reasons, but sometimes people like a good show. Every time this topic comes up (especially outside IETF circles, where one can perhaps be expected to understand the detailed arguments), a number of people argue that it's really necessary to sign the zone, or that having an exception for this sets some kind of precedent, or something. I think these discussions waste a lot of time, and so as a purely tactical measure it strikes me that we could shut down that line of argument by just signing the data. Thoughts? A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing-00
On Tue, Oct 19, 2010 at 10:26:27AM +0200, Johan Ihren wrote: > B. "Better to publish what we have and initiate work on a -bis document > immediately. Also known as the "Perfect is the Enemy of Timely"-alternative. I like this, but I'd like it more if there were text in the document that said something like, "This represents current thinking at the time of publication. The reader is reminded that DNSSEC is as of publication in early stages of deployment, and best practices will likely change in the near term." Or something like that. The idea is to give the reader a clue that s/he ought to be keeping up with the mailing lists and so on in order to understand what is happening. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC
On Sun, Oct 03, 2010 at 11:14:23AM -0400, Phillip Hallam-Baker wrote: > What is actually being proposed is to replace the fifteen year established > system of CAs with a new scheme starting in November. [. . .] > I really don't think that we want to replace the existing infrastructure a > new PKI designed by people who claim not to understand the issues involved. > As the proposers of this scheme have done repeatedly. Suppose all of that is true (and I think it's a gross misrepresentation of the situation, but never mind that), so what? Presumably, if this new PKI sucks as much as you say it does, nobody will use it, and no harm will come. If it's a kind of snake oil that appeals to the clueless (i.e. it sucks as much as you say it does, but it's jumped up and marketed in a way that lures people who don't know any better), then it will have some spectacular failure and everyone will thenceforth avoid it. So what's the problem, even if things are as bad as you say? Also, why isn't this on the list devoted to this discussion (followup set)? A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt
On Sun, Oct 03, 2010 at 01:18:01PM -0400, Joe Abley wrote: > > I'm not entirely sure the answer shouldn't be "because we manage the > keys, and we say so" actually. I think I've made this argument before, but the above seems to me to be one of two possibly relevant perspectives in respect of keys (either in this DNSSEC context or more generally, but I'm concentrating on the DNSSEC context just now). On the one hand, we can understand keys as expressing a certain trustworthiness-assurance on the part of the key publisher. We can understand the publication of the key as an assertion on the part of the publisher that data signed with that key is trustworthy. I call this view publisher-centric. If we understand keys according to this scheme, then it is entirely reasonable for a key publisher to say, "Once I have pulled a key, don't use it, ever." On the other hand, we can understand keys as a feature a publisher offers users in order that those users may make intelligent choices about trust. In this view, we can understand the publication of a key as part of that support offered to users who want to validate data. Those users are then in a position to make evaluations of data they receive. I call this the user-interpretive view. Under this view, it is not reasonable for a key publisher to try to prescribe how the key is to be used once it is published. This approach, however, comes with the risk to the user that the user will not know of a key compromise. The problem in this case is that the use-value to the user, which lies in increased confidence in the value of the signed data, is misplaced. Instead, the publisher's role is reduced to warning users (by policies) what uses the publisher is willing to support, and what uses are unsupported. It seems to me that both perspectives are useful and valuable, but they're different ways of looking at the issue and they have different implications. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fw: New Version Notification for draft-morris-dnsop-dnssec-key-timing-02
On Sun, Jul 25, 2010 at 10:39:15PM +0200, hsalg...@nic.cl wrote: >> My concern is whether this draft is the right place for such text. >> The IANA process is a special case and is not concerned with the >> timing issues that are the focus of the document; as such, it may >> belong more in something that describes how that timing sequence has >> been implemented in a particular case. >> > > But that particular case could be the norm! > Currently, not only the root has this policy. RIPE[1] and .br[2] also > requires prepublication of dnskeys. I'm not entirely sure that the draft ought to reflect what people do, because one could argue that that requirement is a mistake. But in any case, they're still infrastructure domains, just as is ., and the analogy between them and everything else breaks down pretty quickly. I think the draft is _not_ the place for this advice. If advice is needed, it should go in 4641-bis. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notificationfordraft-mekking-dnsop-auto-cpsync-00
On Fri, Jul 02, 2010 at 05:42:15PM +1000, Mark Andrews wrote: > I regularly use TSIG today between my master server and the slave > servers for my zones operated by other parties. TSIG really isn't > a hard thing to setup or use. It may surprise you to learn that there are users who do not find the user interface for these tools, or the idea of cutting and pasting into BIND config files, even slightly intuitive. I've personally encountered situations where it took weeks to set up TSIG between two servers. Anything that makes this sort of thing easier seems to me to be a good idea. (This is not an evaluation of the current proposal, just an observation.) A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] That key size argument...was Re: The case for single active key
On Fri, Jun 18, 2010 at 12:35:31PM -0400, Edward Lewis wrote: >> Remember I'm arguing against the KSK+ZSK split in most cases, a different >> thread will be started on key size recommendation. > > I don't think KSK+ZSK is a dead or outmoded idea. If I understand Olafur correctly, he doesn't either. He just thinks that in a large number of cases, it's not the right approach to achieve the goal of reliable operation (including the reliable availability of data for validation). I agree with him, and tried to make this point in Anaheim. The arguments for KSK/ZSK splits are at best appropriate for certain classes of operation, and I don't think we should publish a document that says that such a split is generally speaking a best practice. I think the arguments for that claim are weak, because there is countervailing evidence to the effect that a single key in the right circumstances will be more reliable and less likely to be messed up by operator error. That is especially true for smaller zones without professional administrators. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Split DNS problems for multi-interfaced hosts and a possible solution
On Tue, Jun 15, 2010 at 09:11:26AM -0400, Edward Lewis wrote: > The DNSOP group has considered but never adopted a draft (nor any > documented promoted to RFC) that defined what split DNS is. Without a If you were referring to draft-krishnaswamy-dnsop-dnssec-split-view there, I'm not sure I agree. My complaint at the time was that the document was trying to do two things at once, and neither was really fully there. In particular, I thought (and still think) that a fairly extensive discussion of split-view was needed, and that the different approaches and so on needed to be enumerated in one document. Then a second document detailing when and how to do split-view with DNSSEC (with that draft as the basis) would be good. I was ready to work on this, and in fact I did some work on it, but there didn't seem to be much other enthusiasm. I am still ready and willing to take this on. I know that it's fashionable to go "lalalala" every time split-brain^H^H^H^H^Hview comes up, but it's a widely-used feature and I think we're remiss if we don't document it. If you and Suresh want to continue work on this, so do I. > The group has to define split DNS. Completely agree. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-default-local-zones and the former IP6.INT.
On Tue, Apr 06, 2010 at 09:53:32AM -0400, Joe Abley wrote: > > "IP6.INT was once used to provide reverse mapping for IPv6. IP6.INT was > deprecated in [RFC4159] and the delegation removed from the INT zone in June > 2006. While it is possible that legacy software continues to send queries for > names under the IP6.INT domain, this document does not specify that IP6.INT > be considered a local zone." > I like this text the best of the three. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] FYI: DNSOPS presentation
Sorry for disappearing from this thread, but I was away. I want to draw attention to something in this discussion, however. On Wed, Mar 31, 2010 at 03:25:35AM -0400, Igor Gashinsky wrote: > > I will completely agree with you that this is where the problem *should* > be solved. However, we are about 5 years (if not more) too late in solving > it that way if we wanted to deploy ipv6 right now -- that is what we are > trying to address. Hell, IE6 still makes up close to 18% of all users out > there despite everybody trying to deprecate that browser, and the > percentage of ipv6 capable users is roughly the same as the percentage of > windows 98 users out there (0.3%)... So, given that clearly users don't > update their software often enough, it is too late to fix the applications > that are already deployed on users PCs (and their broken home > gateways/firewalls/etc), so, what do we do *right now*, to get those > "broken users" through the next 3-5 years till they upgrade? What that really says is that we failed to do this properly 5 years ago, and instead shipped a lot of kludgey half-working stuff that was sort of broken. Having done that, in order to work around it, the right answer now is to add a _new_ half-working kludge that will be sort of broken, and to add it at central places in the network where it will live effectively forever and where it will actually impede perfectly legitimate users who are using dual stack. I think that's a bad trade-off. This is entirely a question of trading the positive effects of doing something against the short- and long-term costs of doing that thing. I completely agree that there's a serious problem here, and I don't buy for a second the argument that end users need to experience this breakage in order to get them to "upgrade" or "fix" or whatever their broken environments (we are past the beginning of the automotive age, where every driver had to be able to make emergency repairs at the side of the road). But authority DNS servers aren't in the right position in the network to figure out whether the end user is having trouble: they can't even tell whether a query that arrives at their door over v4 is due to an end host that is using v4, given the existence of NAT-PT and the NAT64/DNS64 follow-on currently proposed. The ISP _might_ be able to do something, and even has a customer-satisfaction incentive to try to find these broken implementations and help the customer out. The service itself might be able to detect some things about what the client is actually able to do. But the DNS authority servers from the service operator are just not in a position to draw any of those conclusions, and the proposal can easily do as much harm as good. Therefore, it shouldn't be pursued. Best regards, A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] FYI: DNSOPS presentation
On Tue, Mar 30, 2010 at 03:44:43PM -0400, Edward Lewis wrote: > If IPv4 can get through faster than IPv6, why not continue to use it? > When IPv6 is the only way through, use IPv6. When IPv6 is faster, > again, use it. > > Let the end host decide. I thought I saw you in the DNSOP meeting in Anaheim where this was outlined? Anyway, the problem right now is not that the end host can't decide, but that the end host is deciding _wrong_: it does DNS over v4, tries to use v6, but is in fact broken on v6 and therefore won't get the communication it desires. So what we're trying to cope with is real breakage in real deployed stuff really on the Internet. This is not a theoretical exercise in preferring IPv6. It's an exercise in trying to do the least-bad thing, given that there is a tiny minority of hosts (which represents a large number of eyeballs) who are having trouble today. Dual-stack and IPv6-only installations are in some cases broken today. It's unrealistic to say, "Let them feel the pain & they'll upgrade," because the people this affects are unlikely to be able to understand what is happening to them. As a result, people are going to do something bad for the DNS (especially over the long term) unless we find some other thing to suggest to them. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] FYI: DNSOPS presentation
On Tue, Mar 30, 2010 at 02:15:49PM -0400, Edward Lewis wrote: > > I've heard that before. The "run out" does not mean an end to the IPv4 > network. There will still be 4 billion IPv4 network addresses (yes, a > fraction are unusable) in working order plus all the NATted pools out > there. The "run out" is a problem for network growth. Right. That's all I meant. I don't think we need to get people who are using v4 off v4. But there will be people for whom v6 will surely become a more economic option (since as v4 addresses become scarcer, people who have v4 addresses might find it worth moving to v6 because the resource is more plentiful). The point I was trying to make was that, since dual-stack is likely to be around for a while, with growth on the v6 side, it seems like the wrong time to break a perfectly good feature (DNS answers on v4 for a possible v6 connection). There's something else we ought to be able to do. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] FYI: DNSOPS presentation
On Tue, Mar 30, 2010 at 01:46:07PM -0400, Edward Lewis wrote: > > Why is there a need to wean people off IPv4? Because we're about to run out of v4 addresses, according to the people in charge of giving them out. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] FYI: DNSOPS presentation
On Tue, Mar 30, 2010 at 09:04:39AM -0700, Nicholas Weaver wrote: > His linux host would do an A and an query and, until the > query timed out, delay creating connections eg, through SSH, web > browsing, etc. An amazingly painful experience for him until he > diagnosed it. But the answer to this breakage that is being proposed is to turn on, apparently at ISPs' recursive resolvers, a different kind of breakage, and one without a useful way to detect when it's no longer needed. In other words, we'll introduce some sort of bizarre breakage to dual-stack systems (ones that might work correctly, even) without any plan for how we'll even know when to turn this breakage off. And this while we desperately need to wean people off IPv4 and onto IPv6. Rather than having the DNS magically lie to people, why not use the DNS detection mechanism as an indicator that a customer has a broken v6 implementation. Then you can turn off _that customer's_ IPv6 connectivity, contact them, and tell them what their problem is. This has three benefits: 1. The customer doesn't break in surprising ways. 2. Other customers don't break for no reason. 3. The customer learns s/he has an issue, and can take steps to correct it before IPv4 is too expensive to use any more. I am not among those who think that the number of clients involved with this is "insignificant". I know that something people sometimes hear, but the abolute number of people involved does make this a real problem. I just don't think that the right answer is to break perfectly well-functioning systems for everyone else in order to work around clients that are implemented wrong. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-ietf-dnsop-rfc4641bis-02
On Wed, Mar 17, 2010 at 03:51:42PM -0400, Paul Wouters wrote: > I think currently, a wrong DS trumps an updated DLV, but I have not > tested this recently on either bind or unbound. Is it specified anywhere > else what the expected behaviour is? Good point. No, I have no idea. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Review of draft-ietf-dnsop-rfc4641bis-02
rd that it doesn't understand. The text as it stands suggests it _is_ unreasonble, and I think it ought to be changed. The work that's gone on for RFC 4310bis, in my view, reflects this change of approach. Here's suggested new text: When designing a registry system one should consider which of the DNSKEYs, the corresponding DSes, or both, to store. On the one hand, one might regard the DS as fundamentally derivative of the DNSKEY data that originates at the child. In that case, it is reasonable to treat the operator of the child zone as the source for the DS record, in much the way parent-side NS records are generated; and, for the registry to store a DS record that comes from the child. This has the additional benefit of permitting the publication of a DS using a message digest algorithm not yet understood by the registry. On the other hand, the DS is authoritative data only on the parent side of a zone cut. For this reason, registry policy might be to require the submission of DNSKEYs so that the registry can generate itself the DS record for which it alone is authoritative. This has the additional benefit that the registry controls the transformation of the DNSKEY into the DS, so that any errors in this step are solely under the control of the registry operator. It may also be useful to store both a DS and corresponding DNSKEY, since having them may help during troubleshooting. Having an out-of-band mechanism, such as a registry directory (e.g., Whois), to find out which keys are used to generate DS Resource Records for specific owners and/or zones may also help with troubleshooting. The storage considerations also relate to the design of the customer interface and the method by which data is transferred between registrant and registry; Will the child zone administrator be able to upload DS RRs with unknown hash algorithms or does the interface only allow DNSKEYs? In the registry-registrar model, one can use the DNSSEC extensions to the Extensible Provisioning Protocol (EPP) [draft-gould-rfc4310bis-07], which allows transfer of DS RRs and DNSKEY RRs. §4.4.5 I'm skipping this because I'm pretty sure Olafur's recent work on the topic offers a lot of clarification. If the editors want new proposed text anyway, please ask & I'll work up some. § 5.3.4: to address the Ed note in there, perhaps insert the term "roughly" before "from"? AppxA: The "joyfully signs" bit made me chortle. Respectfully submitted, Andrew -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Internet history list (was: rfc 952, rfc 1123 and 25 years of .com)
On Tue, Mar 16, 2010 at 11:55:50AM +0100, Dr Eberhard W Lisse wrote: > can you perhaps email me the address of that list? Since that is already one of two requests I've had: List-Subscribe: <http://mailman.postel.org/mailman/listinfo/internet-history>, <mailto:internet-history-requ...@postel.org?subject=subscribe> A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc 952, rfc 1123 and 25 years of .com
On Tue, Mar 16, 2010 at 09:39:43AM +0100, João Damas wrote: > Thing is I had this vague impression that domain names weren't > allowed to begin with a number until later than that. Upon checking, > RFC 952, published in October 1985 had the starting-number > restriction and it wasn't until RFC 1123 (Oct 1989) that this got > relaxed. Anyone around remember how 3com.com got registered ahead of > it seemingly being a valid domain name (and again, this is in itself > a bit confusing as RFC 952 introduces the restriction for hostnames > and domain names, and RFC 1123 only seems to lift the restriction > for hostnames) I can't answer this question exactly, but I had occasion to ask Bob Braden directly about the context of the "always alphabetic" text in 1123 at one of the meetings last year, because that text in 1123 remains problematic (depending how you read it, it may prohibit TLDs of the form xn--[something], which would be bad given that there are such TLDs in the root zone today). He brightened up and immediately recognized the text in 1123 as "the 3com rule". This makes me think that he might be able to answer your question. Another place to ask might be the Internet history list, where people who remember some of the early decisions tend to hang out. Best, A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On 2010-02-22, at 19:13, Mark Andrews wrote: The problem is that one is using a hash, not the strength of the hash. Precisely. See another remark in this thread about excluded middle and so on. -- Andrew Sullivan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
On Mon, Feb 22, 2010 at 11:17:59AM -0500, Matt Larson wrote: > I am adamantly opposed to including > any text about SHA1 hash collisions in an NSEC3 context. Add me to the choir. Actually, I'm opposed to including any text about SHA-1 hash collisions in _any_ DNSSEC context until we write the document, "Deprecating SHA-1 hash functions for DNSSEC". A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
I think Olafur's point is a good one, but I'm unhappy with the prose. Some suggested changes below. On Sat, Feb 20, 2010 at 08:37:16AM -0500, Olafur Gudmundsson wrote: > There are two meachanisms to provide authenticated proof of > exsitance/non-existance in DNSSEC. A clear text one and a obfuscated > one. There are to mechanisms to provide authenticated proof of non-existence in DNSSEC: a clear text one and an obfuscated-data one. Each mechanism includes a list of all the RRTYPEs present at the name. Each mechanism includes only the name for which the zone is authoritative (that is, glue in the zone is omitted). The clear text mechanism is implemented using a sorted linked list of names in the zone. The obfuscated-data mechanism first hashes the names using a one-way hash function, and then sorts the resulting (hashed) strings. > The clear text version has its one RRtype for negative answer, Clear > text one uses NSEC record and the obfuscated one used NSEC3. I didn't know how to rephrase that, because if I understand it I think what I understand is wrong (but that's obviously not the case, so probably I don't understand it). A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] key rollover for real
On Fri, Jan 22, 2010 at 03:23:02PM +, bmann...@vacation.karoshi.com wrote: > the apparent nub of the argument is... we need to be > able to do this rollover thing, but if we screw up > it will be hard to put back together... so we won't > actually do the task - and hope that we'll never > pull the trigger. That's question-begging. The exact question under dispute is whether "we need to be able to do this rollover thing". Maybe one needs to be able to do it, and maybe not, and maybe the event itself is so rare in some zones that treating every occasion as the 1st time is the right approach. That's exactly what's up for debate. Some (I am among them) claim that there's a risk/reward trade-off, and others seem to start with the premise that it is a necessary event. Only if you accept the latter can you argue that it's the sort of operational event that must be undertaken with any regularity, and even then I think the argument is weak. > DNS operators -have- to pay attention these days or > the system will stop working. This is true, but it's unrelated to key rolls. It has to do with the resigning period, which is a completely different issue. On Fri, Jan 22, 2010 at 12:52:05PM -0500, Joe Abley wrote: > I don't think it matters whether the key roll schedule is perfectly > periodic (e.g. every interval T) or event-driven (e.g. every time > someone joins or leaves the operations team) but in general I am not > comfortable relying on important machinery to work when you need it > if it's not exercised. Ok, except that each exercise of this machinery is in fact a case of "needing it", since you're going to do exactly the things you'd need to do when you need it. The problem with the key roll as "exercising the machinery" is that it's a destructive test. > If you need an analogy, I think generator testing is a better one > than launching ICBMs at schools. You hope never to need your > generator, but you test it regularly anyway just in case. Good analogy. What you do here depends on your operation. If you are the sort of hugely-automated total 24x7 shop that needs to be able to prove in a controlled fashion that your generators all work, come on line, and take the load, then maybe (and only maybe) you turn the whole thing on, flip everything over to generators, and so on from time to time (in a controlled way) to prove that it all works. But if you have a tiny generator that is supposed to allow you to operate a couple things in your house in case of a snowstorm, all you do is fire it up and make sure it produces power. Which sort of test you ought to do is governed by what kind of needs you have. Since I think I've sung that refrain to everyone's boredom, however, I'll shut up about it now. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] key rollover for real
On Fri, Jan 22, 2010 at 12:57:13AM +, Jim Reid wrote: > invoked from time to time in the live environment. And not just for > drills. That sounds rather like a claim that we need to go around and set buildings on fire from time to time (or have levees break, or cause 7+ Richter-scale earthquakes, or pick your analogy) in order to make sure that the procedures are in place. It is simply not true that everything needs to be done "for real" in order to be sure it can be done. I don't think we should have live nuclear-weapon ICBM tests just to see whether the reaction procedures of the local elementary school are up to snuff. As I've now said several times, the risk of some activities is greater than the reward from seeing how well your operation of that activity follows the plans. The question here is how great the risk of key rolling is: is it more like live ICBM tests, or is it more like changing your underwear (the procedures for which I'm sure we all hope everyone keeps in good nick)? I claim the answer to that question is, "It depends," and we need to give people advice on how to decide where on the nuclear-war/underpants scale they lie. I think EKR and Paul have suggested ways to say that. I enclose below some additional long-winded text in case any of it can be useful. Keys in use do not become weaker with continued use, and there are not strong arguments from a cryptographic point of view that keys need to be rolled frequently or even with any regularity. Given the state of the cryptographic art as of this writing, the chances of a key (selected in accordance with the recommendations in this Section 3) being broken by cryptanalysis is exceeding low. It is important to evaluate continuously that risk. When making an evaluation, it is important to remember that the main question is one of cost versus value: 1. What will it cost an attacker to crack the key? 2. What will the benefit to the attacker be (i.e. what is the value of the key)? 3. How long can the attacker realistically expect to gain from the attack? To take a deliberately bad example, if it costs $1,000,000 to crack the key once a month, and the attacker can only actually use the compromised key one time before being detected, then the value of that single use needs to be at least $1,000,000 (however one calculates that value) to make the attack worth performing. Each key rollover comes with some risks and rewards. Every key rollover runs a small risk that the new key will not be available somewhere in time for the old key to be removed, if only because of the possibility that a validator has misconfigured the old key as a preferred trust anchor. Errors in the key rollover procedures or their execution can also lead to the new key not being available in time. If some validating resolver attempts to use the old key, and cannot (or will not, by configuration) use the new key after the rollover has completed, then that validator will treat the zone as bogus. Sites that have well-automated and carefully-tested key rollover procedures, particularly if the site is well-monitored from diverse networks, are somewhat less likely to face long-term outages due to key rollover problems; at the same time, such high-value zones are more likely to suffer embarrassment from a botched key rollover. By similar reasoning, a small site for which DNSSEC is at most a part-time occupation for one staff member might run great risk of outage during a key rollover, just because the testing and detection of DNS issues may not be as complete as at a larger site. Most sites will fall in a continuum between these extremes. Determining policy around key rollover -- whether to do it, how frequently if so, and whether regularly if so -- is a matter of operational policy that needs to be established for each site, taking into account the considerations above. Someone might be able to edit that into something less wordy and more useful. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
On Thu, Jan 21, 2010 at 01:57:49PM -0800, David Conrad wrote: > > First time a scheduled roll botches, any rational organization would > institute policies and processes to ensure that such a botch does > not reoccur. First time a scheduled roll botches with a new > outsourced contractor, any rational organization would institute > policies and processes to ensure that such a botch does not reoccur. You have worked in more enlightened organizations than I, then. In my experience, with a lot of this sort of outsourcing, what will happen is that the outsourcing company will produce an incident report detailing the many ways the overworked drone who didn't know what he was doing screwed up, why their JD Power or whatever surveys prove that this never happens to them, and the 40 meetings that will be held to ensure that even though this was in fact an impossible event, it will never happen again. In an organization that actually knows what it is doing technologically, I'm sure you're right. In an organization that doesn't actually care about running its systems because everyone there has something else they're really doing, DNSSEC will be handed out to someone else. The people in that organization will have _no clue_ how to evaluate the goodness or badness of the DNSSEC procedures of said contractors. Or maybe one person in the company will, but he will be doing the work of three people and won't have time to pay close attention to any of this. The DNS is _not important_ to most of the people who have to rely on it, any more than the details of my plumbing system are something I think about every time I wash my hands (and yes, I have replaced my own pipes). Asking people to roll their keys all the time is like telling them that they need to do annual maintenance checking the washers in all their sinks, to make sure that they're not having leaks. Good, sane practice; but they're not going to do it. They'll notice when a drip starts, and that day they'll call a plumber. > There is a reason people have "fire drills" on a periodic schedule. When we have fire drills, in my experience, we don't actually set off the alarms and run the sprinklers (or set the building on fire). We do it in a controlled, test way, with a mechanism to warn the fire department and so on. And actually, in many places, everyone knows when a fire drill is happening. We don't seem to have mechanisms for all this stuff everywhere in the DNS. Finally, there are places where fire drills practically never happen -- I've never once been in a movie theatre where a fire drill happened during a show, for instance. And for good reason: the risk of setting off a panic and hurting people is much greater than the risk that people won't know what to do in case of a real fire. I'm not trying to say, "Never roll your keys under any circumstances." I am arguing, however, that the advice in a document about how to manage your systems has to contain second-order advice about evaluating risk and reward, if we want that advice to be helpful. Rolling keys entails some risk, and if that risk is greater than the combination of the risk that the key is going to be compromised in the key lifetime and the risk reduction from key rolling practice, then the person deciding to do the key roll anyway is actually being irresponsible: they're taking greater risk than need be. Different environments entail different results for that risk evaluation, because the keys are not all of the same value. The keys for mytinycornerof.universe.example.com are just not as valuable as the keys for the root, and that means I have to make trade-offs that might be different than those for the root. Isn't that obvious? A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
On Thu, Jan 21, 2010 at 04:14:03PM -0500, Edward Lewis wrote: > > I'm finding this discussion enlightening and interesting. Me too. I also think that discussion of exactly this sort belongs in the advice we give to operators. Understanding the trade-offs and the reason for them is exactly what makes for selecting the right policies given the operational considerations of the environment in which one is working. I don't think there's one answer for this question, because what is right is surely related to other considerations. For instance, despite what David says downthread about operational realities and exercise, such exercise is a complete waste of time if the person who does the work is different every time (as might well be the case under a lot of outsourcing contracts). In that circumstance, Paul is probably right: the risk of blowing the key roll outweighs the benefits of practice. One also worries a little that many operations people (me included) so often think "you need to practice this" includes "in production". (But I haven't worked many places where I've had a real, true, complete copy of my production systems just for running fire drills.) A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
On Fri, Jan 22, 2010 at 05:25:29AM +0900, Masataka Ohta wrote: > Andrew Sullivan wrote: > > > I fully agree. I just want to make sure we're not holding ourselves > > to an operational standard that is just impossible to reach. If we > > want "proof" and "facts" about whether something won't ever be > > compromised, > > Remember that DNSSEC was developed because it was believed to make > DNS proven to be secure. You're equivocating on "proof" or "secure" or maybe both. DNSSEC allows you to prove that, assuming secure keys, you're getting the the correct (i.e. authoritatively-sourced) answer. It does not allow you to prove that the keys were handled properly, that Dr Evil hasn't taken over the authoritative machine, that we really are living in a Euclidean universe with the relevant mathematical structures, or that ChipManufactureCorp didn't have a serious bug that caused every cryptographic operation it ever does to be predictable. It also doesn't allow you to prove that Bishop Berkeley's metaphysics was wrong, such that you are in fact connecting to a computer somewhere out there in the world and not just a representation-of-foreign-computer in your consciousness. No other cryptographic proof can ever prove such things, either, since a cryptographic system invariably involves those nasty graphos, who are prone to making errors. Moreover, no existing system can prove that there is not an undiscovered vulnerability of an algorithm (though I understand there are proofs that, under known mathematical assumptions, some algorithms cannot be broken. That's not the same thing). If you wish otherwise, I think you are asking that Godel be proven wrong. If you dislike the word "prove" and cognates to be used for anything other than mathematical certainty, then I suggest you translate any use of "proof" that involves parts of the physical universe into some other term like "increased confidence in the empirico-statistical sense". A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
On Thu, Jan 21, 2010 at 12:12:50PM -0800, Eric Rescorla wrote: > On Thu, Jan 21, 2010 at 11:38 AM, Paul Hoffman wrote: > > is still much higher than the value of the broken key. Remember > > that a broken signing key is only valuable until the fact that it > > is broken is discovered and fixed. So, even if an attacker breaks > > your signing key, when he/she starts to use it for nefarious > > purposes and you discover that, you roll your key and the entire > > time of breaking the new key must be used again before they can > > mount another attack. > > Exactly. So rolling it preemptively doesn't help much. What about the argument that you might not discover the nefarious use (because a small number of DNS transactions, carefully selected, are the only misdirected ones, and everything else appears normal, so you chalk it up to user error)? Remember that unlike many cryptographic protocols, there's no real end-to-end communication here. It could well be hard for a key owner to detect the compromise in a DNS context than in many other contexts. If one accepts that argument (I don't know I do, but let's accept it for the sake of argument), then rolling regularly (modulo jitter) could be argued for on the grounds that it will cut off even undetected compromises. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
On Thu, Jan 21, 2010 at 08:55:33AM -0800, Paul Hoffman wrote: > > But we *can* assume that there are a lot of 1024-bit keys in use > that are much more valuable than the most valuable DNSSEC 1024-bit > key. Thus, as public analysis gets better, we are likely to hear > about it. Even if the first attacks from private crackers, we will > hear about them. I fully agree. I just want to make sure we're not holding ourselves to an operational standard that is just impossible to reach. If we want "proof" and "facts" about whether something won't ever be compromised, it's not going to happen (so I'm very keen we not put anything resembling such language in any draft). That's all I was saying. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
On Thu, Jan 21, 2010 at 04:28:14PM +, Tony Finch wrote: > Operational routines like this will be automated. I wish I believed that was universally true. It isn't. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
On Thu, Jan 21, 2010 at 11:14:25AM -0500, Edward Lewis wrote: > At 11:02 -0500 1/21/10, Andrew Sullivan wrote: >> Sure, but this may well be the exception and not the rule. > > And I've heard the opposite. "automated-registry[0]"-run zones are in > the minority. (I.e., second level domains, third-level domains, etc...) Sure. I think the problem here is that we don't know. I have no clue how many systems are updated exclusively by Dynamic Update vs. by someone opening the zonefile in vi. I don't think anyone else knows, either: the scope of DNS operations is far too widely dispersed for anyone to have done anything like a survey. Therefore, the best we can do is recomment the techniques appropriate to different circumstances. It seems to me that one such technique is, "If it's easier for you to transmit a new DS/DNSKEY than it is for you to roll a KSK, then you don't need a separate KSK. Just roll the one key and be done with it." A separate question, then, is whether the operational regularity that comes from exercising the above technique all the time outweighs the risks associated with frequent key rolls that result from getting the timing wrong. (My personal opinion is a cautious "yes", but I don't know how firmly I hold that view.) A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
On Thu, Jan 21, 2010 at 10:48:52AM -0500, Edward Lewis wrote: > At 10:39 -0500 1/21/10, Andrew Sullivan wrote: >> >> Maybe this is the problem? > > Problem? It that it seems to be the occasion of a lot of disagreement with the document. That is, in many cases, perhaps the advice should simply be, "The ZSK/KSK split is useful in some circumstances, but for most applications one key is sufficient." Or some such. I'm not proposing this text, I'm asking. > Not everyone has an automated registration interface (making that a > reason to have a KSK/ZSK still hold). Sure, but this may well be the exception and not the rule. > And the key word above is "assumptions" - once we know for a fact that a > ZSK of 1024 bits is good for a year no matter how much it is used and Nobody can ever know that for a fact, because it would require proving impossible that such a key could be cracked. Predictions of future impossibility are hard to prove. This is a question of trade-off, not facts, and one of the questions is the degree to which two keys themselves introduce risks that aren't offset by the gains they might produce. I simply don't know the answer, but it seems to me that EKR is asking the right question. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
On Thu, Jan 21, 2010 at 10:14:41AM -0500, Edward Lewis wrote: > So many assumptions have changed...but the idea of KSK/ZSK hasn't. Maybe this is the problem? A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] on what glue is (was: signing glue and additional data)
On Sat, Jan 16, 2010 at 02:54:52PM -, George Barwood wrote: > Ok, you can argue over the definition of what a glue record is. Indeed, there was an I-D floating about that offered to do exactly that. It's expired, though: http://tools.ietf.org/html/draft-koch-dns-glue-clarifications-03 Perhaps someone should take that up? A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-yao-dnsop-idntld-implementation-01.txt
On Sat, Nov 07, 2009 at 08:10:02PM +0800, James Seng wrote: > "There is a genuine user problem here (though whether one should actually > solve it is still an open question)." > > It is a genuine user problem but I disagree with your latter statement. > > It is not an open question it must be solved. It is a serious enough problem > for Chinese that it must be resolve for the Chinese user. The open question > is "how", not "if". I understand that it is a serious problem. But one solution is in fact to solve this exactly the way we actually solved spelling differences in English words: they're different zones, and we treat them that way technically and use some non-technical policy rules to solve the problem. On this interpretation, the danger lies in acting as though there is a mere technical solution for "variants". Delegation (the "NS" solution) just creates a new delegation, nothing more; and we ought to be perfectly clear about that. DNAME doesn't actually mirror an entire tree, so it doesn't actually solve the variant problem for real. Therefore, if we want a complete solution to the problem of variants, we need a new element in the DNS protocol. It may require server side processing, it may not work perfectly anyway, and it may be subject to nasty subversions. So, there is a clear benefit because there is a serious problem. But not all serious problems must be solved, because the solution can be worse than the problem. I don't _think_ the current example is a case where the solution is worse than the problem; but I also don't believe we have completely understood what exactly the problem is, whether there is an actual technical problem here, and whether if there be a technical problem we can invent or reuse any mechanism to solve it. The proposals so far are, in my view, either completely wrong or just mostly wrong. (That includes using DNAME, by the way.) A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-yao-dnsop-idntld-implementation-01.txt
Dear colleagues, I have read the document draft-yao-dnsop-idntld-implementation-01.txt. I note that there is an agenda item on the DNSOP WG agenda to consider this draft. I am strongly opposed to the draft, and wish to express my opposition to it being adopted by the WG. In my opinion, the draft places altogether too much confidence in the notion that data consistency can in any way be enforced across two completely different delegations. If we are to take at all the idea of variants seriously, then what we must suppose is that any name must be _functionally the same_ as all the other variants of that name. The only mechanism we have in the DNS that approaches that functionality is DNAME. DNAME is far from ideal: it does not actually mirror the root of the tree, and there are other nasty issues (MX is an obvious one). The authors are correct that a DNAME deployment could indeed lead DNS operators lower in the tree to do broken things. But neither of those issues holds a candle to the mistaken notion that two actually different delegations may be relied upon to be the same. If we encourage NS delegation from the root into different zones that are supposed to be the same, then in the absence of complicated, as-yet-unwritten tools to enforce the lock step consistency of those different delegations (and to check them all the time), the chances of the different zones actually being the same all the time approaches zero. Since the principle of a variant is that it just be another spelling for the name (as though we granted colour.com automatically to the registrant color.com), any difference in the answer you get from the servers for one and the servers for another is by definition a problem. I appreciate the problems the authors are trying to solve, and I understand why they are taking this path; but it is still the wrong path, and I believe it to be a greater threatl to the stability of the DNS than the introduction of DNAMEs near the top. Best regards, Andrew -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new draft about idn tld variants implementation
ut we rely on the protocol community not to do that. So if your argument depends on that premise, you have to show that the entire protocol community will take leave of its senses. (Now, some would argue that we have ample proof of such leave-taking; but that's an argument you need to make.) > my suggestion is that apply the NS in the root and apply the DNAME > in the second level. By "DNAME in the second level", I understood you to be suggesting that the root delegates variants by NS records, and then TLDs and below uses DNAME to support variants. But maybe you mean something else: the root delegates the variants via NS records, but on the child side at the apex all the variants but one are DNAMEs. If this is what you mean, then actually I don't think there's any difference in these approaches, provided that the parent enforces that the target of the variant NS has exactly the SOA and the DNAME at the apex. I wouldn't oppose a document that said that (although I think it would be tedious to support this arrangement). Best regards, A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new draft about idn tld variants implementation
in the TLD space, where nearly everything is delegation. In fact, this issue, which might cause trouble for DNAMEs being used for variants at other levels of the tree, actually makes DNAMEs well-suited to the top level. Moreover, it is possible to work around this stricture with DNAMEs at lower levels, because DNAME does not prohibit other non-redirecting records at the zone apex where a DNAME lives. I reason, therefore, that while there might be issues with using DNAME to support variants at the DNS root, the draft before us does not make an effective argument for that position. Now, let us consider whether supporting variants with alternative delegations (the NS strategy) in fact achieves the goal that variants are supposed to achieve -- that is, to make two completely equivalent name spaces. The answer is, "No." For as the draft points out, by adding another NS record, one creates a completely different delegation. There is nothing whatever about an NS delegation of $name that links it in any way to an NS delegation of $variantname. Once the delegation is in place, there is no way for the parent to be sure that everything under $name and $variantname are the same. Indeed, a strategy of using different delegations for the variants would not actually be creating variants at all: it would be creating new TLDs, period. For large TLDs, it would in fact be impractical to ascertain whether everything under the two delegations all matched. And since the underlying zones would have to be maintained separately (or else generated from some proprietary database not specified anywhere we are considering), there is every reason to believe that the different zones _would_ diverge, and that the goal of creating just another name for the same zone would be foiled. Therefore, it is my view that the draft provides all the premises needed to support the opposite of one of its important conclusions: for the purposes of adding variants to the DNS root zone, the right way to proceed is to use DNAMEs. There may be a practical issue with using DNAMEs at levels underneath the top level; I haven't thought about that case enough to decide whether the issue is insuperable. Certainly, all of the phishing issues that the draft is apparently worried about avoiding are in fact made worse by NS-style delegation than by the use of DNAME. Best regards, Andrew -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-iab-idn-encoding-00
On Tue, Oct 13, 2009 at 01:11:19AM +0200, Alfred Hönes wrote: > for Internationalized Domain Names", draft-iab-idn-encoding-00, > I got the impression that the DNS related text in this IAB draft > might deserve detailed review from DNS experts -- both on dnsop > and namedroppers, but I have not found any discussion on that memo. It certainly can use review. I am informed by someone who ought to know that -01 is near to release, so if you haven't looked at -00 and want to comment (and I urge you to do so), I counsel waiting until -01 is out. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft on rDNS for IPv6: draft-howard-isp-ip6rdns-00
No hat of any kind. Not even my boater, which I will soon be sad to put away again. On Thu, Sep 03, 2009 at 12:11:29PM +1000, Mark Andrews wrote: > People don't move house very often. Speak for yourself! But anyway, I think we have clearly crossed the Rubicon of folly if we think that the IETF's beliefs about what is "sensible", "reasonable", "sane", or even "fiscally responsible" will have one iota of effect on what ISPs actually do. This is reputedly an _operations_ working group. If we seriously propose to try to tell the community of operators that they oughta do $X if they know what's good for them, I suggest that participants here need to spend some more time reading the lists of NANOG and friends. I claim that we need to provide support for the network that people are actually building. That often includes things that we would not do ourselves, and that we think would be better done otherwise. But I also claim that if we say, "You shouldn't do $CHEAPTHING, you should do $OTHERTHING," we're going to lose. We've lost every single time on this. Why is now different? And if it's not, shouldn't we learn? A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] measuring TCP query performance
No hat. On Wed, Aug 26, 2009 at 04:11:26AM +, Paul Vixie wrote: > since time is short, i would prefer a server-side change, supported by a > spec change (which means this would head back to namedroppers@) whereby > (bufsize<1220 && DO=1) would be treated as (DO=0). Of course, some have argued that this isn't a protocol change anyway. That said, > TCP just because they're probing middlebox PMTU and blinding trying 512. perhaps part of the problem involves "blindly trying". Olafur posted a message from the DNSEXT Chairs today that suggests we (the DNS community) need to unpack that assumption, at least. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Question about detecting generated local-zones (relates todraft-ietf-dnsop-default-local-zones-08)
As usual when posting to this list, I am wearing no hat. On Wed, Jul 29, 2009 at 01:59:08PM +1000, Mark Andrews wrote: > Having a local copy of the root zone is a much better > way to deal with queries to the root. Is that really the advice we are giving people these days? It strikes me that in other contexts, a similar suggestion has been derided as foolhardy, dangerous, and susceptible to evil behaviour by ISPs and others. Confused, A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] query regarding DNS Cache in resolver.
On Mon, Jul 27, 2009 at 10:37:47AM -0400, Olafur Gudmundsson wrote: > DNSSEC aware caches the cache should remember the setting of the > DO bit in the answer. Did you mean the AD bit? In any case, I assume what you're trying to capture is that you need to know whether the cache may possibly have the RRSIG in the cache too, so that you don't accidentally get an RRSIG that does not in fact cover the RRSet in your cache when using that cached RRSet (were you to do that). Right? A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Stockholm meeting slot assignment CHANGED
On Tue, Jul 21, 2009 at 02:37:09PM -0400, John Schnizlein wrote: > Now, what about this other draft that seems to call for recursive > resolvers to know about address translation? > http://www.ietf.org/id/draft-vogt-durand-virtual-ip6-connectivity-01.txt Clearly, it needs review ;-) Note that it's not a BEHAVE WG item yet. Unfortunately, its time slot conflicts with the DNSOP meeting. Remember, anyway, work is supposed to be undertaken on the mailing lists, so if we have an issue with a draft in some WG, we likely ought to be taking our concerns to that WG's list and raising them. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Stockholm meeting slot assignment CHANGED
On Thu, Jul 09, 2009 at 02:11:45AM +0200, Peter Koch wrote: > On Wed, Jul 08, 2009 at 09:34:58AM +0200, Matthijs Mekking wrote: > > > According to the behave ML, they are planning to cover that DNS topic > > indeed on the monday: > > thanks for pointing this out, it's indeed an important overlap. We're > coordinating with the behave chairs to get this resolved, which might > result in another re-scheduling. Please stay tuned ... FWIW, I think this has been sorted out; DNS64 has been moved to the first item in the Tuesday BEHAVE session. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
