Absolutely!
Ray
Sent from my iPhone
On 23 May 2014, at 16:47, Ted Lemon ted.le...@nominum.com 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
* 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
On 21 May 2014, at 11:15, Saku Ytti s...@ytti.fi 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
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 have
On May 23, 2014, at 4:30 AM, Ray Bellis ray.bel...@nominet.org.uk 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
On 23 May 2014, at 11:47, Ted Lemon ted.le...@nominum.com wrote:
On May 23, 2014, at 4:30 AM, Ray Bellis ray.bel...@nominet.org.uk 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
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.
On 5/23/14, 11:47 AM, Ted Lemon wrote:
On May 23, 2014, at 4:30 AM, Ray Bellis ray.bel...@nominet.org.uk 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
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?
I'd
(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.
What
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
replaced (see RFC
Masataka Ohta mo...@necom830.hpcl.titech.ac.jp 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
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
S Moonesamy sm+i...@elandsys.com 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.finch d...@dotat.at http://dotat.at/
Tyne, Dogger, Fisher, German Bight, Humber: Cyclonic 5
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 LOCAL).
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 same can
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 CNAME
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:
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
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 is
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.
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
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
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 for
Masataka Ohta mo...@necom830.hpcl.titech.ac.jp 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.
--
Saku Ytti s...@ytti.fi 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
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 within
Masataka Ohta mo...@necom830.hpcl.titech.ac.jp 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.finch d...@dotat.at http://dotat.at/
West Shannon:
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
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
In message cc8c19f5-75e6-4476-a78e-fa65dd023...@fl1ger.de, Ralf Weber writes:
Moin!
On 21 May 2014, at 10:50, Klaus Malorny klaus.malo...@knipp.de wrote:
please take into account that a CNAME + DNAME, the previously discussed BNA
ME or the now discussed ENAME solution is still interesting
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 variants.
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:
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
Moin!
On 21 May 2014, at 16:16, Mark Andrews ma...@isc.org 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
In message f322b183-de6a-4173-9de6-afc1f1417...@fl1ger.de, Ralf Weber writes:
Moin!
On 21 May 2014, at 16:16, Mark Andrews ma...@isc.org 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
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) at which
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 irrelevant RRs
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
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
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
those
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 the
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.)
On 20 May 2014 04:54, Paul Vixie p...@redbarn.org wrote:
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
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
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
Ben Laurie b...@links.org 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
On 20 maj 2014, at 14:17, Petr Spacek pspa...@redhat.com 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
On May 20, 2014, at 12:48 AM, Patrik Fältström p...@frobbit.se 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
On May 20, 2014, at 2:29 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp
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.?
On May 20, 2014, at 5:36 AM, Ben Laurie b...@links.org 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.
On 20 maj 2014, at 16:00, Ted Lemon ted.le...@nominum.com wrote:
On May 20, 2014, at 12:48 AM, Patrik Fältström p...@frobbit.se 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.
On May 20, 2014, at 10:54 AM, Patrik Fältström p...@frobbit.se 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
On 19 maj 2014, at 23:45, Mark Andrews ma...@isc.org 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
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't
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
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 protocol
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
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.
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. They are
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:
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 ENAME?
No.
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
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
On 20 maj 2014, at 22:57, Mark Delany f...@november.emu.st 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
On 17 maj 2014, at 13:51, Ted Lemon ted.le...@nominum.com 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
On 5/18/14, 1:58 AM, Patrik Fältström wrote:
On 17 maj 2014, at 13:51, Ted Lemon ted.le...@nominum.com 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
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
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 (or other)
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 have been
On May 17, 2014, at 3:12 AM, Mark Andrews ma...@isc.org 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
On 17 May 2014, at 7:51, Ted Lemon ted.le...@nominum.com wrote:
On May 17, 2014, at 3:12 AM, Mark Andrews ma...@isc.org 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
On May 17, 2014, at 9:23 AM, Joe Abley jab...@hopcount.ca 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
In message 9df48618-9856-43f7-8e69-b43a1b0e5...@hopcount.ca, Joe Abley writes
:
On 17 May 2014, at 7:51, Ted Lemon ted.le...@nominum.com wrote:
On May 17, 2014, at 3:12 AM, Mark Andrews ma...@isc.org wrote:
Or are there other uses for ENAME beyond what the HTTP/CDN crowd do
with CNAMEs
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 ma...@isc.org wrote:
Or are there other uses for ENAME beyond what the HTTP/CDN crowd do
with CNAMEs today?
I
domain ENAME domain {0|1} [type list of included / excluded types]
(0 == include, 1 == exclude)
domain ENAME domain 1 is equivalent to domain CNAME domain
(exclude nothing)
domain ENAME domain 1 NS DNSKEY SOA is CNAME at apex
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
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
supporting SRV. Would encouraging that group
95 matches
Mail list logo
