Re: [DNSOP] Extended CNAME (ENAME)

On Sat, May 24, 2014 at 11:58:25PM +0200, Florian Weimer wrote: > Uhm. Why insecure and not bogus? Mark's plan includes an algorithm number change. If you're a validator and the signing algo is one you don't know, then it's an insecure delegation, not a bogus one. I note that this means that DA

Re: [DNSOP] Extended CNAME (ENAME)

* Mark Andrews: > ENAME could be used immediately once the authoritative servers for > the zone support it. It would just be insecure until validators > catch up. Uhm. Why insecure and not bogus? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf

Re: [DNSOP] Extended CNAME (ENAME)

Absolutely! Ray Sent from my iPhone > On 23 May 2014, at 16:47, "Ted Lemon" wrote: > > I've been talking privately with some knowledgable httpbis folks about having > a special joint session at IETF 90 where we can focus on this topic and > hopefully come to a mutual understanding of the pro

Re: [DNSOP] Extended CNAME (ENAME)

>> I've been talking privately with some knowledgable httpbis folks about >> having a special joint >session at IETF 90 where we can focus on this topic and hopefully come to a >mutual understanding of >the problems and opportunities. Would people be interested in attending such >a meeting? >>

Re: [DNSOP] Extended CNAME (ENAME)

On 5/23/14, 11:47 AM, Ted Lemon wrote: On May 23, 2014, at 4:30 AM, Ray Bellis wrote: Given that the CNAME at the Apex problem appears to be mostly (entirely?) an HTTP-related problem, it seems to me we ought to be engaging more with HTTPbis to help them come up with a solution that's mutua

Re: [DNSOP] Extended CNAME (ENAME)

On Fri, May 23, 2014 at 11:47:17AM -0400, Ted Lemon wrote: > I've been talking privately with some knowledgable httpbis folks about having > a special joint session at IETF 90 where we can focus on this topic and > hopefully come to a mutual understanding of the problems and opportunities. > W

Re: [DNSOP] Extended CNAME (ENAME)

On 23 May 2014, at 11:47, Ted Lemon wrote: > On May 23, 2014, at 4:30 AM, Ray Bellis wrote: >> Given that the CNAME at the Apex problem appears to be mostly (entirely?) an >> HTTP-related problem, it seems to me we ought to be engaging more with >> HTTPbis to help them come up with a solution

Re: [DNSOP] Extended CNAME (ENAME)

On May 23, 2014, at 4:30 AM, Ray Bellis wrote: > Given that the CNAME at the Apex problem appears to be mostly (entirely?) an > HTTP-related problem, it seems to me we ought to be engaging more with > HTTPbis to help them come up with a solution that's mutually acceptable and > doesn't involve

Re: [DNSOP] Extended CNAME (ENAME)

On (2014-05-23 08:30 +), Ray Bellis wrote: > I've made him aware of the update to Mark's HTTP SRV draft, but there appears > to be a problem that SVCINFO addresses that SRV doesn't, namely declaration > (or discovery) of which version of the protocol is supported by the endpoint. ACK. We ha

Re: [DNSOP] Extended CNAME (ENAME)

On 21 May 2014, at 11:15, Saku Ytti wrote: > Any opinions on SVCINFO[0]. I was really big fan of SRV until I read the > draft, it made really compelling arguments to me. It looks interesting. I had a long conversation last night with Martin Thomson, editor of the HTTP/2.0 draft and now employ

Re: [DNSOP] Extended CNAME (ENAME)

Klaus Malorny wrote: >> OK. If it is acceptable for you, allow 1 variant per name and we >> are done. >> >> That people around you are happy with at most 5 or 20 variants >> does not mean other people needing more variants may suffer >> from the trade-off. >> >> A better solution is never use IDN.

Re: [DNSOP] Extended CNAME (ENAME)

