Developer

DNS tip for Windows Server 2012 systems using iSCSI

DNS never ceases to raise its head in the realm of troubleshooting. Rickatron shares a tip in this blog post for Windows Server systems running iSCSI.

Just when you think you have it all figured out, DNS is the culprit yet again. I'll give the Windows networking stack props for trying to work well in the realm of defaults, but like most Windows Server administrators out there, I like to push the default configurations a bit.

Recently, I was on a phone call with fellow TechRepublic contributor Scott Lowe and we both were scratching our heads over a problem on a Windows system. It turns out DNS was the culprit, and then subsequently the granular networking configuration. Like many other Windows administrators, I'd put an iSCSI network on a different network interface. There are a lot of benefits for doing this, namely performance and role separation. But, the default network configuration caused a DNS issue that, oddly, was an arbitrary issue.

The central issue is our beloved advanced DNS configuration page of the networking stack for TCP/IP. The option to "Register this connection's addresses in DNS" will put the TCP/IP address of the interface in the Active Directory DNS database. This selection of the main network interface is shown in Figure A below:

Figure A

The register button will put an arbitrary interface into DNS.

The register button will put an arbitrary interface into DNS. (Click to enlarge.)

If additional network interfaces are used to connect to iSCSI storage resources over TCP/IP, they may need to have the Register button deselected. Windows Server 2012 (and most other editions of Windows Server) enable the "Register this connection's addresses in DNS" option by default. So, if the Windows Server 2012 system has multiple network interfaces, the possibility arises for an isolated segment to cause DNS to go awry. Further, this type of registration (again, done arbitrarily for each IP address to DNS) may force traffic down routes that you don't want or expect or, possibly, are not permitted to go.

The best practice is to designate one interface (or a team) that will be registered in Active Directory's DNS resolution. This means that only one interface will have the DNS tab fully populated like Figure A.

How do you manage DNS registration in the network interfaces? How does storage usage effect that practice? Share your comments below.

About

Rick Vanover is a software strategy specialist for Veeam Software, based in Columbus, Ohio. Rick has years of IT experience and focuses on virtualization, Windows-based server administration, and system hardware.

Editor's Picks