Windows 2012 r2 DNS forward a record www.domainname.com to https://domainname.com

Are you using the same name from inside your network as the name purchased for the SSL certificate?
SSL will only work if the name requested matches the name on the certificate.

DNS is not responsible for HTTP forwarding.

You need to add a web server in the path to handle forwarding from one name to another.

Hi Colin_UK; i am using the same domain name inside en outside. The https certificate is working ok (installed by the website builder)

Hi Chris,

Does this mean that i need to build a website in IIS en forward this to https?

Or is there a simpler workaround?

I may have misread, the name you're using inside and outside is identical? If so, scratch my comment as irrelevant, no need to forward if you don't need to change the name.

Chris; only the domainname.com is the same inside the organization as the outside.

That's why it is needed to create a forwarding lookup zone domainname.com to point to an external ip address for www

Can I ask why you need the internal DNS to give you the IP? Is it because you're using a public domain name within your LAN Domain? and thus redirecting www to elsewhere?

If this is the case you might have a re-direction problem. A lot of sites (especially CMS based) redirect visitors from www.domain.tld to the shorter (and more poular lately) domain.tld. If this happens and you are using a LAN based DNS to give the correct IP it will also need to provide the public IP on the base domain name (ie: often indicated as @ or parent domain).

Colin

Hi Colin: because it cannot resolve the www internally (it is hosted external)

Colin: How to accomplish this in DNS?

Loop back to the beginning a minute. What do you get if you lookup www.domainname.com outside? A single IP? A CNAME?

When you're inside your network, are you able to telnet to TCP/443 of the IP? You don't need to complete the SSL exchange for that so it's not at the level of dealing with certificates.

Essentially if you have two names and they both end up at the same IP it should just work.

Chris: outside i get www.domainname.com and ip address. telnet says: network error: sofwtare caused connection abort (putty)

That suggests you might be hitting a firewall. The same approach should work outside your network to confirm it's not a universal problem.

Chris: The same error on the outside network on port 443 telnet

My question now is understanding why DNS resolution does not work from inside the LAN.
Have you physically blocked external name resolution? Is this a restricted network (ie: are firewall rules needed for both internal & external traffic)? Do you need to setup local DNS responders for all public website access (ie: www.google.com)?

Colin

Hi Colin; the forward worked before when there was no https:// in front op www.domainname.com

Since the https:// (created by the website builder) it is not working anymore.

There are no special rules configured in the firewall.

But you can visit the site using https://www.domainname.com?

This PowerShell command will drop all of the application overheads, most like telnet / exit.

try {
    $tcpClient = New-Object System.Net.Sockets.TcpClient
    $tcpClient.Connect('www.domainname.com', 443)
    $tcpClient.Close()

    Write-Host 'Success'
} catch {
    Write-Host 'Failed'
}

Select allOpen in new window

Just in case it's PuTTY being helpful.

Chris; from inside the network I can't visit the https://www.domainname.com but from external no problem

Okay, but you've fixed name resolution so both end up at the same IP address now by virtue of your changes in DNS. By extension, the "telnet" style tests to TCP/443 should work outside at the very least.

That should also mean you can "nslookup www.domainname.com" and end up with the same IP (inside and outside).

If both resolve, and it works outside but not inside it depends on the exact nature of the error message. That is, a connection timeout, or a certificate error, or something else.

Perhaps a silly question as I just quickly read through the previous comments, but did you add an alias record (CNAME) for www to the forward lookup zone?

Understand that DNS is used for name based resolution.  So the name, in your case www, points to an ip address that is external to your network.  If www actually lives on your network then you want to have the record point to the local ip for your client resolution and not the external address (loopback issue).

The reason you are doing this is because your internal and external domain use the same TLD (mycompany.com).  Since you have an internal DNS server that manages the name resolution for mycompany.com, your clients can't hit www.mycompany.com because the host www exists outside the management scope of your internal DNS server (it is literally unknown to your server and therefore your clients).

With regards to the certificate, the certificate is issued (and bound) to the host address of the website.

-saige-

Chris: both are resolving.

Hi it_saige, i did not add an cname record?

CNAME vs A won't make any difference at all. The problem is not DNS if you have a name resolving to a correct IP.

