How to troubleshoot DNS issues with Web Security.cloud
Article ID: 178373
Updated On:
Products
Web Security.cloud
Issue/Introduction
Resolution
This is a guide for Symantec Cloud clients and partners who are having DNS-related issues with the Symantec Cloud Web Security services. These procedures may be useful to perform in cooperation with a Symantec Cloud support team member to test your server's ability to resolve hostnames correctly. This procedure can be especially useful if you suspect you're having DNS-related problems with the Web services which coincides with Symantec Cloud performing an automatic failover of a portion of the infrastructure.
The basic procedure
1. Start -> Run...
Type "cmd" in the input box next to "Open:". This will launch and command prompt window.
At the command prompt, type "nslookup" and press Enter.
This will launch the nslookup command prompt (which is specific to nslookup and not the same as a DOS prompt).
2. At the nslookup prompt, type "set debug" and press Enter. This will enable full debugging output to provide extra information.
3. For each DNS server listed, query the server for "proxy.X.webscanningservice.com", where "X" is the regional code ("eu", "ap", or "us", for Europe, Asia-Pacific, and US/Americas, respectively).
- proxy.eu.webscanningservice.com
- proxy.ap.webscanningservice.com
- proxy.us.webscanningservice.com
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\wporquet>nslookup
Default Server: mlabs007.messagelabs.com
Address: 10.5.1.7
> set debug
> proxy.us.webscanningservice.com
Server: mlabs007.messagelabs.com
Address: 10.5.1.7
------------
Got answer:
HEADER:
opcode = QUERY, id = 2, rcode = NXDOMAIN
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 1, additional = 0
QUESTIONS:
proxy.us.webscanningservice.com.messagelabs.com, type = A, class = IN
AUTHORITY RECORDS:
-> messagelabs.com
ttl = 3600 (1 hour)
primary name server = mlabs007.messagelabs.com
responsible mail addr = admin
serial = 457113
refresh = 900 (15 mins)
retry = 600 (10 mins)
expire = 86400 (1 day)
default TTL = 3600 (1 hour)
------------
------------
Got answer:
HEADER:
opcode = QUERY, id = 3, rcode = NOERROR
header flags: response, auth. answer
questions = 1, answers = 1, authority records = 0, additional = 0
QUESTIONS:
proxy.us.webscanningservice.com, type = A, class = IN
ANSWERS:
-> proxy.us.webscanningservice.com
internet address = 216.82.251.227
ttl = 20 (20 secs)
------------
Name: proxy.us.webscanningservice.com
Address: 216.82.251.227
> exit
C:\>exit
4a. If the TTL looks to be within 20 seconds (e.g. the output line above, "ttl = 20 (20 secs)") the issue is likely with the the a client's machines on their network, or perhaps with their browsers. If you still require further assistance, please copy and paste the relevant outputs into an email for further analysis by the MessageLabs support team.
4b. If the TTL is not within 20 seconds, or it doesn't look to be counting down at all, gain access to the DNS server in question.
5a. If the DNS server in question from 4b is your ISP's, raise a ticket with your ISP stating that they are not correctly adhering to the 20-second TTL.
5b. If the DNS server (or proxy server/firewall that is handling your DNS) is your own, or a server for which you have a support contract, note the type and version of the server.
It may be that this server obtains its DNS from another DNS server, or you have applied the suggested fixes and still see the same problem.
To confirm where this server retrieves its DNS from and thus continue investigations, complete steps 1,2,3 above from the DNS server you have applied the fixes to, until you have traced the issue to the problematic server. Often this can be your ISP's DNS servers and if so, please revert to step 5a.
5c. If you have found fault with your server, but a suggested fix is not listed in step 5b, and the fault likely is not caused by your ISP - please raise it as a problem with the associated vendor of your DNS server/proxy/firewall stating that the server is not correctly observing TTLs.
Microsoft ISA Server issues
If you are using Microsoft ISA Server 2000, keep in mind this server has a typical (default) 6 hour TTL on DNS for our hostnames. ISA versions 2004 and ISA 2006 both overwrite it to 1 hour. Microsoft Server (DNS Server) is also 1 hour. ISA 2000 can be changed in the registry. For ISA 2004 and 2006 there is a script that can be run to change it.
When MessageLabs performs an automatic failover of a trip, this could suddenly highlight ISA server caching problems on a client's side in a way that breaks DNS resolution.
You may refer affected clients to these Microsoft knowledgebase articles, which may help resolve common ISA Server problems with MessageLabs infrastructure:
ISA has its own way of storing a record for about 6 hours - so if the record updated at 10:00 and we do a trip failover at 10:05, the client will get updated records at 16:00 - but this is not on every setup.
Microsoft Server 2003 issues
From our quick investigations we have found that on Server 2003 the TTL by default is set to 1 hour. MessageLabs TTL is set to 20 seconds so as soon as we see a Web scanning trip start to deteriorate in performance we change the DNS records. This should enable our customers to see an uninterrupted failover. However, if a client's DNS has a TTL set to 1 hour (by the Microsoft DNS server) they will not swap over to the new DNS information for an hour, thereby seeing deterioration in service and then a possible total loss of service until the DNS record updates.
Here's a Microsoft knowledgebase article that shows how to override the TTL of Microsoft Server 2003.
In case you need to troubleshoot with a customer, here's a common test SCAs perform to find the TTL of the DNS:
Open a DOS window (cmd.exe).
Type ‘nslookup’
Type ‘set debug’
Type ‘proxy.eu.webscanningservice.com’
Press Enter
Novell BorderManager Issues
We have discovered that Novell BorderManager proxy service has a five minute DNS refresh hard-coded, and this has resulted in outages with our clients in the past.
Tracing back
You may want to trace back, i.e. use other nameservers if you can, such as those provided by your upstream provider (British Telecom, Allstream, etc.), or any servers that appeared in the chain in step 3. Query each one in the chain until you find a broken TTL result.
Two alternate DNS servers you can use, especially for North American clients: 206.222.68.10 and 206.222.68.130. They belong to Allstream, they are nicely distributed and very resilient.
Additional Information
DESCRIPTION :
Web services DNS troubleshooting guide
Feedback
Yes
No
Powered by
