dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
28019
PX Eliezer704
Premium Member
join:2008-08-09
Hutt River

1 recommendation

PX Eliezer704

Premium Member

Testing your router for May 5 internet changes

Background:

"Internet users face the risk of losing their internet connections on 5 May when the domain name system switches over to a new, more secure protocol.

While the vast majority of users are expected to endure the transition to DNSSEC smoothly, users behind badly designed or poorly configured firewalls, or those subscribing to dodgy ISPs could find themselves effectively disconnected...."

»www.theregister.co.uk/20 ··· /dnssec/

---------------------------------

Test:

»labs.ripe.net/content/te ··· e-issues
OmagicQ
Posting in a thread near you
join:2003-10-23
Bakersfield, CA

1 edit

OmagicQ

Member

I just tried the test and it came up RED.

"Your resolver was only able to get packets SMALLER than 512 bytes."

On the test page it says:

This usually implies that a packet filter or firewall is blocking UDP packets bigger than 512 bytes from reaching your resolver. Your resolver works now, although it is probably not able to resolve some names. However, when the root zone is signed your resolver will not be able to receive most responses, and it is possible that you will lose DNS service. You should reconfigure your firewall or packet filter to allow large UDP packets through.

This is going to suck. I have OpenDNS manually configured on my network connection so my router is blocking the larger udp packets. Lousy #@#$^&%# 2-wire!

Edit: I wonder if this is going to break my PAP2T also. If it does, hopefully there will be some non-dnssec servers we can use with it.

adsldude

join:2000-11-10
Colorado

adsldude to PX Eliezer704

to PX Eliezer704
This should be fun for everybody!

adsldude@desktop:~$ 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.
"Tested at 2010-04-28 17:21:30 UTC"
"205.171.253.210 DNS reply size limit is at least 3843"
"205.171.253.210 sent EDNS buffer size 4096"
adsldude@desktop:~$
 
PX Eliezer704
Premium Member
join:2008-08-09
Hutt River

PX Eliezer704 to OmagicQ

Premium Member

to OmagicQ
I use the OpenDNS servers, but not their software.

My router: D-Link DGL 4100.

The Java test result: "Your resolver does not have DNSSEC enabled" which means I should be OK, hopefully.

I am surprised that there has not been more news about this. Oh well, folks worry about who Jesse James is poking rather than about important things.

------------------

Thanks to the CallCentric folks for bringing this up in the forum.

swintec
Premium Member
join:2003-12-19
Alfred, ME

1 edit

swintec

Premium Member

said by PX Eliezer704:

I use the OpenDNS servers, but not their software.

My router: D-Link DGL 4100.

The Java test result: "Your resolver does not have DNSSEC enabled" which means I should be OK, hopefully.
How does that mean you will be okay? I use OpenDNS as well and I see: "Your resolver does not have DNSSEC enabled." and then underneath is a red box saying "Your resolver was only able to get packets SMALLER than 512 bytes."

Is this really a big deal and will the internet implode into itself on the 5th? This is the first I hear about this.

EDIT- Would have helped if I read more. Looks like this is more a firewall issue now on my side.

AVD
Respice, Adspice, Prospice
Premium Member
join:2003-02-06
Onion, NJ

1 recommendation

AVD

Premium Member

cinco de mayo
OmagicQ
Posting in a thread near you
join:2003-10-23
Bakersfield, CA

OmagicQ to PX Eliezer704

Member

to PX Eliezer704
I've been trying a few dns servers. Level 3's dns servers seem to be dnssec enabled. Testing with 4.2.2.1 gave me this result:

Announced buffer size:
4096 bytes
Measured buffer size:
3839 bytes
EDNS enabled:
yes
DNSSEC enabled:
yes

Your resolver announced a buffer size bigger than the largest packet that it can receive.

Note: There will always be a difference between the announced and measured buffer size because of the algorithm used. However this difference should not exceed 300 bytes.
For detailed explanations about these messages see: »k.root-servers.org/replysizetest
Bogtrotter23
join:2009-06-14
East York, ON

Bogtrotter23 to PX Eliezer704

Member

to PX Eliezer704
I tried the test and got:

Announced buffer size:
4096 bytes
Measured buffer size:
1339 bytes