Expected them to, you did say you'd added the entry. Everything now depends on what happens when the HTTPS request attempts to establish. Starting with "telnet" is good because it sorts out everything up to Layer-4 on the OSI model.

If the telnet type tests fail it might be because there's a firewall or proxy sitting in the path. At that point we might need a slightly different approach.

It is critical you find out exactly why you're getting an error in the browser.  Browsers are wonderful at showing users stuff, the downside is that debugging information is hidden to a large extent.

Is the initial TCP connection working?
Is an SSL exchange beginning?
Is the SSL exchange completing?
Is the web server throwing some other error message after SSL completes?

To give me a clearer picture of your landscape, I am assuming something like this for your internal DNS server:

DOMAIN.COM
(same as parent folder)            Name Server (NS)      DC1.DOMAIN.LOCAL
DC1                        Host (A)            192.168.0.10
MYWEB                        Alias (CNAME)            DC1.DOMAIN.LOCAL
MAIL                        Alias (CNAME)            DC1.DOMAIN.LOCAL
MYSITE                        Host (A)            62.48.192.51 <---- Assumes an offsite hosted mysite
WWW                        Host (A)            66.142.78.23 <---- Assumes an offsite hosted www

-saige-

And Chris is correct, if your name is resolving correctly then DNS is not affecting your certificate resolution.

-saige-

it_saige; correct

I'd have Wireshark open at this point, but there are alternatives, including web developer tools for almost every browser and programs like fiddler (http://www.telerik.com/fiddler) which let you inspect everything.

It must be something within the forward from www to https: where the dns cannot give back the site, because it is maybe looking for https locally in stead of remote (externally) ?

This because before it worked correctly and now http://www is forwarded to https://www at the webbuilders site.

Don't get involved in what happens when you type "http://www...". Only deal with what happens when you explicitly type "https://www....". If you add that into the chain it'll only become more confusing.

Forwarding, once you're past the instruction, is handled on the client side. There is no such thing as a server side forward (remote server would be proxying your connection).

If you find that "https://www..." works, but any auto-redirect from "http://www..." does not, you can change the focus of your investigation.

Incorrect...  As I stated, DNS is just for name resolution.  Once the name is resolved the host determines how the request is handled, not DNS.

Here is a very condensed overview of what happens when your computer makes an internet request:

1.  You open a browser and enter in www.mydomain.com.
2.  Your computer looks in it's local cache to see if it knows where www.mydomain.com points to.
3.  Your computer asks the DNS server if it knows where www.mydomain.com points to.
4.  The DNS server sends an ip address back to your computer.
5.  Your computer then makes a direct request to the ip address that the dns server sent back.

Your DNS server does not forward requests, it relays associated addresses for names back to clients.  Your client still makes the request to the endpoint you are attempting to attach to.

-saige-

OK Saige and Chris. Is there a random solution i can try?

You've ruled out DNS. You need another hypothesis

Candidates include (in order):

Firewall
SSL errors
Obscure forwarding after SSL

There's no "do this, fixed" until the problem is known.

Hi Chris: any ideas?

Everything from within the network to outside can pass through the firewall.

Run this in a PowerShell window, need to know if a simple TCP handshake is working:

(New-Object System.Net.Sockets.TcpClient).Connect('www.domain.com', 443)

Select allOpen in new window

If it does nothing at all the connection worked. Red errors means not.

If that works, explicit detail of any error message displayed by the browser are required.

I don't see any outcome, no errors, nothing. Browser says: This page can’t be displayed, no other errors

No outcome, no errors is good, it means it worked :)

Page cannot be displayed always has more meaning. What's the HTTP error code? 404?

Hi Chris, no error codes.

There are, it's just the browser is hiding them from you, it's user-friendly don't you know :)

It's imperative that you get at the underlying reason and any error codes. I would use a packet sniffer, but there are alternatives. Hell we could extend the PowerShell example above to get them if it comes down to it.

Happy enough with using a package sniffer (Wireshark)?

Yes Chris

In fact the PowerShell test might just be a lot less effort. With no firewalls or proxy servers in the way this should work.

Invoke-WebRequest -Uri https://www.domainname.com

Select allOpen in new window

