Conversely, if i'm peering with you and six other guys, and happen to be carrying traffic to your network (but not advertising a route back to some of MY peers, for e.g. traffic engineering reasons) across a given link, you have no business dropping that traffic.
You can announce the route; just make the AS path realllly long so nobody will use it.
RPF is a good idea, but it kind of breaks one of the more fundamental paradigms of the Internets.
I disagree. It would solve this attack, and numerous others, and would in fact break very little.
Sorry, I guess I should have been more explicit. I have seen the claims that BIND v9 was a major rewrite. What I haven't seen are (1) claims that BIND 8 was a major rewrite, or (2) evidence that BIND v9 wasn't a major rewrite. Those are both new claims to me.
That's all right. It should have been parsed as:
That's from the guy who lied about BIND 8
That's from the guy who (made) BIND 9 a complete rewrite
BIND 9 was a major rewrite, but not that a major rewrite is a good thing. Completely rewriting your code base is generally considered bad. A majority of BIND 4 and BIND 8 vulnerabilities could have been fixed by mandating chroot, no-root, port randomization, and separate cache+content servers.
BIND 4 was a mere 10,255 lines, but BIND 8 is over 58,288 lines. Of course, it's more fun to simply load it into git and compare the two versions of the named directory- the patch is 20,548 lines changed alone.
BIND8 wasn't insecure because of "design flaws", or because "it was too complicated", or because "it was written in a different time by different people", but because it was written by people who frankly weren't very good programmers.
Paul is a very smart guy, but a lot of the problems with BIND are simple overengineering and complexity issues.
As for my own investigation, I know, looking at the security advisory history for BIND, there have continued to be a steady stream of vulnerabilities due to implementation errors found in BIND 4 and 8, but very little due to implementation errors in BIND 9. (I'm considering CERT VU#800113 and similar to be design errors, which a rewrite wouldn't fix.)
Except, other nameservers don't have the vulnerability.
The ADDITIONAL-section processing has been the root cause of almost all poisoning attacks. DNS caches that don't have additional-section processing have always been immune.
I'm somewhat willing to forgive the BIND people for certain things, but an outright lie would be another matter entirely.
I'm not. The BIND group has made a number of enormous design errors over the years that have been defended by hubris and ego. I don't trust them at all.
2001.01.29 23:25:06, Paul Vixie*, on bsdi-users: ``See BIND9. Written by a new team, sharing no code with BIND8. Two years in the preparation. 6+ months of testing.... BIND9 is a complete rewrite by completely different (read: better) people.'' (In fact, the team was not ``completely different.'')
2001.02.04 06:32:01, Paul Vixie*, on bind-members: ``We've spent more than $2.5M on BIND9, which is a complete rewrite, and which took a dozen senior or supersenior DNS software experts over two years to complete.''
Ignore for a moment that the claim was wrong, and just bask in the stupidity of the claim that the super senior DNS software experts had never written a name server before (because they didn't work on BIND 4 or BIND 8).
Just because it won't reach critical mass for a time doesn't mean it's inferior.
You're building a straw man mysidia: DNSSEC doesn't do what it claims to do, and doesn't do what people want out of a Secure DNS system.
If DNSSEC is such ajoke, then how do you explain it being the standard? Or do you propose that the IETF is a joke also?
There's a "standard" for IP over Carrier Pigeon. Anyone can submit a paper to the IETF standardization process, and if you get right once, IETF members tend to try to fast-track papers that you submit in the future.
However, the IETF doesn't make you do stuff. They aren't always right, and thy are very often wrong. Example: IQUERY is part of the standard, but no DNS servers support it because it's stupid.
If you think DNSSEC is so poor, then what's your alternative that provides the same level of zone security?
You're confused mysidia: The onus isn't on me to provide and design a perpetual motion machine just because I called Paul's perpetual motion machine broken and stupid.
To be blunt, "the government" can crack your DNSSEC keys as well.
LAN security doesn't enter into it- if your cache is on the same machine, and you're using switched ethernet to the border, any remaining attack vectors "close to home" remain on the same level as transparent proxies and whatnot.
Just because it has "security" in the name, doesn't make it secure, Alice.
The patches make it clear that ADDITIONAL-section processing is to blame- just as it has been numerous times over the last twenty or so years. DJBDNS doesn't do ADDITIONAL-section processing and so it immune. BIND tries to do a lot of hand-waving to continue doing ADDITIONAL-section processing even though it's clearly a bad idea- in order to protect egos.
So the guy who rejects advise from the security community on src port randomization and ADDITIONAL-section handling; the guy who has had countless vulnerabilities, and the very same guy who has lied about BIND8 and BIND9's complete rewrites, that's the guy you're taking at his word regarding the security of DNSSEC?
By the way, DJBDNS supports all RR types- including those that haven't been invented yet, simply because it has an extensible data format.
Yes, DNSSEC is a joke; it doesn't protect against anything happening in reality, and it requires a significant infrastructure that will simply never arrive. Paul is telling everyone to wait for that magic moment where everyone will be able to turn off their "insecure DNS" and replace it with "secure DNS"- it'll just never happen.
Meanwhile, had Paul actually listened to security professionals, Kaminsky's attack would never have happened. And yet, you think he his so above reproach that you practically consider the rejection of DNSSEC some kind of blaspheme.
Getting BGP feeds from nearly every provider requires giving them your AS numbers (including those of all your downstreams and upstreams), and IP blocks- you already have the source routing information. They do this to prevent you from publishing routes for microsoft.com into some black hole someplace.
In fact, many ISPs do infact drop packets with an "invalid" source address- one that they couldn't have learned. All ISPs should do this, and immediately render most practical UDP attacks moot.
Paul is an idiot and a douchebag. He's been lying to you for a long time to cover his own ass: BGP routes are filtered everywhere which means that not only do you have to break the port, and the sequence number, you also have to break the route filtering every AS is already doing.
Meanwhile, had BIND simply gone and removed the stupid ADDITIONAL-section processing like DJBDNS did, you wouldn't be having the described vulnerability.
Secure DNS includes TSIG, TKEY, and all revisions thus far to DNSSEC. So I'm not sure we're using the same dictionary.
TSIG, TKEY, and all revisions thus far to DNSSEC don't make DNS secure.
They (credibility rules) exist to prevent cyclic glue reproduction, and were upgraded due to the Kashpureff attacks.
The credibility rules started showing up in 1992. Kashpureff's 1997 attack had nothing to do with it.
UDP port randomization would not have stopped Kashpureff.
No, but discarding the ADDITIONAL section would. It would be simpler, and cost very little.
... if we ever want to reach Secure DNS's tipping point.
The cost for such an infrastructure is very high, and it's not entirely clear it would be worth it. Most DNS attacks target bugs in the software, or defects in configuration. Increasing the complexity of both decreases DNS security.
As is often the case, I am not sure at this stage exactly what it is we're arguing about.
That's why I call you an idiot: You really don't know why anyone would hesitate to deploy "Secure DNS" because in your mind BIND is as good as they get- nameservers with fewer vulnerabilities "go against the spec" or provide fewer features- BIND provides the right balance.
The reality is that your users don't care: They want to read their email and visit their favorite websites. BIND is nothing more than a means to an end, and pretending otherwise is why you're a douchebag.
Besides, the attacks that DNSSEC and friends actually can protect against are very unrealistic simply because route filtering was easier to deploy.
You'll note I didn't: I called you a very smart man.
However, I also call you a douchebag and an idiot. You and I both know that "Secure DNS" isn't the same thing as DNSSEC- one exists, the other does not. We also know that BIND's credibility rules are stupid.
But most importantly, we also know that a lot of the practical DNS forgery attacks in the past - nearly two decades- could have been mitigated and yet you have led people to believe there is good reason not to stop these attacks.
Page 18: There are three competing implementations, all of which have problems.
Page 21: Deployment problems, clients not supporting; breaks access to sites. BIND bugs.
Also,
$ host -t ds se I.NS.se. Using domain server: Name: I.NS.se. Address: 194.146.106.22#53 Aliases:
se has no DS record
means the security chain is already broken.
Finally, just because someone installed DNS-SEC doesn't mean that "Secure DNS" was deployed. If you can't tell the difference between the two, then you won't be able to have a meaningful conversation about this.
SSL isn't broken when users can't connect to their "secure servers". It's broken when SSL doesn't mean what the users think it means.
Users think SSL means their transaction/connection/information is safe. It might if CA's checked the information of their customers, and made sure they were responsible with data. But they don't. SSL has always been broken.
Randomizing UDP source ports does not solve the problem, it only makes it more difficult to impersonate the responding DNS server.
Tens of thousands of times harder.
Secure DNS makes this kind of impersonation impossible, or at least allows us to bask in the warm glow of impossible
Unfortunately, Secure DNS doesn't exist. Nobody's quite sure what it looks like, or how it'll work because the things crytopgraphers is secure nobody wants to do because it makes ugly domain names, so we just sit here, shouting "Secure DNS" like that's going to make it show up sooner.
Listen, Paul's been crying for DNS-SEC for over a decade and yet there are still zero implementations. Even if there were a software stack, there's no credible authority- domain registrars don't check who they register to, and an email spoof can still steal nameserver configuration.
This isn't a technical problem, it's a social problem.
But it has become abundantly clear to me that DJB and his minions (of which I assume you are one) have failed to matter in most ways, not because of your ideas, but because of the brusque, immature manner in which those ideas are submitted for consideration, outside the standards committees which have served the Internet well for 30 years.
You don't get it, do you? Those thirty years are all about ego. DNS Forgery has been well understood for decades now, and Paul Vixie is only accepting a simple solution while dragging his heels because his very complicated idea didn't work.
The real problem is that Paul is a very smart man, so it's very easy for people like you to see that this is an argument between very smart people. However Paul is also a douchebag and an idiot because he's dragged you into defending his ego, for something that affects millions.
This flaw was well known in 1990. Paul Vixie has been dragging his feet for almost twenty years with crack-potted shit like "additional credibility rules" and extra complexity.
How to fix this bug trivially was well known over ten years ago and still the ISC has been refusing to secure its users because they want to push DNS-SEC- a security system based on a trust hierarchy that doesn't exist, whose implementation has never worked, and will never work because Paul is a fucking idiot who cares more about his own ego than just admitting he was wrong and learning to live with it.
Look even now:
Second, take Secure DNS seriously, even though there are intractable problems in its business and governance model
He can't help himself. He's a douchebag, and I hope he just leaves the Internet business forever. We'd all be much better for it.
Then why don't we have viable 3d open source 3D drivers for graphics cards? I could waste my time naming lots of other examples.
Or you could waste someone elses time by bringing up moot points.
I have multihead 3d, compiz, xinerama, and free drivers. Viable clearly means something else to you, and you're willing to sacrifice your freedom to get it. Fine. Go away.
Slashdot Mirror
I have a full-rate DS3 on a 600mhz Celeron, and six DS1 downstreams.
It isn't as expensive as you think.
You can announce the route; just make the AS path realllly long so nobody will use it.
I disagree. It would solve this attack, and numerous others, and would in fact break very little.
No, the cache has to trust this information.
Not simply, no. It ignores them outright.
Clearly it does not.
That's all right. It should have been parsed as:
BIND 9 was a major rewrite, but not that a major rewrite is a good thing. Completely rewriting your code base is generally considered bad. A majority of BIND 4 and BIND 8 vulnerabilities could have been fixed by mandating chroot, no-root, port randomization, and separate cache+content servers.
BIND 4 was a mere 10,255 lines, but BIND 8 is over 58,288 lines. Of course, it's more fun to simply load it into git and compare the two versions of the named directory- the patch is 20,548 lines changed alone.
BIND8 wasn't insecure because of "design flaws", or because "it was too complicated", or because "it was written in a different time by different people", but because it was written by people who frankly weren't very good programmers.
Paul is a very smart guy, but a lot of the problems with BIND are simple overengineering and complexity issues.
Except, other nameservers don't have the vulnerability.
The ADDITIONAL-section processing has been the root cause of almost all poisoning attacks. DNS caches that don't have additional-section processing have always been immune.
I'm not. The BIND group has made a number of enormous design errors over the years that have been defended by hubris and ego. I don't trust them at all.
Ignore for a moment that the claim was wrong, and just bask in the stupidity of the claim that the super senior DNS software experts had never written a name server before (because they didn't work on BIND 4 or BIND 8).
No, it really doesn't. They simply ask your ISP to tunnel your IP into their site.
DNSSEC doesn't enter into it.
"The only way to support all of the new DNS protocol enhancements was to totally rewrite BIND.
BIND version 9 is a major rewrite of nearly all aspects of the underlying BIND architecture.
You're building a straw man mysidia: DNSSEC doesn't do what it claims to do, and doesn't do what people want out of a Secure DNS system.
There's a "standard" for IP over Carrier Pigeon. Anyone can submit a paper to the IETF standardization process, and if you get right once, IETF members tend to try to fast-track papers that you submit in the future.
However, the IETF doesn't make you do stuff. They aren't always right, and thy are very often wrong. Example: IQUERY is part of the standard, but no DNS servers support it because it's stupid.
You're confused mysidia: The onus isn't on me to provide and design a perpetual motion machine just because I called Paul's perpetual motion machine broken and stupid.
To be blunt, "the government" can crack your DNSSEC keys as well.
LAN security doesn't enter into it- if your cache is on the same machine, and you're using switched ethernet to the border, any remaining attack vectors "close to home" remain on the same level as transparent proxies and whatnot.
Where is your god then?
Just because it has "security" in the name, doesn't make it secure, Alice.
The patches make it clear that ADDITIONAL-section processing is to blame- just as it has been numerous times over the last twenty or so years. DJBDNS doesn't do ADDITIONAL-section processing and so it immune. BIND tries to do a lot of hand-waving to continue doing ADDITIONAL-section processing even though it's clearly a bad idea- in order to protect egos.
So the guy who rejects advise from the security community on src port randomization and ADDITIONAL-section handling; the guy who has had countless vulnerabilities, and the very same guy who has lied about BIND8 and BIND9's complete rewrites, that's the guy you're taking at his word regarding the security of DNSSEC?
By the way, DJBDNS supports all RR types- including those that haven't been invented yet, simply because it has an extensible data format.
Yes, DNSSEC is a joke; it doesn't protect against anything happening in reality, and it requires a significant infrastructure that will simply never arrive. Paul is telling everyone to wait for that magic moment where everyone will be able to turn off their "insecure DNS" and replace it with "secure DNS"- it'll just never happen.
Meanwhile, had Paul actually listened to security professionals, Kaminsky's attack would never have happened. And yet, you think he his so above reproach that you practically consider the rejection of DNSSEC some kind of blaspheme.
Actually, for multihomed sites it's even easier.
Getting BGP feeds from nearly every provider requires giving them your AS numbers (including those of all your downstreams and upstreams), and IP blocks- you already have the source routing information. They do this to prevent you from publishing routes for microsoft.com into some black hole someplace.
In fact, many ISPs do infact drop packets with an "invalid" source address- one that they couldn't have learned. All ISPs should do this, and immediately render most practical UDP attacks moot.
Paul is an idiot and a douchebag. He's been lying to you for a long time to cover his own ass: BGP routes are filtered everywhere which means that not only do you have to break the port, and the sequence number, you also have to break the route filtering every AS is already doing.
Meanwhile, had BIND simply gone and removed the stupid ADDITIONAL-section processing like DJBDNS did, you wouldn't be having the described vulnerability.
The pro-security community has always been safe; DJBDNS and derivatives are immune to this attack and always have been.
TSIG, TKEY, and all revisions thus far to DNSSEC don't make DNS secure.
The credibility rules started showing up in 1992. Kashpureff's 1997 attack had nothing to do with it.
No, but discarding the ADDITIONAL section would. It would be simpler, and cost very little.
The cost for such an infrastructure is very high, and it's not entirely clear it would be worth it. Most DNS attacks target bugs in the software, or defects in configuration. Increasing the complexity of both decreases DNS security.
That's why I call you an idiot: You really don't know why anyone would hesitate to deploy "Secure DNS" because in your mind BIND is as good as they get- nameservers with fewer vulnerabilities "go against the spec" or provide fewer features- BIND provides the right balance.
The reality is that your users don't care: They want to read their email and visit their favorite websites. BIND is nothing more than a means to an end, and pretending otherwise is why you're a douchebag.
Besides, the attacks that DNSSEC and friends actually can protect against are very unrealistic simply because route filtering was easier to deploy.
So what you're saying is that Verisign can't be fooled again?
In January 2001, an attacker fooled VeriSign, the parent company of Network Solutions, into signing a fake ``Microsoft Corporation'' ActiveX key.
You'll note I didn't: I called you a very smart man.
However, I also call you a douchebag and an idiot. You and I both know that "Secure DNS" isn't the same thing as DNSSEC- one exists, the other does not. We also know that BIND's credibility rules are stupid.
But most importantly, we also know that a lot of the practical DNS forgery attacks in the past - nearly two decades- could have been mitigated and yet you have led people to believe there is good reason not to stop these attacks.
Referring to your own PDF:
Page 18: There are three competing implementations, all of which have problems.
Page 21: Deployment problems, clients not supporting; breaks access to sites. BIND bugs.
Also,
$ host -t ds se I.NS.se.
Using domain server:
Name: I.NS.se.
Address: 194.146.106.22#53
Aliases:
se has no DS record
means the security chain is already broken.
Finally, just because someone installed DNS-SEC doesn't mean that "Secure DNS" was deployed. If you can't tell the difference between the two, then you won't be able to have a meaningful conversation about this.
SSL isn't broken when users can't connect to their "secure servers". It's broken when SSL doesn't mean what the users think it means.
Users think SSL means their transaction/connection/information is safe. It might if CA's checked the information of their customers, and made sure they were responsible with data. But they don't. SSL has always been broken.
Disclaimer. I'm the author of LDAPDNS.
Tens of thousands of times harder.
Unfortunately, Secure DNS doesn't exist. Nobody's quite sure what it looks like, or how it'll work because the things crytopgraphers is secure nobody wants to do because it makes ugly domain names, so we just sit here, shouting "Secure DNS" like that's going to make it show up sooner.
Listen, Paul's been crying for DNS-SEC for over a decade and yet there are still zero implementations. Even if there were a software stack, there's no credible authority- domain registrars don't check who they register to, and an email spoof can still steal nameserver configuration.
This isn't a technical problem, it's a social problem.
You don't get it, do you? Those thirty years are all about ego. DNS Forgery has been well understood for decades now, and Paul Vixie is only accepting a simple solution while dragging his heels because his very complicated idea didn't work.
The real problem is that Paul is a very smart man, so it's very easy for people like you to see that this is an argument between very smart people. However Paul is also a douchebag and an idiot because he's dragged you into defending his ego, for something that affects millions.
Randomize the source port. It's in the third paragraph.
Not exactly.
This flaw was well known in 1990. Paul Vixie has been dragging his feet for almost twenty years with crack-potted shit like "additional credibility rules" and extra complexity.
How to fix this bug trivially was well known over ten years ago and still the ISC has been refusing to secure its users because they want to push DNS-SEC- a security system based on a trust hierarchy that doesn't exist, whose implementation has never worked, and will never work because Paul is a fucking idiot who cares more about his own ego than just admitting he was wrong and learning to live with it.
Look even now:
He can't help himself. He's a douchebag, and I hope he just leaves the Internet business forever. We'd all be much better for it.
What a positively useless definition of Freedom you have!
If the firmware is replacable, I have the ability to replace it, and that includes the source code.
Or you could waste someone elses time by bringing up moot points.
I have multihead 3d, compiz, xinerama, and free drivers. Viable clearly means something else to you, and you're willing to sacrifice your freedom to get it. Fine. Go away.
Why not?
I use an entirely free system, and yes, that's counting firmware and other "binary blobs".