This is long, but worth knowing about. You can skim it if your in a hurry and then try the links at the bottom of that article...
Warning: Why your Internet might fail on May 5
Network operators urged to check routers, firewalls.
Network managers are being urged to run a series of checks on their routers and firewalls to ensure their users will still be able to connect to internet sites in the wake of a major change to the internet's domain name system next week.
On May 5, the world's top domain authorities (led by ICANN, the US Government and Verisign) will complete the first phase of the roll-out of DNSSEC (Domain Name System Security Extensions) across the 13 root servers that direct user requests to the relevant websites on the internet.
The DNSSEC upgrade adds a digital signature to the response from every DNS (Domain Name Server) request to give an internet user an extra level of assurance that the domain name is translated to the correct Internet location (such as a website, or email destination).
DNSSEC was developed in an attempt to thwart 'man in the middle' attacks, in which hackers intercept a request and respond with a message that fools the user system into going to a false location.
But the new protocol - much welcomed by the industry - could have an unfortunate side effect for unprepared network managers, according to Bruce Tonkin, chief strategy officer at Melbourne IT and a board director at ICANN.
A response to a standard DNS request tends to be in a single packet (UDP protocol) and tends to fall below 512 bytes in size.
In some older networking equipment, any larger request than this would be blocked by pre-configured factory settings, under the assumption that larger packets (and several of them) represent an anomaly of some kind.
As of May 5 at 17:00 UTC (which is actually pre-dawn on Thursday 6th on the East Coast of Australia), all DNSSEC signature-laden messages sent back to a user's DNS resolver will be four times the size - up to 2 KB. And should packets of that size be rejected, the message would likely be sent in multiple packets via the TCP protocol.
(These signatures will be dummies at first to test the system, as of July 1, they will be the real deal.)
Tonkin fears that while DNSSEC has been on the agenda for some time, many IT and network managers have yet to test their older routers and firewalls to ensure they can handle the larger DNS responses.
"The bigger answer coming back from the DNS request might get blocked by some internet devices in the Corporate network," he said.
DNSSEC is in fact already rolled out across most of the world's 13 root server clusters, in an effort that began in December 2009.
But to date, Tonkin explained, it would only have resulted in a slight lag in the loading of a web page for those with outdated network equipment.
The beauty of DNS is that should a request made to one root server not receive a response, the DNS resolver on a user's machine simply makes the same request along the line of the 13 root servers until it gets a satisfactory response.
But on May 5, once all 13 root server clusters are live with the DNSSEC signatures, responses from all 13 root servers won't make it back inside the corporate LAN on some older systems.
Tonkin expects that the larger Internet Service Providers will have addressed the issue, so most home internet users will be unaffected.
"I'm not entirely sure all ISPs will be prepared, but I imagine the major ones are," he said. "ISPs tend to do DNS translation for you. But it is likely to have a big impact in the corporate environment, where you might run your own DNS server and infrastructure."
In that sense Tonkin doesn't expect a "Y2K meltdown" of the internet May 5.
But he predicts a number of organizations will start experiencing internet access issues, and a number of network administrators will be left scratching their heads as to why.
To complicate the scenario further, network administrators and help desks "may not know what has gone wrong," he said.
The problem may take several days to surface and be inconsistent from one user's PC to the next. A user at one machine that hasn't switched on his PC for two or three days will have no access to the internet. A user that left his machine on the night before will have some pages - and responses from DNS servers - cached on their machine, and will still have connectivity.
"It is usually much easier to address a problem when everything isn't working!" Tonkin said.
Tonkin recommended network managers run a series of simple online tests to ensure their network can handle the larger DNS responses:
Testing your resolver for DNS reply size issues
2009
Some weeks ago, we installed a reply-size tester application at the global instances of K-root. Anyone using a unix-like system can use a command-line DNS query tool such as dig to run a special query, which will make use of this reply-size tester to try and determine the maximum size of a DNS response packet a resolver can handle.
This form of testing, however, is limited to those with a technical background and access to a DNS query tool such as dig. We wanted to make this test available to more people, in an easy-to-use way. We have therefore written a Java application for this purpose. Almost all users these days have a Java runtime installed, so running this application is as simple as downloading a single .jar file, and double-clicking on it.
Running the application: (updated on 28-1-2010)
Get the application here: replysizetest-1.1.jar (MD5 checksum 420bddc70a60c5c93a0d33185a5a3caf)
When you run the application, it will bring up a dialog box, with a list of the IP addresses of the resolvers that it detects on your system, with the first one automatically selected. You can just click on OK to begin the test. If you want to test another resolver, select its address from the drop-down list. If you want to test a resolver which isn't in the list, select "Other" and click on OK, and you'll get a text box where you can type in the address of a resolver.
This application essentially performs the query "dig txt test.rs.ripe.net" against a resolver. When the test completes, it displays one of four results in different colours, with green representing no problems, yellow indicating some problems, and red indicating potentially serious problems. However, even if you see a result in red, please do not panic. It doesn't mean that your resolver is broken. It just means that there is a greater chance that this resolver will have difficulties resolving names when the root zone is signed with DNSSEC.
If the application gives you an internal software error message, it generally means that the java virtual machine on your system is restricted from certain operations. Try disabling your firewall. If this still doesn't help, you can run this test manually using the "dig" command-line tool, as described here.
If the test completes, and you have some results, please refer to the table below to interpret the result:
Go there and Read the Rest...
- Ripe Labs' 'Test your DNS Resolver'
http://labs.ripe.net/content/testing-your-resolver-dns-reply-size-issues
The Java Tool ran fine on my Fedora 11 Linux Machine. So it should run well on a Windows PC too. My results look like I'm just 257bytes away from being just fine on mine. Guess I'll have to check my Routers and see if I can change the settings in them. But I will be ok for the most part, like I am. They say the limit in difference there is 300bytes.OARC's DNS Reply Size Test Server
Recent increases in DNSSEC deployment are exposing problems with DNS resolvers that cannot receive large responses.The maximum reply size between a DNS server and resolver may be limited by a number of factors:
- If a resolver does not support the Extension Mechanisms for DNS (EDNS), replies are limited to 512 bytes.
- The resolver may be behind a firewall that blocks IP fragments.
- Some DNS-aware firewalls block responses larger than 512 bytes.
The BIND resolver, since version 9.5.0, includes a feature to decrease its advertised EDNS receive buffer size (down to 512) when its queries time out. We've seen this lead to significant increases in TCP for DNSSEC-signed zones.
DNS-OARC built the DNS Reply Size Test Server to help users identify resolvers that cannot receive large DNS replies.
How To Use
To use the DNS Reply Size Test Server, simply use dig command line tool to issue a TXT query for the name rs.dns-oarc.net:
$ dig +short rs.dns-oarc.net txt
- A reply-size test available at DNS-OARC:
https://www.dns-oarc.net/oarc/services/replysizetest
When you get to the page look for this to past into your Terminal or Command Line App...
"dig +short rs.dns-oarc.net txt" (without the "). Type it in if you have to... Then follow the instructions on the rest of the page to interpret the results. Honestly I'm not exactly sure that my results are what needs to be there. But as far as I understand this, I'm fine on this one. Or well Close according to the easy Java App... Here's my Terminal Results from running the commands...
[don@gatewaygt5408fedora11 ~]$ dig +short rs.dns-oarc.net txt
rst.x3827.rs.dns-oarc.net.
rst.x3837.x3827.rs.dns-oarc.net.
rst.x3843.x3837.x3827.rs.dns-oarc.net.
"68.113.206.13 sent EDNS buffer size 4096"
"68.113.206.13 DNS reply size limit is at least 3843"
"Tested at 2010-05-01 06:42:09 UTC"
[don@gatewaygt5408fedora11 ~]$ dig +short rs.dns-oarc.net txt
rst.x3827.rs.dns-oarc.net.
rst.x3837.x3827.rs.dns-oarc.net.
rst.x3843.x3837.x3827.rs.dns-oarc.net.
"68.113.206.13 sent EDNS buffer size 4096"
"68.113.206.13 DNS reply size limit is at least 3843"
"Tested at 2010-05-01 06:42:09 UTC"
[don@gatewaygt5408fedora11 ~]$ dig +bufsize=1024 rs.dns-oarc.net txt
; <<>> DiG 9.6.2-P1-RedHat-9.6.2-3.P1.fc11 <<>> +bufsize=1024 rs.dns-oarc.net txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 155
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;rs.dns-oarc.net. IN TXT
;; ANSWER SECTION:
rs.dns-oarc.net. 60 IN CNAME rst.x3827.rs.dns-oarc.net.
rst.x3827.rs.dns-oarc.net. 59 IN CNAME rst.x3837.x3827.rs.dns-oarc.net.
rst.x3837.x3827.rs.dns-oarc.net. 58 IN CNAME rst.x3843.x3837.x3827.rs.dns-oarc.net.
rst.x3843.x3837.x3827.rs.dns-oarc.net. 57 IN TXT "68.113.206.13 sent EDNS buffer size 4096"
rst.x3843.x3837.x3827.rs.dns-oarc.net. 57 IN TXT "68.113.206.13 DNS reply size limit is at least 3843"
rst.x3843.x3837.x3827.rs.dns-oarc.net. 57 IN TXT "Tested at 2010-05-01 06:42:09 UTC"
;; AUTHORITY SECTION:
x3843.x3837.x3827.rs.dns-oarc.net. 57 IN NS ns00.x3843.x3837.x3827.rs.dns-oarc.net.
;; Query time: 1 msec
;; SERVER: 192.168.2.1#53(192.168.2.1)
;; WHEN: Sat May 1 01:49:38 2010
;; MSG SIZE rcvd: 287
[don@gatewaygt5408fedora11 ~]$
[don@gatewaygt5408fedora11 ~]$ dig tcf.rs.dns-oarc.net txt
;; Truncated, retrying in TCP mode.
; <<>> DiG 9.6.2-P1-RedHat-9.6.2-3.P1.fc11 <<>> tcf.rs.dns-oarc.net txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61281
;; flags: qr tc rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 15, ADDITIONAL: 0
;; QUESTION SECTION:
;tcf.rs.dns-oarc.net. IN TXT
;; ANSWER SECTION:
tcf.rs.dns-oarc.net. 60 IN CNAME tcf.x3831.rs.dns-oarc.net.
tcf.x3831.rs.dns-oarc.net. 59 IN CNAME tcf.x3837.x3831.rs.dns-oarc.net.
tcf.x3837.x3831.rs.dns-oarc.net. 58 IN CNAME tcf.x3843.x3837.x3831.rs.dns-oarc.net.
tcf.x3843.x3837.x3831.rs.dns-oarc.net. 57 IN TXT "68.113.206.14 DNS reply size limit is at least 3843"
tcf.x3843.x3837.x3831.rs.dns-oarc.net. 57 IN TXT "Tested at 2010-05-01 06:50:32 UTC"
;; AUTHORITY SECTION:
x3843.x3837.x3831.rs.dns-oarc.net. 58 IN NS ns19.x3843.x3837.x3831.rs.dns-oarc.net.
x3843.x3837.x3831.rs.dns-oarc.net. 58 IN NS ns15.x3843.x3837.x3831.rs.dns-oarc.net.
x3843.x3837.x3831.rs.dns-oarc.net. 58 IN NS ns00.x3843.x3837.x3831.rs.dns-oarc.net.
x3843.x3837.x3831.rs.dns-oarc.net. 58 IN NS ns27.x3843.x3837.x3831.rs.dns-oarc.net.
x3843.x3837.x3831.rs.dns-oarc.net. 58 IN NS ns54.x3843.x3837.x3831.rs.dns-oarc.net.
x3843.x3837.x3831.rs.dns-oarc.net. 58 IN NS ns07.x3843.x3837.x3831.rs.dns-oarc.net.
x3843.x3837.x3831.rs.dns-oarc.net. 58 IN NS ns22.x3843.x3837.x3831.rs.dns-oarc.net.
x3843.x3837.x3831.rs.dns-oarc.net. 58 IN NS ns17.x3843.x3837.x3831.rs.dns-oarc.net.
x3843.x3837.x3831.rs.dns-oarc.net. 58 IN NS ns02.x3843.x3837.x3831.rs.dns-oarc.net.
x3843.x3837.x3831.rs.dns-oarc.net. 58 IN NS ns73.x3843.x3837.x3831.rs.dns-oarc.net.
x3843.x3837.x3831.rs.dns-oarc.net. 58 IN NS ns10.x3843.x3837.x3831.rs.dns-oarc.net.
x3843.x3837.x3831.rs.dns-oarc.net. 58 IN NS ns52.x3843.x3837.x3831.rs.dns-oarc.net.
x3843.x3837.x3831.rs.dns-oarc.net. 58 IN NS ns49.x3843.x3837.x3831.rs.dns-oarc.net.
x3843.x3837.x3831.rs.dns-oarc.net. 58 IN NS ns51.x3843.x3837.x3831.rs.dns-oarc.net.
x3843.x3837.x3831.rs.dns-oarc.net. 58 IN NS ns68.x3843.x3837.x3831.rs.dns-oarc.net.
;; Query time: 3 msec
;; SERVER: 192.168.2.1#53(192.168.2.1)
;; WHEN: Sat May 1 01:50:32 2010
;; MSG SIZE rcvd: 504
[don@gatewaygt5408fedora11 ~]$
http://www.itnews.com.au/News/173412,warning-why-your-internet-might-fail-on-may-5.aspx
Don
No comments:
Post a Comment