
Some clients use SRV lookups, a few (to their embarrassment) do not (2009) - dedalus
https://jdebp.eu/FGA/dns-srv-record-use-by-clients.html
======
inopinatus
There already is a SRV service name reservation for both http and www-http,
with Tim Berners-Lee as the contact name. Fun fact: using DNS address records
("A" or "AAAA") for endpoint name resolution in HTTP is a convention; it is
not required in the standard or in any of the normative references. Web
services do not own the address record and should never have been using it in
the first place. Nonetheless they continue squatting addresses in a de facto
assertion of unwarranted privilege, and every other use of the DNS has to
steer carefully around.

When SRV is discussed e.g. on the HTTP/2 list, the objections of resolution
speed and number of round-trips are usually raised. But SRV records do not
intrinsically require an additional lookup or round trip. Unoptimised zone
configurations (especially those that slice at _tcp, which occurs at some
Microsoft shops) may fare less well, but that is true of all DNS
configuration. Services that care about resolution speed already optimise
their DNS as necessary, and they would for SRV as well if it were mandated.

In practice, the reasons for non-adoption are, mundanely, simply a matter of
inertia, combined with a lack of motivation: the browser vendors who in
practice write the HTTP standard do not care to change and have no external
force that will push them off overloading the address record.

~~~
bluejekyll
> number of round-trips are usually raised

I think you allude to this with your comments on optimization, but DNS
resolvers will generally, just like CNAMEs (which nearly all DNS names begin
with these days) will return additional records to reduce any round-trips for
getting the record at the end of the SRV.

SRV records are great, and would reduce antiquated reliance on ports for
specific services. This would be helpful for HTTP, especially with things like
TLS, where certs cold be returned without SNI being used.

------
andrewstuart2
There's a couple things about modern DNS that just doesn't make sense. There's
probably a good explanation buried somewhere in a mailing list or three.

The other one that still astounds me is that DV certificates rely entirely on
DNS control for validation prior to issuance, and browsers trust that system,
but there still exists no way for me to cut out the middle man and put my own
domain-specific CA Cert in DNS directly.

~~~
vbezhenar
CA can expect that its connection to your DNS server is reliable and not
tampered. So their check is reliable. User can't expect that his DNS is
reliable. So HTTPS must work with those conditions: when user's DNS server
might be controlled by bad actor. DNS security is supposed to solve that, but
it's not widely used AFAIK.

~~~
lucb1e
> CA can expect that its connection to your DNS server is reliable and not
> tampered

Why? It goes over infrastructure that you nor they control.

It might be worth illustrating what happens here, as it's not immediately
clear from common DNS settings or common commands. First, the client asks
their local DNS server, the one you get via DHCP or configure (for example
8.8.8.8 which is by definition already outside your network, but for
argument's sake let's assume that they're smarter than that and they pick one
inside their own network). Let's say this one doesn't have it in cache, so
then it has to go out and ask the TLD (let's assume it has the TLD cached).

The TLD, for example `.com`, will say "the name servers for your.example.com
can be found at ns.your.example.com" and it gives the IP addresses for those.
Now the local resolver at the CA has to go and ask there for your domain. In
this final step, if nowhere else, it will have to leave any sort of trusted
network and venture into whatever place the user's servers are at. This could
be anywhere in the world, with all sorts of intermediate networks.

~~~
geocar
> Why? It goes over infrastructure that you nor they control.

They're able to use many secret locations to perform the query.

There is a theory that it is very unlikely an attacker can detect and get
leverage over every network between every one of those secret locations for an
indeterminate amount of time, without being discovered.

~~~
jessaustin
What you describe is a possible technique that CAs could use, so let's
stipulate that some CA does this. We certainly can't conclude that all or even
many CAs do this.

~~~
cormacrelf
I’m pretty sure AWS Certificate Manager does this.

------
exabrial
Having service location be at the TCP/IP level is a major contributor to the
IPV4 crisis. We have 48 bit addresses, but 16 of those bIts are relatively
unused.

Rather than solving the problem the pragmatically (and in a backwards
compatible way), we're pushing a reinvention of the wheel (protocol).

IPv4 certainly has problems but I think they were solvable without bisecting
the internet.

~~~
axaxs
IPv4, don't get me wrong, I like much more than IPv6 for many reasons(128
bits? Overkill). There are more people on Earth than ipv4 addresses, you can't
solve that problem without heavy NATing, which has its own drawbacks.

