Multiple DNS implementations vulnerable to cache poisoning

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> :slight_smile: 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

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

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 ?

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?

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 :slight_smile:

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

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

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

Regards,
-drc

IANA's 'interim trust anchor repository' will be publicly accessible (of course).

Regards,
-drc

In a message written on Wed, Jul 09, 2008 at 12:30:08PM -0700, David Conrad wrote:

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.

So David, who has control, and what do they need to do?

Every time I've asked someone in the chain about what it takes to
sign the root, their part is done, it's others who aren't doing
their bits.

Perhaps I'm too much of an engineer. Today there is a process for
IANA (ICANN?) to say "update the IP for a.root-servers.net from x
to y" and it makes it to someone who can run vi on the master file,
and they insert a new entry, and boom the root has it.

It seems to me if IANA (ICANN?) generates sigs, hands those same
records to the same person with vi access to the file and they add
them then boom, the root would have it. Signature records are no
different than any other type of record in the root, and other
records have been updated in the past.

Since you already have the sigs on the web page why can't they be
sent to the guy with vi access the same as any other record change?
Please, let us know so people can go fix it.

From: David Conrad [mailto:drc@virtualized.org]
Sent: Thursday, July 10, 2008 1:26 PM
To: Martin Hannigan
Cc: nanog@merit.edu
Subject: Re: Multiple DNS implementations vulnerable to cache

poisoning

>>> 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

Not bait, but agreed. I was trying to indicate that I thought it would
be interesting for the IANA to present something since it is an effort
under the ICANN umbrella, regardless of it being bottom up or top down.

Bad choice of words. Mea culpa.

Best,

Marty

Another test, that apparently was publicized on some dnsops list:

dig +short porttest.dns-oarc.net TXT

Cheers,
-- jra

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

https://www.dns-oarc.net

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

Reading through the JavaScript that drives <http://www.doxpara.com/&gt;,
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/&gt;\.

  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."