Discussion:
Multiple DNS implementations vulnerable to cache poisoning
(too old to reply)
Buhrmaster, Gary
2008-07-08 20:48:57 UTC
Permalink
Multiple DNS implementations vulnerable to cache poisoning:

http://www.kb.cert.org/vuls/id/800113

(A widely coordinated vendor announcement. As always,
check with your vendor(s) for patch status.)

Gary
Jimmy Hess
2008-07-09 02:22:23 UTC
Permalink
Christian Koch wrote:
> surely the tool is not focused at a dns operator/admin audience..
>
I suspect the tool's form might partly be meant to obscure exactly what
patterns it is looking for.
Kind of how one might release a vulnerability checker in binary form
(but with source code intentionally witheld)

5 query samples would not seem to be a sufficient number to compute the
probability that the TXIDs and
source ports are both independent and random, with stringent confidence
intervals, and that there is
no sequence predictability (due to use of a PRNG)...

More exhaustive tool would operate on tcpdump output or run live with
pcap, gather samples of sequences of TXIDs,
port numbers, timestamps.

And perform tests for independency between TXID and port number, timestamp,

and some statistical tests for randomness.

> On Tue, Jul 8, 2008 at 8:20 PM, Owen DeLong <***@delong.com> wrote:
>
>> The tool, unfortunately, only goes after the server it thinks you are using
>> to
>> recurse from the client where you're running your browser.
>>
The very nature of the tool (remote probe by an outside server) also
makes it impossible for it you to probe
intermediary DNS servers.

For example, you might resolve using vulnerable recursive server that
forwards all queries to a 'safe'
recursive server.

The TXIDs generated by the 'vulnerable' server are never seen by the
remote web server.

>> This makes it hard to test servers being used in production environments
>> without GUIs. The tool is not Lynx compatible.
>>
>> Owen
>>

--
-J
Jean-François Mezei
2008-07-09 04:04:33 UTC
Permalink
Re: the tool

My DNS server does not serve the outside world. Incoming packets to port
53 are NAT directed to an non-existant IP on the LAN.

The tool uses my internet facing IP as my DNS server and tells me I am
vulnerable. Since, from the internet, connecting to that IP at port 53
will not get you to a DNS server, I find the tool's conclusion rather
without much value.
Chris Adams
2008-07-09 04:15:00 UTC
Permalink
Once upon a time, Jean-François Mezei <***@vaxination.ca> said:
> The tool uses my internet facing IP as my DNS server and tells me I am
> vulnerable. Since, from the internet, connecting to that IP at port 53
> will not get you to a DNS server, I find the tool's conclusion rather
> without much value.

There are many ways to get your server to look something up other than
allowing direct queries.
--
Chris Adams <***@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
Michael C. Toren
2008-07-09 05:54:27 UTC
Permalink
On Tue, Jul 08, 2008 at 06:26:01PM -0700, Lynda wrote:
> Owen DeLong wrote:
> > The tool, unfortunately, only goes after the server it thinks you are
> > using to recurse from the client where you're running your browser.
> >
> > This makes it hard to test servers being used in production
> > environments without GUIs. The tool is not Lynx compatible.
>
> Figures. It's becoming a pointy-clicky world. I don't like it much,
> either.

[..]

> I'll see whether someone can pry the code loose from Dan, rather than
> having it hidden under a button. As Christian Koch said, the tool isn't
> really directed at NANOG folk. I'm sure that it could be modified so
> that it was. I note that BIND has been updated on all your favorite
> operating systems, which should help some. Still, the updates just
> barely happened, and then the announcement hit.

Reading through the JavaScript that drives <http://www.doxpara.com/>,
it appears to be pretty easy to write a non-AJAX client to query Dan's
service. I threw one together in perl, named "noclicky", that allows you
to use Dan's service against any nameserver specified on the command line.
You can download a copy from <http://michael.toren.net/code/noclicky/>.
Here's an example using the script against an unpatched system:

bash$ ./noclicky 207.106.1.2
Looking up knzcgp14upi9.toorrr.com against 207.106.1.2
Fetching http://209.200.168.66/fprint/knzcgp14upi9
Requests seen for knzcgp14upi9.toorrr.com:
63.139.151.102:32932 TXID=45460
63.139.151.102:32932 TXID=9718
63.139.151.102:32932 TXID=40448
63.139.151.102:32932 TXID=27861
63.139.151.102:32932 TXID=59838
Your nameserver appears vulnerable; all requests came from the same port.

Note that the IP address Dan's service is reporting on is 63.139.151.102,
which is different than the IP address I'm issuing DNS requests against.
In this specific case, it's likely that 207.106.1.2 is configured to use
63.139.151.102 as a forwarder.

Here's an example using the script against a Comcast nameserver, which has
already patched been patched:

bash$ ./noclicky 68.87.76.181
Looking up r14z2k52m6uj.toorrr.com against 68.87.76.181
Fetching http://209.200.168.66/fprint/r14z2k52m6uj
Requests seen for r14z2k52m6uj.toorrr.com:
68.87.76.181:17244 TXID=23113
68.87.76.181:17219 TXID=31336
68.87.76.181:17270 TXID=1613
68.87.76.181:16987 TXID=22846
68.87.76.181:16974 TXID=24013
Your nameserver appears to be safe

