0

I have a small network with two DC's, each with a DNS server, and a single DHCP server. Both are running Windows Server 2008 R2 and standard Microsoft DNS services. Everything has been working fine for years. Our company website as undergone a rewrite and is now hosted on a remote location that doesn't have a dedicated IP address (previously, we had a dedicated IP on our remote web server).

When our internal domain was set up years ago, it was setup with the same name as our internet domain. To make a long story short, I was able to get access to our new web site from inside the domain by adding @ and www records to the DNS as shown below.

(same as parent folder)       Name Server (NS)   Backupdc.mydomain.com.
(same as parent folder)       Name Server (NS)   dcfs.mydomain.com.
(same as parent folder)       Host (A)           166.62.110.232
www                           Alias (CNAME)      mydomain.com

This worked, but after a few hours it would stop working and looking at the DNS entries, I had some new values.

(same as parent folder)       Name Server (NS)   Backupdc.mydomain.com.
(same as parent folder)       Name Server (NS)   dcfs.mydomain.com.
(same as parent folder)       Host (A)           192.168.30.17
(same as parent folder)       Host (A)           192.168.30.20
(same as parent folder)       Host (A)           166.62.110.232
www                           Alias (CNAME)      mydomain.com

The new entries were the IP addresses of my two DNS servers. I was able to stop this from happening by changing Dynamic Updates to None, but this also prevents new systems from being added by the DHCP server.

Is there any way to allow DHCP to add new records to the DNS without having the @ records added for the DNS servers?

LeeG
  • 103
  • 2
  • 1
    I'm really surprised that adding @ records like that ("same as parent folder") has not caused problems on your domain. Normally in a Windows domain, the "same as parent folder records" for *mydomain.com* (for example) **must only** point to domain controllers. A domain member seeking a domain controller to authenticate with will issue a query for *mydomain.com* and then send an authentication request to the IP address it receives in response. In your case, that means domain members are trying to authenticate against your web server about 1/3 of the time. You should not have these records. – Todd Wilcox May 13 '16 at 16:30
  • 1
    Now that I think about it, attempts to reach your web site at *mydomain.com* from inside your network should also fail 2/3 of the time. You should be having all kinds of problems. If you're not, I predict sooner or later you will. You should not configure your DNS this way at all. Do not manually add @ records and you should not disable dynamic updates. You need these records for your domain to function. Internal users who want to get to the web site will have to put "www" in front. They can't reliably use just "mydomain.com". – Todd Wilcox May 13 '16 at 16:33

1 Answers1

1

Those are the ip addresses of your Domain Controllers, which also happen to be your DNS servers. This is a function of AD. The DC's register these records in DNS. You need to allow them to do this. Keep the www CNAME record and instruct your users to use www when navigating to your external web site.

joeqwerty
  • 108,377
  • 6
  • 80
  • 171
  • I tried that. What appears to happen is we enter www.domain.com in the browser. It connects to the destination server and is then replaced with just domain.com which then tries to resolve to the local host. – LeeG May 13 '16 at 16:34
  • So there must be some kind of redirect happening on the web server. You need to investigate that. – joeqwerty May 13 '16 at 16:37
  • 1
    @LeeG That's a common problem when the web developer/marketing department want to not have "www" in the URL and the internal domain has the same domain name as the public web site name. Something has to give. Either you have to rename the internal domain or the web site has to be changed to not redirect "www.mydomain.com" to "mydomain.com". It's not possible to have both and have the domain and the web site function correctly for internal users. – Todd Wilcox May 13 '16 at 16:38
  • 2
    Actually no. This is a standard problem when an incompetent admin has used the internet domain for active directory and made a mess out of DNS - while ignoring published best practices. – TomTom May 13 '16 at 16:50
  • @TomTom Mostly agreed, although some admins can argue that there was a period of time when Microsoft actually recommended making your Windows domain name match your public domain name. If I'm not mistaken, using the TLDN of .local is currently recommended against, and I think that confused a lot of people. In any case, it might sound like I'm specifically blaming only web devs/marketing, but I'm not. I think it's silly to want to prohibit using "www", but it's just as silly to not pay attention and take great care when naming a Windows domain. There's blame for everyone in my comment. – Todd Wilcox May 13 '16 at 17:28
  • I had the company that maintains the web site remove the redirection and set all my local DNS back to normal except for an A record pointing to the web site. It would be nice to actually fix our local domain, but it probably won't happen any time soon. – LeeG May 19 '16 at 20:57