Tony Finch wrote: >> Perhaps, it is a misunderstanding of a suggestion of rfc974: >> >> Note that the algorithm to delete irrelevant RRs breaks if LOCAL has >> a alias and the alias is listed in the MX records for REMOTE. (E.g. >> REMOTE has an MX of ALIAS, where ALIAS has a CNAME of

Re: [DNSOP] Extended CNAME (ENAME)

S Moonesamy wrote: > > Section 8.7 of RFC 6409 is applicable for mail submission and CNAME. Whoops, the second paragraph of that section is completely incorrect. Tony. -- f.anthony.n.finchhttp://dotat.at/ Tyne, Dogger, Fisher, German Bight, Humber: Cyclonic 5 to 7, occasionally gale 8 at fi

Re: [DNSOP] Extended CNAME (ENAME)

On 22.05.2014 03:18, Masataka Ohta wrote: Klaus Malorny wrote: Sure, but I am talking of about 5-20 variants per name, not all that are combinatorially possible. The idea is that the registrant simply decides which of the variants he wants to have included with his original name. Those would

Re: [DNSOP] Extended CNAME (ENAME)

Masataka Ohta wrote: > > > See RFC 1123 section 5.2.2. This requirement was dropped in RFC 2821 and > > successors. > > Perhaps, it is a misunderstanding of a suggestion of rfc974: > >Note that the algorithm to delete irrelevant RRs breaks if LOCAL has >a alias and the alias is listed in t

Re: [DNSOP] Extended CNAME (ENAME)

In message <537d9d47.3000...@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: > (2014/05/22 14:00), S Moonesamy wrote: > > Hi John, > > At 10:43 21-05-2014, John Levine wrote: > >> See RFC 1123, section 5.2.2. > > > > Tony Finch already commented about RFC 1123. That section has been > > repl

Re: [DNSOP] Extended CNAME (ENAME)

(2014/05/22 14:00), S Moonesamy wrote: > Hi John, > At 10:43 21-05-2014, John Levine wrote: >> See RFC 1123, section 5.2.2. > > Tony Finch already commented about RFC 1123. That section has been > replaced (see RFC 5321). Section 8.7 of RFC 6409 is applicable for mail > submission and CNAME.

Re: [DNSOP] Extended CNAME (ENAME)

Hi John, At 10:43 21-05-2014, John Levine wrote: See RFC 1123, section 5.2.2. Tony Finch already commented about RFC 1123. That section has been replaced (see RFC 5321). Section 8.7 of RFC 6409 is applicable for mail submission and CNAME. Regards, S. Moonesamy

Re: [DNSOP] Extended CNAME (ENAME)

Saku Ytti wrote: > Any opinions on SVCINFO[0]. I was really big fan of SRV until I read the > draft, it made really compelling arguments to me. > Goal should be that 1 query returns all the information client > needs to decide The problem of URI and SVCINFO RRs is that they return too much infor

Re: [DNSOP] Extended CNAME (ENAME)

Tony Finch wrote: >> What? A CNAME, redirection purely within DNS, rewrites an email >> address? > > See RFC 1123 section 5.2.2. This requirement was dropped in RFC 2821 and > successors. Perhaps, it is a misunderstanding of a suggestion of rfc974: Note that the algorithm to delete irrelevan

Re: [DNSOP] Extended CNAME (ENAME)

Klaus Malorny wrote: >>> Sure, but I am talking of about 5-20 variants per name, not all that are >>> combinatorially possible. > The idea is that the registrant simply decides which of the variants he > wants to have included with his original name. Those would be added to > the zone via redir

Re: [DNSOP] Extended CNAME (ENAME)

In message <20140521123324.ga2...@pob.ytti.fi>, Saku Ytti writes: > On (2014-05-21 12:38 +0100), Tony Finch wrote: > > Hi, > > > SVCINFO still requires concurrent A and queries. > > Until newer versions of current protocols replace current protocols and > mandate SVCINFO (or requivalent) a

Re: [DNSOP] Extended CNAME (ENAME)

In message , Ralf Weber writes: > Moin! > > On 21 May 2014, at 16:16, Mark Andrews wrote: > > More that it was assumed that people would read the rfc and enforce > > the prohibition themselves. When that wasn't happening it was first > > made into a warning '97 and fatal in '99. > > IMHO a softw

Re: [DNSOP] Extended CNAME (ENAME)

Moin! On 21 May 2014, at 16:16, Mark Andrews wrote: > More that it was assumed that people would read the rfc and enforce > the prohibition themselves. When that wasn't happening it was first > made into a warning '97 and fatal in '99. IMHO a software should not allow me to make incorrect entrie

Re: [DNSOP] Extended CNAME (ENAME)

>What? A CNAME, redirection purely within DNS, rewrites an email >address? Yes, of course. See RFC 1123, section 5.2.2. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Extended CNAME (ENAME)

Getting validators updated will just happen once the code is written. Try to find a validator that doesn't accept NSEC3 records today. It is actually hard to do. RFC 5155 is just over 6 years old at this point. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE:

Re: [DNSOP] Extended CNAME (ENAME)

Commenting on deployment... On May 20, 2014, at 11:11 PM, Mark Andrews mailto:ma...@isc.org>> wrote: In message <537c15b4.2000...@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: Mark Andrews wrote: The reason why CNAME is prohibited at a zone apex is described in

Re: [DNSOP] Extended CNAME (ENAME)

On Wed, May 21, 2014 at 10:50:42AM +0200, Klaus Malorny wrote: > interesting for domain name registries that have to deal with (maybe > lots of) IDN variants. I don't think that SRV records are a viable > solution for their use case. While this is true, xNAME remains a crummy way to handle variant

Re: [DNSOP] Extended CNAME (ENAME)

In message , Ralf Weber writes: > Moin! > > On 21 May 2014, at 10:50, Klaus Malorny wrote: > > please take into account that a CNAME + DNAME, the previously discussed BNA > ME or the now discussed ENAME solution is still interesting for domain name r > egistries that have to deal with (maybe lot

Re: [DNSOP] Extended CNAME (ENAME)

On 21.05.2014 13:30, Masataka Ohta wrote: Klaus Malorny wrote: Sure, but I am talking of about 5-20 variants per name, not all that are combinatorially possible. I'm afraid you don't distinguish "name" and "label". Anyway, what if you encounter a label with 21 variants? Are you saying regis

Re: [DNSOP] Extended CNAME (ENAME)

On (2014-05-21 12:38 +0100), Tony Finch wrote: Hi, > SVCINFO still requires concurrent A and queries. Until newer versions of current protocols replace current protocols and mandate SVCINFO (or requivalent) at which case client has no need to query for anything else. Some services mandate S

Re: [DNSOP] Extended CNAME (ENAME)

Masataka Ohta wrote: > > What? A CNAME, redirection purely within DNS, rewrites an email > address? See RFC 1123 section 5.2.2. This requirement was dropped in RFC 2821 and successors. Tony. -- f.anthony.n.finchhttp://dotat.at/ West Shannon: Northerly 6 to gale 8. Rough or very rough. Showe

Re: [DNSOP] Extended CNAME (ENAME)

Tony Finch wrote: >> What's wrong with allowing a zone apex have SOA, NS, CNAME but >> nothing else? > > One problem is that CNAME pointing at MX is an interop disaster area, > since different MTAs disagree about whether this implies an email address > rewrite. What? A CNAME, redirection purely

Re: [DNSOP] Extended CNAME (ENAME)

Saku Ytti wrote: > Any opinions on SVCINFO. I was really big fan of SRV until I read the > draft, it made really compelling arguments to me. It doesn't provide indirection, and it piles potentially-unrelated SVCINFO records on to the same QNAME. It would be better to prefix the QNAME with _servi

Re: [DNSOP] Extended CNAME (ENAME)

Masataka Ohta wrote: > > What's wrong with allowing a zone apex have SOA, NS, CNAME but > nothing else? One problem is that CNAME pointing at MX is an interop disaster area, since different MTAs disagree about whether this implies an email address rewrite. Tony. -- f.anthony.n.finchhttp://d

Re: [DNSOP] Extended CNAME (ENAME)

Klaus Malorny wrote: > Sure, but I am talking of about 5-20 variants per name, not all that are > combinatorially possible. I'm afraid you don't distinguish "name" and "label". Anyway, what if you encounter a label with 21 variants? Are you saying registries MUST reject registrations requests

Re: [DNSOP] Extended CNAME (ENAME)

On 21.05.2014 12:08, Masataka Ohta wrote: Klaus Malorny wrote: please take into account that a CNAME + DNAME, the previously discussed BNAME or the now discussed ENAME solution is still interesting for domain name registries that have to deal with (maybe lots of) IDN variants. Scalability of

Re: [DNSOP] Extended CNAME (ENAME)

On 21.05.2014 11:52, Ralf Weber wrote: Moin! Hi Ralf, Oh and then came DNAME for redirecting whole domain trees and that might have been a nice idea if I have a couple of domains and want them all to have the same data. But I do not know of Registries/Registrars that picked that up. Or is t

Re: [DNSOP] Extended CNAME (ENAME)

Any opinions on SVCINFO[0]. I was really big fan of SRV until I read the draft, it made really compelling arguments to me. I'm not sure I agree on how the information is encoded, coworker sent some of his thought to the author explaining how to encode in a way which makes machine-parsing easier. B

Re: [DNSOP] Extended CNAME (ENAME)

Klaus Malorny wrote: > please take into account that a CNAME + DNAME, the previously discussed > BNAME or the now discussed ENAME solution is still interesting for > domain name registries that have to deal with (maybe lots of) IDN > variants. Scalability of IDN labels of equivalent characters

Re: [DNSOP] Extended CNAME (ENAME)

Moin! On 21 May 2014, at 10:50, Klaus Malorny wrote: > please take into account that a CNAME + DNAME, the previously discussed BNAME > or the now discussed ENAME solution is still interesting for domain name > registries that have to deal with (maybe lots of) IDN variants. I don't think > that

Re: [DNSOP] Extended CNAME (ENAME)

On 21.05.2014 08:09, Mark Andrews wrote: What's wrong with: _http._tcp.example.net. SRV ... www.example.net. Nothing. Hi, please take into account that a CNAME + DNAME, the previously discussed BNAME or the now discussed ENAME solution is still interesting for domain name registr

Re: [DNSOP] Extended CNAME (ENAME)

In message <537c47f9.4040...@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: > Mark Andrews wrote: > > >> What's wrong with: > >> > >>_http._tcp.example.net. SRV ... www.example.net. > > > > Nothing. > > So, without (C/E)NAME changes, the possibility of the following > configuration: >

Re: [DNSOP] Extended CNAME (ENAME)

Mark Andrews wrote: >> What's wrong with: >> >> _http._tcp.example.net. SRV ... www.example.net. > > Nothing. So, without (C/E)NAME changes, the possibility of the following configuration: _http._tcp.example.net. SRV ... example.net.hoster.net. example.net.hoster.net CNAM

Re: [DNSOP] Extended CNAME (ENAME)

In message <537c2f18.4060...@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: > Mark Andrews wrote: > > > The data stored at www.example.net is usually very different to the > > data stored at example.net. For www.example.net you often don't > > care about anything other than A and . The s

Re: [DNSOP] Extended CNAME (ENAME)

On 20 maj 2014, at 22:57, Mark Delany wrote: >> one can lookup A, and SRV in parallel and positive answer >> to SRV, as Paul mentioned, can have additional A and RRs. > > A downside is that clients has to wait for the SRV query to complete > so they can be sure of the presence or not

Re: [DNSOP] Extended CNAME (ENAME)

Mark Andrews wrote: > I've updated draft-andrews-http-srv-02. > > http://tools.ietf.org/html/draft-andrews-http-srv-02 First, as all the URIs related to SRV are URLs, the draft should specifically say URLs, especially because non-URL URIs are virtually dead replaced by DOIs. Considering a possi

Re: [DNSOP] Extended CNAME (ENAME)

Mark Andrews wrote: > The data stored at www.example.net is usually very different to the > data stored at example.net. For www.example.net you often don't > care about anything other than A and . The same can not be > said for example.net even after you remove SOA, NS and DNSKEY from > the e

Re: [DNSOP] Extended CNAME (ENAME)

In message <537c24fa.6020...@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: > Mark Andrews wrote: > > >>> The reason why CNAME is prohibited at a zone apex is described in RFC 103 > 4: > >> > >> If we must change something, isn't it easier to allow CNAME at > >> a zone apex than introducing E

Re: [DNSOP] Extended CNAME (ENAME)

Ben Laurie wrote: > Surely the problem is that the server must continue to support clients > that don't look for SRV. So, what's the incentive for a server to > start using it? Port based virtual (without port numbers in URLs) hosting. With the following extended reverse look up: 1.0.13

Re: [DNSOP] Extended CNAME (ENAME)

Mark Andrews wrote: >>> The reason why CNAME is prohibited at a zone apex is described in RFC 1034: >> >> If we must change something, isn't it easier to allow CNAME at >> a zone apex than introducing ENAME? > > No. They are roughly equally difficult and allowing CNAME at the > apex still won't

Re: [DNSOP] Extended CNAME (ENAME)

In message <537c15b4.2000...@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: > Mark Andrews wrote: > > > The reason why CNAME is prohibited at a zone apex is described in RFC 1034: > > If we must change something, isn't it easier to allow CNAME at > a zone apex than introducing ENAME? No. T

Re: [DNSOP] Extended CNAME (ENAME)

Masataka Ohta wrote: > Mark Andrews wrote: > >> The reason why CNAME is prohibited at a zone apex is described in RFC 1034: > > If we must change something, isn't it easier to allow CNAME at > a zone apex than introducing ENAME? the reasons for prohibiting it, as given in RFC 1034, still apply.

Re: [DNSOP] Extended CNAME (ENAME)

Mark Andrews wrote: > The reason why CNAME is prohibited at a zone apex is described in RFC 1034: If we must change something, isn't it easier to allow CNAME at a zone apex than introducing ENAME? Masataka Ohta

Re: [DNSOP] Extended CNAME (ENAME)

In message <537af637.2030...@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: > Paul Vixie wrote: > > > 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

Re: [DNSOP] Extended CNAME (ENAME)

Mark Delany wrote: >> one can lookup A, and SRV in parallel and positive answer >> to SRV, as Paul mentioned, can have additional A and RRs. > > A downside is that clients has to wait for the SRV query to complete > so they can be sure of the presence or not of an SRV. ... in a blast p

Re: [DNSOP] Extended CNAME (ENAME)

> one can lookup A, and SRV in parallel and positive answer > to SRV, as Paul mentioned, can have additional A and RRs. A downside is that clients has to wait for the SRV query to complete so they can be sure of the presence or not of an SRV. First-win approaches like happy eyeballs don'

Re: [DNSOP] Extended CNAME (ENAME)

On 19 maj 2014, at 23:45, 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. So query A//SRV in parallel and be done with it. Smart resolves will provide additional data just for fun and everyone will be ha

Re: [DNSOP] Extended CNAME (ENAME)

On May 20, 2014, at 10:54 AM, Patrik Fältström wrote: > Thanks for checking carefully! np. That is a valid idiom in English, of course, but it works better if you can use your voice to emphasize what you mean... :) ___ DNSOP mailing list DNSOP@ietf.

Re: [DNSOP] Extended CNAME (ENAME)

On 20 maj 2014, at 16:00, Ted Lemon wrote: > On May 20, 2014, at 12:48 AM, Patrik Fältström wrote: >> Can we not with HTTP/2 please push SRV forward? > > Dare I assume that you meant "not" for emphasis, not to ask that we not do > this? :) Argghof course. Me and English... I *WANT* SR

