I just noticed this happen to a VM I was connected to this evening.
All I did was change the primary DNS from automatically assigned to manual, gave it a DNS server IP, and provided a backup secondary IP, and my RDP session was instantly dropped. Other HTTPS traffic to the box stopped too.
I had to restart the VM in Azure to get connectivity back. This VM was deployed using the classic portal, but I’ve seen reports of it happening on newer ARM deployed VMs too. Here’s a thread with others that have found the same issue.
Hopefully Microsoft will resolve this soon.
I needed to setup some DNS records for an Office 365 migration earlier and was initially slightly confused translating the settings Microsoft supplied us to those needed as input on 123-reg’s Advanced DNS configuration. The MX, TXT and CNAME records were simple enough, but it was the SRV records that needed a bit of fiddling to get right.
As an example on the SRV records, MS give you something like this:
123-reg give you this interface to enter SRV records yourself:
By looking at the examples you can start to understand how to translate the Service, Protocol, and Weight items that MS give you, into the 123-reg input boxes (which do not exist individually for Service, Protocol and Weight).
In the first SRV record example –
Hostname therefore becomes: _sip._tls (the Service + the Protocol with a dot (.) between)
TTL of course becomes: 3600 (1 hr)
Priority is 100
Destination (the most confusing one) becomes: 1 443 sipdir.online.lync.com. (note that it starts with Weight (1), then a space, then the port number (443), then the Target (sipdir.online.lync.com), followed by a dot (.)
That forms your complete SRV record. By entering these along with the other records you require, you should have a fully functional Office 365 setup on your custom domain name.
After one day, you may find your Windows 2008 DNS Server is unable to resolve names in some top level domains (TLD’s) like .co.uk, .cn, and .br when it is configured to use root hints. This may also be seen with other top level domains too. According to Microsoft, a network monitor trace should show that the DNS Server does not send any DNS traffic out to the internet. The Windows 2008 DNS server returns SERVFAIL to the client or when using nslookup. I have not used Network Monitor to verify this myself, but I am sure if you loaded it up and used this MS KB to set up a trace that you would be able to verify this symptom.
Workarounds include restarting the DNS server, clearing the DNS cache, setting maxcachettl to 2 days or greater, and using DNS Forwarders instead of root hints.
This currently occurs with default SBS 2008 installs that have been configured to use root hints for DNS lookup. I have recently noticed this behaviour myself with two different SBS 2008 installs.
If you want to use root hints, you can set the maxcachettl registry value on the Windows 2008 DNS Server as follows:
1. Start Registry Editor (Regedit.exe).
2. Locate the following registry key:
3. On the Edit menu, click New, click DWORD (32-bit) Value and then add the following value:
Data Type: DWORD
Data value: 0x2A300 (172800 in decimal = 2 days)
4. Click OK.
5. Quit Registry Editor.
6. Restart the DNS server.
Another way to get around this issue is to use the following method (I personally prefer this way):
1. Open up DNS under Administrative tools from the SBS server’s start menu.
2. Right click on the server name and select Properties.
3. Go to the Forwarders tab and click on the “edit” button.
4. Enter the primary DNS address of your ISP (In this case mine was BT so I used 188.8.131.52) and click Ok.
5. The forwarders section will now attempt to automatically resolve the FQDN for that IP. (Note you can also probably enter your router’s IP address in the forwarders section which should then get your SBS to look to the router for DNS information).
6. Click Ok to close the properties window and then close your DNS console.
DNS lookups for the TLDs should now be working again. If not, stop and restart DNS or give the server a reboot.