Blog: DNS

We recently needed to create SPF records for one of our customers’ several email domains. Sender Policy Framework is implemented as a DNS TXT record and it’s designed to provide a mechanism to allow an email server to verify the valid IP addresses for a given email domain. The syntax can be a little tricky so I found several good sites to help generate the SPF. One of the best was Microsoft’s, which retrieves the actual IP addresses from DNS to build the TXT record. After you answer a few questions about email flow it creates the record which you can copy/paste into your DNS configuration.
 
https://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/
 

We recently encountered a strange issue with a customer running Outlook 2010 in an Exchange 2007 environment. Some users (not all) would randomly get certificate warning pop-ups in Outlook. The certificate warnings indicated the Fully Qualified Domain Name (FQDN) "autodiscover.customerdomain.com" wasn’t on the certificate. The certificate warning was legitimate; that FQDN was not on the certificate because this customer didn't have a UCC certificate.

However, all the autodiscover SCP records had been changed via Powershell to point the autodiscover URL to "webmail.customerdomain.com" which WAS on the certificate. All the PCs were joined to the Active Directory domain so the SCP lookup should have had precedence over any other autodiscover method. Doing an autodiscover check via the Outlook system tray icon indicated the certificate warning pop-up and all the values returned by the test were all correct.

The question was why were these PC's even contacting "autodiscover.customerdomain.com"? After much troubleshooting, we found that even though the domain SCP records were correct, some Outlook clients were also doing DNS lookups for "autodiscover.customerdomain.com" in parallel with the SCP lookup. Checking DNS there was an "autodiscover.customerdomain.com" A record and pointed to the IP address of the Exchange server; however, since that FQDN wasn’t a subject alternate name on the certificate, it would have legitimately generated the certificate warning.

The resolution was to simply remove the "autodiscover.customerdomain.com" A record from DNS and we added SRV records for good measure. It doesn’t seem like having that A record in DNS would have mattered since the autodiscover priority shouldn’t have ever used it, but from now on we will use DNS SRV records and SCP exclusively for Exchange autodiscover.

Registration for the new “.bank” domains is coming up soon. These domains could be prime Internet names in the future. A few quick notes: [more] 

• Early “sunrise” registration will be May 18, 2015 with general availability on June 24th.
• Registration will be limited to domain names with corresponding trademark, trade name, service mark, or bank name. 
• There will be a verification procedure to ensure these domain names are only issued to valid financial institutions.
• Banks should consider registering a trademark now to be able to register the associated domain during the sunrise registration period. 
• Registration will be on a “first come, first serve” basis, so if a bank with similar names want the good domains, they need to register early.
• More information is available at https://www.ftld.com

I had needed to make a change to a customer’s WPAD file to add a direct access  location. I made my changes and tested it only to find out that it didn’t work. I decided that I would check and make sure the client could access the WPAD file, so I tested access to HTTP:// SERVERNAME/ WPAD.dat. I was able to see the changes I had saved in the file.  However, the client still didn’t seem to be following the rules. I tried changing the  Automatic Settings in Internet Explorer Proxy settings to use HTTP:// SERVERNAME/ WPAD.dat specifically as the proxy script to use.  As long as I had the Automatic Settings unchecked and the path to the WPAD file defined in the script box, it worked. However, I needed to make sure it would work with Automatic Settings instead. [more]

What I found out was that a client gets it’s instructions about the location of the WPAD file to use through DHCP option 252. Upon checking the settings of this option, I found that it was using HTTP://WPAD/WPAD.dat instead of SERVERNAME. The DNS entry for WPAD was an alias that pointed to SERVERNAME. I went back to the web browser and went to HTTP://WPAD/WPAD.dat.  I discovered that it did not have the changes that I had made even though HTTP://SERVERNAME/WPAD.dat was correct.  On the WPAD server, I restarted IIS and checked it again.  This time, both WPAD.dat files had my changes and the Automatic Settings began working successfully.

It appeared to me what happened was that IIS was serving a cached version of the WPAD.dat file when browsers tried to connect to the DNS alias while the actual server name was not cached. 

When working with a Jack Henry application that required the use of a ‘localhost’ reference, it was discovered that the loopback (127.0.0.1) address in the HOSTS file seems to be commented out by default in newer OS’s (Windows 2008 R2, Windows 7).  The solution in this case was to just uncomment the entry in the HOSTS file.

MS TECH RESPONSE: At some point in the future, as the world transitions from IPV4 to IPV6, IPV4 will be eventually be disabled/uninstalled by companies that want to simplify network management in their environments.
With Windows Vista, when IPv4 was uninstalled and IPv6 was enabled, a DNS query for an A (IPv4) address resulted in the IPv4 loopback (which came from the hosts file). This of course caused problems when IPv4 was not installed. The fix was to move the always present IPv4 and IPv6 loopback entries from the host into the DNS resolver, where they could be independently disabled."

I was troubleshooting something on my phone a while back and through the process, I had realized that I should flush the DNS cache on my phone. The problem was, however, I had no idea how to go about doing that. Of course, I could just reboot the phone and be done with it, but that took time and if I had to do it multiple times, it quickly became impractical. Instead, I stumbled upon a much simpler solution: put the phone in airplane mode. This completely disables all network connectivity until you drop out of airplane mode again and has the natural side effect of flushing the DNS cache of the phone.

A customer called with a  laptop that would not connect to any mapped drives.   Investigating found that attempting to map via name would not work but mapping via IP did work.  DNS was working properly and the file server would ping by name or IP.  Logged in with an administrator account and all mapped drives came up properly.   Finally discovered that this machine had not been on the domain for some months and there were old cached credentials for the file server in stored credentials.  These are stored by path so it was using those credentials by default when attempting to map by name but not when mapping by IP.  Removal of these stored credentials allowed the mapping to complete properly. 

I found out last week how easily one can get a certificate from GoDaddy with a SAN (Subject Alternative Name) for a non-registered domains name. This would include domains that end in .dom or .local that do not have a public registrar. Since GoDaddy cannot retrieve a WHOIS record for the domain, their authorization email only needs to be approved by the account that requests the certificate. This vulnerability removes a significant barrier for a man-in-the-middle attack, since the certificate would be trusted and the name would match the URL requested by the users.

Additionally, Office 365 AD Sync (needed for password synchronization) will not work with these type of non-registerable DNS names in a UPN suffix. While the UPN suffix can be changed to be different than the domain name, the problem would not exist for domains that use names like “internal.registereddomain.com”.

I recently helped a customer having trouble with FaceTime and iMessage not working with his iPod touch. He was able to browse the web and get to the App Store, but the FaceTime and iMessage applications would not work. I connected my cell phone and was able to use FaceTime, a WiFi only application. I assumed this meant the problem was with his iPod, not his wireless Internet. However, his iPod worked correctly when he connected to a different wireless network. The problem fixed itself for about a week at his house, then started happening again. I did some reading and found that this could have been caused by DNS. I changed the DNS servers on his router to use different DNS servers. Immediately the problem was fixed.

Thinking back on my testing, I did not take into account that my phone could have been using 3G DNS servers during the first test. The lesson here is to be careful when using cell phones to test wireless connectivity.