Re: [DNSOP] Extended CNAME (ENAME)

On May 20, 2014, at 5:36 AM, Ben Laurie wrote: > Surely the problem is that the server must continue to support clients > that don't look for SRV. So, what's the incentive for a server to > start using it? That's why this is a clear win for HTTP 2.0 and not so clear for HTTP 1.1. ___

Re: [DNSOP] Extended CNAME (ENAME)

On May 20, 2014, at 2:29 AM, Masataka Ohta wrote: > I have a proposal in: > http://tools.ietf.org/html/draft-ohta-urlsrv-00 > on the problems. Adding the port numbers is a surprising choice. Why not just do something like this: _port._proto._tcp.name.? IOW, if a port is specified in t

Re: [DNSOP] Extended CNAME (ENAME)

On May 20, 2014, at 12:48 AM, Patrik Fältström wrote: > Can we not with HTTP/2 please push SRV forward? Dare I assume that you meant "not" for emphasis, not to ask that we not do this? :) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mai

Re: [DNSOP] Extended CNAME (ENAME)

On 20 maj 2014, at 14:17, Petr Spacek wrote: > Hmm, would it be too weird to use > > _http._srv.[name] CNAME _https._tcp.[name] > > as 'HTTPS required' signalization? > > (This is weird, I admit that. There will be troubles with DNS client > libraries not exposing CNAMEs etc... I just can't

Re: [DNSOP] Extended CNAME (ENAME)

Ben Laurie wrote: > > Surely the problem is that the server must continue to support clients > that don't look for SRV. So, what's the incentive for a server to > start using it? Maybe DNS hosting providers could use the SRV records as a hint for auto-updating the A and records at the zone a

Re: [DNSOP] Extended CNAME (ENAME)

On 20.5.2014 13:52, Chris Thompson wrote: On May 20 2014, Mark Andrews wrote: I've updated draft-andrews-http-srv-02. http://tools.ietf.org/html/draft-andrews-http-srv-02 Wouldn't it be desirable to say something about https URIs as well as http ones? It would seem that we will need an _http

Re: [DNSOP] Extended CNAME (ENAME)

On May 20 2014, Mark Andrews wrote: I've updated draft-andrews-http-srv-02. http://tools.ietf.org/html/draft-andrews-http-srv-02 Wouldn't it be desirable to say something about https URIs as well as http ones? It would seem that we will need an _https._tcp.[name] SRV RRSet as well as the _htt

Re: [DNSOP] Extended CNAME (ENAME)

In message , Ben Laurie writes: > On 20 May 2014 04:54, Paul Vixie wrote: > > > > > > Ted Lemon wrote: > > > > On May 19, 2014, at 6:12 PM, David C Lawrence wrote: > > > > Not so much pushing required, at least of Akamai. You have a > > ready-made [SRV] ally in me, if only clients actually mad

Re: [DNSOP] Extended CNAME (ENAME)

On 20 May 2014 04:54, Paul Vixie wrote: > > > Ted Lemon wrote: > > On May 19, 2014, at 6:12 PM, David C Lawrence 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 obstacl

Re: [DNSOP] Extended CNAME (ENAME)

I've updated draft-andrews-http-srv-02. http://tools.ietf.org/html/draft-andrews-http-srv-02 Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing

Re: [DNSOP] Extended CNAME (ENAME)

On 05/20/2014 12:12 AM, David C Lawrence wrote: > > 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.)