I think I will retreat into disbelief that my lovely internet connection will die on May 5.
neftv
join:2000-10-01
Broomall, PA

neftv to PX Eliezer704

Member

to PX Eliezer704
Is that test for Windows XP systems? I am trying to understand that site.
PX Eliezer704
Premium Member
join:2008-08-09
Hutt River

PX Eliezer704

Premium Member

The OS should not matter at all, although I do use WinXP SP3.

The application is a Java application.

If you need Java, get it here:

»www.java.com/en/download ··· ndex.jsp

Or you can do the test manually with these instructions:

»www.dns-oarc.net/oarc/se ··· sizetest

dcurrey
Premium Member
join:2004-06-29
Mason, OH

dcurrey to swintec

Premium Member

to swintec
said by swintec:

said by PX Eliezer704:

I use the OpenDNS servers, but not their software.

My router: D-Link DGL 4100.

The Java test result: "Your resolver does not have DNSSEC enabled" which means I should be OK, hopefully.
How does that mean you will be okay? I use OpenDNS as well and I see: "Your resolver does not have DNSSEC enabled." and then underneath is a red box saying "Your resolver was only able to get packets SMALLER than 512 bytes."

Is this really a big deal and will the internet implode into itself on the 5th? This is the first I hear about this.

EDIT- Would have helped if I read more. Looks like this is more a firewall issue now on my side.
Get the same think with opendns and dir-655. Works fine with level 3. Google servers give error for some reason with java app. fails test with dig.

n1zuk
making really tiny tech things
Premium Member
join:2001-10-24
Malta

1 recommendation

n1zuk to swintec

Premium Member

to swintec
said by swintec:

Is this really a big deal and will the internet implode into itself on the 5th?
I thought that wasn't supposed to happen until 2012.
pcunite
join:2010-04-10

1 edit

pcunite to PX Eliezer704

Member

to PX Eliezer704
This is what I recevied? Am I okay?

root@firewall:~ # dig +short rs.dns-oarc.net txt
rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
"XX.XXX.XX.XX sent EDNS buffer size 512"
"XX.XXX.XX.XX DNS reply size limit is at least 490"
"Tested at 2010-04-28 22:36:09 UTC"
jfmezei
Premium Member
join:2007-01-03
Pointe-Claire, QC

jfmezei to PX Eliezer704

Premium Member

to PX Eliezer704
On OS-X, the dig test yielded a

"72.0.206.666 sent EDNS buffer size 4096"
"72.0.206.666 DNS reply size limit is at least 3843"

Running that java application revealed the announced buffer size of 512 and measured buffer size of 3828, and the second time I ran it, the announced buffer size was 4096, matching the dig results.

Not sure the java application can be trusted.
jfmezei

jfmezei to pcunite

Premium Member

to pcunite
PCunite, no, the announced EDNA buffer size should be above 4000, yours is at 512.

Try the test a few times to see if it is always at 512.
pcunite
join:2010-04-10

pcunite

Member

said by jfmezei:

PCunite, no, the announced EDNA buffer size should be above 4000, yours is at 512.

Try the test a few times to see if it is always at 512.
Thanks, IPCop 1.4.21, it always returns the same. Thankfully they are about to release an update.

Trimline
Premium Member
join:2004-10-24
Windermere, FL

Trimline to OmagicQ

Premium Member

to OmagicQ
said by OmagicQ:

Announced buffer size:
4096 bytes
Measured buffer size:
3839 bytes
EDNS enabled:
yes
DNSSEC enabled:
yes

Exact same results on my network running a Netgear WNDR3700 running DNS 4.2.2.4. Whew...

dcurrey
Premium Member
join:2004-06-29
Mason, OH

1 edit

dcurrey to PX Eliezer704

Premium Member

to PX Eliezer704
Checking the default Viatalk dns server in the pap2 it has buffer of 4096 but says

EDNS Enabled: YES
DNSSEC Enabled: NO.

Will it work or won't it? Anybody fully understand this?

edit: Think it will work without dnssec on.
Your resolver does not have DNSSEC

