Testing Your Internet Facing Infrastructure

If you are an organisation with any Internet facing resources, it’s important for you to ensure that all the supporting infrastructure is alive, well, and functioning as it should be.  For large institutions, you probably already have all sorts of monitoring in place that can tell you of any problems in near-real time. You do, don’t you?
If you don’t (or you want to augment your existing services) there are number of sites on the Internet that will do that for you and provide you with the results. One site, Pingdom.com provides both a free and a pay service.
The pay service is aimed at monitoring the uptime and performance of you servers, including not only your corporate web server, but others too such as your Lync Edge server.  The Pingdom  service provides real-time monitoring service that can alert you is something interesting happens. You can get alerts ins SMS, Twitter and E-mail. The service also keeps records of the tests performed and the results which enable you to keep track of the performance of your key web sites. You can even get alerts on your mobile phone (Android and IOS it looks like – no Windows phone). 
And there’s even a REST-based API for you to use! The API produces JSON encoded output. Invoking the API and interpreting the JDON responses were features added to PowerShell V3 – thus with the pay-service APIs, you could write PowerShell scripts to manage your Pingdom service!
If you are a Lync Admin, and are providing either remote access (i.e. to your users who are coming in via the Internet) or are providing federation to customers and clients, you have a significant challenge to setup your external infrastructure and ensuring it continues to function. The pay service can provide you with a useful set of eyes/ears on the internet, ensuring that all the infrastructure aspects of your Lync Internet features are working as they should – and will inform you when that stops.
Pingdom also offers three sets of free tests for you to use:

• Ping/Traceroute – provides basic ping and traceroute to your site from Pingdom’s site. This provides a useful point of view in terms of your infrastructure’s availability/reachability across the Internet. The ping comes from one of the many probe servers used by Pingdom - there are over 60!
• DNS Health – this page checks to see if external Internet DNS is setup correctly. DNS setup is critical to ensure your site is reachable but is also easy to misconfigure. This page tests your infrastructure, and provides details as to what it finds: good or bad. There’s also a troubleshooting guide to help you to understand the errors that the checker might find and how to resolve them. See here to see what precisely the DNS test is doing for you.
• Full Page Test – this page tests the performance of a web page on your site and returns a wealth information.  The waterfall view shows all the files that downloaded and how long each download takes.  The Performance Grade view shows you how your page performs against a benchmark set of metrics. The Page Analysis view analyses the download, providing details of the server response code, how the page loaded, what sorts of documents are being downloaded, etc.

Here’s an example of using the Full Page Test against my Office 365 site, Reskit.Net:

