the cold

I guess since we live in "Twilight territory" (Forks is west of us -- past Port Angeles -- we are all in Clallam County), I think with the current weather we can all qualify as "the cold ones". For the last two months we have been in a season of never ending Fall. The daytime highs never really were below 50F and the lows hardly touched freezing. Then all of a sudden, ouch! -- it got cold, 29F and dropping as I write this. To the credit of the weather forecasters, I will admit they DID predict this -- so I spent a good part of the last couple of days preparing for it: The cars were gassed up (we are down to the unheard of price of $1.79/gallon here finally after a few years of $2-$3-$4 prices), I got gas for the generator, checked and wrapped the faucets, moved the cows and put the heater in their water trough. All the little things. It all started on Friday as a simple windstorm -- we only lost the top half of one tree -- hurricane force wind gusts are common here on the North Olympic Peninsula -- something people don't realize. Then last night we got about 2-3 inches of dry snow. Now it's supposed to get cold (in the teens) -- the coldest we've seen since 1990. I know, midwesterners and east coasters think this is balmy...

Why say all of this? Well I intend to release 10.80 mid-week. But if the weather interferes (internet disruptions, power failures, more snow...), it may be delayed.

Recession

On Monday December 1, the National Bureau of Economic Research (NBER) placed the start of the recession at December 2007. I would place it a bit earlier. We noticed a definite drop in business beginning in September 2007.

Specialized DNS Tools

Authoritative DNS servers are databases that contain all the records describing a domain in what are called 'zones'. When you do an IP address lookup of a hostname within a domain, that query may end up going all the way to the authoritative servers using a process known as recursion or it may come from a cached record along the way.

There are usually two authoritative servers, but sometimes more servers are used in the case of a large company with a distributed network. In some DNS implementations, the DNS maintainer changes a record like an MX record defining which machine handles SMTP email by hand and at the same time changes the serial number to show that the zone was altered. This serial number change is automated in other implementions.

The secondary servers get zone information from the primary server when they see that the serial number in SOA record in the primary server is different than the serial number currently in the secondary server. If the serial numbers are not the same, then a "zone transfer" is initiated either using a full zone AXFR or an incremental zone IXFR transfer.

As a side note, zone serial numbers are usually in one of two formats, the first being the most common: YYYYMMDDNN format, where YYYY is the year (four digits), MM is the month (two digits), DD is the day of month (two digits) and nn is the version per day (two digits); the second format is unix time, ie. the number of seconds since Jan 1, 1970. Some DNS maintainers use a simple incrementing number like a revision number.

If there is a breakdown in the process of replicating data between the primary and secondary servers (some DNS software can use methods other than zone transfers), the serial numbers may end up out of sync--especially if the serial number is maintained by hand. To check this, a DNS maintainer would have to individually query each authoritative DNS for its current serial number using NSLOOKUP or DIG to verify that they are all in sync.

To help speed up this process, I have created a new tool that finds the authoritative servers for a domain, then it quickly checks each authoritative server for serial number mismatches. It analyzes the results and tells you if there is a problem -- and since we show each authoritative server with its serial number for the zone, you can quickly see the results yourself. This new tool is tentatively called "Auth Serial Check" and it appears in the new DNS Tools - Advanced window in NetScanTools Pro 10.8 (which is not out yet -- be patient).

Thanksgiving and Xbox

So I'm not sure how it happened...after all the family left Thanksgiving evening, my oldest son somehow talked us into letting him buy an Xbox 360. I can't believe we actually let him -- I guess the turkey made us sleepy and dulled our minds. It's his money though -- not mine. He works as a dishwasher in one of those high end Sequim retirement homes. I guess that's our contribution to keeping Walmart in business in this weird economy.

If only I had learned how to write games instead of networking software.

We have a Black Friday sale going on too on our netscantools.com website.

ENUM records

There are several DNS based registries (zones) where someone using VOIP can publish their SIP (or other) connection information. When a device like an IPPBX needs to connect to another internet phone or IPPBX, it can query DNS to find the service information.

For example, if you have a phone number you can query DNS in the e164.org, or e164.arpa namespaces (there are others) for DNS NAPTR records that describe how to connect to the machine handling the phone number. If the number has been registered in DNS, you will get the service type and a regular expression (regex) defining how the connection is to be made. The regex will have a portion delimited by the exclamation point character called a URI, typically in the format !sip:somenumberorstring@exampledomain.net! -- this part is used along with the service type to make the connection to the machine receiving the phone call via SIP or H323.