Re: [DNSOP] Extended CNAME (ENAME)

Paul Hoffman 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. I'm afraid exchanges of

Re: [DNSOP] Extended CNAME (ENAME)

Paul Vixie wrote: > 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 > t

Re: [DNSOP] Extended CNAME (ENAME)

On 20 maj 2014, at 05:54, Paul Vixie 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

Re: [DNSOP] Extended CNAME (ENAME)

Ted Lemon wrote: > On May 19, 2014, at 6:12 PM, David C Lawrence 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 ge

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 th

Re: [DNSOP] Extended CNAME (ENAME)

On May 19, 2014, at 8:26 PM, Bob Halley wrote: > On 5/19/14, 16:43, "Mark Andrews" 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 a

Re: [DNSOP] Extended CNAME (ENAME)

On May 19, 2014, at 7:43 PM, Mark Andrews 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 6:12 PM, David C Lawrence 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,

Re: [DNSOP] Extended CNAME (ENAME)

On May 19, 2014, at 3:40 PM, Ted Lemon wrote: > On May 19, 2014, at 5:11 PM, Paul Hoffman 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

Re: [DNSOP] Extended CNAME (ENAME)

On 5/19/14, 16:43, "Mark Andrews" 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

Re: [DNSOP] Extended CNAME (ENAME)

