New issue
Advanced search Search tips
Starred by 85 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Apr 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Feature

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

DNS: RFC 2782 not supported (SRV records)

Reported by indey...@gmail.com, Sep 20 2009 Back to list

Issue description

Chromium doesn't support RFC 2782: A DNS RR for specifying the 
location of services (DNS SRV) (see http://tools.ietf.org/html/
rfc2782).

I think it's a important feature which should be supported by 
Chromium.
 

Comment 1 by indey...@gmail.com, Sep 20 2009

Corresponding webkit bug: https://bugs.webkit.org/show_bug.cgi?id=6872
Labels: -Type-Bug -Area-Misc Type-Feature Area-BrowserBackend

Comment 3 by oritm@chromium.org, Dec 17 2009

Labels: -Area-BrowserBackend Area-Internals
Labels Update:

Replace Area-BrowserBackend by Area-Internals

Comment 4 by Deleted ...@, Jan 16 2011

Please provide an update as issue is still outstanding
Labels: Internals-Network
agl: You implemented the DNS RR resolver, do you see this getting traction, or is this as I suspect a WontFix? draft-andrews-http-srv has been expired for some time, and draft-jennings-http-srv didn't seem to get any traction either.

Comment 6 by agl@chromium.org, Jan 18 2011

Status: WontFix (was: NULL)
For latency reasons we will not check SRV records for HTTP/HTTPS navigations.

Comment 7 by bubbl...@gmail.com, Jan 19 2011

Hi agl,

Could you please elaborate on that?

Thank you for your time.
All,

For internal LAN/MAN applications DNS-SRV makes a very good
redundancy/failover option that is quick, cheap, and easy to setup and
provides no single point of failure. For example, my company produces
an E911 call handling system that has a browser based GUI. If one
server becomes un-reachable the browser can easily determine the next
server to try. The only other good way to do this is using an
expensive load balancer (which is still generally a single point of
failure).

As the browser becomes more of an 'application platform' I believe
there will be a greater demand for this type of functionality.
Further, no other browser is currently shipping this feature, it would
give Chromium a substantial leg up.

Comment 9 by agl@chromium.org, Jan 19 2011

SRV records would be a blocking DNS lookup: we would do a SRV lookup first and then start the A record lookup. That would slow everything down.

We could do a SRV and A lookup concurrently, assume that the SRV record doesn't exist and abort+retry if we found that we made a mistake. That would be a significant amount of additional complexity, would still slow things down when the (uncached) SRV lookup took too long and might upset server operators if we did SSL handshakes twice once we get the SRV result.

Either way, no server could rely on SRV records working as, even if every browser added support today, it would be decades until support was universal.

For cases where you want the browser to retry if the first connection fails, multiple A records are the answer. I'm not sure if we support falling back to another IP address but that's a change which could be reasonably made.
SRV is definitely something that is only going to be useful for
particular users and should probably be optional and off by default.

SRV would be very useful in corporate or LAN/MAN environments. Use on
the Internet at large is not likely to ever see widespread use. This
is somewhat analogous to Multicast.

The problem with A records is that you can't have a true 'primary' and
'backup', the records may be delivered and are usually used in random
order. SRV allows a specific ordering.

Comment 11 by bubbl...@gmail.com, Jan 21 2011

Hi agl,

You make a reasonable case against using SRV before or concurrently with A. What about falling back to SRV when:

1) There is no A, or
2) A fails

These two sound like plausible use-cases which do not affect regular hosts adversely but which do support the much more flexible use-cases of SRV.

Thank you for your time in answering this.

Comment 12 by agl@chromium.org, Jan 21 2011

Falling back to a SRV lookup when we see that the domain exists, but that it has no A (or AAAA) records is reasonable. There might be some issues that I'm not thinking of: i.e. does the resolution API on each platform indicate that correctly? (try noarecord.imperialviolet.org)

It would be a long way down the priority list I'm afraid. If you really wanted to see if happen you might need to code it yourself.

Comment 13 by bubbl...@gmail.com, Jan 21 2011

Well, priority: low is always better than a wontfix. Do you agree we can change the resolution to at least indicate the status of this bug? One step at a time.

Comment 14 by agl@chromium.org, Jan 21 2011