Our freeware ENUMresolver make it easy to see if the records are in DNS and it displays their format. It accepts a telephone number and can query your default DNS or a specific DNS for the records and displays them. You must include the country code in front of the phone number. Numbers in the North American Numbering Plan (US/Canada/Carribean) need to include the number "1" in front of the phone: 1 (360) 999-9999 is acceptable US format in ENUMresolver.

We just released v2.00 on November 19, so you can now tell it to query a specific DNS and it also has a list of root zones for you to select from -- of course you can enter any root zone you want.

You can get it at our freeware page.

dig +trace

If you are curious about how DNS works, you probably should have a look at dig +trace. Dig +trace gives you a hierarchical listing of the DNS servers responsible for each level of a domain name.

The tool starts by going to the top level name servers (you know, the 13 root servers that make DNS work) and asking for the top level domain name servers for .com or .net or .uk or .whatever. Then it picks one of those top level servers and asks for the servers responsible for the next level, like netscantools.com, etc. It does this until it finds the authoritative servers for the hostname or domain name or IP address you entered.

It's great for getting a top down view of how the DNS system works. You can also see if there are problems finding the authoritative servers. You can do this from the unix/linux command line (dig hostname +trace) or from our software.

Here is an example using www.microsoft.com as an input to NetScanTools Pro's Name Server Lookup tool:

[Start Query]
DiG Starting Timestamp: 11/14/08 21:03:54

; <<>> DiG 9.x <<>> www.microsoft.com +trace
. 65326 IN NS a.root-servers.net
. 65326 IN NS b.root-servers.net
{snip}
;; Received 228 bytes from 208.200.248.8 (208.200.248.8) in 63 ms

com. 172800 IN NS H.GTLD-SERVERS.NET
com. 172800 IN NS I.GTLD-SERVERS.NET
{snip}
;; Received 509 bytes from a.root-servers.net (198.41.0.4) in 140 ms

(note: these are the authoritative domain servers for handling the queries for hostnames in the microsoft.com domain)
microsoft.com. 172800 IN NS ns1.msft.net
microsoft.com. 172800 IN NS ns2.msft.net
microsoft.com. 172800 IN NS ns3.msft.net
microsoft.com. 172800 IN NS ns4.msft.net
microsoft.com. 172800 IN NS ns5.msft.net
;; Received 209 bytes from H.GTLD-SERVERS.NET (192.54.112.30) in 234 ms

www.microsoft.com. 3600 IN CNAME toggle.www.ms.akadns.net
;; Received 73 bytes from ns1.msft.net (207.68.160.190) in 62 ms

[End Query]

With each level, you can see that a number was returned. This is the TTL (time-to-live) for the DNS record in seconds. If you do the dig +trace query again, the numbers for the root servers will be smaller reflecting the time you took between queries.

You can see that ns1 told us that www.microsoft.com is aliased to a server handled by Akamai. It did not tell us the IP address -- we did an 'ANY' query and the CNAME record was all that was returned to us.

Managed Switch Port Mapping Tool v1.95 Released

The newest release of the Managed Switch Port Mapping Tool was released yesterday and posted this morning. This version has several internal changes which should allow more models of switches to be mapped.

It also has something that was long overdue: support for the Windows Common Controls v6+. When the program is run XP and Vista this gives a different more up-to-date look to things like checkboxes, radio buttons and other controls. Why did we wait so long? it was very hard to do using the Visual C++ 6 compiler. Remember, we only recently made the transition to using Visual C++ 2005 and we are now making the transition to 2008. And speaking of the common control look -- it doesn't work on Windows Server 2003 or 2008. A new milestone: This release of the program has finally been successfully tested on Windows Server 2008.

This release also marks the first time I've fully understood how the Side by Side (WinSxS) DLLs are to be handled properly -- at least I think I understand. The program is linked with the CRT and MFC DLLs so we need a certain version or later of those DLLs on the machine. Our installer now looks for the right version and if it does not find them, the Microsoft Visual C++ 2005 redistributable installer is launched to put the right DLLs in the right places. This was all supposed to stop DLL hell, but I think it created a significantly more complex situation -- if you don't believe me, just have a quick look in C:\windows\WinSxS. It definitely made our installer bigger.

As usual, we updated to the latest version of SQLite: 3.6.4. I can't say enough good things about SQLite. I find it to be very robust and easy to use. The SQL is powerful enough for our needs and it makes it very easy to work with the large amounts of data that we retrieve from the switch. I use a C++ wrapper that I found on CodeProject so the learning curve was really fast. Try SQLite sometime! -the link to their site is on the right.

You can get the latest version by clicking on Help/Check for Update or by going to the Switch Port Mapper website on the right.