In message , 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

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 U

Re: [DNSOP] Extended CNAME (ENAME)

On May 19, 2014, at 5:11 PM, Paul Hoffman 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/li

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

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

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,

Re: [DNSOP] Extended CNAME (ENAME)

On May 16, 2014, at 6:19 PM, Mark Delany 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 > sup

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

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 b

Re: [DNSOP] Extended CNAME (ENAME)

In message <20140518163140.gb27...@solar.andreasschulze.de>, Andreas Schulze wr ites: > Mark Andrews: > > domain ENAME domain {0|1} [type list of included / excluded types] > > (0 == include, 1 == exclude) > > Mark, > > I currently don't see, why ENAME will be usefull. Could you

Re: [DNSOP] Extended CNAME (ENAME)

Mark Andrews: > domain ENAME domain {0|1} [type list of included / excluded types] > (0 == include, 1 == exclude) Mark, I currently don't see, why ENAME will be usefull. Could you (or other) clarify in which scenario ENAME would be helpfull? Or what like to ask: How has my pr

Re: [DNSOP] Extended CNAME (ENAME)

On 5/18/14, 1:58 AM, Patrik Fältström wrote: On 17 maj 2014, at 13:51, Ted Lemon 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,

Re: [DNSOP] Extended CNAME (ENAME)