~~~
bluejekyll
I disagree that 128 bits is overkill. Most networks are devided between 64bits
for public routing, and 64bits for internal routing.

The network space is huge, but segmented. At each branch of the network, you
reduce your addressable space significantly.

When you think of the future, and huge interconnected small devices, I don’t
think 128 bits are going to seem excessive.

Remember, when they came up with 32bits for IPv4, they were not planning for a
computer (or multiple!) in your pocket that was going to be network routable.

~~~
axaxs
To play devil's advocate, there are not enough raw materials on earth to
produce close to the amount of necessary devices that would fill the ipv6
space. I can be convinced that this large amount has other benefits, but not
that this number of IPs was needed for futureproofing.

~~~
jchw
Well, there's a couple other considerations. For one thing, some devices may
have multiple IPv6 addresses - perhaps even entire slices of it. For another,
having additional bits to work with allows people more room to divide their
subnets into future-proof chunks without risking ever running out of IPv6
space - something IPv4 could never really afford in the first place. What
would be considered large chunks of IPv4 are a drop in the bucket in IPv6.

I think the main idea is that you want to have plenty of space both for
growing horizontally _and_ vertically, at least enough to where you can't even
imagine exhausting it in either direction. Giving massive private and public
address space without need for NATs effectively provides this.

Also, hey, who knows. There isn't enough raw materials on Earth, perhaps, but
maybe there are enough raw materials in the universe. Who knows for sure if
the Internet always be confined to just Earth.

~~~
AstralStorm
Unless you get faster than light communication, the interplanetary protocols
will require advanced collision handling which TCP does not provide anyway,
and all kinds of "on-line" access will be impossible due to light lag.

------
mehrdadn
Remote Desktop really needed to use SRV. It's just so much more convenient to
be able to connect to foo.example.com and have that bind to example.com:12345
when all you have is 1 IP address.

------
ben0x539
Just from the article and some of the comments here, it's not quite clear to
me what the motivation for making HTTP use SRV records is. To me, naively, it
seems like relying on A/AAAA records a) "works", and b) is central to a lot of
people's intuition of how networking services function.

Following some of the links in the article, I've seen people make arguments on
how straightforward it would be to implement and how it clearly works well for
some non-HTTP systems. I'm guessing there's some implicit shared understanding
of the problem space that I, as an uninitiated, casual DNS user, can't really
wrap my head around.

Can y'all point me in the right direction to read something about, like, what
problems SRV records solve for HTTP, and specifically how that solution
compares to how people have traditionally solved those problems with HTTP?
There seems to be some tension between best practices as established by IETF
RFCs and best practices coming from decades of deploying public-facing HTTP
infrastructure/browsers, does that sound about right?

~~~
LinuxBender
For web browsers, multiple A/AAAA are sufficient. Web browsers worked around
the issues folks are mentioning some time ago using retries to each IP.

The use of SRV could help in newer API driven implementations so that scripts
and other tooling could enumerate which IP's are preferred. For now,
developers will just have to make use of multiple records like the browsers
do.

That said, it won't likely happen because the HTTP spec does not allow new DNS
implementations. The RFC would have to be deprecated with a new one that
permits SRV. HTTP/2 would have been a grand opportunity to do just that. There
have been many discussions [1] and debates on the issue, but I do not foresee
it happening.

[1] - [https://www.ietf.org/mail-
archive/web/httpbisa/current/msg25...](https://www.ietf.org/mail-
archive/web/httpbisa/current/msg25379.html)

~~~
inopinatus
HTTP protocol & normative references don't actually mention DNS at all.

The hand-wringing evidenced by some about the difficulties of introducing a
new behaviour seems pretty feeble when you consider that Google has
successfully intruded both a new transport protocol (QUIC) and a new
application layer protocol (HTTP/2 i.e. SPDY) in a few short years. Rolling
browser updates are now the norm and enable these major changes.

~~~
LinuxBender
Agreed, but the protocol does not allow for deviation without creating a new
protocol; which to your point, Google did. Google could have introduced SRV
records as optional components in the spec. So the lack of mention of DNS
standards in the protocol is sufficient to block the implementation of a new
DNS requirement.