Your resolver will not be affected when the root zone is signed. It will continue to work as it does now. However, you will not benefit from the security that DNSSEC introduces into the root zone.
Mele20
Premium Member
join:2001-06-05
Hilo, HI

1 edit

Mele20 to PX Eliezer704

Premium Member

to PX Eliezer704
That was interesting. I tested my ISP's servers Oceanic Time Warner).

Test results
for resolver: 24.25.227.53

Announced buffer size:
4096 bytes
Measured buffer size:
3838 bytes
EDNS enabled:
yes
DNSSEC enabled:
yes

I got the red warning but it is meaningless because the difference between announced and measured buffer size is small.

My third DNS server is a Level 3 one and it tests differently:

Test results
for resolver: 4.2.2.1

Announced buffer size:
512 bytes
Measured buffer size:
3838 bytes
EDNS enabled:
no
DNSSEC enabled:
no

Your resolver does not have DNSSEC enabled.
Note: There will always be a difference between the announced and measured buffer size because of the algorithm used. However this difference should not exceed 300 bytes.

OmagicQ See Profile That is odd that your Level 3 servers have DNSEC enabled and mine do not. What does your 4.2.2.1 resolve to? Mine is "vnsc-pri.sys.gtei.net" in Los Angeles area.

EDIT: I thought the Level 3 test was odd so I tested ALL L3 DNS servers and ALL, including 4.2.2.1 (which I retested) show DNSSEC as enabled. I wonder why it tested wrong the first time and how trustworthy is this test?

Test results
for resolver: 4.2.2.1

Announced buffer size:
4096 bytes
Measured buffer size:
3838 bytes
EDNS enabled:
yes
DNSSEC enabled:
yes

Noah Vail
Oh God please no.
Premium Member
join:2004-12-10
SouthAmerica

Noah Vail to PX Eliezer704

Premium Member

to PX Eliezer704

Level3 - 4.2.2.3 - 4.2.2.4 - 4.2.2.5 - 4.2.2.6

Router = WRT54G-V2 + Tomato V1.21

Test results for resolver: 4.2.2.3

Announced buffer size: 4096 bytes
Measured buffer size: 3828 bytes

EDNS enabled: yes
DNSSEC enabled: yes

*Red* Your resolver announced a buffer size bigger than the largest packet that it can receive.

........................................................

Test results for resolver: 4.2.2.4

Announced buffer size: 4096 bytes
Measured buffer size: 3828 bytes

EDNS enabled: yes
DNSSEC enabled: yes

*Red* Your resolver announced a buffer size bigger than the largest packet that it can receive.

.............................................................

Test results for resolver: 4.2.2.5

Announced buffer size: 512 bytes
Measured buffer size: 3828 bytes

EDNS enabled: yes
DNSSEC enabled: yes

*Yellow* Your resolver announced a buffer size smaller than the recommended minimum of 850 bytes.

.........................................................

Test results for resolver: 4.2.2.6

Announced buffer size: 4096 bytes
Measured buffer size: 3828 bytes

EDNS enabled: yes
DNSSEC enabled: yes

*Red* Your resolver announced a buffer size bigger than the largest packet that it can receive.
Noah Vail

Noah Vail to PX Eliezer704

Premium Member

to PX Eliezer704

DNSSEC Dates / Timeline

said by Root DNSSEC :

Planned High Level Timeline

* December 1, 2009: Root zone signed for internal use by VeriSign and ICANN. ICANN and VeriSign exercise interaction protocols for signing the ZSK with the KSK.

* January, 2010: The first root server begins serving the signed root in the form of the DURZ (deliberately unvalidatable root zone). The DURZ contains unusable keys in place of the root KSK and ZSK to prevent these keys being used for validation.

* Early May, 2010: All root servers are now serving the DURZ. The effects of the larger responses from the signed root, if any, would now be encountered.

* May and June, 2010: The deployment results are studied and a final decision to deploy DNSSEC in the root zone is made.

* July 1, 2010: ICANN publishes the root zone trust anchor and root operators begin to serve the signed root zone with actual keys – The signed root zone is available.

Please note that this timeline is tentative and subject to change based on testing results or other unforeseen factors.
.
.
.
said by Root Servers .org :

The root zone will be DNSSEC signed in July 2010

