The timeline for signing ORG was presented by PIR at the recent ICANN meeting in Paris.
http://par.icann.org/files/paris/RaadDNSSEC.pdf
The estimated timeline expressed that slide would have a signed ORG zone containing some DS records by the beginning of next year, with full mainstream availability (such that any registrant could use a DNSSEC-capable registrar to request a secure delegation) in 2010.
Joe
Understanding that immediate DNSSEC deployment
is not a realistic expectation..." I wonder what NANOG folk can do
about the second part of that quote...get the root zone signed, get com/net/org/ccTLD's signed.. oh wait,
There are 4 ccTLDs (se, bg, pr, br) that are signed.
As Joe has indicated, ORG is moving towards signing their zone (as are several more ccTLDs).
that's not nanog... doh!
Pressure your local ICANN officers?
Mmph. https://ns.iana.org/dnssec/status.html
(it's out of ICANN's hands)
Regards,
-drc
Pressure your local ICANN officers?
How many ISPs run DNS servers for customers? Start by signing those
This is likely going to mean some mean OSS changes and perhaps
re-adjustment of where customer zones live to deal with extra load on
auth servers... Also, the customer(s) likely have to ask for that sort
of thing to happen, and include in their OSS re-signing/verifying/blah
when they make changes to their zone(s).
zones -- that has to be done in any event. Set up caching resolvers to
verify signatures. "It is not your part to finish the task, yet you
yup, more server load considerations, for services not being paid for
directly by customers... also, this is but a small minority of the
affected devices here. Not that it's not important, but there are
other parts of the dns pie. Someone mentioned CPE devices doing
cache-resolving as well, if their upstream is an affectd device they
are vulnerable, if they are vulnerable they could be subverted 
My point was really, how do we get dns-sec rolling? From the top-down
that's 'bug icann' right? and from the bottom-up that's:
0) update applications to meaningfully use dnssec data
1) educate users/domain-owners
2) roll infrastructure to the ISP/Enterprise
3) make sure the CPE/end-systems are prepared for dnssec
4) update OSS bits down the dns-tree
5) deploy
6) rejoice?
Just saying "DNSSEC is the answer" is cool, but we've
(network/security community) been saying that for 10 years. How does
this move forward?
No, I didn't say it would be easy, but if we don't start we're not
going to get anywhere.
yup.
> Pressure your local ICANN officers?
Mmph. https://ns.iana.org/dnssec/status.html
(it's out of ICANN's hands)
Huh!?
Then what does this following statement refer to?
(c) 2008 The Internet Corporation for Assigned Names and Numbers.
I found that at the bottom of the IANA page whose URL you quoted.
At the bottom of the IANA home page http://www.iana.org/
it is stated a bit more explicitly:
IANA is operated by the
Internet Corporation for Assigned Names and Numbers
It sounds like ICANN has the matter well in hand to me given
that it is only responsible for the common central bit of the
DNS system. The rest of the job is everyone's problem.
--Michael Dillon
>> Pressure your local ICANN officers?
>>
> How many ISPs run DNS servers for customers? Start by signing thoseThis is likely going to mean some mean OSS changes and perhaps
re-adjustment of where customer zones live to deal with extra load on
auth servers... Also, the customer(s) likely have to ask for that sort
of thing to happen, and include in their OSS re-signing/verifying/blah
when they make changes to their zone(s).
Precisely my point. (In a related vein, how many folks started
updating their OSSs a few years ago to handle IPv6 addresses?)
> zones -- that has to be done in any event. Set up caching
> resolvers to verify signatures. "It is not your part to finish the
> task, yet youyup, more server load considerations, for services not being paid for
directly by customers... also, this is but a small minority of the
affected devices here. Not that it's not important, but there are
other parts of the dns pie. Someone mentioned CPE devices doing
cache-resolving as well, if their upstream is an affectd device they
are vulnerable, if they are vulnerable they could be subvertedMy point was really, how do we get dns-sec rolling? From the top-down
that's 'bug icann' right? and from the bottom-up that's:0) update applications to meaningfully use dnssec data
1) educate users/domain-owners
2) roll infrastructure to the ISP/Enterprise
3) make sure the CPE/end-systems are prepared for dnssec
4) update OSS bits down the dns-tree
5) deploy
6) rejoice?Just saying "DNSSEC is the answer" is cool, but we've
(network/security community) been saying that for 10 years. How does
this move forward?
Maybe this attack will help...
More seriously -- unlike v6, the pieces here can be updated
independently; they'll then DTRT when the proper bits start showing up
on the wire. Enterprises can sign their own zones, and give (with help
from Microsoft, of course) their employees resolvers and configurations
that know to expect signatures for that zone. Enterprises and
consumer-facing ISPs can start deploying caching resolvers that use the
AD bit and TSIG when talking to clients.
The pressure on ICANN and down from there can happen at the same time.
Some day, they'll meet in the middle...
--Steve Bellovin, Steven M. Bellovin
Are these the same ISPs that haven't started implementing other
anti-spoofing controls like BCP38++?
What is the estimated completion date to stop all spoofed IP packets,
included but only DNS spoofing?
One of the commenters on Slashdot, who did not sound entirely like a
crank, says the root zone DNSKEYs and RRSIGs have been generated
already, and his informant is waiting for the OK to deploy them.
http://it.slashdot.org/comments.pl?sid=607413&cid=24106363
Cheers,
-- jr 'yes, yes, I know; it's /. No, I don't believe in the Easter Bunny' a
[ snip ]
My point was really, how do we get dns-sec rolling? From the top-down
that's 'bug icann' right? and from the bottom-up that's:
It's from the bottom up, not the top down, that might be most effective
here.
-M<
Pressure your local ICANN officers?
Mmph. https://ns.iana.org/dnssec/status.html
(it's out of ICANN's hands)Huh!?
...
It sounds like ICANN has the matter well in hand to me given
that it is only responsible for the common central bit of the
DNS system.
Two answers:
1) The term 'signing the root' means a whole lot more than running dnssec-signzone over zone data. Specifically, the URL I provided shows that IANA is _already_ signing the root (more or less) and has been for over a year -- IANA actually has a _very_ elaborate and secure infrastructure (including multiple FIPS 140-3 hardware security modules, air gaps, physical security, and all sorts of other stuff) for root signing. The fact that root zone data you receive from the root servers is not signed may suggest that there is a bit more that needs to be done and pretty much all of that is NOT something ICANN has direct control over.
2) You are exactly right when you say:
The rest of the job is everyone's problem.
Getting DNSSEC to be more than an academic exercise requires BOTH folks signing zones that form an unbroken chain of trust up to a trust anchor configured in validating name servers AND for the operators of those validating name servers to enable DNSSEC. Most of the thrust to date has been on one half of that requirement. How many ISPs represented here are in a position to turn on DNSSEC validation? How many are even running caches that are capable of doing DNSSEC?
For DNSSEC to actually be useful, I suspect somebody needs to write software that provides the user with some indication other than a timeout that a name validation failed, but that's a separate issue.
Regards,
-drc
We have one IETF ID on port randomization for years: http://www.gont.com.ar/drafts/port-randomization/index.html
While this does not make the attack impossible, it does make it much harder.
The same thing applies to those RST attacks circa 2004.
Most of these blind attacks assume the source port numbers are easy to guess. But... why should they?
Kind regards,
Because many name servers use one port, or easily guessable sequence of ports?
Anyone using Infoblox DNSOne? They claimed to have fixed their BIND version
but I still see issues with source ports staying the same.
Eric Davis
Sr. Network Technician
Rockefeller University IT Dept.
212-327-7508
646-772-4667(cell)
There are 4 ccTLDs (se, bg, pr, br) that are signed.
wanna crawl in a corner in dublin and i can sign a few?
randy
Love to. We can also put your trust anchors in the prototype ITAR (see the first part of https://par.icann.org/files/paris/IANAReportKim_24Jun08.pdf).
Regards,
-drc
David Conrad wrote:
There are 4 ccTLDs (se, bg, pr, br) that are signed.
wanna crawl in a corner in dublin and i can sign a few?
Love to. We can also put your trust anchors in the prototype ITAR (see
the first part of
https://par.icann.org/files/paris/IANAReportKim_24Jun08.pdf).
aside from just getting some cctlds signed, i will be interested in the
tools, usability, work flow, ... i.e. what is it like for a poor
innocent cctld which wants to sign their zone?
randy
If there is sufficient interest, we could do a bar bof to describe some of the tools IANA has...
Regards,
-drc
aside from just getting some cctlds signed, i will be interested in
the tools, usability, work flow, ... i.e. what is it like for a
poor innocent cctld which wants to sign their zone?If there is sufficient interest, we could do a bar bof to describe
some of the tools IANA has...
sounds like a plan. i volunteer to be victim.
randy
David Conrad wrote:
I think Sandy Murphy or other Sparta folks have presented some of the
work they've done on this... Perhaps finding one/some of them and
having a more operations focused presentation in LAX or ... is a good
idea as well?
-Chris
I'd rather see the IANA do it. I wouldn't say that they are 100%
neutral, but they're more neutral than SPARTA.
-M<