Prevent registration of multiple IP addresses in DNS

There are times when you will need to have multiple IP addresses on a server.  It could be for an additional receive connector in Exchange, or for another website in IIS, among other things.  This is not recommended if the server is a domain controller and/or DNS server.  Best practice for a DC/DNS server is to have a single NIC (or NIC team) with a single IP address.  Having more than one IP can and does cause DNS resolution issues, logon issues for clients, and other Active Directory weirdness.  However, I realize that there are situations where you don’t have any other way of accomplishing an objective, and you simply must have multiple IPs on your DC/DNS server.  I have been IN that situation more than once, which is the reason for this post.

Adding another IP address on a server can be accomplished either by adding a secondary IP address on an existing network adapter (shown above), or by adding another network adapter with its own IP address.

In any case, by default, the server will register all assigned IP addresses in DNS.  This may cause problems if clients resolve an IP for the server other than the one they need to access whatever service they are trying to use.  For example, if you have multiple IP addresses on an Exchange server, but only the first IP address bound to the default receive connector, clients running Outlook that were given the secondary IP address by DNS would have trouble connecting to Exchange.

There are several ways to prevent registration of multiple IP addresses in DNS, depending on the configuration (secondary IP or NIC) and role of your server.

Scenario 1: Windows Server with multiple network adapters; no secondary IP addresses on either adapter, nor is the server a DNS server.

Resolution: In this situation, the only action you should need to take is to prevent the server from registering the address from the 2nd NIC.  You can do that by going to the properties of the connection –> IPv4 settings –> Advanced button –> DNS tab.  Then, UNcheck the “Register this connection’s addresses in DNS” checkbox, as shown here:

Scenario 2: Windows Server with multiple network adapters running DNS server role.

Resolution: First, perform the same action as the resolution for scenario 1, to prevent the server from registering the 2nd NIC address in DNS.

Also, because the server is running DNS, you must configure DNS to only listen on the primary IP address.  By default, a Windows server running DNS registers all IP addresses that are being used by DNS.  To prevent this, open the DNS console right-click on the DNS server name on the left side and go to Properties –> Interfaces tab.  From here, select the radio button which says “Only the following addresses”.  Then, if necessary, add the primary address to the list below and remove all other IP addresses.  Here is an example:

Scenario 3: Windows Server with single network adapter and multiple IP addresses

This is the same as the example at the top of this post.  In this case, there is not a clean way to prevent registration of the 2nd IP address in DNS.

If you are in this situation, it would be best to remove the secondary IP address from the adapter and set the IP on another adapter.  Then, you can just follow the resolution for scenario 1 or 2.

If you absolutely must configure the server this way and you cannot add another network adapter, then you CAN use the resolution from scenario 1 and prevent the server from registering its addresses in DNS.  However, after that, you may have to go into DNS and manually create a DNS entry in the forward lookup zone for the server.  Any servers from recent years have at least 2 NICs in them, and lately are even being shipped with 4 onboard NICs.  So, having an extra NIC available won’t usually be an issue.

Another way to prevent dynamic registration of DNS records on a server (2000 and 2003, that is) is to modify the registry using the following Microsoft KB article:

According to the article, it can be done globally, affecting all NICs on the server, or on a per-NIC basis.  If you decide to try this option, be CAREFUL!

How to use nslookup to test DNS servers

NSLookup is a very useful tool for testing specific DNS servers.  For instance, if you are having DNS resolution issues or if you are transferring your DNS records to different DNS servers, you can use nslookup to test the authoritative name servers for your domain.  This will enable you to ensure that each of the authoritative servers for your domain are serving all the domain DNS records correctly.  There is a command with a similar function in Linux, called ‘dig‘, however I will not cover use of that command in this post.

If you are planning on transferring your DNS records to different name servers, I would recommend having the DNS records created on the new servers first.  Then, you can use nslookup to verify that the new records are in place before you change the authoritative DNS servers for your domain in your registrar account.

NSLookup has been included in every recent version of Microsoft Windows.  It can be accessed by simply opening up a command prompt and typing the ‘nslookup’ command:

Now that you are running the nslookup program, you can select the server you want to use by simply typing “server <server IP address>”.  This sets the focus on the server that you want to test.  Any subsequent queries for DNS records will use this server until you select a different server.  For example:

By default, nslookup is set to query for ‘A’ records.  So, if you want find the A record for, you simply type that in, like so:

If you want to query for the MX records for a domain, you will first need to change the query type.  That is done using “set q=mx”, as shown here:

(you can also use set querytype=MX or set type=MX)

Then, type in the domain for which you would like to see the MX records:

Here are the various record types you can use with the “set q=” command:

  • A
  • ANY
  • GID
  • MG
  • MR
  • MX
  • NS
  • PTR
  • SOA
  • TXT
  • UID
  • WKS

You can find a description of these record types on this page:

In addition, here is the command reference for the nslookup utility:

Test Your DNS with Namebench

Namebench is a great utility to test your DNS performance against other publicly available DNS servers.  It will run a multitude of DNS-related tests and give you back a recommended DNS configuration for your computer, based on the connection you are using when you run the test.  The tool was created by a Google developer, but is not biased towards Google Public DNS.  In my case, it suggested I use ‘The Planet” (company in Dallas) as my primary DNS provider.

The original project page is here:


It takes about 10 minutes to run, and can definitely be worth the trouble if you are having slow Internet browsing issues.

How to Safely Transfer DNS Records

Occasionally, you will find yourself in a situation where you have to transfer DNS records from one set of name servers to another.  It is not a technically difficult process, but one that must be handled with the greatest care so that you don’t leave your company (or your client) without email or access to their website for hours or days.

