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.
Thursday, November 27, 2008
Friday, November 21, 2008
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.
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.
Friday, November 14, 2008
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.
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.
Thursday, November 6, 2008
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.
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.
Subscribe to:
Posts (Atom)