On Tue, Jul 08, 2008 at 09:22:23PM -0500, Jimmy Hess wrote:
> I suspect the tool's form might partly be meant to obscure exactly what
> patterns it is looking for. Kind of how one might release a
> vulnerability checker in binary form (but with source code intentionally
> witheld)
>
> 5 query samples would not seem to be a sufficient number to compute the
> probability that the TXIDs and source ports are both independent and
> random, with stringent confidence intervals, and that there is no
> sequence predictability (due to use of a PRNG)...

The logic for determining whether or not a nameserver is vulnerable
turns out to be entirely exposed in the JavaScript client. It isn't
doing anything with the TXID values, but rather just checking to see if
requests were issued from more than one source port. See line 86 of
<http://foo.toorrr.com/printme.html>. Also, if you want to see how the
service is forcing the client to issue five successive DNS requests,
check out the output of dig(1) against foo.toorrr.com.

(Disclaimer: I'm somewhat sleep deprived at the moment due to jet lag,
and some of the information above could very well end up being wrong.
Others are encouraged to double check my work.)

Thanks,
-mct
Jean-François Mezei
2008-07-09 08:39:49 UTC
Permalink
Michael C. Toren wrote:

> bash$ ./noclicky 68.87.76.181
> Looking up r14z2k52m6uj.toorrr.com against 68.87.76.181
> Fetching http://209.200.168.66/fprint/r14z2k52m6uj
> Requests seen for r14z2k52m6uj.toorrr.com:
> 68.87.76.181:17244 TXID=23113
> 68.87.76.181:17219 TXID=31336
> 68.87.76.181:17270 TXID=1613
> 68.87.76.181:16987 TXID=22846
> 68.87.76.181:16974 TXID=24013
> Your nameserver appears to be safe
>

Thanks for the explanation. I used wireshark to capture the DNS traffic
from my server to the outside world while running the doxpara.com test.

My DNS server made the various DNS requests from the same port and is
thus vulnerable. (VMS TCPIP Services so no patches expected).
Jay R. Ashworth
2008-07-09 13:16:53 UTC
Permalink
On Wed, Jul 09, 2008 at 04:39:49AM -0400, Jean-Fran?ois Mezei wrote:
> My DNS server made the various DNS requests from the same port and is
> thus vulnerable. (VMS TCPIP Services so no patches expected).

Well, yes, but unless I've badly misunderstood the situation, all
that's necessary to mitigate this bug is to interpose a non-buggy
recursive resolver between the broken machine and the Internet at
large, right?

So just make sure your corporate/campus edge router has a reasonable
named on it, and point everything broken at that, and you should be ok,
even though, as you note, DEC won't be updating VMS any time soon. :-)

Cheers,
-- jr 'Compaq? No, that's HP now, isn't it?' a
--
Jay R. Ashworth Baylink ***@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com '87 e24
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

Those who cast the vote decide nothing.
Those who count the vote decide everything.
-- (Joseph Stalin)
Simon Waters
2008-07-09 13:38:38 UTC
Permalink
On Wednesday 09 July 2008 14:16:53 Jay R. Ashworth wrote:
> On Wed, Jul 09, 2008 at 04:39:49AM -0400, Jean-Fran?ois Mezei wrote:
> > My DNS server made the various DNS requests from the same port and is
> > thus vulnerable. (VMS TCPIP Services so no patches expected).
>
> Well, yes, but unless I've badly misunderstood the situation, all
> that's necessary to mitigate this bug is to interpose a non-buggy
> recursive resolver between the broken machine and the Internet at
> large, right?

He said "DNS server", which you wouldn't want to point at a correct named,
because that would be forwarding, and forwarding has its own security issues.

I've already dragged a name server here back to a supported OS version today
because of this, don't see why others should escape ;)
Jay R. Ashworth
2008-07-09 14:18:04 UTC
Permalink
On Wed, Jul 09, 2008 at 02:38:38PM +0100, Simon Waters wrote:
> On Wednesday 09 July 2008 14:16:53 Jay R. Ashworth wrote:
> > On Wed, Jul 09, 2008 at 04:39:49AM -0400, Jean-Fran?ois Mezei wrote:
> > > My DNS server made the various DNS requests from the same port and is
> > > thus vulnerable. (VMS TCPIP Services so no patches expected).
> >
> > Well, yes, but unless I've badly misunderstood the situation, all
> > that's necessary to mitigate this bug is to interpose a non-buggy
> > recursive resolver between the broken machine and the Internet at
> > large, right?
>
> He said "DNS server", which you wouldn't want to point at a correct named,
> because that would be forwarding, and forwarding has its own security issues.

Assuming that he actually meant "name server" and not "the resolver
library on my VMS machine" -- lots of Unix boxes don't run a local
named either. No offense to JF...

> I've already dragged a name server here back to a supported OS version today
> because of this, don't see why others should escape ;)