The deployment of the signed root zone is happening now, with some of the root servers already providing signed responses. Though not yet useful for validation purposes these signed responses are larger than unsigned responses and this may have operational impact for resolvers.

More information on the deployment of the signed root zone and how to send feedback at: »www.root-dnssec.org
NV
OmagicQ
Posting in a thread near you
join:2003-10-23
Bakersfield, CA

OmagicQ to Mele20

Member

to Mele20

Re: Testing your router for May 5 internet changes

said by Mele20:

OmagicQ See Profile That is odd that your Level 3 servers have DNSEC enabled and mine do not. What does your 4.2.2.1 resolve to? Mine is "vnsc-pri.sys.gtei.net" in Los Angeles area.
Here are the last two hops on a tracert i did.

7 16 ms 23 ms 13 ms ae-31-80.car1.LosAngeles1.Level3.net [4.69.144.131]
8 16 ms 15 ms 15 ms vnsc-pri.sys.gtei.net [4.2.2.1]
PX Eliezer704
Premium Member
join:2008-08-09
Hutt River

1 recommendation

PX Eliezer704

Premium Member

How'd we all miss this?

The folks at OpenDNS have said they will NOT utilize DNSSEC but rather an alternative:

---------------------------------------

Comcast Goes DNSSEC, OpenDNS Adopts Alternative DNS Security

DNS provider OpenDNS selects DNSCurve over DNSSEC, but experts say the two technologies could eventually play together

By Kelly Jackson Higgins , DarkReading
Feb. 24, 2010
URL:»www.darkreading.com/stor ··· 23100630

Domain Name System (DNS) security was hot this week, with the much-anticipated DNSSEC technology for locking down domain servers getting both the nod from a major ISP and passed over by a DNS service provider.

Comcast has announced it will deploy DNSSEC in its Websites, including comcast.com, comcast.net, and xfinity.com, by the first quarter of next year, and it will begin using DNSSEC validation for all of its customers by the end of 2011. In a separate announcement, meanwhile, OpenDNS said it had deployed an alternative to DNSSEC, DNSCurve.

OpenDNS engineer and security researcher Matthew Dempsky says the company "put a lot of thought into" adopting DNSCurve at this time and concluded it made more sense than DNSSEC because it's simpler and easier to deploy and manage than DNSSEC -- and because it uses stronger cryptography. "DNSSEC is not a very viable solution as a whole," Dempsky says. "While there are increasing efforts to deploy it ... there's been a lot of testing with questionable results. There are still a lot of compatibility issues to be worked out."

DNSSEC adoption has finally begun gaining traction during the past year after nearly 15 years in the making. Concerns about how to defend against the DNS cache-poisoning flaw discovered by Dan Kaminsky have helped invigorate DNSSEC adoption efforts by government and industry. The .gov and .org top-level domains have begun to adopt the DNS security protocol, and .edu has been under way recently, as well.

The root zone DNS servers will be "signed" with DNSSEC technology in July, and VeriSign plans to deploy DNSSEC in the .com, .net, and .edu domains by the first quarter of 2011. "The critical mass has started," says Matt Larson, vice president of DNS research for VeriSign, which today rolled out its anticipated DNSSEC Interoperability Lab for vendors and service providers. "You're starting to see the snowball begin to roll down the hill with DNSSEC this year."

But OpenDNS' Dempsky argues that DNSSEC adoption is not far along and that DNSCurve is the technology for "right now" for preventing the Kaminsky DNS cache-poisoning attack and other threats. He says DNSSEC's RSA 512-bit and 1024-bit keys aren't secure enough given recent crypto hacks, and aren't up to date with recommended 2028-bit keys.

In addition, DNSSEC's use of digital signatures to authenticate Website domain information is inefficient, according to Dempsky. DNSCurve uses a different approach: per-packet encryption and authentication. The two technologies aren't interchangeable, per se -- DNSCurve is aimed more at transactional security between pairs of name servers, while DNSSEC protects the zone data, says Cricket Liu, vice president of architecture for Infoblox and author of several DNS books. "They don't address the same spectrum of threats," Liu says.

And unlike DNSSEC, DNSCurve isn't an IETF-backed technology, although OpenDNS's Dempsky has written a draft of the protocol for the IETF that he hopes will be accepted by the standards organization.

