13 ms·
Some clients use SRV lookups, a few (to their embarrassment) do not (2009)
- andrewstuart2 8y agoThere'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 8y agoCA 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.
- deleted 8y ago[deleted]
- CKN23-ARIN 8y agoWhy is it that the CA can expect no tampering? It seems to me that it would not be hard for certain classes of attackers to MitM a CA.
- miniflux 8y agoCan you elaborate this MITM attack? How would it work?
- fulafel 8y agoLocal network tampering (ARP etc) at registrar end, routing attacks such as BGP hijack, below-IP attacks in transit (eg MPLS hijack, malicious transit router, QUANTUM INSERT, other fiber tap approaches, ...) DNS implementation bugs in UDP spoofing countermeasures, local network tampering at domain holder end, social engineering or extortion against transit or stakeholder sysadmins, etc. It's a long list of possibilities.
- Arnt 8y agoRight. Which ones of those leave the signatures on root zone, the .com zone and the cert unaffected and are transparent in any real sense of the word?
- viraptor 8y agoCAs should be able to afford to make the requests from multiple sources and compare the results. Alternatively they can use secondary challenge-response auth which depends on some credentials being deployed to your server. Mitm-ing it wouldn't give the attacker anything interesting in that case.
- skissane 8y ago> CAs should be able to afford to make the requests from multiple sources and compare the results. Do they actually do that in practice? Are they required to do so? (How many sources and how far distinct?)
- CKN23-ARIN 8y agoTo test this, I just now acquired a Let's Encrypt cert using `certbot certonly` while tailing the logs. I received only a single request, from 64.78.149.164. The cert was issued. They did not appear to take a second measurement.
- zaarn 8y agoOn your DNS or on your webserver? Did you use a fresh domain or a domain that has been previously seen in DNS?
- CKN23-ARIN 8y agoOn my webserver (http-01 challenge type). Fresh hostname. Fresh VM. Fresh certbot install.
- shawnz 8y agoThat's not a DNS challenge.
- peterwwillis 8y ago
- miniflux 8y ago> User can't expect that his DNS is reliable. Yet both the user and DV certificate issuers rely on the same DNS that you consider unreliable. So you seem to dismiss DV certificates altogether but your comment seems to imply that you only want to dismiss certificates as DNS records. There's something very inconsistent about your comment.
- lathiat 8y agoThat inconsistency is that users are generally on much less trustworthy networks and DNS right now is rarely authenticated (DNSSEC is not wide spread and even then most clients don’t authenticate it) While not perfect it’s generally quite true for the majority case.
- phicoh 8y agoActually, a large number of hosts are behind a DNSSEC validating resolver. And that's because the use of Google's public resolvers is extremely wide spread. I don't know if they document it somewhere, but it is essentially trivial for letsencrypt to use a DNSSEC validating resolver. So that means that if you care about DV security, you enable DNSSEC.
- tptacek 8y agoDNSSEC doesn't protect the connection between a browser and Google's DNS server. Attackers can simply edit the responses generated by Google's DNS. Moreover, virtually nobody signs their domains with DNSSEC (why would they? It's all downside.) So CA's can't require DNSSEC, or depend on it being there. You can enable it, but it's pointless, because the attack against DV that DNSSEC is meant to prevent can be launched whether or not you enable it. DNSSEC has essentially no practical impact on DV.
- phicoh 8y agoIf we are talking about obtaining DV certificates, then why do you bring up the connection between a browser and Google DNS? The good thing about Google doing DNSSEC validation that on average zones can either be unsigned or need to have valid signatures. By signing your own domains with DNSSEC and assuming CAs do DNSSEC validation you can protect your own domains from malicious DV certificates. That's a nice feature. If you don't like DNSSEC, nobody is forcing you to sign your zones. I can still sign my zones even if you don't sign yours. The next step would be for CAs to honour DANE records.
- lucb1e 8y ago> 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 8y ago> 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 8y agoWhat 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 8y agoI’m pretty sure AWS Certificate Manager does this.
- vbezhenar 8y agoAttacking server infrastructure is order of magnitude harder than attacking user. Those who can do this attack, can just ask their CEO to issue them a certificate via subpoena.
- deleted 8y ago[deleted]
- peterwwillis 8y agoMost of the things that are "curious" about DNS I think comes from its lack of a version. DNS has no version, so it has no obvious way to extend itself by allowing for graceful upgrades. So you can't just change behavior and have clients support a particular version. Everything has to be backwards compatible with something written in 1984. The only serious attempt at extending DNS died because the specs and DNS admins allowed the extension mechanism to be optional. Now, most networks break the extension, and the DNS just limps along because nobody is willing to implement a sane upgrade path.
- tonyg 8y agoQuery opcodes 3 and 6 through 15 are unassigned [1]. Middlebox brokenness aside [2], a completely new payload could be placed behind a header 0000 7800 0000 0000 0000 0000 Public DNS installations already have to deal with getting unsolicited random crap, so the risk of fatal confusion is low. [1] https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-5 https://www.iana.org/assignments/dns-parameters/dns-paramete... [2] Middlebox brokenness is probably the biggest issue with extending or upgrading DNS, though, I suppose
- peterwwillis 8y agoAnd the middlebox brokenness is due to a lack of versioning. Virtually all middlebox brokenness is a result of a lack of versioning and poor upgrade paths - usually from people demanding backwards compatibility above all else.
- tonyg 8y agoI view it as more of a consequence of "fail closed" thinking than a lack of versioning. As we've seen recently with TLS [1], even protocols with explicit versioning suffer from middlebox brittleness. [1] https://news.ycombinator.com/item?id=17298747 https://news.ycombinator.com/item?id=17298747
- throwaway201862 8y agoThere is, it's called a TLSA record: https://tools.ietf.org/html/rfc6698 https://tools.ietf.org/html/rfc6698
- Promarged 8y ago> put my own domain-specific CA Cert in DNS directly. Remember that this allows any of your government or people controlling the zone to transparently put the cert there too. (For potential problems see [0]). With the CA system (that I personally also don't like) at least the certs are logged in Certificate Transparency logs so you see any potential attacks. [0]: https://www.theguardian.com/technology/2010/oct/08/bitly-libya https://www.theguardian.com/technology/2010/oct/08/bitly-lib...
- Arnt 8y agoCan you elaborate? AFAICT, anyone who controls .com can add or replace a cert for ycombinator.com, but only visibly. If they do it, they show the change to the entire world at once, because .com is signed with dnssec. Right?
- tialaramex 8y agoYour parent mentioned Certificate Transparency. Under CT all the public CAs log certificates they issue, and everybody can see the logs, programmatically (with cryptographic security) or via a log monitor like crt.sh So yes, bad guys operating a TLD can trick a CA into issuing for a domain under theirs, but the CT logs would preserve evidence of this cert existing, and the CA is required to keep records of why it was confident to issue. Monitors would know about the cert in 24 hours (usually much less)
- tptacek 8y agoThe idea behind the attack they're talking about is that the USG has de jure control over .COM's DNSSEC keys, and so they can in fact edit .COM transparently.
- tialaramex 8y agoDNS is actually the least sketchy component in the DV story. Until about a year ago the situation was that each CA could do anything they (without even peer review) thought seemed good. Then we got the Ten Blessed Methods, a specific list of ways to verify that your subscriber really controls the names they want a cert for. Most of the Blessed Methods involve DNS, but not all of them, some are relying on paper documents, some use WHOIS and out of band communications (e.g. Fax!). And of those which use DNS, many involve even less secure elements, email, plaintext HTTP, that sort of thing. So there's still work to do, but we're headed in the right direction.
- inopinatus 8y agoThere 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 8y ago> 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.
- JdeBP 8y agoEnjoy https://news.ycombinator.com/item?id=14721416 https://news.ycombinator.com/item?id=14721416 . (-:
- mehrdadn 8y agoRemote 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.
- JdeBP 8y agoFor 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 8y agoOK, 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 8y agoI 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.
- amaccuish 8y agoIt 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 8y agoIt 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.
- deleted 8y ago[deleted]
- pas 8y agoI'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.
- lucb1e 8y agoYou can put in multiple queries in a single packet. It's just that the response header would be ambiguous (a NODATA status could refer to any one of your queries) and therefore not even a minority of clients or servers support this. It's right there in the protocol, we just need to figure out how to signal NODATA/NXDOMAIN/SERVFAIL/... for each individual query.
- exabrial 8y agoHaving 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.
- solidsnack9000 8y agoIs SRV part of the problem in your view?
- inopinatus 8y agoI think they're saying that address records are part of the address-exhaustion problem. If we used SRV records instead then the port numbers become available for service endpoint discrimination, and this is a 16-bit space as alluded to. If adopted some time back this would indeed have conserved IPv4 address space; certainly there would have been far fewer 1:1 assignments for SSL termination, and a public cloud load balancer would be able to handle many distinct customers on a single IP address and so on. In practice there'd be some introductory issues in deviating from the well-known ports involving gateway traversal (particularly corporate firewalls), but we've cleared such hurdles before.
- exabrial 8y agoNo I'm saying the opposite, SRV was a a potential cure
- axaxs 8y agoIPv4, 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.
- exabrial 8y agoI think you missed my point, so I'll explain another way because I think it's important to make. If you look at the TCP packet, bits 16-31 are constant for all HTTP traffic. Because they are a fixed value, they're wasted (non-unique). With the current system, we can only have 2,147,483,647 web servers. Using SRV records, these bits become distinguishable, giving us 281,474,976,710,656 possible addresses for web servers. [Yes this is an oversimplification for the pedantic]
- nickodell 8y agoI 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 8y agoI am not sure to whom embrassment this is. I prefer my http server fast, works over firewall and less depends on other services.
- fuzzy2 8y agoHm. 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.
- Qwertie 8y agoSRV lookups for http would have been great as some ISPs block well known ports.
- a1r 8y agoFun fact: the Minecraft client has for years supported SRV to discover the server port number. Thanks Notch.
- JdeBP 8y agoThank you.
- ben0x539 8y agoJust 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?
- sneak 8y agoA big one: client-side load balancing allows for the removal of the last SPOF for most websites: the IP(s) of the load balancer(s) to which the A record(s) point to. A second one: deploying TLS websites used to require one ip per hostname, and presently requires weird hacks like SNI (which leak the hostname to which one is connecting to observers). Being able to deploy any website on any port allows for a lot more flexibility in deployments, especially given the current trends such as “serverless”, k8s, et c.
- ben0x539 8y agoHm, I don't quite understand, if I have multiple A records, is it still a single point of failure? Could you clarify the difference between having a bunch of SRV records and a bunch of A records here?
- JdeBP 8y agoIf your client recieves multiple A/AAAA resource records, your client has no way to know what order they should best be tried in, from the server's point of view, and there is no way for the content DNS server to transmit that information. * http://jdebp.eu./FGA/dns-round-robin-is-useless.html http://jdebp.eu./FGA/dns-round-robin-is-useless.html Note that making priority and weighting available is given in the rationale section of the original RFC from 1996. What you're talking about actually isn't specific to HTTP. * https://tools.ietf.org/html/rfc2052 https://tools.ietf.org/html/rfc2052