If it works, it'll pull back the default page for the site in raw HTML.

If it doesn't, you'll get error messages. Red error messages are interesting.

Otherwise, spin up Wireshark, access the site and look at the conversation with your web server. If it can connect you'll see SSL negotiation followed by any (encrypted) HTTP requests and the methods associated with those.

Invoke-WebRequest :Cannot make connection to external server
At line:1 char:1
+ Invoke-WebRequest -Uri https://www.domainname.com
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
   eption
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

Hmm okay, lets drop back a level, please these two:

Invoke-WebRequest -Uri https://www.domainname.com -UseBasicParsing

Select allOpen in new window

And:

$webClient = New-Object System.Net.WebClient
$webClient.DownloadString('https://www.domain.com')

Select allOpen in new window

Exception calling "DownloadString" with "1" argument(s): "Unable to connect to the remote server"
At line:1 char:1
+ $webClient.DownloadString('https://www.domainname.com')
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : WebException

Same thing... hmm could be SSL, but I'd expect an error about SSL if that were the case.

Okay, we're up to Wireshark. If the earlier command worked then establishing the TCP session works. That pushes the error into SSL negotiation (because otherwise the commands above would show us an HTTP error code).

OK Chris, And now?

Wireshark, the simple tests have failed, you need to know precisely what is happening in that conversation. How far it's getting or not getting.

Get the IP for www.domainname.com. Configure a capture filter as:

host 1.2.3.4 and tcp port 443

Select allOpen in new window

Then verify that:

1. The three-way handshake completes
2. SSL negotiation completes
3. The remote server starts talking HTTP

This part is a little tricky from my point of view because I can't do much to walk you through Wireshark.

Chris;

i don't know much about wireshark, but i get an error: encrypted alert in protocol tlsv1.2

Cipher and protocol suite negotiation starts at the most secure and works backwards until client and server can agree. A failure to negotiate TLS 1.2 is not necessarily the end of the world if it falls down to TLS 1.1 and TLS 1.0 afterwards (we can hope it doesn't need to go further).

If SSL negotiation stops at TLS 1.2 and your client systems cannot agree then you have a problem to resolve. Most of the time this is just a matter of patching, cipher suites are updated over time and support for newer hashing algorithms is a recent thing.

Before you go too far down this path, if you connected the computer you're testing this on to an external network and successfully browsed the site it cannot be a problem with the device.

You can use nmap to tell you exactly which cipher suites a site supports:

https://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html

Or you can use SSLLabs SSL test function:

https://www.ssllabs.com/ssltest/

You'd have to compare that with the list supported by your client operating systems. That is windows version and patch dependent as well as contingent on any settings you may have configured.

I see this (server is Windows 2012r2);

IE 11 / Win 8.1  R            RSA 4096 (SHA256)         TLS 1.2 > http/1.1         TLS_DHE_RSA_WITH_AES_128_GCM_SHA256   DH 2048  FS

According to the suites, it is supported;

# TLS 1.2 (suites in server-preferred order);

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e)   DH 2048 bits   FS       128

That looks good to me, does it complete SSL negotiation in the network trace?

Network trace, in Wireshark?

Yep.

Split brain because domainname.com is an AD domain, right?

If you do that you'll break your AD domain. The "(same as parent folder)" entries *must* point to your DCs.

Chris; ok :(

It still looks like DNS is the problem?

If it's caused by needing domainname.com then there are internal references / redirects in the site that are breaking your attempts to access it.

That is, it's likely you're getting past the initial SSL negotiation and all the way to a point where it decides its time to redirect. Then it all breaks because domainname.com itself just directs everything to your DCs.

It's one of those really annoying things that's very easy to debug in person, yet exceptionally difficult to do remotely.

The choices at this stage are hard, either the web site has to be fixed such that it really only uses www.domainname.com, or you get the "fun" project of attempting to rename your domain so there's no overlap.

Chris; we are using split DNS. We have a zone which is called domainname.com and here we changed the (same as parent folder). We also have a zone _msdcs.domainname.com were everything is untouched?

You need domainname.com to resolve to your Domain Controllers. Clients joining the domain, group policy deployment... It was like that for good reason.

This solution still works great