Labels: -Pri-2 Pri-3 Mstone-X
Status: Available (was: NULL)
Yep, I can mark as Available.
While deploying VMWares with IPv6 (and allow IPv4 based clients), we WANT to use SRV record (we want to return different port# to different clients based on the queried hostnames) when the clients use HTTP to remote access their VMs.

Lacking the need for SRV, the client must have to remember the port# and type it in the browser.

Could we please make this available on chromium?
While deploying VMWares with IPv6 (and allow IPv4 based clients), we WANT to use SRV record (we want to return different port# to different clients based on the queried hostnames) when the clients use HTTP to remote access their VMs.

Lacking the need for SRV, the client must have to remember the port# and type it in the browser.

Could we please make this available on chromium?
While deploying VMWares with IPv6 (and allow IPv4 based clients), we WANT to use SRV record (we want to return different port# to different clients based on the queried hostnames) when the clients use HTTP to remote access their VMs.

Lacking the need for SRV, the client must have to remember the port# and type it in the browser.

Could we please support SRV query on chromium?

Comment 18 by mbp@google.com, Jul 24 2012

The answer to the SRV query should include the relevant A records in the "additional" section, so (maybe not always?) there should not need to be a second round trip.
Labels: -Internals-Network Internals-Network-DNS
How about if the DNS server returns an SRV record in the 'additional' section of the response to an A query; couldn't Chrome then prioritize the SRV data?

"Legacy" browsers or problematic DNS infrastructure would still get the traditional (SPOF, IPv4-depleting) behaviour.  But Chrome would see the SRV pool of http servers (no SPOF), or even a pool of https servers on different ports (preserve IPv4 space with resilient infrastructure).

I'm not sure that https on non-standard ports is actually realistic (because of corporate firewalls), but as long as this suggestion was only implemented by browsers that also supported SNI, then this we could assume that SRV resolution => SNI => we can share port 443.  It seems unlikely that anyone not supporting SNI would add support for this suggestion.  Just in case though, maybe Chrome could recognize a SRV record with type _spdy, which would mandate SNI (?).

Recognized a _spdy additional SRV response could also be a nice way for a site to say "always use SPDY (even if the user didn't specify https)".  Only browsers that implemented this would get the benefits: SRV's resiliency, with SPDY's speed and security everywhere.

Comment 21 by Deleted ...@, Jan 3 2013

Why not check for SRV records if you check for an A record and you get 2 or more addresses back that is. There's a good chance someone could supply them for the sake of not having to get an AS# and a /24 to create a fail-over cluster of load balancers for web servers. 

Now I'll bet you're going to respond and say that all of these are anycast addresses and so it doesn't make any sense for Google am I right?

Name:   google.com
Address: 173.194.46.8
Name:   google.com
Address: 173.194.46.9
Name:   google.com
Address: 173.194.46.14
Name:   google.com
Address: 173.194.46.0
Name:   google.com
Address: 173.194.46.1
Name:   google.com
Address: 173.194.46.2
Name:   google.com
Address: 173.194.46.3
Name:   google.com
Address: 173.194.46.4
Name:   google.com
Address: 173.194.46.5
Name:   google.com
Address: 173.194.46.6
Name:   google.com
Address: 173.194.46.7

also its not like there aren't already features that can't be disabled such as "unsafe ports" in google chrome, whats the difference if you add one more? I would think you'd want features like that for giving people the "option to have a more reliable browsing experience at the cost of slightly extra latency on SOME websites vs. "the wild cowboy outwest" for those who wanna deal with life as it happens either in anticpiation or with the mild assumption of "who the heck cares faster is better most of the time."

I'm going home man, please I've always wanted to learn BGP and would totally use it if you guys can help me figure out how to get an AS # and will fund it.
Recent events at my job make SRV records something that I too would love to be able to use (while performing a website admin's role).

As I see it the stated reason that Chrome does not implement this is a perception that doing so increases complexity (unavoidable but possibly manageable) and decreases performance (how do we know, is this an inherent design flaw in SRV records or DNS requests?).

I found this open bug via http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/dns-srv-record-use-by-clients.html

Using the 'dig' tool I see that presently to resolve SRV records you must:
1: Make a special request (EG: $ dig _http._tcp.fqdn SRV)
2: Resolve any hosts specified in the SRV records of interest in order to locate their actual IP.
3: If the domain lacks a valid SRV record all of the above was for naught.

This, categorically, does not make sense.

RFC 2782 has this to say about the target field, for anyone else unfamilliar with other types of aliases I believe they mean 'CNAME or similar':
"Target
        The domain name of the target host.  There MUST be one or more
        address records for this name, the name MUST NOT be an alias (in
        the sense of RFC 1034 or RFC 2181).  Implementors are urged, but
        not required, to return the address record(s) in the Additional
        Data section.  Unless and until permitted by future standards
        action, name compression is not to be used for this field."

I would propose that ONLY servers returning the 'optional' additional data in SRV requests are useful, and further that clients MUST support both DNS name (de)compression and aliases.

The behavior for a DNS server that supports 'speedy' DNS SRV requests would be thus:
1: Support alias (CNAME) resolution
2: Include the 'optional' additional (all the way to) A/AAAA resolution information for AT LEAST one SRV record of the highest (lowest number) priority (preferably this is the only area the DNS server would try to 'be smart'; it might preferentially offer servers thought to be 'near' the customer or even ones that are co-located with the customer's ISP)

3: Most, importantly, If a SRV record for that protocol does not exist the DNS server MUST still return the same information a normal query would have in the 'additional' section.


I am not aware of any server which behaves as outlined above but it seems like this would address the potential performance and client complexity concerns, while still only asking DNS servers to return in one request what a client would need to ask for over many requests anyway (thus returning the same information over less requests, which I think is universally beneficial).


The final performance enhancing step would be to have each browser query either a test site it owns on startup (in the case of Chrome this might be _https._tcp.nosrvrecord.google.com) or a site it wants information on anyway (quick search/URL filtering) that it knows does not (and should never) have explicit SRV records setup for.

If the SRV request returns the useful data anyway then it should proceed with using SRV as the lookup method.
If the SRV request returns insufficient data, or fails completely, then it should annotate in some development area what the test results were and use 'old' resolution methods.

There should also be a way of forcing on SRV resolution as the specification currently outlines as a process even though by design it degrades initial visit performance; this would be useful for testing and development as well as environments that have yet to transition to a 'speedy' SRV DNS environment when that outcome is in the extreme minority and it is considered 'increasingly legitimate' to no longer use traditional DNS resolution names alone.
I'm trying to work this out in my head. Presumably the browser is configured to use a DNS server that is a recursive resolver, yes? Can you explain how the DNS server that supports 'speedy' DNS SRV queries would implement it in a way that does not impact latency? Is it itself doing SRV queries and A/AAAA queries in serial? Parallel? Can the browser rely on a DNS server that supports 'speedy' DNS SRV queries implementing it in a performant manner? Otherwise, should the browser issue SRV and A/AAAA queries in parallel in its stub resolver to make sure there's no latency hit?
If the authoritative DNS server puts information into the Additional Information section, presumably a recursive resolver would return that information also.  Then Chrome could favor the SRV record from the AI if it's returned in response to an A query, otherwise proceed normally.

I'm not sure I understand the probing technique mjevans described, but I think a "sufficiently smart" resolver could add SRV records to responses, perhaps cached from a previous response.  I'm not sure whether it's worthwhile adding this functionality to a recursive resolver, but I don't know if that's really our concern!  In my view, the advantage comes when the authoritative DNS server returns a _spdy_ SRV record in the Additional Information.  It sounds like different people have different use-cases though.

I think it's a chicken-and-egg situation, because DNS servers aren't going to support this until browsers support this.  But I think parsing SRV records returned in the additional information section is a way for Chrome to support SRV with no latency cost and minimal complexity (no additional lookups), and I believe those were the main objections.  I'm inclined to have a go at implementing it, but I'd like to know if people think it's a good solution first!
I think that before we consider it here, you should probably reach out to the IETF to see what they think about your idea.

Comment 26 Deleted

A typo edited version post sleep and when I'm not distracted by listening to another conversation.

My belief is that the above idea technically obeys one interpretation of the standard, but makes a requirement for preferring use of 'optional' components of the standard.

My reading of the above comments makes it seem highly unlikely Chrome or another browser will observe the standard without those preferences; I believe it best to forge ahead and have a working real-world code that 'encourages' evolution to a future revision of the standard that alters those optional 'extras' to requirements given that real world use cases prefer them.  All of the other changes are just minor things that a -client- should proactively do, just as browsers already do with malformed markup (though it would be nice if servers later enabled them too).
Sorry I'm lost. Which above idea are you talking about? Yours or Justin's?

Comment 29 by indey...@gmail.com, Jan 24 2013

mjevans: can you, please, provide step-by-step dialog of dns client and server in your scenario? I'm not sure I understand you correctly. 

2 use-cases:
1. "example.com" doesn't have any SRV records
2. "example.com" has "_http._tcp" and "_https._tcp" SRV records which point to different servers
3rd use-case:

Example.com returns an A or AAAA record = IP_add_1 (say) and SRV record points to port number (or range) 'X'.

Example123.com returns an A or AAAA record = IP_add_1 (say) and SRV record points to port number (or range) 'Y'.
TL;DR version; Only use SRV requests if the DNS in use returns full resolution to the A/AAAA record level in the additional section (as is presently optional); otherwise fall back to ‘current’ methods.



I’m working only off of the memory of the interesting bits I remember about DNS records from networking classes in college and when studying for a CCNA/MCSE in highschool around the time of the dot-com bubble bursting.

DNS name compression is interesting because it can be performed ‘naturally’ if a server has data structures developed with it in mind; strings can instead continue on to other locations within a sent message (blindly following them without bounds checking / length checking is a bad idea).

I am making an assumption that each invocation of the dig utility that is available in many Linux distributions as a diagnostic tool performs a single typical operation on each invocation.

Given my reading of this bug report for understanding the workflow in Chrome as well as my reading of some portions of the RFC which seemed relevant I speculate that the following sequence of events is what was ‘intended’ when it was written.

1: Query for _http._tcp.host
2: If no valid SRV data go to 5
3: Resolve the host provided in the selected SRV record (there can be more than one) to obtain it’s address.
4: goto 6
5: Resolve the hostname as normal
6: Attempt to connect to the host/port

Let us assume a ‘best’ case scenario for testing and say that the SRV records have just initially been setup and there is technically no benefit /now/ of having done that; merely that it is a placeholder for when additional resources that aren’t normally provisioned are put in place to handle additional load or scheduled downtime at a normally core site (EG a business which can normally easily handle all operations at a corporate HQ during business hours, but which must for some season or reason allow a normally more costly or time consuming distributed response).

Currently I run dnsmasq on a home server which queries Google’s public DNS servers, I feel this is also a good test environment:

Following the above sequence of steps:

(actually I first queried butter.eu both ways, then I did the A lookup for www.butter.eu)

; <<>> DiG 9.9.2-P1 <<>> _http._tcp.butter.eu SRV
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64994
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;_http._tcp.butter.eu.          IN      SRV

;; ANSWER SECTION:
_http._tcp.butter.eu.   6000    IN      SRV     0 0 80 www.butter.eu.

;; Query time: 648 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jan 24 19:52:25 2013
;; MSG SIZE  rcvd: 82



; <<>> DiG 9.9.2-P1 <<>> www.butter.eu
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4031
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.butter.eu.                 IN      A

;; ANSWER SECTION:
www.butter.eu.          6000    IN      A       213.239.213.254

;; Query time: 632 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jan 24 19:52:46 2013
;; MSG SIZE  rcvd: 58


The response time for each DNS query is about 600 mSec, for user experience it would be desirable to minimise this response time.  Further if someone is asking for a SRV record, there is a high degree of chance that they are going to follow that request with another for the A/AAAA record.  So, as the RFC allows, why not include both in the additional section?

If the server might include that data, why not use SRV as the primary requesting method where the server is nice enough to do so?


RFC 2782 also specifies a record target that denotes an explicit lack of SRV service at that domain.  "A Target of "." means that the service is decidedly not available at this domain."


It might be technically accurate if a DNS server returned a synthetic record with a target of . to indicate that it has understood the request and is providing data anyway.  This might actually be superfluous for the needs of a browser.


In any case (one or more SRV records, null (.) SRV record, empty set) the Additional section of the reply should be included and must contain (as I outlined above) at least one IN A and IN AAAA record (if at least one of each exists) from a host in the top priority tier of the SRV records for that FQDN; if the SRV request does not contain this log the debugging info and proceed using traditional methods.


Returning all of those records at once should keep the resolution duration approximately the same as it is now, and avoid incurring at least double penalty for making it a multi-step process.  In the event that contact with the preferential server fails then the additional data captured by the SRV query process can be used to resolve additional hosts and attempt contacting the backups if they exist.

Even smarter corporate or ISP DNS servers might check on the availability/response time for a few records that are requested frequently during a caching period and prefer hosts that are not only online, but most responsive.
Re: http://code.google.com/u/103782742691539148719/
Re: http://code.google.com/u/100623751320882601237/

Above mentioned use cases.

Case 1: example.com lacks SRV records

DNS server should return a SRV answer that either lacks the answer section or has a . record synthesised for that section.
The DNS server should return the 'optional' additional section and it MUST contain either an A or AAAA record (if both exist it must include both) for the domain as if it were answering a normal A/AAAA request; otherwise the server doesn't support speedy SRV requests and browswers do not want to use it.

Case 2: example.com has SRV records for http and https which point to different ports on different servers.

The DNS server should return the SRV record set for whichever request is made (_http._tcp.host OR _https._tcp.host) and, as outlined in other proposals, unless the user explicitly specified a port to over-ride the SRV record's return value with the SRV record's port for the selected server MUST be obeyed.
The DNS server should return the 'optional' additional section and it MUST contain either an A or AAAA record (if both exist it must include both) for the domain as if it were answering a normal A/AAAA request; otherwise the server doesn't support speedy SRV requests and browswers do not want to use it.

Case 3: two different domains have SRV records pointing to the same IP but different ports.

See Case 2 for how to proceed.


In all of the above cases, on browser startup a test query to a known location should be made to determine IF speedy SRV requests are returned.  ONLY if that is the case will they be used again in the future; otherwise debugging info about why they are not being used should be logged somewhere.

There should also be a setting to 'skip' this test and assume a positive/negitive outcome for it's value.
Project Member

Comment 33 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Internals -Internals-Network-DNS Cr-Internals Cr-Internals-Network-DNS
Just curious, why not make it obvious SRV records are desired in the url? Perhaps one of these schemes would work?

http://example.com:srv/
httpsrv://example.com/
hsrv://example.com/

It really would be a nice feature for systems that dynamically assign ports.
#34 kevin

http://example.com:srv/
- that look ugly and not good for domain hack.
- protocol info might be duplicated (or conflict) since it already include in SRV record.
- Some people also expect SRV record to hide non standard port. Use "srv" instead of port number is comparable ugly.

the latter seem OK in user experience perspective but I think just "srv://" is enough. (if no appropriate SRV return just treat it as no record returned)
However, it not good in standardization and programming perspective since originally the string there used to determine which protocol used to communicate with the server so it affect program flow only when tcp connection can be made.
If we do it like that it will change entire program flow since DNS lookup.
It also potentially conflict with current specification for example:
What if someone use _srv._tcp.example.com. as srv record?

Please also reference:

http://tools.ietf.org/html/rfc3986#section-3

Specifically sections:
3.  Syntax Components
3.2.  Authority

The authority section is already comprehensively defined and there is no provisioning for additional forward compatible payload.

Relating to reply #34 replacing the port with srv is invalid.  srv records offer an opportunistic upgrade which does not degrade existing mechanisms.

The provisioning of a new
3.1.  Scheme
Would allow for additional data payload within a URI which various agents might conform to.  An end user or semi-implementing agent may downgrade the request by altering the request scheme and authority components.

However it makes more sense to integrate these changes in to a fully new transfer scheme.  I have not yet reflected upon what may be desirable but the Internet has developed far beyond a mere collection of hyperlink text documents that need a transfer protocol.  A more generic Information or Resource Transfer Protocol might be the next logical name as it would service more complicated exchanges of information.  

It would be nice to clearly articulate aspects of the transferred data, such as if it represents a single entity, a collection of delineated resources (eg: pre-packed tar/zip/etc/some kind of minimal easy to decipher multi-stream transport), if the content is generated output (and if so, for how long to anticipate that the same query would yield the same results), also actually requiring client implementations to differentiate session authentication state from re-authentication data.  Thus clients can reliably log out (invalidate authorization) without invaliding stored authentication information.
In my opinion if the standardization aim toward adoption of SRV record we can make it fallback like socks4a.

Just assign an ip address to use as "look for srv" command. (or use deliberately wrong ip address)
Since a hostname can has multiple A records it will compatible with all current clients with "client retry" feature.

About the latency issues I think we shouldn't worry much in SRV record case.
Since SRV record already introduce latency everywhere. The person who deploy it must know the trade off.
- SRV record already introduce DNS roundtrips because it likely make a big DNS response.
Since UDP DNS response was limited to 512 bytes client will retry query DNS with TCP (which also require roundtrip) anyway. if we adopt "look for srv" command method we can eliminate UDP query for SRV record (because it tend to exceed 512 bytes ***in assumption that if SRV record is widely adopt it will be deployed by all services not just HTTP)
- SRV record already use fallback method in design so it's already slow.
for example: if someone setup 5 servers as http servers and use SRV record to prioritize the http servers. How many seconds took for a client to reach fifth server?

And like what someone else said if SRV record was adopt widely enough the recursive DNS server will eventually update their algorithm to include SRV as additional record when required.
Labels: -Mstone-X Restrict-AddIssueComment-EditIssue
Status: WontFix (was: NULL)
I think here, Comment #25 is going to apply. Closing this as WontFix - we are not doing anything to support SRV and won't be anytime soon. Exploring the handling of URIs is best discussed in a standards body like IETF and then driving multiple browsers' interests.

There is none such yet.
Cc: ojan@chromium.org
 Issue 777157  has been merged into this issue.

Sign in to add a comment