Re: [DNSOP] Extended CNAME (ENAME)
On 05/18/2014 07:58 AM, Patrik Fältström wrote: It might be worth actively pushing the CDN folks to go the SRV direction. Even if ENAME were a good idea, which is not clear to me, it's an idea that would require significant infrastructure changes, whereas SRV records appear to be functional now, with no DNS software changes. As I have stated several times I disagree with any statement that claim significant infrastructure changes. This usage is the reason I did define the URI resource record, so that one could get a redirect already in DNS instead of escaping to HTTP. example.com. IN URI 1 2 https://foo.hosting.bar/example.com/startpage/en; So can that be used instead of specifying something where the initial proposal casually mentions This would require a dnssec algorithm bump? Not saying this to move it from dnsop to any other list or group, but that line alone implies there's a significant protocol change. Jelte ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
It might be worth actively pushing the CDN folks to go the SRV direction. Even if ENAME were a good idea, which is not clear to me, it's an idea that would require significant infrastructure changes, whereas SRV records appear to be functional now, with no DNS software changes. As I understand it, this is proposing a large DNS change as an alternative to a modest HTTP change. Doesn't strike me as a great tradeoff. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-bortzmeyer-dnsop-dns-privacy (was: DNS privacy : now at least two drafts)
Folks, I believe consensus was that dnsop needs a problem statement about DNS privacy before we explore possible solutions. Stephane's draft-bortzmeyer-dnsop-dns-privacy seems like a very good start to this problem statement. Are there plans to discuss this draft at IETF90 in Toronto? I sent him some detailed comments out-of-band, but one question for the list: what do we call the parts of the DNS resolver hierarchy? draft-bortzmeyer-dnsop-dns-privacy-02 defines and uses the terms (1) stub resolver, (2) resolver and (3) name server and also (2.5) a forwarding DNS resolver/server that is beyond the first-hop recursive resolver/server but not authoritative. for the things that (1) initiates queries, (2) handle recursive resolution, (3) reply with authoritative responses. The short version is: I recommend against use of resolver without an adjective for (2). Prior RFCs do not have consensus about what to use (both recursive resolver and recursive name server appear). Personally I'd go with recursive resolver. Does the list have other recommendations? The tl;dr version is below: I looked over many (but certainly not all) existing RFCs, and there is some variation in terminology: RFC-1035 (the original DNS spec): (1) stub resolver (2) recursive server (3) no specific term (!)... it does talk about foreign name servers and masters and authoritative data, but not authoritative servers RFC-1996 (DNS notify): (1) (not used) (2) (not used) (3) authoritative server RFC-1999 (EDNS): none RFC-3833 (DNS threats) uses (1) stub resolver (2) recursive name server (3) authoritative name servers RFC-4033 and 4035 (DNSsec) use: (1) stub resolver (2) recursive name server (3) authoritative name servers RFC-4871 (DKIM): uses only (2) recursive name server RFC-5966 (DNS over TCP): (1) stub resolver (2) recursive server (or forwarder) (3) authoritative server RFC-6891 (ENDS(0)): (1) stub resolver (2) recursive resolver AND caching resolver (3) authoritative server Back to draft-bortzmeyer-dnsop-dns-privacy My recommendation for terms is: (1) stub resolver (2) recursive resolver (2.5) forwarding resolver OR maybe caching intermediate resolver (3) authoritative nameserver (or authoritative name-server) Based on these observations: - resolver without an adjective for (2) risks ambiguity - recursive resolver vs. recursive server for (2) seem to depend on if you're approaching the problem from the end-user or the providers point of view. The challenge is that (2) is both a client AND server, leading to inconsistency. Just a suggestion, -John Heidemann ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
On May 16, 2014, at 6:19 PM, Mark Delany f...@november.emu.st wrote:
On 17May14, Mark Andrews allegedly wrote:
domain ENAME domain {0|1} [type list of included / excluded types]
(0 == include, 1 == exclude)
As I recall, the HTTP/2.0 folks have been intermittently talking about
supporting SRV. Would encouraging that group on that front be easier
than inventing CNAME support at the apex?
Yes they have, and yes it would. However, they are not focused on SRV (nor URI)
at the current time.
--Paul Hoffman
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
In message 20140519161241.39243.qm...@joyce.lan, John Levine writes: It might be worth actively pushing the CDN folks to go the SRV direction. Even if ENAME were a good idea, which is not clear to me, it's an idea that would require significant infrastructure changes, whereas SRV records appear to be functional now, with no DNS software changes. As I understand it, this is proposing a large DNS change as an alternative to a modest HTTP change. Doesn't strike me as a great tradeoff. It's trading off a in nameserver redirection which works with wildcards to a in client redirection that doesn't work with wildcards. Everytime I have mentioned SRV records to HTTP folks they say it won't work as the extra lookup takes too long. R's, John ___ 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] Extended CNAME (ENAME)
Mark Andrews wrote: ... Everytime I have mentioned SRV records to HTTP folks they say it won't work as the extra lookup takes too long. this sounds strange to me. TTL=0 SRV RR's strike me as precisely what the CDN industry needs, since they can include an (or for back-compatibility, an A) RR in the same response as additional data. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
Ted Lemon wrote: It might be worth actively pushing the CDN folks to go the SRV direction. Not so much pushing required, at least of Akamai. You have a ready-made ally in me, if only clients actually made good use of it. The clients are the real obstacle. Looking at a random high-traffic DNS server on our network, I see practically no use at all of _http._tcp SRV requests. Over 6 days of logs on this machine, they are just over 0.7% of all requests. (Yes, that decimal point is right.) Exactly 90% of them are for the same hostname, with a name that implies to me that one application, not a web browser, is responsible for all of them. On another server that provides a separate set of zones, HTTP SRV requests are a mere 0.01% of all requests, for only 3 distinct names among tens of thousands web server names. I appreciate what Mark is proposing, but personally I'd sooner see us using SRV than yet another new alias type if only it would get traction. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
On May 19, 2014, at 5:11 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: Yes they have, and yes it would. However, they are not focused on SRV (nor URI) at the current time. What _are_ they focused on? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
I too think the SRV route is far better. I've always thought it was an architectural mistake to be looking up hostnames when what you wanted was a service. SRV records have priority, weighting, and the ability to specify a port, all of which are useful. Since the owner name for a service whose URL would be at a zone origin is *not* at the zone origin, ordinary CNAME is still possible if you want to have the SRV in the control of the CDN. ENAME does not have a good transition mechanism for DNSSEC. If you do not know the new algorithm(s), you will not be able to validate, and a zone signed with an earlier algorithm will not work either as the synthesized CNAME will not validate. ENAME can thus not be used with DNSSEC until there is sufficient adoption of the new algorithms by the installed base of resolvers. Anything which requires DNSSEC validator changes is a transition disaster that will become totally untenable if DNSSEC is ever widely deployed (in the millions of zones signed sense). That level of deployment has not yet occurred, but nevertheless I think that DNSSEC validation process changes should be held to the very strictest standards and only be contemplated for dire problems. This is *not* a dire problem! I think we should encourage the use of SRV in HTTP 2.0. We can also recommend that if people are contemplating ever needing to use a CDN, then they shouldn't publish URLs with names at zone cuts. /Bob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
In message cf9fdbdd.117d1%bob.hal...@nominum.com, Bob Halley writes: I too think the SRV route is far better. I've always thought it was an architectural mistake to be looking up hostnames when what you wanted was a service. SRV records have priority, weighting, and the ability to specify a port, all of which are useful. Since the owner name for a service whose URL would be at a zone origin is *not* at the zone origin, ordinary CNAME is still possible if you want to have the SRV in the control of the CDN. ENAME does not have a good transition mechanism for DNSSEC. If you do not know the new algorithm(s), you will not be able to validate, and a zone signed with an earlier algorithm will not work either as the synthesized CNAME will not validate. ENAME can thus not be used with DNSSEC until there is sufficient adoption of the new algorithms by the installed base of resolvers. No. Your analysis is faulty. ENAME could be used immediately once the authoritative servers for the zone support it. It would just be insecure until validators catch up. ENAME + old algorithm would be illegal and would be enforced by signing code and authoritative servers. Anything which requires DNSSEC validator changes is a transition disaster that will become totally untenable if DNSSEC is ever widely deployed (in the millions of zones signed sense). That level of deployment has not yet occurred, but nevertheless I think that DNSSEC validation process changes should be held to the very strictest standards and only be contemplated for dire problems. This is *not* a dire problem! We have already managed two DNSSEC validator change, NSEC - NSEC + NSEC3 (algorithm bump), and adding DNAME awareness to DNSSEC (type code roll, though we could have done it using a algorithm bump) and the world did not end. If we wanted to do it we could deploy this on multiple implementations before the end of the year. It just requires the will to do it. There is nothing in the proposal that is technically harder than what we are already doing when validating or have already done in terms of transition management. I think we should encourage the use of SRV in HTTP 2.0. We can also recommend that if people are contemplating ever needing to use a CDN, then they shouldn't publish URLs with names at zone cuts. Nobody is saying don't get SRV support in HTTP 2.0. I would love SRV or even a HTTP record to be support in HTTP 2.0. There is however a need to be able to fully redirect a zone. CNAME cannot be used along side DNAME. There is also a needed for aliasing by type. These needs will come up again. We can deal with them now or deal with them later. /Bob ___ 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] Extended CNAME (ENAME)
On 5/19/14, 16:43, Mark Andrews ma...@isc.org wrote: No. Your analysis is faulty. ENAME could be used immediately once the authoritative servers for the zone support it. It would just be insecure until validators catch up. ENAME + old algorithm would be illegal and would be enforced by signing code and authoritative servers. I didn't say ENAME wouldn't work if you didn't validate. What I'm saying is that proposals which are incompatible with existing DNSSEC should be subject to the most rigorous scrutiny and cost-benefit analysis, and that I don't think ENAME's benefits are worth its costs. Others may have differing valuations. That's all I'll say on this matter. /Bob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
off-topic On May 19, 2014, at 3:40 PM, Ted Lemon ted.le...@nominum.com wrote: On May 19, 2014, at 5:11 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: Yes they have, and yes it would. However, they are not focused on SRV (nor URI) at the current time. What _are_ they focused on? Transport and layering of messages within the protocol and, to a lesser extent, interaction with TLS. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
On May 19, 2014, at 6:12 PM, David C Lawrence t...@akamai.com wrote: Not so much pushing required, at least of Akamai. You have a ready-made ally in me, if only clients actually made good use of it. The clients are the real obstacle. Yup. It would be great if we could get the HTTP 1.1 clients to do it, but getting HTTP 2.0 clients to do it seems at least as do-able as any of the alternatives that have been proposed. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
On May 19, 2014, at 7:43 PM, Mark Andrews ma...@isc.org wrote: These needs will come up again. We can deal with them now or deal with them later. Let's deal with them later. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
On May 19, 2014, at 8:26 PM, Bob Halley bob.hal...@nominum.com wrote: On 5/19/14, 16:43, Mark Andrews ma...@isc.org wrote: No. Your analysis is faulty. ENAME could be used immediately once the authoritative servers for the zone support it. It would just be insecure until validators catch up. ENAME + old algorithm would be illegal and would be enforced by signing code and authoritative servers. I didn't say ENAME wouldn't work if you didn't validate. What I'm saying is that proposals which are incompatible with existing DNSSEC should be subject to the most rigorous scrutiny and cost-benefit analysis, and that I don't think ENAME's benefits are worth its costs. Others may have differing valuations. That's all I'll say on this matter. +1 Anything that requires logic changes in resolvers takes a long time to roll out. We can not afford having one more change that negatively affects DNSSEC validation. SRV use by HTTPv2 is mostly a client change, we will not need to wait for the 5+ year developmental + deployment cycle of upgraded resolver in certain OS distributions. As a matter of fact I recall that Mark wrote this document many years back: http://tools.ietf.org/html/draft-andrews-http-srv-00 If that draft had got traction then, the world would be a much better place today. Olafur ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
Hi, First, let me say that I like Mark's sketch of ENAME that I read on this list. (To disclose my bias, I had a much inferior, faintly similar idea a couple years ago, but it was not complete, and not as compact or elegant. The customer I offered it to therefore told me not to pursue it.) I think the ENAME suggestion is a promising idea (though it needs fleshing out and deeper evaluation). I think it is a vast improvement over the last suggestion in this direction (BNAME). Nevertheless, On Tue, May 20, 2014 at 09:43:42AM +1000, Mark Andrews wrote: the zone support it. It would just be insecure until validators catch up. …I think that may be a little too glib. Given the DNSSEC environment these days, I'm not sure we can just shrug our shoulders at the idea of breaking DNSSEC validators. Replacing validators on a large scale takes perhaps 18-24 months (it's a new feature, and a lot of stable server systems are now committed to no feature change in that time scale), and likely longer for really complete penetration. End point validation uptake is worse; but on the other hand that continues to be an enthusiast market, so it might be ok. _But_, there might be a slightly better argument. The driving use cases for ENAME are for zones that today are almost certainly not signing and, perhaps more importantly, have a whole bunch of challenges in signing. Stupid DNS tricks in the presence of DNSSEC are awful hard. Given the still-low utility in end point validation, an administrator of such a candidate zone might not be ready to adopt DNSSEC anyway. So, if we quickly added ENAME and got the algorithm change in place, then validators might be ready in time. I can't say I'm optimistic about this. ENAME would require special server-side processing, so it's full standards action. If we as a community are actually convinced this is worth doing, however, then we ought to be able to crank this out in 3-5 months. I have heard people claim that we shut down DNSEXT too fast. It took years to do that, which I took to be evidence that we did it too slowly. Perhaps this is an opportunity for those who think I was too keen to prove what a jerk I am. That oughta be incentive ;-) Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
Ted Lemon wrote: On May 19, 2014, at 6:12 PM, David C Lawrence t...@akamai.com wrote: Not so much pushing required, at least of Akamai. You have a ready-made [SRV] ally in me, if only clients actually made good use of it. The clients are the real obstacle. Yup. It would be great if we could get the HTTP 1.1 clients to do it [SRV], but getting HTTP 2.0 clients to do it [SRV] seems at least as do-able as any of the alternatives that have been proposed. i was there when SRV was conceived. we intended it to be used opportunistically, like MX before it, falling back to or even A queries if there was no SRV. it can be added to any protocol at any time, including HTTP/0.9 clients to the extent there are still any of those around. SRV's rules are defined for a service not by the client. if we decide that web servers can be reached by SRV records, then any web client can start looking for the SRV that describes that service, falling back to whatever tin-cups-and-string it did before if it can't find the SRV it wants. in that sense mark andrews' HTTP SRV I-D from all those years ago should not have been controversial. if you want to do this, here's how everybody else agreed to do it. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-bortzmeyer-dnsop-dns-privacy (was: DNS privacy : now at least two drafts)
On 5/19/14, 1:09 PM, John Heidemann wrote: Folks, I believe consensus was that dnsop needs a problem statement about DNS privacy before we explore possible solutions. If I were to speculate on the basis of the dicussion here and in the DNSE bof the solution space involves signficant if maybe not dramatic architecture changes. I would be happy to support exploration of the problem here and documents of an according nature, but I imagine us chartering it as a standalone activity. Stephane's draft-bortzmeyer-dnsop-dns-privacy seems like a very good start to this problem statement. Are there plans to discuss this draft at IETF90 in Toronto? I sent him some detailed comments out-of-band, but one question for the list: what do we call the parts of the DNS resolver hierarchy? draft-bortzmeyer-dnsop-dns-privacy-02 defines and uses the terms (1) stub resolver, (2) resolver and (3) name server and also (2.5) a forwarding DNS resolver/server that is beyond the first-hop recursive resolver/server but not authoritative. for the things that (1) initiates queries, (2) handle recursive resolution, (3) reply with authoritative responses. The short version is: I recommend against use of resolver without an adjective for (2). Prior RFCs do not have consensus about what to use (both recursive resolver and recursive name server appear). Personally I'd go with recursive resolver. Does the list have other recommendations? The tl;dr version is below: I looked over many (but certainly not all) existing RFCs, and there is some variation in terminology: RFC-1035 (the original DNS spec): (1) stub resolver (2) recursive server (3) no specific term (!)... it does talk about foreign name servers and masters and authoritative data, but not authoritative servers RFC-1996 (DNS notify): (1) (not used) (2) (not used) (3) authoritative server RFC-1999 (EDNS): none RFC-3833 (DNS threats) uses (1) stub resolver (2) recursive name server (3) authoritative name servers RFC-4033 and 4035 (DNSsec) use: (1) stub resolver (2) recursive name server (3) authoritative name servers RFC-4871 (DKIM): uses only (2) recursive name server RFC-5966 (DNS over TCP): (1) stub resolver (2) recursive server (or forwarder) (3) authoritative server RFC-6891 (ENDS(0)): (1) stub resolver (2) recursive resolver AND caching resolver (3) authoritative server Back to draft-bortzmeyer-dnsop-dns-privacy My recommendation for terms is: (1) stub resolver (2) recursive resolver (2.5) forwarding resolver OR maybe caching intermediate resolver (3) authoritative nameserver (or authoritative name-server) Based on these observations: - resolver without an adjective for (2) risks ambiguity - recursive resolver vs. recursive server for (2) seem to depend on if you're approaching the problem from the end-user or the providers point of view. The challenge is that (2) is both a client AND server, leading to inconsistency. Just a suggestion, -John Heidemann ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
On 20 maj 2014, at 05:54, Paul Vixie p...@redbarn.org wrote: if we decide that web servers can be reached by SRV records, then any web client can start looking for the SRV that describes that service, falling back to whatever tin-cups-and-string it did before if it can't find the SRV it wants. in that sense mark andrews' HTTP SRV I-D from all those years ago should not have been controversial. if you want to do this, here's how everybody else agreed to do it. Speaking as an Applications Area Director of the time when SRV records where proposed I completely agree. Algorithm should be defined by the service, and when done, it should be implemented and used. Can we not with HTTP/2 please push SRV forward? Patrik signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