Infoblox's Liu called OpenDNS's choice to go with DNSCurve "regrettable" given all of the community effort to finalize and push DNSSEC forward. "This is potentially diluting the focus on DNSSEC," he says.

Even so, Liu and VeriSign's Larson say the two technologies could ultimately be used together. "DNSCurve is clever and solves some problems," Liu says. He says DNSCurve is basically a bootstrap for the existing transactional security standard used in DNS today. "So in the communication between two name servers, it's able to check that what you hear is what I said," he says. But unlike DNSSEC, it can't determine "if I'm lying to you," for example.

"Over time, it might be possible for these [technologies] to be used together," Liu says. "But they are not two different options for solving the same set of problems."

One area where there might be symmetry is in cryptography. VeriSign's Larson says DNSSEC is architected such that it can swap crypto algorithms, so although the focus for now is on the widely implemented RSA algorithms, DNSSEC could potentially deploy the Elliptic Curve Cryptography (ECC) used by DNSCurve. "VeriSign is very interested in that," he says. "I absolutely see adding ECC to it in the next couple of years."

For now, OpenDNS runs the only known operational implementation of DNSCurve, according to Dempsky. But the company has had several inquiries to its invitation for others to join as well. Dempsky says OpenDNS has not yet decided on any plans for DNSSEC adoption.
OmagicQ
Posting in a thread near you
join:2003-10-23
Bakersfield, CA

1 edit

OmagicQ

Member

I read a little on DNSCurve but its way over my head. I'm all for security as long as it doesn't become cumbersome to use and then gets effectively negated by the end-user.. similiar to the ever changing password that just gets written on a post-it and put on the monitor.

Edit: DNSCurve appears to have a smaller packets than DNSSEC will. If I read it right, dnssec packets could routinely be 3x larger.

buckeyered
Premium Member
join:2005-05-07
Hamilton, OH

buckeyered to PX Eliezer704

Premium Member

to PX Eliezer704
now my brain hurts, Ive read but don't fully understand all this. I get announced buffer size 4096, measured 1223, EDNS enabled yes, DNSSEC enabled yes, Your resolver announced a buffer size bigger than the largest packet that it can receive.
Do I change the buffer size in the router? I couldn't find it in DD-WRT micro.
Mele20
Premium Member
join:2001-06-05
Hilo, HI

Mele20 to OmagicQ

Premium Member

to OmagicQ
said by OmagicQ:
said by Mele20:

OmagicQ See Profile That is odd that your Level 3 servers have DNSEC enabled and mine do not. What does your 4.2.2.1 resolve to? Mine is "vnsc-pri.sys.gtei.net" in Los Angeles area.
Here are the last two hops on a tracert i did.

7 16 ms 23 ms 13 ms ae-31-80.car1.LosAngeles1.Level3.net [4.69.144.131]
8 16 ms 15 ms 15 ms vnsc-pri.sys.gtei.net [4.2.2.1]
Thanks. You did see my edit of my post? Apparently, the first test was an anomaly. But now I am wondering how accurate the test is.

sivran
Vive Vivaldi
Premium Member
join:2003-09-15
Irving, TX

sivran to PX Eliezer704

Premium Member

to PX Eliezer704
quote:
Test results
for resolver: 192.168.1.5

Announced buffer size: 4096 bytes
Measured buffer size: 3839 bytes
EDNS enabled: yes
DNSSEC enabled: yes
My bind9 installation is ready.

La Luna
Fly With The Angels My Beloved Son Chris
Premium Member
join:2001-07-12
New Port Richey, FL

La Luna to PX Eliezer704

Premium Member

to PX Eliezer704
I have Java but I can't get the test to run, the dialogue box just flashes and then closes.
neftv
join:2000-10-01
Broomall, PA

neftv to PX Eliezer704

Member

to PX Eliezer704
When I do the test manually with the command they give
dig +short rs.dns-oarc.net txt

I get "connection time out no servers could be reached"

La Luna
Fly With The Angels My Beloved Son Chris
Premium Member
join:2001-07-12
New Port Richey, FL

La Luna

Premium Member

I tried that too, I got not a valid command.....