Re: [DNSOP] draft-mglt-dnsop-search-list-processing-00.txt
On Mon, Apr 14, 2014 at 09:41:10PM +0200, Daniel Migault mglt.i...@gmail.com wrote a message of 63 lines which said: Please find draft-mglt-dnsop-search-list-processing-00.txt [1] a single label that is 63 characters or less, starts with a letter, ends with a letter or digit, and has as interior characters only letters, digits, and hyphen as defined by [RFC1035]. Why this restriction, which is *not* in RFC 1035. _tcp is not a single label? In addition, fall backs resolution between these two categories will happen and MUST be address by administrator before any new gTLD. It seems to be a policy decision and not suitable for a RFC. For Unqualified Domain Names, the resolver MUST proceed to the resolution using search list. If the resolution fails, returning a NXDOMAIN, no attempt SHOULD be done to resolve it as an Qualified Domain Name. The second sentence is a protocol change and should not be done lightly. Frankly, I see no reason to forbid single-label domain names to work. (Whatever ICANN may say.) This section provides a small command line that tests which TLD has an A or a RRset. May be a mention of RFC 7085 here? It has a similar script and similar results. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-mglt-dnsop-search-list-processing-00.txt
In message 20140507103639.ga28...@nic.fr, Stephane Bortzmeyer writes: On Mon, Apr 14, 2014 at 09:41:10PM +0200, Daniel Migault mglt.i...@gmail.com wrote a message of 63 lines which said: Please find draft-mglt-dnsop-search-list-processing-00.txt [1] a single label that is 63 characters or less, starts with a letter, ends with a letter or digit, and has as interior characters only letters, digits, and hyphen as defined by [RFC1035]. Why this restriction, which is *not* in RFC 1035. _tcp is not a single label? In addition, fall backs resolution between these two categories will happen and MUST be address by administrator before any new gTLD. It seems to be a policy decision and not suitable for a RFC. For Unqualified Domain Names, the resolver MUST proceed to the resolution using search list. If the resolution fails, returning a NXDOMAIN, no attempt SHOULD be done to resolve it as an Qualified Domain Name. The second sentence is a protocol change and should not be done lightly. Frankly, I see no reason to forbid single-label domain names to work. (Whatever ICANN may say.) It's not forbidding single label domain names. It's forbidding searches crossing administrative boundaries. Has anything really changed since RFC 1535 was published to make that *safe*? Have 'COM' or '.' in the search list was bad when RFC 1535 was published. Nothing has made having either of them in a search list any better since. With the opening up of '.' to more players has made it worse. This section provides a small command line that tests which TLD has an A or a RRset. May be a mention of RFC 7085 here? It has a similar script and similar results. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-mglt-dnsop-search-list-processing-00.txt
On Wed, May 07, 2014 at 10:32:46PM +1000, Mark Andrews ma...@isc.org wrote a message of 52 lines which said: It's not forbidding single label domain names. It does and it is explicit about it: These rules do not make possible the resolution of TLD as Single- Label Domain Name. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] vomity or not, *is* that the question?:Re: call to work on edns-client-subnet
On May 6, 2014, at 21:44, Jiankang Yao ya...@cnnic.cn wrote: One view about this issue based on the previous discussion years ago is that the dns implementors may choose to tailor the dns response in their own way, but ietf is unlikely to standardize it. At the risk of repeating an unpopular opinion, what’s the purpose of the standards? Is it to record the way in which the Internet is working (code before words) or to mandate a particular way of operating (words before code)? In recent years I’ve seen much more talk on DNS (industry) operations in DNS-OARC than inside the IETF. One can ask - what makes something worthy of standards track (as opposed to informational)? Depending on that criteria, the likelihood of the IETF standardizing client-subnet can be debated, but I have never seen such criteria. And not seeing it might be because I haven’t looked hard enough. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] vomity or not, *is* that the question?:Re: call to work on edns-client-subnet
On Wed, May 07, 2014 at 10:04:13AM -0400, Edward Lewis edlewis.subscri...@cox.net wrote a message of 105 lines which said: to record the way in which the Internet is working This is not standards, it is journalism :-) If I were to document the way the Internet is really working, the RFC would be full of do not forget to insert bugs here, please do not document and throw a dice before making a choice. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] vomity or not, *is* that the question?:Re: call to work on edns-client-subnet
On May 7, 2014, at 10:11, Stephane Bortzmeyer bortzme...@nic.fr wrote: This is not standards, it is journalism :-) If I were to document the way the Internet is really working, the RFC would be full of do not forget to insert bugs here, please do not document and throw a dice before making a choice. I have ask for clarity: What do you consider “best current practices”? …and...What do you call a situation in which major players in the industry want to interoperate but do not want to illegally collude? Bugs and unintended consequences aside, what would you call documenting a business arrangement that anyone can be party to if they desire? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] vomity or not, *is* that the question?
On 7 May 2014, at 15:11, Stephane Bortzmeyer bortzme...@nic.fr wrote: If I were to document the way the Internet is really working, the RFC would be full of do not forget to insert bugs here, please do not document and throw a dice before making a choice. Surely the experience of getting DNSSEC out the door showed that quite a few earlier DNS RFCs had those attributes even if they weren't explicitly labelled as such? :-) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call to work on edns-client-subnet
On Tue, 6 May 2014, Doug Barton wrote: So NAT is an interesting case, since there's no doubt that the IETF dropped the ball on that. But the problem there was not that the IETF chose not to act in order to not support NAT, the problem there was that the collective decision process failed by determining that NAT was a bad idea. The collective decision had the right outcome. NAT is bad - don't do it. It is however just like climate chance - those doing it don't care about the fall out and aren't forced the pay the price of the problems they cause. The sheer amount of protocol workaround for not having a peer-to-peer internet anymore is a huge cost that everyone collectively bears just because a few players wanted a cheaper internet method that has caused great pollution. The remedy to that error is not to swing the pendulum all the way in the other direction, and support every idea no matter how bad. The answer is to make better decisions. The problem is not the IETF. The problem is capitalism making decisions. Look at the IPv4 to IPv6 transition. I don't think the IETF made a bad choice. They gave everyone over a decade to work things out. Capitalism doesn't care. IPv6 was too expensive until it was a requirement. That's also why NATs came into existence. As for DNS, I do like that people can use random DNS resolvers out on the internet (and hopefully securely and privately soon as well). The edns-subnet option is a decent compromise in revealing rough locations for a large geographic region. I am still a little fearful of abuse, but that same abuse would happen if I queried using my own validating DNS resolver on my mobile device, except they would use the exposed IP address directly. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call to work on edns-client-subnet
On 6 May 2014, at 22:34, Doug Barton do...@dougbarton.us wrote: You could say that I'm arguing 'ad absurdum' here, but I'm not. There really are such things as bad ideas, and it's perfectly reasonable for the IETF to decide that something is a bad idea, and shouldn't be done. Or at least, shouldn't be made easier to do. Consider the two possible outcomes: (a) use of edns-client-subnet effectively involves a large depth of undocumented experience and knowledge about specific implementations and where those specific implementations are used. Use of the option is constrained to applications supported by big money or big government, since no individual (e.g. unfunded, open source) implementer can realistically hope to understand such a moving target with accuracy. The extent to which end-user privacy is affected in the big picture is difficult to characterise since the landscape is so fluid. (b) use of edns-client-subnet is documented, oddities that come up following implementation are rolled into the documentation, and we have a stable resource that exactly describes how the option works against which interop testing has half a chance of bearing fruit, and using which privacy implications can be easily understood. I think (b) is preferable to (a). (And again, see NAT.) So NAT is an interesting case, since there's no doubt that the IETF dropped the ball on that. But the problem there was not that the IETF chose not to act in order to not support NAT, the problem there was that the collective decision process failed by determining that NAT was a bad idea. NAT *is* a bad idea. And the amount of global effort required to work around the differences in every implementation is absurd, now that it has become a de-facto implementation standard in IPv4 networking. The remedy to that error is not to swing the pendulum all the way in the other direction, and support every idea no matter how bad. The answer is to make better decisions. The IETF has documented lots of protocols that nobody uses. Those are, by reasonable measure of uptake, bad protocols. The IETF is not the packet police. De-centralisation of innovation is what led to the phone network becoming an Internet application, rather than the other way round. The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call to work on edns-client-subnet
On Wed, May 07, 2014 at 12:36:18PM -0400, Joe Abley wrote: (a) use of edns-client-subnet effectively involves a large depth of undocumented experience and knowledge about specific implementations and where those specific implementations are used. NAT *is* a bad idea. And the amount of global effort required to work around the differences in every implementation is absurd, now that it has become a de-facto implementation standard in IPv4 networking. Indeed, just to emphasise what Joe is saying, there were so many different ways to do NAT things that once the IETF finally decided that it needed to cope with the actual deployed Internet, we had to have a whole WG (BEHAVE) to figure out how everything worked, and write that down. Understanding the DNS is already hard enough without making even more of it a mysterious arcane topic that you can only learn about by hanging out on secret-handshake mail lists. Moreover, we edns0-client-subnet has a code point in the EDNS0 OPT registry. Doug's argument seems to be, Let's have that code point and let it be mysterious. I think that would be a perverse outcome. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call to work on edns-client-subnet
I think if we want good engineering then we should recommend on host or on net validating resolvers. I think if we want interoperability then we have to standardize anything anybody is doing. If ietf documents client-subnet then it should be an FYI. That's hardly a death sentence... Look what happened with SRV. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call to work on edns-client-subnet
On Wed, May 07, 2014 at 07:06:34PM +0200, P Vixie wrote: If ietf documents client-subnet then it should be an FYI. Can't do that. https://tools.ietf.org/html/rfc6360, Conclusion of FYI RFC Sub-Series. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call to work on edns-client-subnet
Ouch. Well so if a large body of ietf participators think wide area rdns is a bad idea and that this option should never be recommended then we would presumably have to say so in the document which standardized the option. Strange. On May 7, 2014 7:09:26 PM CEST, Andrew Sullivan a...@anvilwalrusden.com wrote: On Wed, May 07, 2014 at 07:06:34PM +0200, P Vixie wrote: If ietf documents client-subnet then it should be an FYI. Can't do that. https://tools.ietf.org/html/rfc6360, Conclusion of FYI RFC Sub-Series. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call to work on edns-client-subnet
This sounds to me like a) support for working on edns-client-subnet (and possibly things like it in the future), with b) a resulting RFC as Informational. I've found this discussion very helpful in solidifying the thoughts Tim already wrote about, particularly with regards to carrying out our new charter. Thank you all. best, Suzanne On May 7, 2014, at 1:06 PM, P Vixie p...@redbarn.org wrote: I think if we want good engineering then we should recommend on host or on net validating resolvers. I think if we want interoperability then we have to standardize anything anybody is doing. If ietf documents client-subnet then it should be an FYI. That's hardly a death sentence... Look what happened with SRV. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ 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] call to work on edns-client-subnet
On 7 May 2014, at 13:12, P Vixie p...@redbarn.org wrote: Ouch. Well so if a large body of ietf participators think wide area rdns is a bad idea and that this option should never be recommended then we would presumably have to say so in the document which standardized the option. Strange. I think documenting a bad idea and including text that describes why it is bad is better than ignoring it. I'm not saying that I think edns-client-subnet is necessarily bad; I'm observing that others here believe it is. Even if we all thought it was definitively bad, given that it has been implemented I am still strongly in favour of documenting it. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call to work on edns-client-subnet
Joe... To clarify... Client subnet is not what I an complaining about. It's wide area rdns itself that I think is a bad idea. One reason wide area rdns is a bad idea is that it needs client subnet options. Centralized rdns is not necessary and it makes the internet brittle. Better alternatives exist. The architecture of DNS assumes localized rdns. If we're going to document client subnet then all that advice will have to go into it. On May 7, 2014 7:15:04 PM CEST, Joe Abley jab...@hopcount.ca wrote: On 7 May 2014, at 13:12, P Vixie p...@redbarn.org wrote: Ouch. Well so if a large body of ietf participators think wide area rdns is a bad idea and that this option should never be recommended then we would presumably have to say so in the document which standardized the option. Strange. I think documenting a bad idea and including text that describes why it is bad is better than ignoring it. I'm not saying that I think edns-client-subnet is necessarily bad; I'm observing that others here believe it is. Even if we all thought it was definitively bad, given that it has been implemented I am still strongly in favour of documenting it. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call to work on edns-client-subnet
On Wed, May 07, 2014 at 07:12:21PM +0200, P Vixie wrote: Ouch. Well so if a large body of ietf participators think wide area rdns is a bad idea and that this option should never be recommended then we would presumably have to say so in the document which standardized the option. Strange. No, Informational status is still available. There's nothing wrong with that. Also, however, it seems to me that even if this went up on the Standards track, one wouldn't have to say whether it was a good idea. But you _could_ write a separate doc (and try to get it published or else publish it on the Independent stream) that said, Wide Area Recursive DNS Considered Harmful. I think that's a separate question from, How to deliver topological information from a recursive server to an authoritative? A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call to work on edns-client-subnet
On May 7, 2014, at 10:23 AM, P Vixie p...@redbarn.org wrote: Joe... To clarify... Client subnet is not what I an complaining about. It's wide area rdns itself that I think is a bad idea. One reason wide area rdns is a bad idea is that it needs client subnet options. Centralized rdns is not necessary and it makes the internet brittle. Better alternatives exist. The architecture of DNS assumes localized rdns. If we're going to document client subnet then all that advice will have to go into it. Not necessarily. centralized is often really anycast. E.g. if you look at Comcast there are multiple anycast responders in their own internal network for 75.75.75.75. Likewise, '8.8.8.8' is insanely anycasted. This is not brittle, but remarkably robust. In this case, still, edns client subnet is very useful. It is, frankly, a mess to map client subnet to recursive resolver, but it is an insanely powerful optimization when you can. edns_client_subnet makes this mapping trivial, and therefore acts to significantly improve end user performance. -- Nicholas Weaver it is a tale, told by an idiot, nwea...@icsi.berkeley.edufull of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call to work on edns-client-subnet
Dear Uncle Ben, On Wed, May 07, 2014 at 07:26:51PM +0200, P Vixie wrote: The architectural context of a feature should not be divorced from its specification. RFC is an imprimatur. With great power comes great responsibility. I disagree with this point of view. I see nothing at all wrong with one thing that states clearly and precisely how a feature works, and another one that says, Here is the wider environment in which such-and-thus thing works. Even the DNS protocol itself has this separation of duties, between 1034 and 1035 (though heaven knows the actual protocol specification could use some attention). If this were not the case, then in fact we'd have had to discuss the entire architectural context of any DNS feature. It only seems like the DNS RFCs are infinitely long. Best, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call to work on edns-client-subnet
On May 7, 2014, at 12:23 PM, P Vixie p...@redbarn.org wrote: Centralized rdns is not necessary and it makes the internet brittle. Better alternatives exist. The architecture of DNS assumes localized rdns. If we're going to document client subnet then all that advice will have to go into it. While I am sure many readers will sympathize with your point about centralized rdns, it's worth noting that it's equally true that relying on topology to determine the answer that the resolver gives to certain queries is also brittle. The architectural assumption you are claiming is not actually an architectural assumption in the DNS protocol, but rather an assumption commonly made by a particular (admittedly fairly important) set of publishers of DNS data, because it is convenient to do so. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call to work on edns-client-subnet
Andrew Sullivan wrote: Dear Uncle Ben, keep it civil, please. On Wed, May 07, 2014 at 07:26:51PM +0200, P Vixie wrote: The architectural context of a feature should not be divorced from its specification. RFC is an imprimatur. With great power comes great responsibility. I disagree with this point of view. I see nothing at all wrong with one thing that states clearly and precisely how a feature works, and another one that says, Here is the wider environment in which such-and-thus thing works. let me show you something wrong with that, then. http://www.cisco.com/c/en/us/products/collateral/wireless/5700-series-wireless-lan-controllers/data_sheet_c78-722607.html an rfc is seen by sellers and buyers as an unalloyed good. we can (and i do) criticize uneducated people making appeals to authority, but that's a far cry from pretending it won't happen or that any undesirable result from its happening is not the responsibility of those who write and edit and approve RFC documents. the current thrust is to move from ietf should do good engineering to ietf should document anything that has to be interoperable, and in that move we have to plan on being quite detailed in our applicability statement sections. my draft for that section of a client subnet option goes more or less like this: APPLICABILITY STATEMENT The method described in this document is controversial, as is the use of wide area anycasting for Full Service Resolvers (recursive DNS servers). The Domain Name System as originally contemplated and implemented made the assumption that a Full Service Resolver would either share a host with, or a LAN with, or a campus with its end-user stub resolvers. In that scenario, the need for something like the client subnet option does not arise. Since at the time of this writing, personal electronics are far more complex and resource intense than a Full Service Resolver, even when including DNSSEC validation and DNS firewall policy. The purpose of this document is to describe the client subnet option so that cooperating systems can interoperate. No recommendation is expressed or should be implied as to whether this method should be used, or that its antecedent, wide area anycasted Full Service Resolvers (recursive DNS servers) should be used. if i thought i could get consensus on an addition, i'd add: The client subnet option is only useful when other earlier assumptions about Internet architecture are violated. Specifically, it's when a market driven CDN (content delivery system) desires to tune DNS authority responses to control end-user web performance, is reached by an end user who uses a market driven anycast recursive DNS service. Neither the described authority DNS tuning nor the described anycasted recursive DNS service are Internet architecture requirements, or even recommendations. A web site without a CDN front end will still work, as will a CDN who has no insight into each requestor's actual address at the time it receives an authority DNS request. End users who use local recursive name servers will receive faster service per query due to the reduced round trip time (one millisecond instead of a dozen or more milliseconds) and will be less affected by cloud outages. Design by market force can lead to unnecessary features and not always to good engineering. obviously i'm miffed that Stupid DNS Tricks ultimately demands more complexity for the DNS, and so on. Even the DNS protocol itself has this separation of duties, between 1034 and 1035 (though heaven knows the actual protocol specification could use some attention). that's a terrible example since neither one of them talks about the limited applicability of the other. If this were not the case, then in fact we'd have had to discuss the entire architectural context of any DNS feature. It only seems like the DNS RFCs are infinitely long. that's a terrible example since any internet draft describing a controversial technique either failed or got an applicability statement. if you think there are cases where RFC 2136 should not be used, over and above the IAB-demanded statement about authentication, speak on. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] remarks on draft-vandergaast-edns-client-subnet-02
Dear colleagues, On the principle that I should work on something instead of talking about it, I had a look at draft-vandergaast-edns-client-subnet-02. I have a couple questions and remarks. First, I'm a little uncomfortable with optimized reply as the name for this. It seems to me that one could be getting this special authoritative reply for lots of reasons, though optimization is the usual one. I'd suggest a more neutral term; perhaps origin-tailored reply or something. The point is that the response you got is somehow scoped to some query originators and not others, and the document needn't take a position on whether that's good or bad. (This remark was mostly inspired by all the talk of sub-optimal later in the draft. As we know, some of these optimized cases are themselves sub-optimal. All the sub-optimal talk needs to be adjusted too.) Section 5.3 says In the cache, any resource record in the answer section will be tied to the network specified by the FAMILY, ADDRESS and SCOPE NETMASK fields, as detailed below. Note that the additional and authority sections from a DNS response message are specifically excluded here. Now, imagine I'm querying for the NS for an in-baliwick DNS server, and I get back the answer, and it is somehow an optimized reply (as defined in the draft). (Note that I am not arguing this _should_ be something the authoritative server does, but it's implied as possible by the draft, so we better understand it.) In this case, the glue records that I get will in fact be optimized too. One is not allowed to cache them discriminately on the basis of client-subnet, however. I _think_ this is ok, because the right answer for the cache is to use additional section data for that query only, and throw it away, querying next time for the A and records if need be. Is that right? I'm pretty sure STRONGLY RECOMMENDED isn't an RFC 2119 term! (See section 5.3.) Also in 5.3, Replies coming from servers not supporting edns-client-subnet or otherwise not containing an edns-client-subnet option SHOULD be considered as containing a SCOPE NETMASK of 0 (e.g., cache the result for 0.0.0.0/0 or ::/0) for all the supported families. I think the or in the parenthetical is properly and. No? Otherwise, this option implicitly divides all operations into v4-operations and v6-operations. If so, it needs to be made explicit somewhere. I'm concerned about the consistency between section 5.4 and this text in 5.1: The Stub Resolver may also add non-empty edns- client-subnet options to its queries, but Recursive Resolvers are not required to accept/use this information. In general, there is no way for a resolver to tell whether the request it just received is from a stub or from some other sort of resolver. So I don't see how that not required part and the restrictions in section 5.4 can all be true at the same time. Also, at the end of 5.4, there is, Note again that an edns-client-subnet option with 0 address bits MUST NOT be refused. Surely that needs some scoping, like MUST NOT be refused on the grounds of edns-client-subnet matching or something. There are lots of reasons to REFUSE a query (like, for instance, the originating IP isn't allowed to query via you). Why is there no advice in section 9.1 for IPv6? Pick a number. /56 perhaps. It seems that there is nascent practice anyway among ISPs, and the draft ought to pick one. I'm really very happy to see a description of what the experiment is and what the conditions are to determine whether things have been successful. Section 12 still says that the option code is tentative, but perhaps that ought to be altered to indicate that, if the experiment is successful it might continue in use. Also, since this document is nearly a year old and the code point happened some time ago, I'm wondering whether there are any updates to the experiment. Maybe it's already yielded some results? I still think this is a worthy draft, and I think it ought to go ahead. It does alter the DNS protocol, so DNSOP is not the WG for it. I have included the DNSEXT mailing list, which is supposed to be where we discuss such changes, though I confess I have faint hope we'll actually do that. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call to work on edns-client-subnet
On May 7, 2014, at 1:13 PM, Suzanne Woolf suzworldw...@gmail.com wrote: This sounds to me like a) support for working on edns-client-subnet (and possibly things like it in the future), with b) a resulting RFC as Informational. I've found this discussion very helpful in solidifying the thoughts Tim already wrote about, particularly with regards to carrying out our new charter. Thank you all. best, Suzanne I support publication of this “stupid DNS trick” as an RFC .. of some sort, particularly given the breath of deployment. That said, I’ve seen some of the warts and am sympathetic to Paul’s aging architectural concerns and I think some review from the abundance of DNS experts here will likely serve it well :-) As for the publication track here, or any other [E]DNS extensions similar application, whether deemed unorthodox or unfashionable, I don’t think there should be blanket discretion and edict by the chairs, we have processes that say what can be published on Experimental, Informational, or Standards Track, IIRC… Then again, perhaps DNSOP is not the place to document deployed and operational DNS stuff and we should revive DNSEXT to discussed operationally deployed DNS stuff, particularly given the charter discussions as of late. Or, um.. -danny signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
