Some broadband providers here in .br seems to be blocking access to
the dns-oarc.net test zone (but not to the portal site); most thought
it was intended behavior by those providers (hiding instead of
patching), but you are right, someone might have corrupted the test
zone itself, which aleviates the pressure on the provider to patch it
which in turn keeps the exploits working for more time.
Rubens
Might be the Slashdot effect, in a manner of speaking, since the NANOG community is quite large.
jms
For one iPhone it reported 209.183.54.151 as having GREAT source port randomness and GREAT transaction ID randomness. However, despite the test reporting GREAT, the source ports were _definitely_ non-random.
http://5d93b9656563a44e4c900ff9.et.dns-oarc.net/
-Richard
For one iPhone it reported 209.183.54.151 as having GREAT source port randomness and GREAT transaction ID randomness. However, despite the test reporting GREAT, the source ports were _definitely_ non-random.
"Proving random" is not easy. Proving random that isn't done by certain methods (i.e. certain algorithms or certain sources of entropy) is easier.
Deepak
So is this patch a "true" fix or just a temporary fix until further
work can be done on the problem? I listened to Dan's initial
presentation and I've read a lot of speculation since then. I've also
taken a look at the various blog entries that detail the problem. I
believe I understand what the issue is and I can see how additional
randomization helps. But it that truly an end-all fix, or is this
just the initial cry to stop short-term hijacking?
Ok. I'm just a small-edge-networks weenie; IANAI, or anything else
big like all that. So I usually try to listen more than I talk.
But it seems to me that Paul, you are here espousing the opinion that
there's no business value in people being able to trust that the domain
name they heard on a TV ad and typed into a browser (let's ignore phishing
for the moment) actually takes them to E-Trade, and not RBN.
Am I misunderstanding you?
Cause I see business value in trying to perpetuate that condition.
I don't say it's easy to sell to suits. But that doesn't make it
unnecessary.
I also don't say it's the only way to guarantee that trustability. But
what else have you?
Cheers,
-- jra
So is this patch a "true" fix or just a temporary fix until further
work can be done on the problem?
the only true fix is DNSSEC. meanwhile we'll do UDP port randomization,
plus we'll randomize the 0x20 bits in QNAMEs, plus we'll all do what
nominum does and retry with TCP if there's a QID mismatch while waiting for
a response, and we'll start thinking about using TKEY and TSIG for
stub-to-RDNS relationships.
but the only true long term fix for this is DNSSEC. all else is bandaids,
which is a shame, since it's a sucking chest wound and bandaids are silly.
But it that truly an end-all fix, or is this just the initial cry to stop
short-term hijacking?
all we're trying to do is keep the 'net running long enough to develop
and deploy DNSSEC, which would be much harder if updates.microsoft.com
almost never points to a microsoft-owned computer.
jra@baylink.com ("Jay R. Ashworth") writes:
and if you have time after that, write a letter to your congressman
about the importance of DNSSEC, which sucks green weenies, and is a
decade late, and which has no business model, but which the internet
absolutely dearly needs.But it seems to me that Paul, you are here espousing the opinion that
there's no business value in people being able to trust that the domain
name they heard on a TV ad and typed into a browser (let's ignore phishing
for the moment) actually takes them to E-Trade, and not RBN.Am I misunderstanding you?
yes. and if you re-ask this on dns-operations@lists.oarci.net, i'll explain.
The problem is that the business value, in general, accrues to the wrong
people.
It's useful and valuable for the *end user* and for *E-Trade* to be able to be
sure they didn't go to RBN. The problem is that Joe Sixpack points his
resolver stub at "Bubba's Bait, Tackle, and Internet Emporium ISP", and it's
Bubba that has to fix stuff.
And Bubba doesn't have a clear way to make money off the fixing - there's no
way Bubba can explain to Joe that Bubba is more secure than the *other* bait,
tackle, and DSL reseller in town, because Joe can't understand the problem....
It doesn't help that apparently there's some multi-billion-dollar Bubbas out there.
Hmm, cute.
So uh, is this patch available for download over HTTPS with a key that was generated by the vendor and signed by well trusted root CAs on a boxes with OpenSSL versions not released by Debian?
PATCH NOW PATCH NOW seems like a fantastic way to get nefarious code deployed in really, really interesting places.
So is this patch a "true" fix or just a temporary fix until further
work can be done on the problem?
I guess you need to read some of the related
papers/presentations/advisories/etc
related to a subject that has been under discussion for more 20+ years.
Answering your questions, as said before, the patch is NO FIX to the
problem, it's
just a workaround that (together with an appropiate architecture and
following well
know best practices for DNS deployment) *may* reduce the chances of becoming
a victim of the exploit.
The solution ? DNSSEC, I believe Paul is asking people interested to learn
more
about what needs to be done to get it done to discuss the subject in the
dns-operations list.
My .02
Regards
Jorge
I would argue most of the responsible providers took actions to
prepare for such a leak two weeks ago. Some places have longer test cycles,
so those fixes may be somewhere in the deployment queue. Change managment
policies can be a problem if you're a large telco, and I'm sympathetic.
Regarding Bubba, he won't likely move until there is a real problem,
this makes it on CNN, and even then, he may not understand what is going
on. That win2k server in the corner never got updated. But when he realizes
his business is at risk due to the buggy software, our pal Bubba will
eventually upgrade.
- Jared
I'm not smiling.
I'm wondering if we're insufficiently paranoid.
Course that could be because I'm reading the Mitnick book this week.
But I don't think so.
Cheers,
-- jra
Regarding Bubba, he won't likely move until there is a real problem,
this makes it on CNN, and even then, he may not understand what is going
on. That win2k server in the corner never got updated. But when he
realizes
his business is at risk due to the buggy software, our pal Bubba will
eventually upgrade.
[sarcasm]
It won't take too long until the three lettered news outfits declare the
demise of the internet, Angelina already had the twins, Obama convinced the
Germans to vote for him, McCain didn't win bingo night, and Dolly didn't
sunk the state of Texas under water, so there are no really exciting news to
report, sooner or later they will fish what is being discussed and make up
something to fill the void.
I'd leave the "Bubba in chief" and his associates out of the loop, if they
see the word "poisoned" they will decimate the entire DNS infrastructure and
later send Paul Vixie to explain to Congress why is a good idea to go back
to the HOSTS.TXT, charge 5 bucks for each download (price dependant on the
actual barrel of oil) and return to punch cards (made by Halliburton) ...
[/sarcasm]
Cheers
Jorge
So, you say that(sarcasm). I just got off a 45 minute call where the US
Federal government is interested in how to effectively communicate to the
infrastructure operators the importance and risks of not upgrading the
resolvers.
They wanted someone to apporach those NANOG guys to see if they'll get
off their butts and upgrade. Personally, I share some of their frustration
in getting the reasonable people to upgrade their software, knowing that
the unreasonable folks won't. The question is how can we as an interdependent
industry close the gaps of the "Bubba" SPs and their software upgrade
policies?
That being said, is there anyone keeping metrics of what upgrades have been
done so far?
- Jared
So, you say that(sarcasm). I just got off a 45 minute call where
the US
Federal government is interested in how to effectively communicate to the
infrastructure operators the importance and risks of not upgrading the
resolvers.
Just tell them to call the head of DoC and explain why is so important and
imperative to come up with an acceptable/reasonable signing authority and
enable the deployment of DNSSEC. The patch is just a workaround, it does not
fix the underlying problem that has been there for very long time.
My .02
I raised that issue earlier in the week with some parts of the US Feds
already.
Personally, I see this event as major driver for deploying dnssec.
- Jared
I've been talking to US Gov't folks, too. They really want DNSSEC (and
secure BGP...) deployed.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
jared@puck.nether.net (Jared Mauch) writes:
That being said, is there anyone keeping metrics of what upgrades
have been done so far?
yes. OARC is coordinating that, with data from its own test tool, and from
kaminsky's test tool, and from passive DNS traces seen at ISC SIE. OARC is
also coordinating a notification effort in conjunction with lawrence baldwin
of MyNetWatchman. we're also sharing data with US-CERT to gauge penetration
and while i don't have a pretty graph to show yet, i can say "it's ugly."
Unfortunately, several of the public "testing" sites have been generating
false-positives. The ISPs have updated their DNS servers, some several weeks ago, but the testing site gets confused. Several DNS "security experts" (i.e. anyone with a blog) have also been confused about which ISPs manage which DNS servers versus other DNS servers on a network.
Lots of phone calls to the wrong service providers complaining about
the wrong things.
Some folks who handle lookups for lots of domains have some data, but
without knowing which DNS servers are "official" ISP recursive servers and which DNS servers are just random recursive resolvers owned by end-users, breaking down the data by ISP is a bit of a challange.
If you just want data about overall DNS upgrade activity, not broken down
by "official" or "unofficial" servers, that could be easier to collect.