On 17 maj 2014, at 13:51, Ted Lemon 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 functio

Re: [DNSOP] Extended CNAME (ENAME)

Subject: Re: [DNSOP] Extended CNAME (ENAME) Date: Sat, May 17, 2014 at 07:51:00AM -0400 Quoting Ted Lemon (ted.le...@nominum.com): > On May 17, 2014, at 3:12 AM, Mark Andrews wrote: > >> Or are there other uses for ENAME beyond what the HTTP/CDN crowd do > >> with CNAMEs to

Re: [DNSOP] Extended CNAME (ENAME)

In message <9df48618-9856-43f7-8e69-b43a1b0e5...@hopcount.ca>, Joe Abley writes : > > On 17 May 2014, at 7:51, Ted Lemon wrote: > > > On May 17, 2014, at 3:12 AM, Mark Andrews wrote: > >>> Or are there other uses for ENAME beyond what the HTTP/CDN crowd do > >>> with CNAMEs today? > >> > >> I wo

Re: [DNSOP] Extended CNAME (ENAME)

On May 17, 2014, at 9:23 AM, Joe Abley wrote: > With respect to using SRV for HTTP (which I agree would be great) the gap is > on the client side. It's an application issue, and I don't see a lot of work > to be done in this working group. How widespread is HTTP 2.0 support in browsers at the m

Re: [DNSOP] Extended CNAME (ENAME)

On 17 May 2014, at 7:51, Ted Lemon wrote: > On May 17, 2014, at 3:12 AM, Mark Andrews wrote: >>> Or are there other uses for ENAME beyond what the HTTP/CDN crowd do >>> with CNAMEs today? >> >> I would encourage both. ENAME is just service agnostic. > > It might be worth actively pushing the

Re: [DNSOP] Extended CNAME (ENAME)

On May 17, 2014, at 3:12 AM, Mark Andrews wrote: >> Or are there other uses for ENAME beyond what the HTTP/CDN crowd do >> with CNAMEs today? > > I would encourage both. ENAME is just service agnostic. It might be worth actively pushing the CDN folks to go the SRV direction. Even if ENAME we

Re: [DNSOP] Extended CNAME (ENAME)

In message <20140517011926.71263.qm...@f5-external.bushwire.net>, "Mark Delany" writes: > 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 hav

  1   2   >