This site is a fairly simple SharePoint site – and you can see each of the individual files downloaded to make up the page and what’s happening during the downloading of each file. You can use this waterfall graph to possibly optimise the page for faster downloads (and less bandwidth used).
And speaking of Free, Pingdom also provides a free check of a single site. This is the same check you could perform using their paid service, but free. The pay service allows you to check more than one site/page, and other services (see https://my.pingdom.com/account/subscription for details of the pay version).
All in all these free tools are pretty good – and I discovered a small DNS configuration issue I need to resolve! Nice catch Pingdom. And the pay tools look like being useful as well.

Technorati Tags: Lync,Monitoring,PowerShell

The Root-Servers vs. the RootServers–a DNS mystery

I was working today with Nslookup running against the root servers to see what responses I got, and what the TTL times were for records retrieved were.  When I first tried, I got some really weird results:

This really didn’t make any sense – since when did the responsible person for the root servers on the internet devolved to buydomains.com? Then I noticed the problem. Look carefully at the SOA I was trying to resolve. Retying the command with a strategic adjustment yielded success:

So the mystery was easy – my typing stinks. But if I can make that mistake, no doubt others might.

 

Technorati Tags: DNS

Google DNS

Last week,  Google announced a new service, Google DNS. The idea is simple – instead of using your own, or your ISPs DNS, you use theirs. Most readers of this blog will know what DNS is, why it’s really important and how to configure and manage it, at least I sure hope so! But that leaves a great percentage of the Internet-using population who both don’t know and  probably don’t care as it all just works.

The idea of an independent DNS network is not new. Several years ago, I wrote about the ORSN, the European Open Root Server Network. I sometimes set systems up to use it, but like most folks, the DNS that most of I use is a part of the huge distributed network that comes as part of the Internet. Personally, I have my own internal DNS server which serves as a resolver for the  systems in my network, as well as hosting the records for my AD domain.

The Google DNS service is just a resolving DNS cache – they host no zones  (other than Google’s own zones) and they do not host any root domains. They just resolve the names you send it, and cache those results for others to use. Google say their goal is “to benefit users worldwide while also helping the tens of thousands of DNS resolvers improve their services, ultimately making the web faster for everyone.” A laudable goal, but is it actually a useful service. On Google’s code blog, they cite three main advantages: Speed, Security and Validity. I’ve spent some this morning looking at the speed claim.

Google DNS is hosted at several servers. In their configuration instructions, they :there are two servers (at 8.8.8.8 and at 8.8.8.4), although another document shows 5 servers (ns[1-4].google.com). I have been doing some testing, using PathPing.Exe this morning to look at performance. Access to these servers from the UK (where this article is being written) is quick and has no packet loss. The path to the servers goes first via my ISP to Google-Lon.Google.Com and then via a few un-named routers to the DNS server. The RTT to 8.8.8.8 was 38 ms.

I then ran a PathPing against my own ISP’s DNS server and another DNS Server run by Demon Internet. For both UK servers, I see a shorter route (10 hops vs 12) – not surprising as these servers are in the UK, and Google’s I suspect are not.I also see a faster path (31 ms to Demon, 28 to Clara.Net vs 38 to Google). Packet loss to both UK servers is also zero although the route to Demon’s name server goes via  tele-service-22-s267.router.demon.net which drops 100% of the ICMP packets (no such issue to Clara.Net. So on path grounds, using Google does not seem to provide much benefit as it’s slower and has more hops.

As for security, Google makes the valid point that DNS is vulnerable to attach – it can be spoofed routing users to malicious sites rather than the intended site. The DNSSEC protocol is meant to attack that problem through cryptography, but DNSSEC is not yet in widespread use (and is a lot more work to setup). I’m not sure I entirely buy the argument that they are any better at protecting DNS than my ISP. We’ll have to see.

The validity advantage that Google cites seems even less interesting. They say their DNS servers comply with DNS Standards. Well I’d sure hope so – a non-standards compliant DNS server would be a bit a a waste of time. They also avoid blocking, filtering or redirection. Doing some testing using NSLookup, it looks like they don’t do wildcard DNS – thus trying to resolve (hopefully!) non-existent domains gives teh expected error. I tried resolving x.microsoft.com and foo.foo.foo – both queries were “refused” since ns1.google.net could not find those domains.

All in all, this looks to be a reasonably fast and competent DNS solution. For many users, using this might benefit their web surfing. For me, it looks a tad slower – so ‘buyer’ beware. As for the security argument, I accept they intend to make their service secure, but experience will show whether this is a good argument, or not.

Technorati Tags: Google,Claranet,Demon,DNS

Global DNS Query Block List in Windows Server 2008

Looking over at the TechNet DNS sub-site, I've been reading a neat document: DNS Server Global Query Block List. The document describes a new feature in WS08's DNS Server: the Global Query Block List.

Some network protocols rely on DNS name resolution  to resolve specific well known host names. Two examples are WPAD and ISATAP. Malicious users could register hosts computers using these names and thus pose as a legitimate server.

Windows uses the web proxy auto-discovery protocol to discover a local web proxy. The client queries DNS for wpad.<domain> where <domain> is the computer's domain name (eg wpad.contoso.com for a computer in the contoso.com domain).

Intra-site Automatic Tunnel Addressing Protocol (ISATAP) is part of the set of protocols used to aid in IPv6 migration. ISATAP tunnels IPv6 traffic in IPv4 packets. The IPv6 traffic comes from an IPv6 network to the ISATAP server for for transmission across IPv4 only networks. Essentially, ISATAP servers encapsulate inbound IPv6 traffic into IPV4 traffic and passes it to another ISATAP server for conversion back to IPv6 and transmission to another IPv6 aware host. ISATAP does not provide for automatic ISATAP router discovery. ISATAP hosts use a potential routers list (PRL) to discover available ISATAP routers, typically  by using DNS to locate a host named isatap on the local domain (eg isatap.contoso.com).

In the case of both these protocols, if a malicious user was to rename their system it could then appear to be a genuine server, to the potential detriment of the user. The result may just be a denial of service, but could be worse. And even if your network doesn't use these protocols, your clients my be trying to use them anyway. In that case, they are vulnerable to the hijacking that DNS dynamic update enables.

The Server Block list prevents such hijacking by refusing to reply to a query. This renders the dynamic update useless. If you subsequently implement either protocol, then just remove the relevant name from the block list. Before doing this, you should manually enter the relevant RRs into DNS, and adjust the ACLs to remove the miscreant's ability to hijack the name.

And of course, you can use this same technique in your own environment, perhaps by protecting a computer called accounting, or manufacturing or something similar.

To configure the DNS query block list, you use DNSCMD as shown here:

PS C:\foo> dnscmd /config /globalqueryblocklist wpad isatap gratefuldeadmusiclibrary

Registry property globalqueryblocklist successfully reset.
Command completed successfully.

To view the current block list, use the /info switch with DNSCMD as shown here:

PS C:\foo> dnscmd /info /globalqueryblocklist

Query result:
String:  wpad
String:  isatap
String:  gratefuldeadmusiclibrary

Command completed successfully.

A neat feature!

Technorati Tags: Windows Server 2008,DNS,Global Query Block List,WPAD,ISATAP