Well, in his case, for the same reason that no one will be upgrading
the resolver library on Win98 if it's broke, I think.

Cheers,
-- jra
--
Jay R. Ashworth Baylink ***@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com '87 e24
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

Those who cast the vote decide nothing.
Those who count the vote decide everything.
-- (Josef Stalin)
Jay R. Ashworth
2008-07-08 23:20:05 UTC
Permalink
On Tue, Jul 08, 2008 at 01:48:57PM -0700, Buhrmaster, Gary wrote:
> Multiple DNS implementations vulnerable to cache poisoning:
>
> http://www.kb.cert.org/vuls/id/800113
>
> (A widely coordinated vendor announcement. As always,
> check with your vendor(s) for patch status.)

Obligatory Slashdot link: http://it.slashdot.org/article.pl?sid=08/07/08/195225

(There's actually some useful data in the comments for a change, or I
wouldn't have bothered.)

Cheers,
-- jra
--
Jay R. Ashworth Baylink ***@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com '87 e24
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

Those who cast the vote decide nothing.
Those who count the vote decide everything.
-- (Joseph Stalin)
Jay R. Ashworth
2008-07-08 23:56:05 UTC
Permalink
On Tue, Jul 08, 2008 at 07:20:05PM -0400, Jay R. Ashworth wrote:
> Obligatory Slashdot link: http://it.slashdot.org/article.pl?sid=08/07/08/195225

Additional coverage:

http://news.cnet.com/8301-10789_3-9985815-57.html
http://news.cnet.com/8301-10789_3-9985826-57.html
http://news.cnet.com/8301-10789_3-9985618-57.html
http://www.linux.com/feature/141080
http://www.internetnews.com/security/article.php/3757746
http://www.techmeme.com/080708/p137#a080708p137

Y'know, for you to put on the noticeboard for your help desk, for when
the spooked herd starts calling.

Cheers,
-- jra
--
Jay R. Ashworth Baylink ***@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com '87 e24
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

Those who cast the vote decide nothing.
Those who count the vote decide everything.
-- (Joseph Stalin)
Lynda
2008-07-09 00:12:04 UTC
Permalink
This is also being covered over on the Defcon Forums. Jeff Moss has said
that he'll post the link to the interview that Kaminsky is doing right
now, after it's over. Here's the link to the Forum discussion:

https://forum.defcon.org/showthread.php?t=9547

The forum link also has a link to Dan's tool, where you can see if your
DNS server is vulnerable.

--
In April 1951, Galaxy published C.M. Kornbluth's "The Marching Morons".
The intervening years have proven Kornbluth right.
--Valdis Kletnieks
Owen DeLong
2008-07-09 00:20:30 UTC
Permalink
The tool, unfortunately, only goes after the server it thinks you are
using to
recurse from the client where you're running your browser.

This makes it hard to test servers being used in production environments
without GUIs. The tool is not Lynx compatible.

Owen

On Jul 8, 2008, at 5:12 PM, Lynda wrote:

> This is also being covered over on the Defcon Forums. Jeff Moss has
> said that he'll post the link to the interview that Kaminsky is
> doing right now, after it's over. Here's the link to the Forum
> discussion:
>
> https://forum.defcon.org/showthread.php?t=9547
>
> The forum link also has a link to Dan's tool, where you can see if
> your DNS server is vulnerable.
>
> --
> In April 1951, Galaxy published C.M. Kornbluth's "The Marching
> Morons".
> The intervening years have proven Kornbluth right.
> --Valdis Kletnieks
Christian Koch
2008-07-09 00:38:56 UTC
Permalink
surely the tool is not focused at a dns operator/admin audience..




On Tue, Jul 8, 2008 at 8:20 PM, Owen DeLong <***@delong.com> wrote:

> The tool, unfortunately, only goes after the server it thinks you are using
> to
> recurse from the client where you're running your browser.
>
> This makes it hard to test servers being used in production environments
> without GUIs. The tool is not Lynx compatible.
>
> Owen
>
>
> On Jul 8, 2008, at 5:12 PM, Lynda wrote:
>
> This is also being covered over on the Defcon Forums. Jeff Moss has said
>> that he'll post the link to the interview that Kaminsky is doing right now,
>> after it's over. Here's the link to the Forum discussion:
>>
>> https://forum.defcon.org/showthread.php?t=9547
>>
>> The forum link also has a link to Dan's tool, where you can see if your
>> DNS server is vulnerable.
>>
>> --
>> In April 1951, Galaxy published C.M. Kornbluth's "The Marching Morons".
>> The intervening years have proven Kornbluth right.
>> --Valdis Kletnieks
>>
>
>
>


--
^christian$
Lynda
2008-07-09 01:26:01 UTC
Permalink
Owen DeLong wrote:

> The tool, unfortunately, only goes after the server it thinks you are
> using to recurse from the client where you're running your browser.
>
> This makes it hard to test servers being used in production
> environments without GUIs. The tool is not Lynx compatible.

Figures. It's becoming a pointy-clicky world. I don't like it much, either.

> On Jul 8, 2008, at 5:12 PM, Lynda wrote:
>
>> This is also being covered over on the Defcon Forums. Jeff Moss has
>> said that he'll post the link to the interview that Kaminsky is doing
>> right now, after it's over.

Here's the direct link, for the curious:

Audio of Dan's press interview:

https://media.blackhat.com/webinars/...conference.mp3

I'll see whether someone can pry the code loose from Dan, rather than
having it hidden under a button. As Christian Koch said, the tool isn't
really directed at NANOG folk. I'm sure that it could be modified so
that it was. I note that BIND has been updated on all your favorite
operating systems, which should help some. Still, the updates just
barely happened, and then the announcement hit.

--
In April 1951, Galaxy published C.M. Kornbluth's "The Marching Morons".
The intervening years have proven Kornbluth right.
--Valdis Kletnieks
Jeffrey Ollie
2008-07-09 01:38:55 UTC
Permalink
On Tue, Jul 8, 2008 at 8:26 PM, Lynda <***@deaddrop.org> wrote:
>
> Audio of Dan's press interview:
>
> https://media.blackhat.com/webinars/...conference.mp3

Actual URL:

https://media.blackhat.com/webinars/blackhat-kaminsky-dns-press-conference.mp3

Jeff
Jay R. Ashworth
2008-07-09 01:43:36 UTC
Permalink
On Tue, Jul 08, 2008 at 05:12:04PM -0700, Lynda wrote:
> The forum link also has a link to Dan's tool, where you can see if your
> DNS server is vulnerable.

As a /.er noted, running that tool after *accessing it via DNS* may not
tell you anything, and I don't know that Kaminsky has himself
publically announced the IP address of his test machine.

Cheers,
-- jra
--
Jay R. Ashworth Baylink ***@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com '87 e24
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

Those who cast the vote decide nothing.
Those who count the vote decide everything.
-- (Joseph Stalin)
Joe Greco
2008-07-09 12:17:53 UTC
Permalink
> > surely the tool is not focused at a dns operator/admin audience..
>
> I suspect the tool's form might partly be meant to obscure exactly what
> patterns it is looking for.
> Kind of how one might release a vulnerability checker in binary form
> (but with source code intentionally witheld)
>
> 5 query samples would not seem to be a sufficient number to compute the
> probability that the TXIDs and
> source ports are both independent and random, with stringent confidence
> intervals, and that there is
> no sequence predictability (due to use of a PRNG)...
>
> More exhaustive tool would operate on tcpdump output or run live with
> pcap, gather samples of sequences of TXIDs,
> port numbers, timestamps.
>
> And perform tests for independency between TXID and port number, timestamp,
> and some statistical tests for randomness.

Since it appears as though a significant part of the solution is tied to
upgrading to new code, which implements better PRNG *and* random source
ports, it seems that one indicator for vulnerability is simply the reuse
of a source port number, which should be trivial to identify without any
concern for having to look for "patterns" within the PRNG-generated TXID.

You do not necessarily need to be able to verify that something is NOT
vulnerable in order to detect vulnerability. Your answers will only be
"is vulnerable" and "might be vulnerable" of course, but that's useful
all by itself.

... JG
--
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.
Steven M. Bellovin
2008-07-09 15:41:43 UTC
Permalink
On Tue, 8 Jul 2008 13:48:57 -0700
"Buhrmaster, Gary" <***@slac.stanford.edu> wrote:

>
> Multiple DNS implementations vulnerable to cache poisoning:
>
> http://www.kb.cert.org/vuls/id/800113
>
> (A widely coordinated vendor announcement. As always,
> check with your vendor(s) for patch status.)
>
It's worth noting that the basic idea of the attack isn't new. Paul
Vixie described it in 1995 at the Usenix Security Conference
(http://www.usenix.org/publications/library/proceedings/security95/vixie.html)
-- in a section titled "What We Cannot Fix", he wrote:

With only 16 bits worth of query ID and 16 bits worth of UDP
port number, it's hard not to be predictable. A determined
attacker can try all the numbers in a very short time and can
use patterns derived from examination of the freely available
BIND code. Even if we had a white noise generator to help
randomize our numbers, it's just too easy to try them all.

The ISC web page on the attack notes "DNSSEC is the only definitive
solution for this issue. Understanding that immediate DNSSEC deployment
is not a realistic expectation..." I wonder what NANOG folk can do
about the second part of that quote...


--Steve Bellovin, http://www.cs.columbia.edu/~smb
Christopher Morrow
2008-07-09 16:05:38 UTC
Permalink
On Wed, Jul 9, 2008 at 11:41 AM, Steven M. Bellovin <***@cs.columbia.edu> wrote:

> The ISC web page on the attack notes "DNSSEC is the only definitive
> solution for this issue. 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,
that's not nanog... doh!

Pressure your local ICANN officers?

-Chris
Steven M. Bellovin
2008-07-09 16:11:27 UTC
Permalink
On Wed, 9 Jul 2008 12:05:38 -0400
"Christopher Morrow" <***@gmail.com> wrote:

> On Wed, Jul 9, 2008 at 11:41 AM, Steven M. Bellovin
> <***@cs.columbia.edu> wrote:
>
> > The ISC web page on the attack notes "DNSSEC is the only definitive
> > solution for this issue. 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,
> that's not nanog... doh!
>
> Pressure your local ICANN officers?
>
How many ISPs run DNS servers for customers? Start by signing those
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
are not free to desist from it." (From the Talmud, circa 130.)

No, I didn't say it would be easy, but if we don't start we're not
going to get anywhere.


--Steve Bellovin, http://www.cs.columbia.edu/~smb
Christopher Morrow
2008-07-09 17:06:53 UTC
Permalink
On Wed, Jul 9, 2008 at 12:11 PM, Steven M. Bellovin <***@cs.columbia.edu> wrote:
> On Wed, 9 Jul 2008 12:05:38 -0400
> "Christopher Morrow" <***@gmail.com> wrote:
>> 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.
Steven M. Bellovin
2008-07-09 17:55:07 UTC
Permalink
On Wed, 9 Jul 2008 13:06:53 -0400
"Christopher Morrow" <***@gmail.com> wrote:

> On Wed, Jul 9, 2008 at 12:11 PM, Steven M. Bellovin
> <***@cs.columbia.edu> wrote:
> > On Wed, 9 Jul 2008 12:05:38 -0400
> > "Christopher Morrow" <***@gmail.com> wrote:
> >> 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).

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 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?
>
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, http://www.cs.columbia.edu/~smb
Martin Hannigan
2008-07-09 18:10:12 UTC
Permalink
[ 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<
Sean Donelan
2008-07-09 17:55:52 UTC
Permalink
On Wed, 9 Jul 2008, Steven M. Bellovin wrote:
> How many ISPs run DNS servers for customers? Start by signing those
> 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
> are not free to desist from it." (From the Talmud, circa 130.)
>
> No, I didn't say it would be easy, but if we don't start we're not
> going to get anywhere.

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?
Joe Abley
2008-07-09 16:32:13 UTC
Permalink
On 9 Jul 2008, at 12:05, Christopher Morrow wrote:

> On Wed, Jul 9, 2008 at 11:41 AM, Steven M. Bellovin <***@cs.columbia.edu
> > wrote:
>
>> The ISC web page on the attack notes "DNSSEC is the only definitive
>> solution for this issue. 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,
> that's not nanog... doh!

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
David Conrad
2008-07-09 16:59:27 UTC
Permalink
On Jul 9, 2008, at 9:05 AM, Christopher Morrow wrote:
>> 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
Randy Bush
2008-07-09 21:52:45 UTC
Permalink
> 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
David Conrad
2008-07-09 22:58:23 UTC
Permalink
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

On Jul 9, 2008, at 2:52 PM, Randy Bush 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?
>
> randy
>
Randy Bush
2008-07-09 23:17:21 UTC
Permalink
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
David Conrad
2008-07-09 23:28:43 UTC
Permalink
On Jul 9, 2008, at 4:17 PM, Randy Bush wrote:
> 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...

Regards,
-drc
Randy Bush
2008-07-09 23:31:08 UTC
Permalink
>> 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
Christopher Morrow
2008-07-10 02:55:05 UTC
Permalink
On Wed, Jul 9, 2008 at 7:28 PM, David Conrad <***@virtualized.org> wrote:
> On Jul 9, 2008, at 4:17 PM, Randy Bush wrote:
>>
>> 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...
>

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
Martin Hannigan
2008-07-10 03:27:02 UTC
Permalink
On Wed, Jul 9, 2008 at 10:55 PM, Christopher Morrow
<***@gmail.com> wrote:
> On Wed, Jul 9, 2008 at 7:28 PM, David Conrad <***@virtualized.org> wrote:
>> On Jul 9, 2008, at 4:17 PM, Randy Bush wrote:
>>>
>>> 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...
>>
>
> 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?


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<
Christopher Morrow
2008-07-10 03:46:53 UTC
Permalink
On Wed, Jul 9, 2008 at 11:27 PM, Martin Hannigan <***@gmail.com> wrote:
> On Wed, Jul 9, 2008 at 10:55 PM, Christopher Morrow
> <***@gmail.com> 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?
>
>
> I'd rather see the IANA do it. I wouldn't say that they are 100%
> neutral, but they're more neutral than SPARTA.

I've got no particular want of sparta doing it, just mentioning that
they had done at least one in the past... maybe DRC can roll out a
preso/examples/docs for LAX/<next-location> :) I don't care as long as
it'll help people start doing work on their part of the pie and it's
applicable to the conference.

-Chris
David Conrad
2008-07-10 17:25:56 UTC
Permalink
On Jul 9, 2008, at 8:27 PM, Martin Hannigan wrote:
>>> If there is sufficient interest, we could do a bar bof to describe
>>> some of
>>> the tools IANA has...
>> 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?
> I'd rather see the IANA do it. I wouldn't say that they are 100%
> neutral, but they're more neutral than SPARTA.


Not taking the bait on neutrality (:-)), but I don't see this as
either/or...

