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 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. A problem of SRV is that, purely within DNS, SRV is well defined and fine, but within wider context, it is not. For example, for browsers, as both SRV RRs and URLs can specify port numbers, what if they specify different port numbers? For another example for browsers, correspondences between service of SRV and proto in URLs are not clear. Does proto of mailto should use service name of smtp? Maybe, it does, but correspondences are not straight forward. Thus, it is not easy for browser developers, who do not have much expertise in IETF process on DNS, to support SRV. I have a proposal in: http://tools.ietf.org/html/draft-ohta-urlsrv-00 on the problems. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 the messages within the protocol need extra time, which can be too long. Though Mark wrote: : Everytime I have mentioned SRV records to HTTP folks they : say it won't work as the extra lookup takes too long. one can lookup A, and SRV in parallel and positive answer to SRV, as Paul mentioned, can have additional A and RRs. Masataka Ohta PS Even without SRV, extra lookup for DNSSEC takes to looong, even though the root zone operated by ISOC/ICANN, both of which are under US legislation, is not very trustworthy. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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.) 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. That's technically 0.7% too many, as the SRV RFC specifically mentions not to use it for protocols if there's isn't a document stating how to exactly use it with that protocol (mainly, as Ohta-san already mentioned, what to do with apparent data conflicts and a security considerations section), so right now browsers are not supposed to use SRV for http requests. That certainly doesn't mean we shouldn't go forwards and try to introduce such a document together with the http people. I never did find out why Mark's proposal didn't take. Regardless of whether we should go forwards with ENAME, btw. I think having SRV for http would be nice anyway. Jelte ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-dnsop-delegation-trust-maintainance-13.txt (Automating DNSSEC Delegation Trust Maintenance) to Informational RFC
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' draft-ietf-dnsop-delegation-trust-maintainance-13.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the As the intended status of this document is Informational I don't have a strong opinion about the following comments. From the Abstract: This document describes a method to allow DNS operators to more In Section 1: This document outlines a technique in which the parent periodically (or upon request) polls its signed children and automatically This document describes a method for automating maintenance of the delegation trust information, and proposes a polled / periodic trigger for simplicity. There is also a mention of technique in the Abstract. The is a lengthy discussion of what the document, technique and method is about in the first six pages. Which section(s) describe the method or technique? It is only when I read Section 3 that I found out that the document specifies two new DNS resource records. The two new DNS RRs are uses interchangeably in that section. It would be better to have a clear definition of each resource record. Section 3.1 provides a pointer to RFC 4034 for the reader to see the wire and presentation format of the CDS RR. There is then a mention of how IANA has allocated the code and some text about the CDS RR using the same registries as DS. It would be better to include the wire format in the document as that might be the information a reader would look for. From Section 4: 'The child SHOULD publish both CDS and CDNSKEY resource records. If the child knows which the parent consumes, it MAY choose to only publish that record type (for example, some children wish the parent to publish a DS, but they wish to keep the DNSKEY hidden until needed). If the child publishes both, the two RRsets MUST match in content.' I have seen an approach similar to the above in another (non-DNS) RFC. In my opinion, a must match in content open the door to inconsistent content as mistakes do happen. The recommendation to publish both RRs and to publish only one RR if the RR that the parent will use is known doesn't encourage standardization. From Section 6: The parent MUST choose to use either CDNSKEY or CDS resource records as their default updating mechanism. The parent MAY only accept either CDNSKEY or CDS, but it MAY also accept both, so it can use the other in the absence of the default updating mechanism, but it MUST NOT expect there to be both. The first sentence states that the parent must choice either RR. The second sentence states that the parent may accept either RR but it must not expect there to be both. It looks like the DNSOP WG could not agree on a choice and decided to keep the proponents of each RR happy. Section 6.1 explains that the Pushing is simply a button in a web panel and polling is about someone operating a tool. I gather that this is all a matter of relationships and contracts. The following stence in Section 6.2 is odd: The Parental Agent MAY take extra security measures. And this one is an odd usage of a RFC 2119 key word: However the precise out-of-band measures that a parent zone SHOULD take are outside the scope of this document. A diligent Area Director would file a DISCUSS if he or she notices that. Making extra security measures optional makes it sound like the DNSOP WG has not given due consideration to security measures. Section 8 discusses about privacy considerations. The only sentence states that all the information handled by this protocol is public. There isn't any description of a protocol in the document. In Section 9: While it may be tempting, this SHOULD NOT be used for initial enrollment of keys since there is no way to ensure that the initial key is the correct one. What does this refer to in the above? If is used, strict rules for inclusion of keys such as hold down times, challenge data inclusion or similar, ought to be used, along with some kind of challenge mechanism. The above sentence is difficult to parse (re. if is used). The CDS RR type should allow for enhanced security by simplifying process. Which process is being referred to in the above? As this introduces a new mechanism to update information in the parent it MUST be clear who is fetching the records and creating the appropriate records in the parent zone. Is the usage of must in the above for contractual purposes? If there is a failure in applying changes in the child zone to all DNS servers listed in either parent or child NS set it is possible that the Parental agent may get confused, either
Re: [DNSOP] Extended CNAME (ENAME)
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 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. 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? 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 _http._srv.[name] one. (The idea of https overriding the port number(s) in the _http._srv.[name] records with 443 seems too horrible to contemplate.) -- Chris Thompson University of Cambridge Information Services, Email: c...@uis.cam.ac.ukRoger Needham Building, 7 JJ Thomson Avenue, Phone: +44 1223 334715 Cambridge CB3 0RB, United Kingdom. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 _https._tcp.[name] SRV RRSet as well as the _http._srv.[name] one. (The idea of https overriding the port number(s) in the _http._srv.[name] records with 443 seems too horrible to contemplate.) 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 resist.) -- Petr Spacek @ Red Hat ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
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 the zone apex. A bit ugly and based on gratuitously specific assumptions about what protocols the domain might provide on those addresses, but we do that already and pretend it doesn't matter... Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Faeroes: Northeast 5 to 7, perhaps gale 8 later. Moderate, becoming rough or very rough. Rain or showers. Moderate or good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
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 just can't resist.) _http._srv.[name] URI https:[name] ;-) Patrik signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
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 https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
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.? IOW, if a port is specified in the URL, it's used to find the SRV record. If there is no SRV record that matches that port, give up. That matches the current meaning of ports in URLs: http://www.netbsd.org:90/ is not in any sense equivalent to http://www.netbsd.org/ and therefore shouldn't result in the same query. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
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. Me and English... I *WANT* SRV, URI or something similar. Thanks for checking carefully! Patrik signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
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 list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
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 everyone will be happy. Given how much pre-caching and magic modern web browsers do, the extra lookup argument is just moot IMHO. jakob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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't work here so most clients are going to perform at the rate of negative cache lookups for the foreseeable future. In aggregate I would expect this will slow clients a bit. You're also ensuring that the global query rate will substantially increase on the assumption that HTTP/2.0 becomes as popular as HTTP/1.0. Generally speaking, the challenge is that SRV is likely acceptable to commercial CDN providers that have thus far relied on CNAME - with it's intrinsic level of indirection - but will be less welcome by those who are using every trick to squeeze latency out of HTTP. The latter - who are well represented in http-wg - will probably not welcome a parallel SRV even if the latency impact is mostly zero. If you want to make everyone happy, you need to invent a single round-trip resolution that supports indirection... These are just observations - not judgments. Mark. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 protocol where all N queries are sent to the same destination, one can reset the blast timeout upon first response, to 1.2x that response time. or even 1.1x. the total time cost delta of a blast protocol is thus ~10%. since this is only happening on a cache miss, i don't see it as decisive. ... You're also ensuring that the global query rate will substantially increase on the assumption that HTTP/2.0 becomes as popular as HTTP/1.0. not so. 97% of the queries reaching the root name servers (as an example of an important subset of global DNS traffic) are unanswerable due to an initator-side screwup of some kind (rfc1918 source; firewall doesn't permit response; etc). if we doubled the traffic that is not that 97%, it would still be mouse nuts compared to that 97%. ... Generally speaking, the challenge is that SRV is likely acceptable to commercial CDN providers that have thus far relied on CNAME - with it's intrinsic level of indirection - but will be less welcome by those who are using every trick to squeeze latency out of HTTP. disagreeing for a third time, SRV is an opportunity to squeeze even more latency out of HTTP. ... If you want to make everyone happy, you need to invent a single round-trip resolution that supports indirection... content-centric networking would do this. lixia and van have been talking about it for a few years. alas it's a totally non-IP model and not likely to replace the internet during the time it will take us to decide what to do about SRV (and also do whatever it is we decided.) vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 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. A problem of SRV is that, purely within DNS, SRV is well defined and fine, but within wider context, it is not. For example, for browsers, as both SRV RRs and URLs can specify port numbers, what if they specify different port numbers? For another example for browsers, correspondences between service of SRV and proto in URLs are not clear. Does proto of mailto should use service name of smtp? Maybe, it does, but correspondences are not straight forward. Thus, it is not easy for browser developers, who do not have much expertise in IETF process on DNS, to support SRV. I have a proposal in: http://tools.ietf.org/html/draft-ohta-urlsrv-00 on the problems. We left this for being done on a case by case basis for good reasons some of which you enumerate above. I don't think anything has changed in the intervening 15 years to make doing this generically work. What we missed out on doing was going back and doing the case by case analysis of the existing protocols. Doing this on a individual basis may end up saying the same thing multiple times but that is fine. Browser/proxy vendors will see the commonality. Mark Masataka Ohta ___ 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: 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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. They are roughly equally difficult and allowing CNAME at the apex still won't solve CNAME + MX or CNAME + DNAME or CNAME + TXT or CNAME + just about any other type. The zone apex has lots of data stored at it. You have to update validators. You have to do a DNSSEC algorithm bump. You need to update signers and authoritative servers to enforce the algorithm bump. You have to update recursive servers to know about the new CNAME semantics. You have to have a transition strategy. If you do allow CNAME at the apex one will then just end up with two zones to manage instead of one just the second one is on the CDN's nameservers for all the apex data. Mark Masataka Ohta -- 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)
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.132.32.112.131.in-addr.arpa. PTR a.example.com 2.0.132.32.112.131.in-addr.arpa. PTR b.example.com it is better than name based ones. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 ENAME? No. They are roughly equally difficult and allowing CNAME at the apex still won't solve See below. CNAME + MX or CNAME + DNAME or CNAME + TXT or CNAME + just about any other type. What's wrong with allowing a zone apex have SOA, NS, CNAME but nothing else? The zone apex has lots of data stored at it. Nodes, not necessarily zone apex, having lots of their own data can not have CNAME. So? I'm saying just allowing CNAME + SOA + NS + DNSKEY doesn't help in the grand scheme of things. It just moves the problem rather than fixing the problem which is two organisations wanting to change data at the same node. 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 evaluation. You have to do a DNSSEC algorithm bump. No, I don't, because I think DNSSEC must be obsoleted. Anyway, special treatment for CNAME in DNSSEC is no different regardless of whether a node is a zone apex or not. You have to update recursive servers to know about the new CNAME semantics. The update is never rely on cached CNAME for SOA or NS query. Thus, even without the update, most people won't notice lack of the update. Most != all. You have to have a transition strategy. First, change name server implementations. Then, declare that people can use CNAME at zone apex. That's all. Masataka Ohta -- 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: 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 evaluation. Are you saying to have: www.example.net. SOA ... NS ... CNAME example.net. ? What's wrong with: _http._tcp.example.net. SRV ... www.example.net. ? The update is never rely on cached CNAME for SOA or NS query. Thus, even without the update, most people won't notice lack of the update. Most != all. Those who notice are those who can update their servers if they think it necessary (I think it is not). Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 possibility that a port based virtual host may use multiple port numbers: If the URI does explicitly specify a port, other than the default port, to connect to then there is a potential conflict in the port specification between the URI and the SRV records, and the SRV record is ignored. In this case the user agent MUST query for address records for the host name in the URI (instead of SRV records). is not a good idea, which is why I suggested port number addition in my draft. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
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 presence or not of an SRV. You have to look and count on A/ + HTTP with redirect when comparing with SRV+A/ or URI+A/. I.e. some of the losses in even parallell URI/A/ are compensated by loosing roundtrips in HTTP. Patrik signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