What does ‘transfer DNS records’ mean?  All of the DNS records for a given domain (i.e. are managed on the authoritative name servers for that domain.  That means all of the ‘A’ records, MX, TXT, SPF and every other kind of record (except for your reverse PTR!) are stored primarily on a certain group of servers that are authoritative for your domain.  You can find out the name servers for your domain a couple of different ways:

  • Log in to the registrar account where you have registered your domain name (i.e. GoDaddy,  In the control panel or settings for the domain, you can see the name servers.  Unless you changed them, they are likely set to the defaults for your registrar.  For Godaddy, they will be something like and
  • Use an online tool like MXToolbox or Hexillion, which will show you your domain’s name servers and will probably be quicker than having to log in to your registrar account.

There are several reasons why you might need to change those name servers to something else:

  • You need to consolidate a domain name obtained through a company merger into another registrar account that you normally use.  For instance, your company acquires another company who has their domain name registered with GoDaddy, and all of your existing domains are at Network Solutions.  You would actually transfer the entire name, from GoDaddy to your Network Solutions account.  The name server change will actually happen as part of the domain transfer from one registrar to another.
  • You have a hosting company for your website and they “require” that you set the name servers for your domain to point to their name servers.  This is not really true; they don’t HAVE to have control of your DNS records.  All they really need is for your to point the ‘A’ record for and to their web server (depending on what your domain name is, of course).  But that is a little bit of a tangent.  For the purpose of this post, let’s just assume that you are changing your name servers to point to your web host.
  • You need to have a reverse lookup zone and the only way that your ISP will create one for you is if they host your DNS for you, a la AT&T.  This is also not something that you HAVE to do.  Again, kind of a tangent.  So, let’s assume that you are changing your DNS servers to point to your ISP so they can create a reverse zone for you.

If you are in one of these situations, or are just moving your DNS servers around for the fun of it, here is what you should do:

  1. Find all of the DNS records that exist for your domain on the current name servers. If you have access to some kind of ‘DNS Management Console’ in your registrar account, like at GoDaddy or Network Solutions, this is where you need to go.  Record or export a list of all the records that exist and where they are pointed.  The most important records are where the root domain name itself is pointed as well as ‘www’ and of course your MX records.  If your name servers are pointed at something outside the control of the registrar, you won’t have any kind of DNS management console.  In this case, the only way to get a complete list of all the DNS records (aka a full zone listing) will be to contact the entity that manages the name servers that your domain is pointed at currently.  Most likely, this is going to be whomever does your website hosting.  Just contact them and ask for a full DNS zone listing for your domain.
  2. At least 3 days before you change the name servers, change the Time-To-Live (TTL) values of your most critical DNS records to 3600 seconds (1 hr.) or less. The TTLs dictate how long other DNS servers that have looked up your ‘A’ or MX records can cache them.  TTLs are also why you always hear the butt-covering statement or warning that “it can take 48 – 72 hours for DNS changes to propagate”.  A lot of TTL values are set to 86400 seconds (1 full day).  If multiple levels of DNS servers from your name servers have cached these records, it can definitely take 2 – 3 days for any changes to those records to propagate.  So, if you change these to much lower values (3600 seconds), the changes you make will propagate in 2 – 4 hours at most, rather than 2 – 3 days.  Now, if you are just moving the name servers, and are not actually making changes to any of your DNS record values at the same time, then you shouldn’t even have to worry about this.  But better safe than sorry.  If something goes awry, and someone on the other end doesn’t recreate all of your DNS records as you specify, recovery can occur much more quickly if the TTL values are set very low.  I’m just sayin’….
  3. Provide the full listing of DNS records for your domain to the company to which you are transferring the name servers. If you are transferring to another account/registrar that you already control, you can’t really do this (I’ll mention more on that later in this post).  If you ARE transferring the name servers to someone else and out of your control, make sure they get your list and they understand what it is for.  You’d be surprised at how little some people at hosting companies, who deal with DNS records all the time, actually know about DNS.  There are usually some people on the back-end that know what is going on, but sometimes the front line people….don’t.
  4. Verify the DNS records have been created in the new location. If the 3rd party guys have done their job, they will have recreated all the DNS records you gave them and have provided you with at least two server addresses where your DNS records are hosted.  You should use nslookup or dig to verify that each of the DNS records you asked them to create exist and are accurate.
  5. Set Expectations. Whether this is your company or a client, you should set some expectations with regard to what is going on.  This is a very important step.  You don’t necessarily need to explain this whole process and how DNS propagation works, but you should let them know that changes are being made and that the potential exists for disruption of certain things like access to the website and email.  Get contact information for the decision makers and/or your points-of-contact at the company so you can relay information to them in some form besides email in case you run into problems.
  6. Switch the name servers or transfer the domain to new registrar. This is cutover time; start biting your fingernails.  This is where you actually go into your registrar account and switch the name servers from (example) to whatever addresses were given to you by the 3rd party.  Or, you are transferring the domain to another account you control.  You should periodically check to see what name servers are listed for your domain using one of the methods I mentioned at the beginning of this article.  Now, as I said before, if you are just transferring the domain to another registrar and you will have control of the DNS records there, this is the point at which you would go into the DNS management console at the new location and recreate all the DNS records yourself.  If you have any trouble getting into the new DNS management console, call the registrar as soon as possible to resolve any problems.
  7. Test, test, test. Check the name server and do DNS lookups using various methods throughout the evening/weekend after the change until you see that everything has propagated.  Check access to your website.  Send test emails to and from addresses on the domain in question.  If there are any problems, contact the registrar or the 3rd party company hosting the records immediately.  It would be a good idea to have after hours contact info for the people involved so you know you can get a hold of someone in a pinch.

Reverse PTR Troubleshooting

If you administer a mail server, do you know if your reverse PTR (‘pointer’, aka Reverse DNS) record is set up correctly?  If you don’t know, then probably not.  It’s not one of those things that happens ‘automagically’ when you run through the Exchange 2000/2003/2007, Sendmail or <insert name of any other mail-handling software> installation process.

One way you can tell if your reverse PTR is NOT set up correctly is if you regularly have delayed our bounced email when sending messages to,, or  Those are some of the higher profile domains which do reverse lookups on connecting mail servers.  And they are not very forgiving.  If your PTR record is not set up correctly, they and others will delay or reject messages from your mail server IP address.

So, let me give a quick overview of how the reverse lookup process works in the context of sending an email, and what you can do to make sure your PTR exists and is correct.

When you send an email:

  1. Your mail client submits a message to the server; if it is for a non-local address, your server puts it in the outbound SMTP queue.  Let’s say your email address, the source, is it’s going to   For the purpose of this post, I’ll assume you are not using a smarthost.
  2. Your server performs a DNS query to find the MX records for  It gets a response like ‘’
  3. Your server resolves the MX record to its IP address, which we will say is
  4. The SMTP service on your server then makes a connection to on TCP port 25.  For our example, the WAN IP address of your mail server will be
  5. SMTP then ‘introduces itself’ (using EHLO or HELO) and provides the receiving server with its name.  THIS is something that was probably configured during the installation of your mail server, and is typically or something similar.  So, at this point, the receiving mail server,, sees an incoming SMTP connection from a server at claiming to be  How does the server at know that the sending mail server is really who it says it is?  That is where the reverse lookup comes into play.
  6. The receiving server at takes the connecting IP address,, and does a reverse lookup on it.  A reverse lookup is a DNS query that is looking for a specific type of record, called a PTR.  It is called a reverse PTR because, during the DNS query process, an IP address is resolved to a name.
  7. The reverse DNS lookup on results in a response that is (hopefully) “”.  Notice that the response matches what the sending server said that it was in the introduction in step 5.  This is ideal.
  8. Next, the destination server takes that response and does a regular forward lookup on it.  So it just finds the ‘A’ record for  That query should return an IP address that matches the source IP, in our case
  9. At this point, the reverse lookup process is complete.  The receiving mail server is satisfied that the sending server is who it says it is and allows the connection to proceed.  The destination server may actually allow the sending server to specify the source and destination email addresses before performing the reverse lookup; this depends on how the server was set up by the administrator.

Now, how can you make sure reverse lookups done on your mail server IP address go as smoothly as outlined above?

Gather the following information:

  • Find out how your mail server is introducing itself when it is connecting to other mail servers.  This is a setting in the SMTP server properties (‘Send Connector’ in Exchange 2007) and is likely going to be ‘’ or something like that.  Again, it was probably set when Exchange (or other mail-handling software) was installed.  More technically, this is the name being given along with the EHLO or HELO command when your server connects to another mail server.
  • Look up the current IP address associated with the name you found in the item above.  If you looked on your Exchange server send connector and found that it was set to use, just ping that address and see what IP address you get.  Depending on how your internal DNS is set up on your network, you may get an internal address when doing this.  You need to know the external IP address that is given in response to a query for the name, so you may have to do this step from a computer outside your network.
  • Find out the WAN IP address that your mail server is using to send email.  One fairly reliable way to do this is just to get on your mail server and go to  Another way would be to look at the NAT rules on your firewall to see what address traffic from your mail server is being translated to on the outside.
  • Look up the current reverse PTR record for your mail server IP address.  A couple of websites that I use for that are MXtoolbox and ZoneEdit.  Often, the result you get here will be the default for your ISP, and may look like this:  That is bad.

Armed with this information, you can now determine whether you are in good shape, or if you need to take action.

Verify everything is Ok or fix the problem:

  1. Does the WAN IP of your mail server already have a valid reverse PTR record that matches your domain?  Or, does it look like my example,  Typically, the most difficult thing to get changed is the reverse PTR record.  These are usually controlled and created/changed by your ISP (Time Warner Cable, AT&T, Comcast, etc.).  There are different ways to request that a reverse PTR be set or changed depending on the provider.  It can be as simple as sending an email to (for Time Warner), to having to sacrifice your first-born child (for AT&T).  Just kidding, although for some reason, AT&T has made it exceptionally difficult in the past to get a reverse PTR set up.  I’ve had to go so far as to have AT&T host the DNS records for my domain in order to have them host a simple reverse PTR record for me.  Bottom line, go to your provider and ask for the process to create or change a reverse PTR record, and go from there.  All administrative overhead aside, the technical information they will need to set it up will be the WAN IP address of your mail server and what you want the record response to be.  In our example case, we would have provided them with as the WAN IP and told them that we wanted the reverse PTR for that IP to be “” (without the quotes).
  2. When you ping your EHLO address,, does the IP that is resolved match the WAN IP address of your mail server?  If not, you can fix this in a couple of ways.  Either change the ‘A’ record for to be the IP address of your mail server, or change the WAN IP address of your mail server.  Obviously, you should be careful when changing DNS records or IP addresses.  Make sure you get someone else in your IT group involved for a sanity check so you can make sure you are not going to be causing some other problem trying to fix this one!
  3. Is your SMTP server EHLO address set to a valid external DNS name?  In our example, I used  However, I have seen mail servers configured to use ‘sbserver.domainname.local’, which is not a valid DNS name on the Internet.  In this case, you will have to set your EHLO address to something similar to the example; something that likely matches your domain name.

That’s it!  If you went through all this and your reverse PTR was already in good shape, great!  If not, then I hope that this helped you to find your way.  It was painful for me when I learned this, because I did it the hard way.  Thanks for reading.

Posted via email from Aaron Johnstone