Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations bkrike on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Can't access our own website from our internal server
- Thread starter technp
- Start date
What type of network do you have?
It's probably a DNS problem.
Is your local domain name the same as the external website?
What happens when try to access the website?
What does a nslookup 'website' turn up?
Sorry to answer a question with questions but hopefully it will lead in the right direction. Some people with a similar problem just needed to add a host entry in their dns to properly resolve their external website.
It's probably a DNS problem.
Is your local domain name the same as the external website?
What happens when try to access the website?
What does a nslookup 'website' turn up?
Sorry to answer a question with questions but hopefully it will lead in the right direction. Some people with a similar problem just needed to add a host entry in their dns to properly resolve their external website.
GlenJohnson
MIS
Is there anything else you can't get to? All other websites accessible? Can you ping the website by name?
Glen A. Johnson
"Without words, without writing and without books there would be no history there could be no concept of humanity"
Hermann Hesse (1877-1962), German-born Swiss writer
Tek-Tips in Chicago IL
Glen A. Johnson
"Without words, without writing and without books there would be no history there could be no concept of humanity"
Hermann Hesse (1877-1962), German-born Swiss writer
Tek-Tips in Chicago IL
- Thread starter
- #5
Hello, I am responding for technp. I am the IT Department in his organization. Our network is Windows 2000 Server (Active Directory), Exchange 2000, Terminal Server, Sonic Wall.
Our website is hosted by BellSouth. BellSouth did some type of migration over the past year. They claim that we no longer have a "static IP" but instead some type of dynamic that functions like a static. (can never get a good explanation from them)
We also think it is a DNS problem.
Our local domain name is the same as our external website. I think this is the root of the problem.
When we try to access website from within our LAN, we get error "page cannot be displayed..."
nslookup:
Results Returned for "arcbroward.com":
Name: arcbroward.com
Address: 65.83.225.173
tracert results:
1)208.62.31.129
2)68.152.171.89
3)205.152.144.94
4)205.152.110.62
5)65.83.237.138
6)axr00asm-0-3-0.bellsouth.net [65.83.236.12]
7)ixc00asm-4-0.bellsouth.net [65.83.237.1]
8)205.152.152.50
9)205.152.152.86
10)66.21.240.205
11)host04.swh.bellsouth.net [65.83.225.173]
We have no other resolution problems that I know of. All other sites are accessible.
When I ping arcbroward.com, our terminal server replies with the internal address of 192.168.0.4
I did some research and mentioned the host entry to a consultant that came out to try to fix this. I don't remember what his response was. I will post when he calls me back. Here are the results of a DNS report I ran that may be of use, too:
--------------------------------------------------------------------------------
DNS Report for arcbroward.com
Generated by at 04:14:37 GMT on 29 Apr 2005.
Category Status Test Name Information
Parent PASS Missing Direct Parent check OK. Your direct parent zone exists, which is good. Some domains (usually third or fourth level domains, such as example.co.us) do not have a direct parent zone ('co.us' in this example), which is legal but can cause confusion.
INFO NS records at parent servers Your NS records at the parent servers are:
ns4.web.bellsouth.net. [65.83.225.31] [TTL=172800] [US]
ns5.web.bellsouth.net. [65.83.225.32] [TTL=172800] [US]
[These were obtained from m.gtld-servers.net]
PASS Parent nameservers have your nameservers listed OK. When someone uses DNS to look up your domain, the first step (if it doesn't already know about your domain) is to go to the parent servers. If you aren't listed there, you can't be found. But you are listed there
PASS Glue at parent nameservers OK. The parent servers have glue for your nameservers. That means they send out the IP address of your nameservers, as well as their host names.
NS INFO NS records at your nameservers Your NS records at your nameservers are:
ns5.web.bellsouth.net. [no glue provided] [TTL=10800]
ns4.web.bellsouth.net. [no glue provided] [TTL=10800]
PASS Mismatched glue OK. The DNS report did not detect any discrepancies between the glue provided by the parent servers and that provided by your authoritative DNS servers.
PASS All nameservers report identical NS records OK. The NS records at all your nameservers are identical.
PASS All nameservers respond OK. All of your nameservers listed at the parent nameservers responded.
PASS Nameserver name validity OK. All of the NS records that your nameservers report seem valid (no IPs or partial domain names).
PASS Number of nameservers OK. You have 2 nameservers. You must have at least 2 nameservers (RFC2182 section 5 recommends at least 3 nameservers), and preferably no more than 7.
PASS Lame nameservers OK. All the nameservers listed at the parent servers answer authoritatively for your domain.
PASS Missing (stealth) nameservers OK. All 2 of your nameservers (as reported by your nameservers) are also listed at the parent servers.
PASS Missing nameservers 2 OK. All of the nameservers listed at the parent nameservers are also listed as NS records at your nameservers.
PASS No CNAMEs for domain OK. There are no CNAMEs for arcbroward.com. RFC1912 2.4 and RFC2181 10.3 state that there should be no CNAMEs if an NS (or any other) record is present. Note that I only checked arcbroward.com, I did not check the NS records, which should not have CNAMEs either.
FAIL No NSs with CNAMEs ERROR: I checked with your nameservers to see if there were any CNAMEs for your NS records (there shouldn't be), but they all timed out.
WARN Nameservers on separate class C's WARNING: All of your nameservers (listed at the parent nameservers) are in the same Class C (technically, /24) address space, which means that they are probably at the same physical location. Your nameservers should be at geographically dispersed locations. You should not have all of your nameservers at the same location. RFC2182 3.1 goes into more detail about secondary nameserver location.
PASS All NS IPs public OK. All of your NS records appear to use public IPs. If there were any private IPs, they would not be reachable, causing DNS delays.
INFO Nameservers versions Your nameservers have the following versions:
65.83.225.31: "9.2.1"
65.83.225.32: "9.2.1"
PASS Stealth NS record leakage Your DNS servers do not leak any stealth NS records (if any) in non-NS requests.
SOA INFO SOA record Your SOA record [TTL=10800] is:
Primary nameserver: ns4.web.bellsouth.net.
Hostmaster E-mail address: support.swh.belsouth.net.
Serial #: 412020138
Refresh: 10800
Retry: 3600
Expire: 604800
Default TTL: 86400
PASS NS agreement on SOA serial # OK. All your nameservers agree that your SOA serial number is 412020138. That means that all your nameservers are using the same data (unless you have different sets of data with the same serial number, which would be very bad)! Note that the DNS Report only checks the NS records listed at the parent servers (not any stealth servers).
PASS SOA MNAME Check OK. Your SOA (Start of Authority) record states that your master (primary) name server is: ns4.web.bellsouth.net.. That server is listed at the parent servers, which is correct.
PASS SOA RNAME Check OK. Your SOA (Start of Authority) record states that your DNS contact E-mail address is: support@swh.belsouth.net. (techie note: we have changed the initial '.' to an '@' for display purposes).
WARN SOA Serial Number WARNING: Your SOA serial number is: 412020138. That is OK, but the recommended format (per RFC1912 2.2) is YYYYMMDDnn, where 'nn' is the revision. For example, if you are making the 3rd change on 02 May 2000, you would use 2000050203. This number must be incremented every time you make a DNS change.
WARN SOA REFRESH value WARNING: Your SOA REFRESH interval is : 10800 seconds. This seems a bit high. You should consider decreasing this value to about 3600-7200 seconds. RFC1912 2.2 recommends a value between 1200 to 43200 seconds (20 minutes to 12 hours, with the longer time periods used for very slow Internet connections; 12 hours seems very high to us), and if you are using DNS NOTIFY the refresh value is not as important (RIPE recommends 86400 seconds if using DNS NOTIFY). This value determines how often secondary/slave nameservers check with the master for updates. A value that is too high will cause DNS changes to be in limbo for a long time.
PASS SOA RETRY value OK. Your SOA RETRY interval is : 3600 seconds. This seems normal (about 120-7200 seconds is good). The retry value is the amount of time your secondary/slave nameservers will wait to contact the master nameserver again if the last attempt failed.
PASS SOA EXPIRE value OK. Your SOA EXPIRE time: 604800 seconds. This seems normal (about 1209600 to 2419200 seconds (2-4 weeks) is good). RFC1912 recommends 2-4 weeks. This is how long a secondary/slave nameserver will wait before considering its DNS data stale if it can't reach the primary nameserver.
PASS SOA MINIMUM TTL value OK. Your SOA MINIMUM TTL is: 86400 seconds. This seems normal (about 3,600 to 86400 seconds or 1-24 hours is good). RFC2308 suggests a value of 1-3 hours. This value used to determine the default (technically, minimum) TTL (time-to-live) for DNS entries, but now is used for negative caching.
MX INFO MX Record Your 1 MX record is:
10 fl.arcbroward.com. [TTL=10800] IP=208.62.31.131 [TTL=10800] [US]
PASS Invalid characters OK. All of your MX records appear to use valid hostnames, without any invalid characters.
PASS All MX IPs public OK. All of your MX records appear to use public IPs. If there were any private IPs, they would not be reachable, causing slight mail delays, extra resource usage, and possibly bounced mail.
PASS MX records are not CNAMEs OK. Looking up your MX record did not just return a CNAME. If an MX record query returns a CNAME, extra processing is required, and some mail servers may not be able to handle it.
PASS MX A lookups have no CNAMEs OK. There appear to be no CNAMEs returned for A records lookups from your MX records (CNAMEs are prohibited in MX records, according to RFC974, RFC1034 3.6.2, RFC1912 2.4, and RFC2181 10.3).
PASS MX is host name, not IP OK. All of your MX records are host names (as opposed to IP addresses, which are not allowed in MX records).
WARN Multiple MX records WARNING: You only have 1 MX record. If your primary mail server is down or unreachable, there is a chance that mail may have troubles reaching you.
PASS Differing MX-A records OK. I did not detect differing IPs for your MX records.
PASS Duplicate MX records OK. You do not have any duplicate MX records (pointing to the same IP). Although technically valid, duplicate MX records can cause a lot of confusion, and waste resources.
FAIL Reverse DNS entries for MX records ERROR: The IP of one or more of your mail server(s) have no reverse DNS (PTR) entries (if you see "Timeout" below, it may mean that your DNS servers did not respond fast enough). RFC1912 2.1 says you should have a reverse DNS for all your mail servers. It is strongly urged that you have them, as many mailservers will not accept mail from mailservers with no reverse DNS entry. You can double-check using the 'Reverse DNS Lookup' tool at the DNSstuff site (it contacts your servers in real time; the reverse DNS lookups in the DNS report use our local caching DNS server). The problem MX records are:
131.31.62.208.in-addr.arpa [No reverse DNS entry (rcode: 3 ancount: 0) (check it)]
Mail PASS Connect to mail servers OK: I was able to connect to all of your mailservers.
PASS Mail server host name in greeting OK: All of your mailservers have their host name in the greeting:
fl.arcbroward.com:
220 fl.arcbroward.com Microsoft ESMTP MAIL Service, Version: 5.0.2195.6713 ready at Fri, 29 Apr 2005 00:14:41 -0400
PASS Acceptance of NULL <> sender OK: All of your mailservers accept mail from "<>". You are required (RFC1123 5.2.9) to receive this type of mail (which includes reject/bounce messages and return receipts).
PASS Acceptance of postmaster address OK: All of your mailservers accept mail to postmaster@arcbroward.com (as required by RFC822 6.3, RFC1123 5.2.7, and RFC2821 4.5.1).
PASS Acceptance of abuse address OK: All of your mailservers accept mail to abuse@arcbroward.com.
INFO Acceptance of domain literals WARNING: One or more of your mailservers does not accept mail in the domain literal format (user@[0.0.0.0]). Mailservers are technically required RFC1123 5.2.17 to accept mail to domain literals for any of its IP addresses. Not accepting domain literals can make it more difficult to test your mailserver, and can prevent you from receiving E-mail from people reporting problems with your mailserver. However, it is unlikely that any problems will occur if the domain literals are not accepted (mailservers at many common large domains have this problem).
fl.arcbroward.com's postmaster@[208.62.31.131] response:
>>> RCPT TO:<postmaster@[208.62.31.131]>
<<< 550 5.7.1 Unable to relay for postmaster@[208.62.31.131]
PASS Open relay test OK: All of your mailservers appear to be closed to relaying. This is not a thorough check, you can get a thorough one here.
fl.arcbroward.com OK: 550 5.7.1 Unable to relay for Not.abuse.see.
WARN SPF record Your domain does not have an SPF record. This means that spammers can easily send out E-mail that looks like it came from your domain, which can make your domain look bad (if the recipient thinks you really sent it), and can cost you money (when people complain to you, rather than the spammer). You may want to add an SPF record ASAP, as 01 Oct 2004 was the target date for domains to have SPF records in place (Hotmail, for example, started checking SPF records on 01 Oct 2004).
Your A record is:
CNAME arcbroward.com. [TTL=10800]
arcbroward.com. A 65.83.225.173 [TTL=10800] [US]
PASS All public OK. All of your appear to be public IPs. If there were any private IPs, they would not be reachable, causing problems reaching your web site.
PASS CNAME Lookup OK. You do have a CNAME record for which can cause some confusion. However, this is legal. Your CNAME entry also returns the A record for the CNAME entry, which is good -- otherwise, it would require an extra DNS lookup, which slightly delays the initial access to the website and use extra bandwidth. Note that if the CNAME points to another CNAME, it will likely cause problems.
Legend:
Rows with a FAIL indicate a problem that in most cases really should be fixed.
Rows with a WARN indicate a possible minor problem, which often is not worth pursuing.
Note that all information is accessed in real-time (except where noted), so this is the freshest information about your domain.
--------------------------------------------------------------------------------
Thanks for you help
Our website is hosted by BellSouth. BellSouth did some type of migration over the past year. They claim that we no longer have a "static IP" but instead some type of dynamic that functions like a static. (can never get a good explanation from them)
We also think it is a DNS problem.
Our local domain name is the same as our external website. I think this is the root of the problem.
When we try to access website from within our LAN, we get error "page cannot be displayed..."
nslookup:
Results Returned for "arcbroward.com":
Name: arcbroward.com
Address: 65.83.225.173
tracert results:
1)208.62.31.129
2)68.152.171.89
3)205.152.144.94
4)205.152.110.62
5)65.83.237.138
6)axr00asm-0-3-0.bellsouth.net [65.83.236.12]
7)ixc00asm-4-0.bellsouth.net [65.83.237.1]
8)205.152.152.50
9)205.152.152.86
10)66.21.240.205
11)host04.swh.bellsouth.net [65.83.225.173]
We have no other resolution problems that I know of. All other sites are accessible.
When I ping arcbroward.com, our terminal server replies with the internal address of 192.168.0.4
I did some research and mentioned the host entry to a consultant that came out to try to fix this. I don't remember what his response was. I will post when he calls me back. Here are the results of a DNS report I ran that may be of use, too:
--------------------------------------------------------------------------------
DNS Report for arcbroward.com
Generated by at 04:14:37 GMT on 29 Apr 2005.
Category Status Test Name Information
Parent PASS Missing Direct Parent check OK. Your direct parent zone exists, which is good. Some domains (usually third or fourth level domains, such as example.co.us) do not have a direct parent zone ('co.us' in this example), which is legal but can cause confusion.
INFO NS records at parent servers Your NS records at the parent servers are:
ns4.web.bellsouth.net. [65.83.225.31] [TTL=172800] [US]
ns5.web.bellsouth.net. [65.83.225.32] [TTL=172800] [US]
[These were obtained from m.gtld-servers.net]
PASS Parent nameservers have your nameservers listed OK. When someone uses DNS to look up your domain, the first step (if it doesn't already know about your domain) is to go to the parent servers. If you aren't listed there, you can't be found. But you are listed there
PASS Glue at parent nameservers OK. The parent servers have glue for your nameservers. That means they send out the IP address of your nameservers, as well as their host names.
NS INFO NS records at your nameservers Your NS records at your nameservers are:
ns5.web.bellsouth.net. [no glue provided] [TTL=10800]
ns4.web.bellsouth.net. [no glue provided] [TTL=10800]
PASS Mismatched glue OK. The DNS report did not detect any discrepancies between the glue provided by the parent servers and that provided by your authoritative DNS servers.
PASS All nameservers report identical NS records OK. The NS records at all your nameservers are identical.
PASS All nameservers respond OK. All of your nameservers listed at the parent nameservers responded.
PASS Nameserver name validity OK. All of the NS records that your nameservers report seem valid (no IPs or partial domain names).
PASS Number of nameservers OK. You have 2 nameservers. You must have at least 2 nameservers (RFC2182 section 5 recommends at least 3 nameservers), and preferably no more than 7.
PASS Lame nameservers OK. All the nameservers listed at the parent servers answer authoritatively for your domain.
PASS Missing (stealth) nameservers OK. All 2 of your nameservers (as reported by your nameservers) are also listed at the parent servers.
PASS Missing nameservers 2 OK. All of the nameservers listed at the parent nameservers are also listed as NS records at your nameservers.
PASS No CNAMEs for domain OK. There are no CNAMEs for arcbroward.com. RFC1912 2.4 and RFC2181 10.3 state that there should be no CNAMEs if an NS (or any other) record is present. Note that I only checked arcbroward.com, I did not check the NS records, which should not have CNAMEs either.
FAIL No NSs with CNAMEs ERROR: I checked with your nameservers to see if there were any CNAMEs for your NS records (there shouldn't be), but they all timed out.
WARN Nameservers on separate class C's WARNING: All of your nameservers (listed at the parent nameservers) are in the same Class C (technically, /24) address space, which means that they are probably at the same physical location. Your nameservers should be at geographically dispersed locations. You should not have all of your nameservers at the same location. RFC2182 3.1 goes into more detail about secondary nameserver location.
PASS All NS IPs public OK. All of your NS records appear to use public IPs. If there were any private IPs, they would not be reachable, causing DNS delays.
INFO Nameservers versions Your nameservers have the following versions:
65.83.225.31: "9.2.1"
65.83.225.32: "9.2.1"
PASS Stealth NS record leakage Your DNS servers do not leak any stealth NS records (if any) in non-NS requests.
SOA INFO SOA record Your SOA record [TTL=10800] is:
Primary nameserver: ns4.web.bellsouth.net.
Hostmaster E-mail address: support.swh.belsouth.net.
Serial #: 412020138
Refresh: 10800
Retry: 3600
Expire: 604800
Default TTL: 86400
PASS NS agreement on SOA serial # OK. All your nameservers agree that your SOA serial number is 412020138. That means that all your nameservers are using the same data (unless you have different sets of data with the same serial number, which would be very bad)! Note that the DNS Report only checks the NS records listed at the parent servers (not any stealth servers).
PASS SOA MNAME Check OK. Your SOA (Start of Authority) record states that your master (primary) name server is: ns4.web.bellsouth.net.. That server is listed at the parent servers, which is correct.
PASS SOA RNAME Check OK. Your SOA (Start of Authority) record states that your DNS contact E-mail address is: support@swh.belsouth.net. (techie note: we have changed the initial '.' to an '@' for display purposes).
WARN SOA Serial Number WARNING: Your SOA serial number is: 412020138. That is OK, but the recommended format (per RFC1912 2.2) is YYYYMMDDnn, where 'nn' is the revision. For example, if you are making the 3rd change on 02 May 2000, you would use 2000050203. This number must be incremented every time you make a DNS change.
WARN SOA REFRESH value WARNING: Your SOA REFRESH interval is : 10800 seconds. This seems a bit high. You should consider decreasing this value to about 3600-7200 seconds. RFC1912 2.2 recommends a value between 1200 to 43200 seconds (20 minutes to 12 hours, with the longer time periods used for very slow Internet connections; 12 hours seems very high to us), and if you are using DNS NOTIFY the refresh value is not as important (RIPE recommends 86400 seconds if using DNS NOTIFY). This value determines how often secondary/slave nameservers check with the master for updates. A value that is too high will cause DNS changes to be in limbo for a long time.
PASS SOA RETRY value OK. Your SOA RETRY interval is : 3600 seconds. This seems normal (about 120-7200 seconds is good). The retry value is the amount of time your secondary/slave nameservers will wait to contact the master nameserver again if the last attempt failed.
PASS SOA EXPIRE value OK. Your SOA EXPIRE time: 604800 seconds. This seems normal (about 1209600 to 2419200 seconds (2-4 weeks) is good). RFC1912 recommends 2-4 weeks. This is how long a secondary/slave nameserver will wait before considering its DNS data stale if it can't reach the primary nameserver.
PASS SOA MINIMUM TTL value OK. Your SOA MINIMUM TTL is: 86400 seconds. This seems normal (about 3,600 to 86400 seconds or 1-24 hours is good). RFC2308 suggests a value of 1-3 hours. This value used to determine the default (technically, minimum) TTL (time-to-live) for DNS entries, but now is used for negative caching.
MX INFO MX Record Your 1 MX record is:
10 fl.arcbroward.com. [TTL=10800] IP=208.62.31.131 [TTL=10800] [US]
PASS Invalid characters OK. All of your MX records appear to use valid hostnames, without any invalid characters.
PASS All MX IPs public OK. All of your MX records appear to use public IPs. If there were any private IPs, they would not be reachable, causing slight mail delays, extra resource usage, and possibly bounced mail.
PASS MX records are not CNAMEs OK. Looking up your MX record did not just return a CNAME. If an MX record query returns a CNAME, extra processing is required, and some mail servers may not be able to handle it.
PASS MX A lookups have no CNAMEs OK. There appear to be no CNAMEs returned for A records lookups from your MX records (CNAMEs are prohibited in MX records, according to RFC974, RFC1034 3.6.2, RFC1912 2.4, and RFC2181 10.3).
PASS MX is host name, not IP OK. All of your MX records are host names (as opposed to IP addresses, which are not allowed in MX records).
WARN Multiple MX records WARNING: You only have 1 MX record. If your primary mail server is down or unreachable, there is a chance that mail may have troubles reaching you.
PASS Differing MX-A records OK. I did not detect differing IPs for your MX records.
PASS Duplicate MX records OK. You do not have any duplicate MX records (pointing to the same IP). Although technically valid, duplicate MX records can cause a lot of confusion, and waste resources.
FAIL Reverse DNS entries for MX records ERROR: The IP of one or more of your mail server(s) have no reverse DNS (PTR) entries (if you see "Timeout" below, it may mean that your DNS servers did not respond fast enough). RFC1912 2.1 says you should have a reverse DNS for all your mail servers. It is strongly urged that you have them, as many mailservers will not accept mail from mailservers with no reverse DNS entry. You can double-check using the 'Reverse DNS Lookup' tool at the DNSstuff site (it contacts your servers in real time; the reverse DNS lookups in the DNS report use our local caching DNS server). The problem MX records are:
131.31.62.208.in-addr.arpa [No reverse DNS entry (rcode: 3 ancount: 0) (check it)]
Mail PASS Connect to mail servers OK: I was able to connect to all of your mailservers.
PASS Mail server host name in greeting OK: All of your mailservers have their host name in the greeting:
fl.arcbroward.com:
220 fl.arcbroward.com Microsoft ESMTP MAIL Service, Version: 5.0.2195.6713 ready at Fri, 29 Apr 2005 00:14:41 -0400
PASS Acceptance of NULL <> sender OK: All of your mailservers accept mail from "<>". You are required (RFC1123 5.2.9) to receive this type of mail (which includes reject/bounce messages and return receipts).
PASS Acceptance of postmaster address OK: All of your mailservers accept mail to postmaster@arcbroward.com (as required by RFC822 6.3, RFC1123 5.2.7, and RFC2821 4.5.1).
PASS Acceptance of abuse address OK: All of your mailservers accept mail to abuse@arcbroward.com.
INFO Acceptance of domain literals WARNING: One or more of your mailservers does not accept mail in the domain literal format (user@[0.0.0.0]). Mailservers are technically required RFC1123 5.2.17 to accept mail to domain literals for any of its IP addresses. Not accepting domain literals can make it more difficult to test your mailserver, and can prevent you from receiving E-mail from people reporting problems with your mailserver. However, it is unlikely that any problems will occur if the domain literals are not accepted (mailservers at many common large domains have this problem).
fl.arcbroward.com's postmaster@[208.62.31.131] response:
>>> RCPT TO:<postmaster@[208.62.31.131]>
<<< 550 5.7.1 Unable to relay for postmaster@[208.62.31.131]
PASS Open relay test OK: All of your mailservers appear to be closed to relaying. This is not a thorough check, you can get a thorough one here.
fl.arcbroward.com OK: 550 5.7.1 Unable to relay for Not.abuse.see.
WARN SPF record Your domain does not have an SPF record. This means that spammers can easily send out E-mail that looks like it came from your domain, which can make your domain look bad (if the recipient thinks you really sent it), and can cost you money (when people complain to you, rather than the spammer). You may want to add an SPF record ASAP, as 01 Oct 2004 was the target date for domains to have SPF records in place (Hotmail, for example, started checking SPF records on 01 Oct 2004).
Your A record is:
CNAME arcbroward.com. [TTL=10800]
arcbroward.com. A 65.83.225.173 [TTL=10800] [US]
PASS All public OK. All of your appear to be public IPs. If there were any private IPs, they would not be reachable, causing problems reaching your web site.
PASS CNAME Lookup OK. You do have a CNAME record for which can cause some confusion. However, this is legal. Your CNAME entry also returns the A record for the CNAME entry, which is good -- otherwise, it would require an extra DNS lookup, which slightly delays the initial access to the website and use extra bandwidth. Note that if the CNAME points to another CNAME, it will likely cause problems.
Legend:
Rows with a FAIL indicate a problem that in most cases really should be fixed.
Rows with a WARN indicate a possible minor problem, which often is not worth pursuing.
Note that all information is accessed in real-time (except where noted), so this is the freshest information about your domain.
--------------------------------------------------------------------------------
Thanks for you help
- Thread starter
- #6
Well, the domain looks good. DNS is working okay. You can trace to it okay. It's not a DNS problem per se. I think that the issue is that you are using the same domain name internally and so hosts are looking for another host on the LAN, not the external web server.
"When I ping arcbroward.com, our terminal server replies with the internal address of 192.168.0.4"
Where is it getting this resolution from? do you have a hosts file? Internal DNS? Are your hosts using your internal DNS or the ISP's DNS?
Chris.
**********************
Chris A.C, CCNA, CCSA
**********************
"When I ping arcbroward.com, our terminal server replies with the internal address of 192.168.0.4"
Where is it getting this resolution from? do you have a hosts file? Internal DNS? Are your hosts using your internal DNS or the ISP's DNS?
Chris.
**********************
Chris A.C, CCNA, CCSA
**********************
GlenJohnson
MIS
Chris is correct. The problem is with the name. Has this ever worked? I remember you said users could access it using ip, but not name. If you create a host file on a client, can the client access the website? Do you have any pointers installed? What happens when you click on this?
Glen A. Johnson
"Without words, without writing and without books there would be no history there could be no concept of humanity"
Hermann Hesse (1877-1962), German-born Swiss writer
Tek-Tips in Chicago IL
I had the same problem.
All I had to do was and a entry for a host named ' And point the IP to my internal webserver.
So that when users enter ' your dns looks for a host 'www' which it knows as the IP of your internal webserver.
Assuming your DNS doesn't resolve internal hostnames for external users it should work just as well.
All I had to do was and a entry for a host named ' And point the IP to my internal webserver.
So that when users enter ' your dns looks for a host 'www' which it knows as the IP of your internal webserver.
Assuming your DNS doesn't resolve internal hostnames for external users it should work just as well.
- Thread starter
- #10
Thanks Saugilsr. I made the entry for the host as you suggested and it work. Is there any way I can do an entry on the server instead of going to all 150 clients?
Thanks
Thanks
Yeah. In your dns snapin on the server:
In the arcbroward.com forward lookup zone right click, add new 'A Host'.
The name is 'Enter the IP of your webserver. Done.
So when a client computer needs to access they will look in your server's dns first for a host 'www' and resolve the internal ip.
You may have to clear out some browser caches but otherwise it should be all right.
In the arcbroward.com forward lookup zone right click, add new 'A Host'.
The name is 'Enter the IP of your webserver. Done.
So when a client computer needs to access they will look in your server's dns first for a host 'www' and resolve the internal ip.
You may have to clear out some browser caches but otherwise it should be all right.
- Thread starter
- #12
I did what you suggested on the server. The result was the following:
The DNS server: When I put in our web address, I get a logon screen and when I put in my credentials, it goes to IIS management screen.
From all other servers and clients: I get "under construction" page. Any suggestions?
The DNS server: When I put in our web address, I get a logon screen and when I put in my credentials, it goes to IIS management screen.
From all other servers and clients: I get "under construction" page. Any suggestions?
What Saugilsr mentions regarding the DNS record for only for a dedicated webhost; ie the IP address points to a server on which ONLY your website is hosted. If you point to an IP address for a web server which has virtual hosting (hosts multiple websites), you will get to pages such as you have mentioned (no page configured etc).
Except for moving to a dedicated server for hosting, am not sure what other options you may have.
Actually, if you say it works when you put it into the HOST file, why not have your logon script copy that HOST file over what users have on their PCs? Worth a try.
Claudius (What certifications??)
Except for moving to a dedicated server for hosting, am not sure what other options you may have.
Actually, if you say it works when you put it into the HOST file, why not have your logon script copy that HOST file over what users have on their PCs? Worth a try.
Claudius (What certifications??)
- Status
Similar threads
- Locked
- Question