6

Basically I need for DNS to respond with different CNAMES depending if the request was made for HTTPS or HTTP object.

s.test.com -> IF(https) RESPONSE special.domain.com ELSE simple.domain.com

Is it possible? What other possible ways to do that?

cyberhicham
  • 202
  • 2
  • 13
Jim
  • 410
  • 4
  • 14
  • 3
    Your solution would be to have the http server send all https requests to the special.domain.com – HTDutchy Jan 17 '13 at 14:56
  • 1
    This would also require all DNS clients to cooperate; standard DNS clients do not include the application. Hence, there is no way that the DNS server could respond differently, even if you could modify the DNS server. – MSalters Jan 18 '13 at 08:11
  • @MSalters - DNS is already used to discover mail services, via MX records. And it would certainly be possible to write web clients which looked for and used SRV records to find HTTP/HTTPS services (see my answer). – Peter Jan 19 '13 at 17:36
  • @Peter: Discovering services is not the same as resopondig differently depending upon the protocol that is making the NS request. – user9517 Jan 19 '13 at 18:05
  • @Iain - I'm not assuming that Jim has stated his question perfectly & completely. So the usefulness of the answer hinges on what Jim is actually assuming about the behavior of the DNS "client" and the DNS "service". What a web browser does, after all, for http:// URLs is very different from what it does with mailto:// URLs. And although web browsers typically handle http:// and https:// URLs by doing a simple name lookup for the FQDN, there's no reason they *have* to behave this way. – Peter Jan 19 '13 at 20:52

9 Answers9

43

No.

DNS is not aware of HTTP or HTTPS.

Compare it to asking for secretary the phone number (IP number) for someone. You will get the same reply, no matter what you wanted to ask the person on the other end.

Hennes
  • 4,842
  • 1
  • 19
  • 29
  • 1
    +1 - Nice way of putting it. I like the "...no matter what you wanted to ask..." bit. I think I'll use that. – Evan Anderson Jan 18 '13 at 04:09
  • 1
    You're overlooking the fact that DNS is already used to discover mail services, via MX records. And it would certainly be possible to write web clients which looked for and used SRV records to find HTTP/HTTPS services (see my answer). – Peter Jan 19 '13 at 17:38
26

This isn't possible with DNS. The DNS request is completely independent of the reason for the request.

For this to be possible, the entire caching system for DNS would have to be scrapped. DNS would also have to be rewritten every time a new scheme was invented.

What are you trying to do? There might be a better way to solve your actual problem.