Browsers are not the only thing that speak http. There are a myriad of
libraries used by API's and all manor of automation that must also be updated
to support a new protocol. A good example of this is SNI. All major browsers
support SNI, but there are plenty of libraries that have yet to catch up to
that very well aged protocol.

~~~
inopinatus
Funny thing is, TBL anticipated this years ago when registering the service
names. Read the assignment notes at [https://www.iana.org/assignments/service-
names-port-numbers/...](https://www.iana.org/assignments/service-names-port-
numbers/service-names-port-numbers.xhtml?search=http) \- yes it's talking
about DNS-SD specifically but the remark generalises to all service discovery,
basically setting the expectation of different service names based on intended
use.

API endpoints tend not to be apex records, indeed are characterised by using a
label of "api" or similar which doesn't automatically conflict with other
services, certainly not in the common case. It'd remain a violation IMO to use
a host name as a service selector but in practice they could continue using
address records for many years of transition.

------
JdeBP
For what it is worth, that is not actually my title, and the answer does deal
with a lot of things _other_ than that subject including the many things that
one can discover _do_ use SRV resource record sets.

Enjoy a related discussion of some poor FTP clients:

* [http://jdebp.info./FGA/web-browser-ftp-hall-of-shame.html](http://jdebp.info./FGA/web-browser-ftp-hall-of-shame.html)

~~~
dang
OK, we've changed the title to yours, shortened a bit to fit the year in. What
year was this written, by the way? It's a bit hard to tell.

(Submitted title was "Why Dont HTTP Clients Use DNS SRV Records?")

~~~
JdeBP
I try to keep the Frequently Given Answers up to date, occasionally revising
them as I learn new stuff and people tell me stuff. I'm going to trust my own
footer information (-: and not check with the Wayback Machine. So first
published in 2004 but revised over the years since.

------
fuzzy2
Hm. Sounds great and all, but there’s a catch: All “managed” networks
(corporate, schools or otherwise) are built on the fact that port 80 means
HTTP and port 443 means HTTPS.

I don’t see SRV in use for browsers, ever.

------
a1r
Fun fact: the Minecraft client has for years supported SRV to discover the
server port number. Thanks Notch.

~~~
JdeBP
Thank you.

------
amaccuish
It would be great if you could do a DNS lookup, and in the request, say I want
x record types for y name. Like, give me A, AAAAA, CNAME and SRV records for
apple.com. I guess there's opportunity for abuse, but I think it would be
better than ANY.

~~~
JdeBP
It would be better than ANY for starters because "any" does not mean "all".
(-:

* [https://news.ycombinator.com/item?id=14720919](https://news.ycombinator.com/item?id=14720919)

Of course, if we _were_ redesigning the DNS protocol (which for what you want
would be necessary, given how questions are structured) I would suggest being
far more radical and not structuring things in terms of separate A, AAAA,
CNAME, and SRV resource record sets in the first place; but rather in terms of
<domain,transport,service> tuples and <priority,weight,address,port> tuples,
as getaddrinfo() roughly is. Query goes out with <example.org,tcp,https>, full
answer response comes back with a prioritized and weighted set of IPv4 and
IPv6 addresses and port numbers (possibly with intermediate domain names, if
one wanted to keep that concept in a redesigned protocol, which one possibly
would not) all together.

~~~
pas
I'm wondering, is there support for multiple queries in one request in DOH
(DNS over HTTPS)? Currently that looks like where browsers are most likely to
try new things.

------
Qwertie
SRV lookups for http would have been great as some ISPs block well known
ports.

------
nickodell
I think this page needs more explanation of the motivation behind this
request. Why should browser vendors give a shit?

Yeah, it's a standard, and at least three people want to use it, but what
else?

------
j16sdiz
I am not sure to whom embrassment this is.

I prefer my http server fast, works over firewall and less depends on other
services.

~~~
JdeBP
Perhaps some of the embarrassment belongs to those who get _server_ and
_client_ confused. (-:

~~~
perl4ever
The usage of "server" and "client" is traditionally confusing.

See:
[https://en.wikipedia.org/wiki/X_Window_System](https://en.wikipedia.org/wiki/X_Window_System)

~~~
JdeBP
Not really. That's the odd one out in that respect, and is not even a part of
this discussion.