Regards,
-drc
Christopher Morrow
2008-07-10 15:08:49 UTC
Permalink
On Thu, Jul 10, 2008 at 10:22 AM, Wes Hardaker <***@hardakers.net> wrote:
>>>>>> On Wed, 9 Jul 2008 22:55:05 -0400, "Christopher Morrow" <***@gmail.com> said:
>
>>>> 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...
>>>
>
> CM> I think Sandy Murphy or other Sparta folks have presented some of the
> CM> work they've done on this... Perhaps finding one/some of them and
> CM> having a more operations focused presentation in LAX or ... is a good
> CM> idea as well?
>
> The tools that Sparta developed (and made freely available via an open
> source packaged that is BSD licensed) can be found at
> http://www.dnssec-tools.org/ . In particular, signing a zone is

yup, and that's helpful stuff.

> intended to be easy using "zonesigner" (requires bind tools):
>
> zonesigner -genkeys db.example.com
>

great... what about a zone that's getting slaved off of a silent
master at the customer site? how does that get integrated? (customer
does the dns-sec magic, my server validates the updates... config
examples help here)

> Then next time, just leave off the -genkeys argument.
>
> (there is also a daemon called "rollerd" that can auto-sign on a regular
> basis and help automate key-rollever timing)
>

nice, extra load induced on server? impact on the number of zones I
can serve? tinydns compatible? db-backended NS daemon support?