Ladadadada
  • 26,337
  • 7
  • 59
  • 90
  • I have 2 CDNs and I want for one to server HTTPS traffic and the other the HTTP traffic – Jim Jan 17 '13 at 13:40
  • 2
    And why do you want one to serve HTTPS and the other to serve HTTP? We're aiming for the *root cause* of this problem because that's the best problem to fix. – Ladadadada Jan 17 '13 at 13:46
  • Because the provider with the small network supports SSL for custom cnames and the provider with the huge network does not. Any ideas? – Jim Jan 17 '13 at 14:00
  • 4
    So, assuming that the small network is not big enough for your traffic and that SSL is necessary, the two solutions I can see are: 1. using a different domain or subdomain for your SSL traffic or 2. Finding a third CDN provider that is large enough *and* supports SSL for custom domains. Would [Google AppEngine suit your needs](https://developers.google.com/appengine/docs/ssl)? – Ladadadada Jan 17 '13 at 14:11
  • 1
    Although shopping questions are off topic, [there's a question on CDN providers that do SSL for custom domains here already](http://serverfault.com/questions/242103/cdn-that-supports-custom-ssl-over-custom-domain) that has some companies and prices. – Ladadadada Jan 17 '13 at 14:18
  • Don't be melodramatic. DNS is already used to discover mail services, via MX records. And it would certainly be possible to write web clients which looked for and used SRV records to find HTTP/HTTPS services (see my answer). – Peter Jan 19 '13 at 17:37
  • 1
    @Peter SRV records are a nice theoretical solution to this problem but not a practical one. Web browsers don't currently use SRV records and it doesn't look like they're going to any time soon. Once we dug down to the root cause of this problem, a solution became evident that can be implemented today. – Ladadadada Jan 19 '13 at 22:52
  • 1
    @Ladadadada - You're right, digging down always gets to the most useful answer. I hadn't carefully read all the comments on your answer before posting mine. A clarification of the original question at this point might be helpful to folks who run across the question in the future. – Peter Jan 19 '13 at 23:58
11

As everyone has mentioned, you can't do this with DNS. I think this is typically done with URL redirects. For example, if you're using Apache as your Web Server you can do set up redirect rules with mod_rewrite. Then you can write rules like:

# If HTTPS redirect to special.domain.com
RewriteCond %{HTTPS} =on
RewriteRule .* https://special.domain.com%{REQUEST_URI} [R,L]

# If not HTTPS redirct to simple.domain.com
RewriteCond %{HTTPS} !=on
RewriteRule .* http://simple.domain.com%{REQUEST_URI} [R,L]

Here are some more examples: http://www.askapache.com/htaccess/ssl-example-usage-in-htaccess.html

dough
  • 316
  • 1
  • 3
7

I'll give you the benefit of the doubt and assume that:

  • You're familiar with the OSI model, and the fact that DNS, HTTPS, and HTTP are all application level protocols.
  • You understand that protocols must be independent (both across layers and within layers) in order to be useful.

I therefore take your question to mean that you're wondering if there is an HTTP/HTTPS analogue in DNS to the MX (mail exchange) resource record (RR) among the resource record types supported by DNS.

This appears to be the purpose of the SRV (service) record type, described in RFC 2782. although it appears that LDAP, SIP, and XMPP services are more commonly advertised this way via DNS.

The reason for this appears to be historical: SRV records were proposed, implemented, and deployed only after HTTP was proposed, developed, and deployed. For some discussion about why it may not be a good idea to use SRV records to advertise HTTP/HTTPS at this point, see this question.

Community
  • 1
Peter
  • 171
  • 4
  • This was my initial reaction at an answer, too: `SRV` records. However, much like you point out, few clients ask for them, so other than for specialty purposes, they are largely unused. – user Jan 18 '13 at 08:32
5

No, DNS doesn't know (or care) which protocol is requesting the lookup.

user9517
  • 115,471
  • 20
  • 215
  • 297
  • You're overlooking the fact that DNS is already used to discover mail services, via MX records. And it would certainly be possible to write web clients which looked for and used SRV records to find HTTP/HTTPS services (see my answer). – Peter Jan 19 '13 at 17:43
  • @Peter: No I'm not. Read the question, he wants different responses depending on whether it's https ot http requesting the name. SRV and MX records have nothing to do with protocols requesting the NS lookup. – user9517 Jan 19 '13 at 17:53
  • It depends on what you mean by "https or http requesting the name". It's the browser's job to take a URL - including the prefix (which could be http, https, ftp, or mailto), the FQDN, and path - and figure out what DNS query(ies) is(are) relevant. There's no reason a priori that the IP address & port for one FQDN + service pair has to be the same as the IP address & port for the same FQDN with a different service. That's how MX records work. – Peter Jan 19 '13 at 20:45
  • @Peter: Browsers don't work like that though - I really don't see (in respect of the question) what the point is you're trying to make. – user9517 Jan 19 '13 at 20:48
  • You're right that most browsers don't use SRV records, and although this isn't the fault of DNS itself, perhaps I'm being obtuse in pointing out that the original question doesn't indicate what behavior *is* expected from the client side. IMO this would be remedied of some of the comments on Ladadadada's answer were replicated in the original question. – Peter Jan 20 '13 at 00:06
3

I don't know of any, but if you have control of the web server on the other end, you could redirect to a different domain (or have a different vhost) depending on whether it is using ssl or not.

lsd
  • 1,673
  • 10
  • 10
2

As already mentioned, basic DNS does not do this. However, if you control the client (i.e., it's software that you code and distribute), you could use SRV records:

http://en.wikipedia.org/wiki/SRV_record

So if you want one response for HTTP and another for HTTPS, you would put something like the following in your DNS zone record:

_https._tcp.s.test.com. 86400 IN SRV 0 5 443 special.domain.com.
_http._tcp.s.test.com.  86400 IN SRV 0 5 80  simple.domain.com.

So a DNS client that looks for the https/tcp service for the the "s.test.com" record gets a response back saying the service is on host special.domain.com, port 443. A DNS client that asks for http/tcp for "s.test.com" gets back a response saying host simple.domain.com, port 80.

The "0 5" are priorities/preferences so that you can do round-robin if you have multiple hosts for the same service (special1, special2, ...; simpleA, simpleB, etc.).

Most software (e.g., web browsers) don't look up the SRV records, only A records.

DAM
  • 21
  • 1
0

Since you put load-balancing tag in your question, I have to mention that load-balancing by port (http is 80 and https is 443) is the easiest thing you can do.

Moreover, you can add another level of load balancing by virtualhost (http) or SNI (https).

Other than that, this question is already well-answered.

0

No. As others have mentioned, that is not the name server's responsibility.

However, you could modify your application to detect the protocol (HTTP or HTTPs) and provide its links accordingly.

Here's an example. Let's say you have a Web Page that displays multiple images. You may want to link these images to your HTTPs CDN when the Page is viewed using HTTPs and you may want the page to use your HTTP CDN when the page is accessed using HTTP. Use a dynamic web application to check the protocol and replace all links accordingly.

Kurtis
  • 101
  • 1