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
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
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
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
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
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
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
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
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
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.
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
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
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
> 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'
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
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.
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
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.
___
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
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
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
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
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
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
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
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
At 05:21 12-05-2014, The IESG wrote:
The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'Automating DNSSEC Delegation Trust Maintenance'
as
Informational RFC
The IESG plans to make a decision in the next few weeks, and solic
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
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.)
29 matches
Mail list logo