> The full list of tools and tutorials sectioned into different needs can
> be found here:
>
> http://www.dnssec-tools.org/wiki/index.php/Tutorials
>

great :)

>
> All for free. Don't you hate those ??biased??, freely-available,
> source-code-supplied-so-you-can-change-it, BSD-licensed open source
> packages?
> --

I like free... as long as it's the hammer I need for the nails I have.

-Chris
David Conrad
2008-07-10 17:24:32 UTC
Permalink
Already gotten a hint that something along these lines would be
desirable for LAX. I can propose something to the PC -- which would
be more useful for folks, a more general DNSSEC signing workshop or a
focused presentation on IANA's stuff?

Regards,
-drc

On Jul 9, 2008, at 7:55 PM, Christopher Morrow wrote:

> On Wed, Jul 9, 2008 at 7:28 PM, David Conrad <***@virtualized.org>
> wrote:
>> On Jul 9, 2008, at 4:17 PM, Randy Bush wrote:
>>>
>>> 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...
>>
>
> 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
>
Michael Sinatra
2008-07-10 18:12:56 UTC
Permalink
On 07/10/08 11:03, Jay R. Ashworth wrote:
> Another test, that apparently was publicized on some dnsops list:
>
> dig +short porttest.dns-oarc.net TXT

The "some dnsops list" is the OARC public dns-operations list, and this
posting explains the tool and briefly describes the results:

http://lists.oarci.net/pipermail/dns-operations/2008-July/002932.html

There's a healthy discussion of this vuln and DNSSEC going on over
there, and that list is an appropriate forum for further discussion of
this topic.

michael
Russ Mundy
2008-07-10 21:51:12 UTC
Permalink
At 10:24 AM -0700 7/10/08, David Conrad wrote:
>Already gotten a hint that something along these lines would be
>desirable for LAX. I can propose something to the PC -- which would
>be more useful for folks, a more general DNSSEC signing workshop or a
>focused presentation on IANA's stuff?
>
>Regards,
>-drc

Folks might find the DNSSEC session at the recent ICANN meeting interesting
since it focused on DNSSEC in the field and DNSSEC tools. Descriptions of
the presentations as well as the slides are available at:

http://par.icann.org/en/node/77


I imagine that folks might want something different at LAX but I's be happy
to work with drc to put together a DNSSEC session of some sort if there was
interest.

Russ

>
>On Jul 9, 2008, at 7:55 PM, Christopher Morrow wrote:
>
>> On Wed, Jul 9, 2008 at 7:28 PM, David Conrad <***@virtualized.org>
>> wrote:
>>> On Jul 9, 2008, at 4:17 PM, Randy Bush wrote:
>>>>
>>>> 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...
>>>
>>
>> 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
>>
Eric Brunner-Williams
2008-07-10 00:32:34 UTC
Permalink
David Conrad wrote:
> On Jul 9, 2008, at 4:17 PM, Randy Bush wrote:
>> 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...
>
> Regards,
> -drc

Early please. I've got a tight schedule.
Joao Damas
2008-07-10 10:17:08 UTC
Permalink
I would love to get input on that be it in Dublin or elsewhere, both
sides: the authoritative server and the recursive validator. We have
ideas and want to do this but I will not claim to be the owner of THE
TRUTH, so input is much desired.

Joao

PS: I would also want a copy of, or a secure method to access, the
public part of the keys you use to sign those ccTLDs so I can place
them in ISC's DLV registry

On 10 Jul 2008, at 01:17, Randy Bush wrote:

> 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
Jay R. Ashworth
2008-07-09 18:05:40 UTC
Permalink
On Wed, Jul 09, 2008 at 12:05:38PM -0400, Christopher Morrow wrote:
> get the root zone signed, get com/net/org/ccTLD's signed.. oh wait,
> that's not nanog... doh!
>
> Pressure your local ICANN officers?

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
--
Jay R. Ashworth Baylink ***@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com '87 e24
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

Those who cast the vote decide nothing.
Those who count the vote decide everything.
-- (Josef Stalin)
Fernando Gont
2008-07-09 20:07:38 UTC
Permalink
At 12:41 p.m. 09/07/2008, Steven M. Bellovin wrote:

>It's worth noting that the basic idea of the attack isn't new. Paul
>Vixie described it in 1995 at the Usenix Security Conference
>(http://www.usenix.org/publications/library/proceedings/security95/vixie.html)
>-- in a section titled "What We Cannot Fix", he wrote:
>
> With only 16 bits worth of query ID and 16 bits worth of UDP
> port number, it's hard not to be predictable. A determined
> attacker can try all the numbers in a very short time and can
> use patterns derived from examination of the freely available
> BIND code. Even if we had a white noise generator to help
> randomize our numbers, it's just too easy to try them all.

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,

--
Fernando Gont
e-mail: ***@gont.com.ar || ***@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Patrick W. Gilmore
2008-07-09 20:15:20 UTC
Permalink
On Jul 9, 2008, at 4:07 PM, Fernando Gont wrote:
> At 12:41 p.m. 09/07/2008, Steven M. Bellovin wrote:
>
>> It's worth noting that the basic idea of the attack isn't new. Paul
>> Vixie described it in 1995 at the Usenix Security Conference
>> (http://www.usenix.org/publications/library/proceedings/security95/vixie.html
>> )
>> -- in a section titled "What We Cannot Fix", he wrote:
>>
>> With only 16 bits worth of query ID and 16 bits worth of UDP
>> port number, it's hard not to be predictable. A determined
>> attacker can try all the numbers in a very short time and can
>> use patterns derived from examination of the freely available
>> BIND code. Even if we had a white noise generator to help
>> randomize our numbers, it's just too easy to try them all.
>
> 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?

Because many name servers use one port, or easily guessable sequence
of ports?

--
TTFN,
patrick
Eric Davis
2008-07-09 20:24:54 UTC
Permalink
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)

-----Original Message-----
From: Patrick W. Gilmore [mailto:***@ianai.net]
Sent: Wednesday, July 09, 2008 4:15 PM
To: ***@merit.edu
Subject: Re: Multiple DNS implementations vulnerable to cache poisoning

On Jul 9, 2008, at 4:07 PM, Fernando Gont wrote:
> At 12:41 p.m. 09/07/2008, Steven M. Bellovin wrote:
>
>> It's worth noting that the basic idea of the attack isn't new. Paul
>> Vixie described it in 1995 at the Usenix Security Conference
>>
(http://www.usenix.org/publications/library/proceedings/security95/vixie.htm
l
>> )
>> -- in a section titled "What We Cannot Fix", he wrote:
>>
>> With only 16 bits worth of query ID and 16 bits worth of UDP
>> port number, it's hard not to be predictable. A determined
>> attacker can try all the numbers in a very short time and can
>> use patterns derived from examination of the freely available
>> BIND code. Even if we had a white noise generator to help
>> randomize our numbers, it's just too easy to try them all.
>
> 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?

Because many name servers use one port, or easily guessable sequence
of ports?

--
TTFN,
patrick
Phil Regnauld
2008-07-10 13:31:09 UTC
Permalink
Eric Davis (eric) writes:
> Anyone using Infoblox DNSOne? They claimed to have fixed their BIND version
> but I still see issues with source ports staying the same.

Which version are you running of the OS ?
m***@bt.com
2008-07-09 17:39:42 UTC
Permalink
> > 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
David Conrad
2008-07-09 19:30:08 UTC
Permalink
On Jul 9, 2008, at 10:39 AM, <***@bt.com> <***@bt.com
> wrote:
>>> 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
Paul Ferguson
2008-07-09 18:03:48 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- -- Sean Donelan <***@donelan.com> wrote:

>On Wed, 9 Jul 2008, Steven M. Bellovin wrote:
>> How many ISPs run DNS servers for customers? Start by signing those
>> 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
>> are not free to desist from it." (From the Talmud, circa 130.)
>>
>> No, I didn't say it would be easy, but if we don't start we're not
>> going to get anywhere.
>
>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?

The second Tuesday of next week? ;-)

- - ferg (BCP38 Protagonist)

-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.6.3 (Build 3017)

wj8DBQFIdP19q1pz9mNUZTMRAjhrAKC1a0S5jPNyp3BMg932hghE8xG/xwCgzNgl
wdnoEpm0aNTbg+2KHU0w94I=
=Uyns
-----END PGP SIGNATURE-----


--
"Fergie", a.k.a. Paul Ferguson
Engineering Architecture for the Internet
fergdawg(at)netzero.net
ferg's tech blog: http://fergdawg.blogspot.com/
Andrews Carl 455
2008-07-10 19:02:42 UTC
Permalink
https://www.dns-oarc.net

