Web Development optimize

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.

6 comments
jdcurry
jdcurry

What was the issue you ran into that you were scratching your head about in th first place?

David Schulze
David Schulze

I have always unchecked the DNS registration options on an iSCSI network. It is a best practice. I also modify the binding order, as well as some other tweeks and mods.

chutikorn
chutikorn

We've been dealing with this problem on our Windows Server 2003 and 2008 servers as well. Microsoft really should include this in their iSCSI configuration guide.

The_Real_BSAFH
The_Real_BSAFH

A DNS server with a GUI. Now that's a waste of perfectly good hardware.

PretzelBoy
PretzelBoy

I use a completely isolated network for storage traffic- if not physically then via an isolated VLAN. There's no DNS on that network so it's best to disable the self-registration as suggested but there's no significant problems if it's not.

mmetcalfe
mmetcalfe

Spoken like a true BIND/VI master!