(First time poster)
Ok... here is the situation...
We have a webserver hosted by an ISP. www.noelkerhull.com
That is fine.
We have an internal PDC/DNS/DHCP server (192.168.1.9) that 40 client computers connect to.
All of that sits behind a Cisco Pix 515 Firewall/Router
Problem I am having is this:
When I setup the Domain Controller with Active Directory, I used noelkerhull.com as the domain name.
Now, when my internal clients open up IE and browse to www.noelkerhull.com, it bounces to a page:
Under Construction
The site you are trying to view does not currently have a default page. It may be in the process of being upgraded and configured.
Please try this site again later. If you still experience the problem, try contacting the Web site administrator.
I also have IMail server running on the PDC, and have set that up in DNS.
So, if I browse to http://mail.noelkerhull.com, i am forwarded to httpS://mail.noelkerhull.com and prompted for email username/password. This works both inside/outside of our companies network (which is what I want)
I also have an FTP server running in much the manner (192.168.1.17) and is accessible from inside/outside of the network.
My problem seems to be that while inside of the network, the clients cannot get to our external website.
Now, if I manually change my DNS settings on my laptop from 192.168.1.9, to Sprints DNS IPs (204.....) it works fine.
So, is our DNS server not forwarding the request? Or is it finding something on 1.9 giving me the error page, and not bothering to try to send it to our external DNS (sprint) server?
One thing I forgot to mention. I set up an A record for the following
mail - 192.168.1.9
ftp - 192.168.1.17
www - 212.whatever (IP of external webserver)
I created the www hoping that it would take any request for the www.noelkerhull.com and immediately direct it to the external server.
Now, the clincher is... I have a subwebsite running on our external website.
www.noelkerhull.com/subwebsite
Internally and Externally, that works fine! So the problem just seems to be www.noelkerhull.com
Was this answer helpful ?
Yes No
hum hum hum. Fun times. Configuring the dns server to point www to the public IP was definately the right way to go about things. So if it still doesn't work, it might be due to caching related problem. Let's explore that theory.
First run this command on one of the clients:
ipconfig /flushdns
Then show me the results for this command on that same client.
ping www.noelkerhull.com
Either you'll find that flushdns made everything work, or ping will tell us the domain still resolves to a private IP address.
Was this answer helpful ?
Yes No
Excellent Post!
Ok, I did the Flush... (never knew about that command)
Pinged and got the correct IP addy 209....
Opened up IE, and it worked!
Mail server still works too!
So, problem fixed!
But, in noticing that... I noticed something else since I was tweaking DNS
I have about 30 DNS warnings in my event log:
The DNS server encountered a packet addressed to itself on IP address 192.168.1.9. The packet is for the DNS name "_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.noelkerhull.com.". The packet will be discarded. This condition usually indicates a configuration error.
Check the following areas for possible self-send configuration errors:
1) Forwarders list. (DNS servers should not forward to themselves).
2) Master lists of secondary zones.
3) Notify lists of primary zones.
4) Delegations of subzones. Must not contain NS record for this DNS server unless subzone is also on this server.
5) Root hints.
Example of self-delegation:
-> This DNS server dns1.example.microsoft.com is the primary for the zone example.microsoft.com.
-> The example.microsoft.com zone contains a delegation of bar.example.microsoft.com to dns1.example.microsoft.com,
(bar.example.microsoft.com NS dns1.example.microsoft.com)
-> BUT the bar.example.microsoft.com zone is NOT on this server.
Note, you should make this delegation check (with nslookup or DNS manager) both on this DNS server and on the server(s) you delegated the subzone to. It is possible that the delegation was done correctly, but that the primary DNS for the subzone, has any incorrect NS record pointing back at this server. If this incorrect NS record is cached at this server, then the self-send could result. If found, the subzone DNS server admin should remove the offending NS record.
You can use the DNS server debug logging facility to track down the cause of this problem.
For more information, see Help and Support Center at
Other than my Mail A Record, I dont have anything pointing to 1.9.
Was this answer helpful ?
Yes No
The ipconfig flushdns command flushes the "DNS Client" service of all cached dns records. Restarting the computer, restarting or shutting down "DNS Client", or waiting a while would also have fixed the problem.
As for the warnings. I assume this means the dns server sent a packet to itself. This is a waste of a small amount of resources but otherwise not a functional problem. So as the message says, check the following:
1) Forwarders list. (DNS servers should not forward to themselves).
If you configured the dns server to forward to an IP address which exists on the local machine, this is a nono. You don't want to forward queries to yourself.
2) Master lists of secondary zones.
If you have a secondary (slave) zone whose primary (master) IP list includes an IP address which exists on the local server, this is a nono. You don't want to retrieve a zone transfer from yourself.
3) Notify lists of primary zones.
If you have a primary zone (master) whose notify list includes an IP address which exists on the local server, this is a nono. You don't want to notify yourself of changes.
4) Delegations of subzones. Must not contain NS record for this DNS server unless subzone is also on this server.
If you have a primary zone (master) that delegates queries for a subzone with NS records to a dns server domain that resolves to an IP address that exists on the local server, AND that subzone does not actually exist on the local server, this is a nono. You don't want to delegate queries to yourself when you aren't authoritative for them.
5) Root hints.
If your root hints includes an NS record pointing to a dns server domain that resolves to an IP address that exists on the local server, this is a nono. You don't want to query yourself to find domains you're not authoritative for.
Was this answer helpful ?
Yes No
Again, an excellent response! You guys are great here!
It looks like the only problem I have is #1. I have the mail A Record pointing to 1.9 (DNS server)
But, if I take that out... i cannot get to the mail server from the inside.
Was this answer helpful ?
Yes No
The mail record was probably fine. The "forwarders" is a list of dns servers that your dns server will forward queries to IF it doesn't know the answer. So like if you ask the dns server to lookup the IP address for www.yahoo.com, the dns server wouldn't know. So, it forwards the request to a dns server that can find out. That's forwarding.
You don't have to use forwarding however. The dns server can find out what the IP address is all by itself using multiple DNS queries.
I don't know if you're using forwarding, but if you are... then you need to make sure none of the IPs refer to the local server.
Was this answer helpful ?
Yes No
I've seen you refer this command many times. How often should it be done? And suggestion for how and where to put it. Thanks!
Quote:
| Originally Posted by SilentRage hum hum hum. Fun times. Configuring the dns server to point www to the public IP was definately the right way to go about things. So if it still doesn't work, it might be due to caching related problem. Let's explore that theory.
First run this command on one of the clients:
ipconfig /flushdns
Then show me the results for this command on that same client.
ping www.noelkerhull.com
Either you'll find that flushdns made everything work, or ping will tell us the domain still resolves to a private IP address. |
Was this answer helpful ?
Yes No
ipconfig /flushdns is not intended to be a maintanence task. If there is a problem that requires you to flush regularly, then you need to fix the problem - not the symptom. You enter the command through the DOS prompt, and there should never be a reason to schedule it. Although, under some circumstances I recommend that people shut down the "DNS Client" service so that caching isn't even done by the client.
Was this answer helpful ?
Yes No