-----Original Message-----
From: Michael Sinatra [mailto:***@rancid.berkeley.edu]
Sent: Thursday, July 10, 2008 1:13 PM
To: Jay R. Ashworth
Cc: ***@nanog.org
Subject: Re: Multiple DNS implementations vulnerable to cache poisoning

On 07/10/08 11:03, Jay R. Ashworth wrote:
> Another test, that apparently was publicized on some dnsops list:
>
> dig +short porttest.dns-oarc.net TXT

The "some dnsops list" is the OARC public dns-operations list, and this
posting explains the tool and briefly describes the results:

http://lists.oarci.net/pipermail/dns-operations/2008-July/002932.html

There's a healthy discussion of this vuln and DNSSEC going on over
there, and that list is an appropriate forum for further discussion of
this topic.

michael
Russ Mundy
2008-07-10 21:34:34 UTC
Permalink
At 11:08 AM -0400 7/10/08, Christopher Morrow wrote:
>On Thu, Jul 10, 2008 at 10:22 AM, Wes Hardaker <***@hardakers.net> wrote:
>>>>>>> On Wed, 9 Jul 2008 22:55:05 -0400, "Christopher Morrow"
>>>>>>><***@gmail.com> said:
>>
>>>>> 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...
>>>>
>>
>> CM> I think Sandy Murphy or other Sparta folks have presented some of the
>> CM> work they've done on this... Perhaps finding one/some of them and
>> CM> having a more operations focused presentation in LAX or ... is a good
>> CM> idea as well?
>>
>> The tools that Sparta developed (and made freely available via an open
>> source packaged that is BSD licensed) can be found at
>> http://www.dnssec-tools.org/ . In particular, signing a zone is
>
>yup, and that's helpful stuff.
>

Great, we're trying to provide tools that will help with the deployment and
operation of DNSSEC. We also try to keep a listing of all the 'pieces'
that we know about that could be helpful to folks who want to deploy and
use DNSSEC in various ways whether they are operating a signed zone,
running a validating resolver or wanting DNSSEC-aware applications. The url
for the listing is:

http://www.dnssec-deployment.org/tracker

We provide the listing as community resource and try to keep it reasonably
current. But we are always on the lookout for additional information (&
corrections) to the list - if you have any, please let me know.

------------->snip<--------------
>>
>> All for free. Don't you hate those ??biased??, freely-available,
>> source-code-supplied-so-you-can-change-it, BSD-licensed open source
>> packages?
>> --
>
>I like free... as long as it's the hammer I need for the nails I have.
>
>-Chris

We don't try to keep track of things in the listing by whether they or free
or not but I know a lot of them have typical open source type of licenses.

Russ
Tuc at T-B-O-H.NET
2008-07-11 14:58:01 UTC
Permalink
> Reading through the JavaScript that drives <http://www.doxpara.com/>,
> it appears to be pretty easy to write a non-AJAX client to query Dan's
> service. I threw one together in perl, named "noclicky", that allows you
> to use Dan's service against any nameserver specified on the command line.
> You can download a copy from <http://michael.toren.net/code/noclicky/>.
>
It looks like Dan changed what it returns, and noclicky 1.00 gets
confused. You can fix this, atleast until MCT comes out with a new version,
by putting :

my $date = shift @data;

before the line :

print "Requests seen for $domain:\n";


Tuc/TBOH
Brian Keefer
2008-07-25 09:28:53 UTC
Permalink
On Jul 11, 2008, at 7:58 AM, Tuc at T-B-O-H.NET wrote:

>> Reading through the JavaScript that drives <http://www.doxpara.com/>,
>> it appears to be pretty easy to write a non-AJAX client to query
>> Dan's
>> service. I threw one together in perl, named "noclicky", that
>> allows you
>> to use Dan's service against any nameserver specified on the
>> command line.
>> You can download a copy from <http://michael.toren.net/code/
>> noclicky/>.
>>
> It looks like Dan changed what it returns, and noclicky 1.00 gets
> confused. You can fix this, atleast until MCT comes out with a new
> version,
> by putting :
>
> my $date = shift @data;
>
> before the line :
>
> print "Requests seen for $domain:\n";
>
>
> Tuc/TBOH
>

Sorry to necro this, but the original version will lead to a false
sense of security and people might be finding it in the archives...

--- noclicky-1.00.pl Fri Jul 25 02:02:16 2008
+++ noclicky-1.01.pl Fri Jul 25 02:11:18 2008
@@ -64,10 +64,12 @@
my %ports;
for my $data (@data)
{
- chomp($data);
- my ($ip, $port, $txid) = split "-", $data;
- print " $ip:$port TXID=$txid\n";
- $ports{$port} = 1;
+ if ($data =~ /^[1-9]/) {
+ chomp($data);
+ my ($ip, $port, $txid) = split "-", $data;
+ print " $ip:$port TXID=$txid\n";
+ $ports{$port} = 1;
+ }
}

Thanks to Michael for the tool, though!

Brian Keefer
Sr. Systems Engineer
www.Proofpoint.com
"Defend email. Protect data."
Loading...