Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
On Fri, 12 Sep 2008, Kurt Erik Lindqvist wrote: I don't dispute there have been open recursor attacks. However the attacks appear to be contrived and solicited, lacking in number, lacking in intensity, and lacking in actual damage. People working in the field seems to think otherwise. What people? There are 3000 or so members of ARIN. There must be tens of thousands over all the registries. Where are these thousands of ISPs handling DNS open recursors attacks? The (very) few people opposed to open recursors either stand to sell DNSSEC software or support it, or are known to have participated in similar deceptions. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
Please tell about the experiences you personally had with open recursor attacks at Afilias. Afilias doesn't seem to run open recursors--is that correct? Was Afilias a target of an attack? If so, what did Afilias do to mitigate the attack? Why couldn't the attack be mitigated using ordinary methods? I don't seem to have any mention anywhere about Afilias being down or harmed as a result of any attack. --Dean On Wed, 10 Sep 2008, Andrew Sullivan wrote: On Wed, Sep 10, 2008 at 05:38:05PM -0400, Dean Anderson wrote: -Sullivan appears to have no personal knowledge of any attacks working at Afilias, and doesn't assert having personal knowledge. I'm not sure how you conclude I have no personal knowledge, or how you make any inferences about appearances in this matter. But for the record, I do in fact have such personal knowledge, so I hereby assert it. Because when I left Afilias I (naturally) left behind any documents or other evidence to which I might have had access as part of my employment, I'm not actually in a position to deliver any evidence to prove to anyone what I have observed. Since you have responded to everyone who has said, I have observed these attacks, with a demand that they produce evidence that will convince you, it seemed to me to be futile to claim I've such personal knowledge. It will only result in another round of shrill accusations of fraud, long quotations from (in my opinion completely irrelevant) law dictionaries, c. I am willing to take it as stipulated that I am yet another member of the giant global conspiracy to suppress the right-thinking way of running DNS, which is obviously your way; so you may skip listing the many evils I have committed in the course of my miserable life. I still support the document, on the basis of my experience. I leave it to others to evaluate whether my experience is of any worth whatsoever. A -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
On Thu, 11 Sep 2008, [UTF-8] OndÅej Surý wrote: No. And I don't understand why the burden of open resolvers should be put on shoulders of attacked DNS operators. DNS operators aren't generally being attacked, and aren't generally complaining of the burden. Almost no one is complaining of an actual burden. Indeed, the almost total lack of burden is what's most notable for this extreme measure of closing all open recursors. However, if there someday becomes a true burden, the first complaint should go to the DNSSEC vendors/advocates such as Nominet and DNSSEC.NET who are soliciting abuse of open recursors. I don't understand why open recursors should be closed to increase the sales of DNSSEC software---closed to increase the harm from cache poisoning---closed for no reason. The whole thing appears to be a scam to me. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
On Tue, 9 Sep 2008, Kevin Darcy wrote: First layer of defense: BCP 38 Second layer of defense (because there are those who cannot or will not implement the first layer): Restrict recursive service by default If you mean 'restrict software configuration defaults', I'm OK with that. If the draft is amended to only recommend that vendors should alter their _default_ software configuration, then I will not object to the draft. Third layer of defense (because there are those who cannot or will not implement the first or second layers): Reactively filter abusive recursors (as Dean suggested). --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOP Digest, Vol 22, Issue 16
The address 0.0.0.0 as usually an alias for self, so packets to 0.0.0.0 will be locally delivered. So for recursive DNS servers, this would result in a recursion-to-self error on most DNS servers. --Dean On Thu, 11 Sep 2008, venkatesh.bs wrote: Hi, what may be DNS behaviour if the DNS server address is 0.0.0.0 Regards, venkatesh. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
Hmm. just about 23 hours. So much for sitting quietly while the working group discusses matters. The answer to both the questions is yes. There is still no evidence for no, and _still_ no one has come forward with personal knowledge of any attacks: -Sullivan appears to have no personal knowledge of any attacks working at Afilias, and doesn't assert having personal knowledge. -Conrad says BCP38 hasn't worked (it has indeed worked--imagine if no one implemented BCP38), worked for Nomimum, and ICANN, and appears to have no personal knowledge of any attacks and does not assert personal knowledge. -Andrews works for ISC, the document author's employer. Appears to have no personal knowledge of any attacks, and doesn't assert having any. -Maton Sotomayer works for the Canada National Research Council, and also appears to have no direct knowledge of any attacks, and doesn't assert having any. -Darcy works for Chrysler, appears to oppose the document, I think. Not one single attack has been cited where the two measures cited were actually insufficient. To recap: For some reason that promotors can't or won't explain, they want everyone take the extreme measure to close open recursors, even though this causes harm to many users through cache poisoning of recursors they can't control. DNSSEC advocates sell DNSSEC as a solution to cache poisoning. So they are making a situation worse for their own benefit and profit. DNSSEC advocates are also SOLICITING abuse of open recursors. Some of the above people are known to be DNSSEC advocates. DNSSEC software promoters stand to sell more software if open recursors are widely closed. I've already given a definition of Actionable Fraud. Strangely, the Area Director Ron Bonica thinks (onlist and offlist email) that honesty, reputation, and evidence of harm, are of no consequence to the IETF when considering extreme measures such as this document, and that objections based on the a reputation for previous deceptions, lack of evidence and justification for the extreme action in this document are for some reason (also unexplained) irrelevant. Kind of like a kangaroo court for IETF documents: Evidence for the document is unnecessary; evidence against the document is irrelevant. How is that an honest and open process? Of course, an Area Director has a lot of ability to force a document through the process---violating a lot of rules and violating IETF principles along the way as previous experience shows with RFC4786 and TLS-AUTHZ (one succeeded, on failed; ISC et al benefited from RFC4786). The Area Director can do this because its up to the Area Director to enforce the process rules, so if the Area Director disregards the rules, they can do anything--for a while, anyway. If this document is forced through 'by hook or by crook', it may just wind up another in a pattern of discredited IETF documents. Fortunately, not everyone believes there should not be any personal accountability for past actions. Sometimes all that is needed is an account of past actions. --Dean On Tue, 9 Sep 2008, Ron Bonica wrote: Dean, Thanks for this proposal. At his point, I will sit quietly for a while and let the WG comment on whether they think that your proposed alternative mitigation is adequate. On Friday, the WG chairs will gauge consensus and I will take appropriate action. Ron Dean Anderson wrote: Mitigation of open resolver attacks is well described, both by BCP38 and by the previous comparision with the more damaging DNS attack. If one is attacked by open recursors, the mitigation during the attack is to filter the packets from the open recursors during the attack. Filtering open recursors usually has little or no damage to either the recursor operator or the target of the attack. This is the typical response by ISPs to all kinds of packet flooding attacks. There is nothing special about open recursor attacks that requires any kind of special handling. --Dean On Wed, 10 Sep 2008, Ron Bonica wrote: First layer of defense: BCP 38 Second layer of defense (because there are those who cannot or will not implement the first layer): Restrict recursive service by default If you mean 'restrict software configuration defaults', I'm OK with that. If the draft is amended to only recommend that vendors should alter their _default_ software configuration, then I will not object to the draft. Third layer of defense (because there are those who cannot or will not implement the first or second layers): Reactively filter abusive recursors (as Dean suggested). Folks, Based on the response that we have seen from the WG so far, I don't see any reason to amend the draft. BCP 38 is already published. The questions before the WG are: - is BCP38 enough to mitigate the attack vectors described in draft-ietf-dnsop-reflectors
Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
On Mon, 8 Sep 2008, Ron Bonica wrote: Do you deny that the vulnerabilities described in this document *could* be exploited? If this is your claim, and you can substantiate it, the WG will entertain your objection. I'm asserting that whatever vulnerabilities that do exist can be mitigated in ordinary ways without closing open recursors, including by BCP38. However, if you are arguing any or all of the following, the WG will not entertain your objection: - that there have only been two attacks - that these attacks were contrived - that the organization reporting these attacks is not credible - that the organization reporting these attacks has not satisfied your requests for evidence - that there are easier ways to attack DNS This is because vulnerabilities need to be mitigated, regardless of whether they have been exploited. All protocols have theoretical vulnerabilities. Your assertion that vulnerabilities need to be mitigated, regardless of whether they have been exploited is without basis. ICMP PING can be exploited, and is not especially mitigated by the IETF. Whatever vulnerabilities posed by open recursors can be mitigated in other, cheaper ways, without closing open recursors. This document, (and the specific action it states: closing open recursors) is not necessary to mitigate open recursor abuse. Open recursors have legitimate users and legitimate uses, especially in light of recent cache poisoning attacks. One does not want to trust someone else's recursor. Closing open recursors has an significant expense in security and cost of new servers, and should be well-justified. Your assertion that false statements, contrived attacks, discredited sources, and lack of evidence of harm, are somehow not legitimate reasons to dispute a document is also without basis, and indeed is refuted by IESG actions in TLS-AUTHZ. The fabrications made for this document amount to fraud on the public. It appears that proponents of this document are _encouraging_ exploitation of open recursors in the Rapid Enumeration Tool. (see www.dnssec.net/software) The 'recursors-are-evil' document is just a fraudulent scheme to sell DNSSEC software. Rapid Enumeration Tool (RET) by Nominet UK The Rapid Enumeration Tool (RET) is designed to use DNSSEC NSEC records to enumerate quickly zone data whilst evading detection by systems which might be designed specifically to identify zone enumeration activity. It does this by using one or more open recursive resolvers to forward queries to the authoritative name servers for the zone. Each resolver is configured with its own 'personality', specifying query rates, query failure/success ratio, proportions of query types, query name decoration, etc. This allows the RET to feed queries to each resolver, that are specifically tailored to match the queries that a resolver might typically send to the authoritative name server. Unlike other NSEC resource record 'walkers', the RET does not explicitly query for NSEC RRs to walk the zone. Instead, it combines a 'walker' approach with a dictionary attack (combined with a random name generator for more awkward cases). This means that discernible artifacts in the pattern of queries that arrive at the authoritative servers should be minimised. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
On Tue, 9 Sep 2008, Ron Bonica wrote: Your assertion that false statements, contrived attacks, discredited sources, and lack of evidence of harm, are somehow not legitimate reasons to dispute a document is also without basis, and indeed is refuted by IESG actions in TLS-AUTHZ. I stand by my previous statement. This is a technical argument and not an argument about the moral status of any group or individual. We agree! Well, probably not: I haven't made any argument based on the moral status of any individual. The existance of false statements, contrived attacks, discredited sources, and lack of evidence of harm, are technical issues concerning the actual state of the world. They are not moral issues; I offer no moral judgements. The fabrications made for this document amount to fraud on the public. Be careful about this kind of statement. In any interesting technical discussion, we all run the risk of being wrong. I'm wrong sometimes and I am sure that you are wrong sometimes, too. When you make this kind of statement and you end up being wrong, you have committed a grave offense! I've studied the law on the subject of defamation in detail. Truth is an absolute defense. It appears that proponents of this document are _encouraging_ exploitation of open recursors in the Rapid Enumeration Tool. (see www.dnssec.net/software) The 'recursors-are-evil' document is just a fraudulent scheme to sell DNSSEC software. You can't have it both ways. On one hand, you are saying that the vulnerability isn't significant because it is easily mitigated and on the other hand you are complaining about those bad guys who aren't keeping it low enough profile. If it's so easy to mitigate, why do you care whether knowledge of the vulnerability goes public? Actually, its you who are trying to have it both ways. Proponents claim that the attack is a real threat, but in fact, they are encouraging people to conduct the attack. Lawyers call that solicitation. The attacks using open recursors are contrived, SOLICITED, by the people advocating the closure of open recursors, and SELLING DNSSEC software. My position is consistent: Even though proponents are soliciting the attacks, the attacks are still easily mitigated, and in fact do not represent a real threat that requires special handling. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Reflectors are Evil was Re: Anycast was Re: Cache poisoning on DNSSEC
Gentlefolks, I note that Gadi Evron was, until recently, employed by Afilias, the same company as Joe Abley. At present, acccording to another recent NANOG controversy, Mr. Evron. Mr Hankins is also not an independent source, being part of ISC, Joao Damas' (document author) employer. Also, I do not think that we need to require aristotelian proof. The basis of my objection isn't the lack of aristotelian proof. Rather, it seems reasonable to require _some_ evidence that this is a real problem, especially in light of the contrived and exaggerated nature of the claims; the fact that there are DNS attacks that are easier to conduct; the fact that the alternative attack doesn't risk detection; the fact that the alternative attack is harder to mitigate; as well as the previously discredited source(s) of the claims [See http://www.iadl.org/nanog/nanog-story.html and http://www.iadl.org/maps/maps-story.html] Given that the questioned sources form only a tiny part of even just the North American ISPs, it shouldn't be very hard to find credible sources---that is, if indeed this is a real problem that is widely experienced by internet service providers and that this problem is serious enough to justify the costs of closing open recursors. But so far, We've seen no direct evidence nor any indirect evidence. Anecdotes and personal assurances from a tiny group that has collaborated (properly and improperly) in the past is insufficient to justify the costs of implementing this change. I am also reminded of another point that hasn't been brought up recently: BCP38 provides a complete and general solution for this and other spoofing attacks. Given BCP38, there is really no need for this document. BCP38 should protect many services that could potentially be abused by spoofing, including the legitmate uses of open recursors. The efforts spent on this document (both in writing and in later implementation) would be better applied to promoting and implementing BCP38. I might suggest a poll of ISPs, and if 5000 or so ISPs worldwide agree that open recursors attacks are a current, serious problem that can't be solved by BCP38, then its a problem that should be acted on. However, given past experiences with blacklists (particularly the proponents association with disreputable blacklists), we should take care that the proponents do not unduly solicit or threaten ISPs to obtain agreement. Thanks, --Dean On Fri, 5 Sep 2008, David W. Hankins wrote: [For brevity, this is intended as a message in support of Joe's position. I think my original got eaten in the earlier mail server event announced on ietf@, so apologies for any duplicates.] On Tue, Sep 02, 2008 at 03:46:48PM -0400, Joe Abley wrote: My point is that there are a large number of distributed denial of service attacks happening every day, on a scale large enough to involve multiple providers and cross-organisational teams for mitigation. For informational purposes, I'd like to point out that yesterday on the NANOG mailing list, it was asserted that DNS Amplification attacks are being observed by one security worker (Gadi Evron) on a seemingly daily basis, frustrated by the lack of adoption of BCP 38 (which is proposed as the root cause). [1] Let me say that it is entirely right to suggest that in this case, if you are engaged in a dialogue of logical deduction, then in the face of the claim that something does not exist, the responsibility of argument is to prove that thing does exist, on the basis that one cannot reasonably prove non-existence of any physical object (or event) with Aristotelian tenacity. Which is problematic because such a proof (with Aristotelian tenacity) in this case would require publishing of normally witheld and guarded data in provably unaltered forms. This may not even be possible. This would appear then to be an impasse if the IETF required such tenacity. Fortunately, the IETF works on a basis of consensus among practicioners, not on a basis of Aristotelian deductive proofs of draft contents and volunteers' opinions. I'm content to agree with the other WG participants that DNS Amplification attacks do persist in the modern day, and that it is useful to write and publish a document that seeks mitigation. I hope that the WG's consensus will be so measured by the chairs. [1] - http://www.merit.edu/mail.archives/nanog/msg11131.html -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Reflectors are Evil was Re: Anycast was Re: Cache poisoning on DNSSEC
On Wed, 3 Sep 2008, Danny McPherson wrote: You don't see any evidence of attacks because you haven't read about them on NANOG [or various network forums that you do monitor] - duly noted, and comically ironic. It is indeed comically ironic (telling, actually) that NANOG hasn't discussed the issue. But I fail to understand why YOU think that is comically ironic. It is not merely that *I* don't see any evidence. It is that NO ONE has presented ANY evidence of ANY FURTHER ATTACKS, despite being challenged to provide some evidence. Someday (after we approve this document I suppose) you promise to have *OG types report on this attack. This survey has nothing to do with NANOG, and it's not in any way supported or executed by NANOG. I'm not sure why you keep repeating this when I responded to your initial query as such: No, there's quite a wide distribution of responses, but mostly *OG types in various regions. I never said the survey was sponsored by NANOG. But as you admit above, it limited to the *OG types, which I note have misled us in the past. http://www.iadl.org/nanog/nanog-story.html I'm not very surprised that Vixie and Crocker support this document by personal attacks. They try to use emotion rather than reason to get what they want. They've done that before with the result that the Working Group and the public is deceived. On Wed, 3 Sep 2008, Paul Vixie wrote: how long is this community going to let a single person dominate its agenda? The deception in this assertion is just incredible. I haven't prevented anyone from discussing anything. This is an email list; Anyone can post at any time. Vixie/Crocker (calling me troll) are just engaging in namecalling, and have added nothing but noise and emotion. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] suggestion for 4641bis: key algorithm rollover section
On Thu, 4 Sep 2008, Mark Andrews wrote: It's not a issue. You remove the DS's which have that algorithm then once they have expired from caches you can remove the DNSKEY. Of course, you can replay them, resulting in a DOS. (I'll call this attack 6) --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Reflectors are Evil was Re: Anycast was Re: Cache poisoning on DNSSEC
On Tue, 2 Sep 2008, Joe Abley wrote: Dean, On 1 Sep 2008, at 20:57, Dean Anderson wrote: mostly operations people (as opposed to credible engineers)? If av8.net starts selling t-shirts, I'll take one with that phrase. Perhaps a t-shirt should have this quote from Paul Vixie: describing the IETF as self-selected rabble and trolls http://www.ietf.org/mail-archive/web/ietf/current/msg25874.html Or later in the same message, Vixie says it's hard to commit acts of leadership inside a burning movie theatre. Which is just wrong. Its quite easy to commit acts of leadership during an emergency. (the emergency being spam) The problem was that Vixie was himself a spammer, false teaming with anti-spammers and misleading network operators. Of course, there will be no such t-shirt, you are just using the notion of t-shirt to misrepresent something I said. I don't mean to say that network operators aren't credible, as you seem to imply. I definitely appreciate the craft skills very much. But craft skills don't generally imply knowledge of theory and mathematics; actual engineering. I mean that Network operations staff have a history of being easily misled by emotional appeals such as the war won't be over until the last spammer's head is stuck onto a spear at the city limits.--Paul Vixie, Sept 1997. Although this really fired-up network operations staff, it was later discovered that Vixie was a spammer. Network operations staff however gave Vixie (MAPS/SORBS/SPAMHAUS) anti-spam information on Whitehat's competition, while Whitehat was able to avoid spam-traps; none of this would have been possible without the support of the misled network operations staff. This draft is a similar emotional appeal with insufficient basis in fact of number of attacks, or in theory. There is no harm in public resolvers. Not to the people running the resolvers, usually, no. There is usually no harm to anyone from open resolvers. No one has reported any further attacks since this draft was conceived. I note that there have been no substantive answers to any of the questions I raised, just platitudes and personal attacks. Has there been any subsequent attacks since the motivating attack was reported? Given that we now have some high-profile DNSSEC test zones (thanks to David Conrad), there is now no reason at all to use a recursor in a DDOS attack. One would merely make DNSSEC queries against a high-profile authority server. One can conduct attacks on well-known high-profile authority servers without the risk of exposure inherent in searching out reflectors. And I note that Paul Wouters previously asserted that 100:1 amplification is a non-issue. If so, then certainly reflector attacks are also a non-issue for the same reason. So, this draft is in search of a problem to solve. However, closing open recursors may promote the sales of DNS servers to people who didn't need them before, so I wonder about that. And can we expect to see people selling 'reflector blacklist' products to ISPs to block DNS to open recursors, merely because the recursors are open? Will we see 'reflector blacklist' people scanning for open recursors? -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Reflectors are Evil was Re: Anycast was Re: Cache poisoning on DNSSEC
On Tue, 2 Sep 2008, Joe Abley wrote: On 2 Sep 2008, at 11:04, Dean Anderson wrote: There is no harm in public resolvers. Not to the people running the resolvers, usually, no. There is usually no harm to anyone from open resolvers. No one has reported any further attacks since this draft was conceived. That is not true. It's possible that the forums in which such attacks are discussed are not available to you, of course. I say that not as some kind of thinly-veiled attack, but merely as an observation that security ops forums tend not to be public. Really? Your position is that there are attacks but all these attacks are somehow being kept secret? People talked about ping floods, syn floods, and an uncountable slew of other attacks. Incredible. If these attacks were indeed happening, someone, somewhere would be talking about specific attacks. I note that there have been no substantive answers to any of the questions I raised, just platitudes and personal attacks. Oh, I didn't notice any questions. In any case, I was only responding to what I saw as factual errors. But you don't have any factual counter-evidence to offer to refute the alleged factual errors. Incredible. And I was serious about the t-shirt, if the price is reasonable. XXL, thanks. Then you should know that this isn't a proper forum to be soliciting me about t-shirts. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] DNSKEY / multiprecision number format? (fwd)
If someone could forward this to DNSEXT WG, I would appreciate it. Thanks, --Dean -- Forwarded message -- Date: Sat, 30 Aug 2008 23:14:44 -0400 (EDT) From: Dean Anderson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: DNSKEY / multiprecision number format? I'm wondering how the exponent and modulus are stored in a DNSKEY record for RSASHA1. RFC3110 just makes some vague references to where things go, but does not define their precise format: exponent length 1 or 3 octets (see text) exponent as specified by length field modulus remaining space The format of large binary numbers is never specified in RFC3110, and no standard exists that I can find. I notice that BIND tools just use the openssl library calls bn2bin, which produces an undefined and non-standardized openssl format. GMP and presumably other multiprecision libraries have their own format. GMP's mpz_import function has a number of parameters for importing from different binary multiprecision number formats: count, order, size, endian, nails http://gmplib.org/manual/Integer-Import-and-Export.html#Integer-Import-and-Export The parameters specify the format of the data. /count/ many words are read, each /size/ bytes. order can be 1 for most significant word first or -1 for least significant first. Within each word /endian/ can be 1 for most significant byte first, -1 for least significant first, or 0 for the native endianness of the host CPU. The most significant /nails/ bits of each word are skipped, this can be 0 to use the full words. The only one that can be inferred from an instance of an DNSKEY RR is count. So, can anyone say what the remaining 4 parameters should be for DNSKEY and other DNSSEC records? Is there an RFC that defines these parameters? Thanks, --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Reflectors are Evil was Re: Anycast was Re: Cache poisoning on DNSSEC
On Tue, 2 Sep 2008, Joe Abley wrote: On 2 Sep 2008, at 13:43, Dean Anderson wrote: Really? Your position is that there are attacks but all these attacks are somehow being kept secret? People talked about ping floods, syn floods, and an uncountable slew of other attacks. Incredible. My point is that there are a large number of distributed denial of service attacks happening every day, on a scale large enough to involve multiple providers and cross-organisational teams for mitigation. When new attack techniques emerge, sometimes they make the news. The fiftieth DNS reflection attack on any particular day, years after the technique was first described, is unlikely to be newsworthy. The fact that alarm bells are not sounding in the streets doesn't mean that people continue to work to mitigate such attacks, however, nor that such attacks no longer happen. Significant problems are always newsworthy, or at least discussion-worthy on various network forums that I do monitor. There has been no further discussion of these attacks since the two very small motivating attacks were discussed on NANOG some time ago. I don't see any evidence that there have been more than two such attacks. The existence of closed, operational forums for the discussion and mitigation of denial of service attacks is no great secret to operators. If you're unaware, and you're an operator, feel free to drop me a private note. I would be very happy to let you know about the subscription procedures and attendant vetting by peers that would be required for you to participate (at least, in the forums I am aware of). I imagine discussions of your applicability would be entertaining. I never said the existance of forums were secret. Indeed, the genuine forums are usually for coordination between major carriers' operations groups, and so are only appropriate to the operations employees of those few major carriers. The rest of the (somewhat dubious) forums are groups more or less like blackhat; groups basically training bad guys and/or sharing techniques amoung bad guys, or else amoung dilettantes. Because I am not currently employed in the operations department of a large major carrier myself, I would be unable to actually mitigate any in-progess attacks. Moreover, I've always worked for major carriers in engineering, not operations. So I can't imagine why I would ever want to be in genuine forum, nor would I want to be in any dubious forum. I note that you aren't employeed by any of the major carriers, either. In anycase, I doubt that I would need your assistance with any application. However, not participating in the actual mitigation efforts doesn't mean that attacks aren't discussed post-mortem. These discussions are usually more widespread and are more public. But you have no evidence of such discussion, nor evidence of any actual attacks whatsoever after the motivating attacks. At a higher level, you seem to be seeking some measure of proof regarding the existence of something. My aim was not to provide proof of anything, since as far as I know this is not a court of law, a philosophy class nor a distillery. Apologies if that was not clear. I guessed that your aim was not to provide proof of your assertions. However, for your claims to be credible, there needs to be some evidence that this is a problem that needs to be solved, that the costs are justified. You have no evidence of there being a problem and your claims are not credible because of the lack of evidence. The costs imposed on legitimate open recursors are unjustified. If these attacks were indeed happening, someone, somewhere would be talking about specific attacks. And my point is that they are. Your point is that you don't believe me. I might make the point that I don't care who believes me. Regardless, I will continue not to lose sleep. The people who don't believe you won't lose sleep either when we collectively decide you don't have a genuine problem to be solved, or don't have any evidence of a genuine problem. And I was serious about the t-shirt, if the price is reasonable. XXL, thanks. Then you should know that this isn't a proper forum to be soliciting me about t-shirts. Shame. Perhaps someone else will do the right thing and start selling av8 t-shirts with such pithy catchphrases, given your documented lack of interest in exploiting this no-doubt lucrative opportunity. Then I guess they'll learn about the law on trademark infringement. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Reflectors are Evil was Re: Anycast was Re: Cache poisoning on DNSSEC
On Tue, 2 Sep 2008, Danny McPherson wrote: On Sep 2, 2008, at 12:44 PM, Dean Anderson wrote: I find this hard to believe from three standpoints: 1) the expected number of open DNS recursors and their collective bandwidth doesn't seem to be large enough to support a 40Gbps attack. Really? With trivial amplification vectors 20 low-speed broadband connected bots can generate nearly 1.5 Gbps of attack traffic. It isn't the case that many open recursors are on low-speed broadband connections; That is a residential service, while recursors are usually run by businesses or ISPs, which changes a number of things. I also suppose you expect that 20 * 384kbps * 100x = 1.5Gbps. (384kbs upload speed) (100x amplification factor) The error in your estimate is that you assume if there are bots to send demand, that there are recursors to handle the load. This just isn't the case. The estimate is an ideal maximum, assuming a lot of things are true that aren't true. For example, one never has ideal bandwidth available to any host. And one must still have enough recursors to can handle the offered load. But there aren't enough recursors to provide the load. There are only about 20k or so recursors, and most don't sit on high bandwidth connections. Many don't support EDNSO, so can't get more than about 10x amplification, anyway. Most businesses and ISPs would probably soon notice their participation in a DDOS attack due to their own bandwidth consumption and block the (spoofed) source address without damage as a result of the block, or an upstream carrier would block the spoofed source, also without collateral damage. Furthermore, its relatively easy to change the IP address of a recursor. Abusers need to keep scanning. So, that'd put you around 500 or so bots, and any number of open resolvers, to generate such an attack, which is low-hanging fruit these days. Really? Recursors are low hanging fruit'? By what measure? Of course, the reported amplification vector was higher than this, the number of bots lowers. Higher than what? You can't get more than about 100x from DNS under ideal conditions. 2) Why would anyone capble of programming bother searching for open recursors (with often small connection speeds) when they can use 100+ root servers with large amplification factors and high bandwidth connections at key exchange points? We'll leave that an exercise for the reader... Let's not, since its important to consider the alternatives available to the attacker and the costs of this proposal. Significantly, the abuser has an option that doesn't expose them to discovery by their scanning efforts, and the other attack isn't very easy to mitigate. It doesn't require the effort of scanning, or of distributing a payload of recursors to the bots. Quite a lot easier to do. This seems to make the other attack much more attractive. Something about low-hanging fruit??? 3) Why aren't these attacks being prosecuted? Someone searching for open recursors is bound to be noticed. The only people I know of searching for open recursors is UltraDNS and a scientific group at Cornell. Searching for open recursors and launching an attack are two entirely different things. Yes. One must precede the other. Scanning comes first. And abusers need to keep scanning, which puts them at a disadvantage for this attack. And launching spoofed-based attacks makes finding the attacking sources more difficult. And given that they're most always botted, you then have to find a CC, and then an attacker stepping stone, etc.., etc., No need for rehashes of this here, methinks. Finding the CC for a botnet that must keep scanning to conduct abuse should be easier than for a botnet that doesn't need to scan. You find the person scanning and you found the person involved in the CC. Also, one doesn't need to find the attacking source with recursor abuse. Its a very mitigatable attack. Just like open proxy abuse, one can usually block the recursor without collateral damage. Significantly, one can't easily mitigate the other attack (ala DNSSEC responses) of roots, TLDs, major domain's authority servers. Blocking authority servers generally does significant damage; roots, TLDs, major domains in particular can't be blocked. I'll wait to see the report. It will also be interesting to find out who was surveyed. If it turns out to be primarilly NANOG (the source of the original reports), I'll be more dubious. No, there's quite a wide distribution of responses, but mostly *OG types in various regions. Ahh. Figured as much. Mr. McPherson is associated with NANOG, attending 18 meeting as of NANOG 42; Only 46 people have attended more NANOG meetings than Mr. McPherson. Interesting tidbit, I had no idea. Useless, but interesting :-) Useless to you perhaps. Not so useless to everyone. But its interesting that you aren't concerned by the association
Re: [DNSOP] Anycast was Re: Cache poisoning on DNSSEC
On Mon, 1 Sep 2008, Ralf Weber wrote: Well we tested it as good as we could in our small lab Ahh. This is where your engineers are supposed to consider theory, in this case RFC1546 and RFC1812. Did you tell your senior management that RFC1546 explicitly states that Anycast isn't suitable for TCP? Did you inform your senior management that the Anycast TCP promoters are mostly operations people (as opposed to credible engineers)? Did you tell them that the Anycast promoters have financial conflicts of interest for making their claims, and that they have no theoretical backing for their assertions? Or did you leave all that out? and we did test tcp and we did have problems with it in one setup as described earlier. We did overcome this problems in the lab and now we are actively monitoring it (tcp connection to anycast ips). And we didn't got tickets of customers having problems with DNS TCP connection so far. So you don't see the same source IP addresses repeated at multiple anycast servers within a few minutes? You must have a very unique setup. Are your resolvers public? Of course not, I think there is a paper floating around here that this is a bad idea ;-). Surprisingly, that paper is promoted by the same people promoting Anycast DNS... There is no harm in public resolvers. Would it be OK if I test them? Yeah will send you an separate mail about that. Will do. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Anycast was Re: Cache poisoning on DNSSEC
On Tue, 26 Aug 2008, Ralf Weber wrote: Moin! On Aug 26, 2008, at 21:02 , Dean Anderson wrote: Large UDP packets (think EDNSO DNSSEC as a good example of large UDP packets almost certain to be fragmented) suffer the same problem, as they can be fragmented by PMTU discovery. The server (operating system) has to maintain UDP state for PMTUD to work. If the ICMP fragmentation needed is lost due to Anycast, PMTUD will fail. Lost UDP fragments are fatal to the UDP transaction. Ack that's the reason why the MTUs in todays networks get bigger and bigger. Possibly. But MTU size should properly be a matter of latency vs overhead. Only one packet can be transmitted at once. The larger the packet, the greater the latency before a higher priority packet can be transmitted. Smaller packet have lower latency, but are less efficient due to repeated overhead of mac addrs, ip addrs, etc. Adjusting MTU to prevent fragmentation is sometimes possible, but a bad idea. FIB entries change at every hop. The more hops away, the more often the paths can change. What works close by, might not work far away, and vice versa. FIB and path changes only matter when the final IP destination changes, again not a problem in todays network where IP is just one overlay transport of an underlying label switched network. And thus the path changes, but the final (anycasted) destination does not. The FIB entries can change at *any* router, and a FIB change *anywhere* _can_ result in a different exit from an intermediate network; a different exit also means there may be a different entry into the final destination network, which usually changes the anycast host. FIB changes always matter. While I get paid for that it does work four our customers, so this obviously this is my first concern. I doubt that many of your customers use TCP DNS. You only *think* it works, because you didn't do adequate testing to see it doesn't work. That isn't the same as 'works for our customers'. Are your resolvers public? Would it be OK if I test them? --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Another TLD intending to sign soon
On Tue, 26 Aug 2008, Ted Lemon wrote: If you had a problem with (1), you should have raised this back when the working group made this change. The above criticism is an entirely disingenuous comment. Mr Lemon has previously been made aware that critics of DNSSEC were silenced on DNSEXT WG on false and fictitious pretenses that were made in bad faith and with undisclosed conflict of interest; the purpose and result were deception of the Working Group and the public. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Anycast TCP DNS stability was Re: Cache poisoning on DNSSEC
On Mon, 25 Aug 2008, Masataka Ohta wrote: Dean Anderson wrote: I recently read David Blacka's blog entry on Anycast, where Blacka asserted that Anycast had to be proven UNstable before anyone should consider stability questions. Blacka suggests that non-root operators had no experience or data to prove these things unstable--which is true and root operators aren't sharing their data. As the, seemingly, only expert on anycast in the world, anycast is stable as long as unicast routing is stable. It should be noted that unicast TCP is unstable if unicast routing is unstable. That is not so. 'Unicast routing' is, by definition, stable if routing complies with RFC1812 and delivers every unicast packet to the correct unicast host. RFC1812 allows load-splitting, and load-splitting was the first obvious flaw in the 'anycast stable if unicast routing stable' assertion, many years ago. Some people have asserted, without justification, that load-splitting is somehow pathological. However, load-splitting is not necessary to observe Anycast instablity. Most routers expire FIB entries every 60 seconds. All routers eventually expire FIB entries, usually in a similar timeframe. When the FIB entry is replaced, a different, equal cost path may be installed. This FIB could come from the interior (e.g. ospf, is-is) or the exterior(e.g. BGP). The unicast routing system is stable because RFC1812 is fullfulled and all unicast packets are delivered to the correct unicast host. However, subsequent Anycast packets can be delivered to different Anycast hosts; Anycast TCP is not stable. This instability was explicitly stated by RFC1546. One need only send packets delayed by 60 seconds to see Anycast instability. TCP can delay packets for a long time. Keep-alives are sent every 2 minutes, well outside the FIB expiration time. This behavior has been experimentally observed. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
On Sun, 24 Aug 2008, Brian Dickson wrote: Dean Anderson wrote: On Sun, 24 Aug 2008, Dean Anderson wrote: Ok. But when you resign using arbitrary data controlled by the attacker, the private key can be obtained. [There is a crypto attack on rekeying] OOPS!!. Rekeying is out of the question for, say, .com, .net, etc. I guess you didn't know that. Correction: The above should say there is a crypto attack on re-SIGNing. ReKEYing is fine. Apologies for the confusion I just created. You say there is a crypto attack on re-signing. One using arbitrary data provided by the attacker - what is the arbitrary data, as opposed to some other kind of data? I don't think I can give the exact correct mathematics without using a book--and I don't have my crypto library right now--so I'll try to armwave a bit: Basically, if the attacker can pick a known-plaintext that corresponds to a large-prime, they can use the result and the public key to obtain the private key. This is consequence of modular arithmetic. I'm not entirely certain from memory if the plaintext has to be prime or if it can be a multiple of a prime. (e.g. If the data being signed were limited to valid public key data that might, for example, be possible to itself be validated before signing)? Can you provide a reference to back up this assertion? I think there is a description of this in Schier's book, or other books that describe security and insecurity of PKI depending on modular arithmetic, like RSA. If you still can't find it, let me know and I'll send you detailed reference tomorrow. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
On Mon, 25 Aug 2008, Ralf Weber wrote: It should be noted that unicast TCP is unstable if unicast routing is unstable. Yes, but TCP usually adapts to the problem while anycast can't, as it may reach another target. Large UDP packets (think EDNSO DNSSEC as a good example of large UDP packets almost certain to be fragmented) suffer the same problem, as they can be fragmented by PMTU discovery. The server (operating system) has to maintain UDP state for PMTUD to work. If the ICMP fragmentation needed is lost due to Anycast, PMTUD will fail. Lost UDP fragments are fatal to the UDP transaction. As someone who has deployed anycast DNS within a carrier network there are some things to consider , e.g don't put anycast routes in fast converging routing protocols and be careful with multi links for similar destinations. FIB entries change at every hop. The more hops away, the more often the paths can change. What works close by, might not work far away, and vice versa. But if you follow the rules it can be deployed and also works with tcp transport for DNSat least for me. But the question is not whether your DNS works for you; The question is whether it works for everyone else. While you may be satisified with your own DNS operations, you may not care if they work for everyone. Different requirements apply to Root and TLD services. Everyone, everywhere has to be able to use Root and TLD DNS services reliably. This is precisely the 'deploy and hope for the best' attitude at its worst: It worked for me in a very limited scenario, and I don't worry about theory or about what works everyone. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Another TLD intending to sign soon
On Tue, 26 Aug 2008, Roy Arends wrote: This will be a very interesting experiment. And finally a good test of DNSSEC. Great for consultants. Why would this be experimental or test? Why 'finally'. This implies DNSSEC has not been deployed or been tested 'good' before. Has DNSSEC been thorough tested and analyzed? If so, where? When? By who? How could their testing and analysis be considered 'thorough' or credible when they didn't find the very serious flaws just recently identified on this list? But the memo on .gov probably means those of us with DNSSEC concerns should write a letter to the author(s) of the memo. Contact me offlist for drafting and to sign the letter. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
On Tue, 26 Aug 2008, Andrew Sullivan wrote: On Tue, Aug 26, 2008 at 02:44:08PM -0400, Dean Anderson wrote: I don't think I can give the exact correct mathematics without using a book--and I don't have my crypto library right now--so I'll try to armwave a bit: If you're claiming that, after 10 years and review unto death, people with significant profile in the crypto community got the math wrong, The text of mine that you quote was an explanation of how a chosen plaintext attack works on PKI like RSA. All that I said is that I can't quote the exact math of how the attack works. However, If you mean to suggest that DNSSEC has been checked over for 10 years by crypto experts without finding flaws, I think your drawing the wrong conclusion from DNSSEC history, as well as who has certified its security. DNSSEC work has proceeded in fits and starts for 15 years. Prior DNSSEC work has been almost completely abandoned by RFC4033-35. Not completely replaced, since there are new typecodes are needed to continue with incompatible use of SIG, KEY, and NXT records from prior (failed) attempts at obtaining secure and workable DNSSEC. I don't think you're going to get a warm reception. I think you need to demonstrate that there is an actual problem. Certainly, we'll need an argument somewhat stronger than, The math could be wrong somewhere. I never said 'the math could be wrong somewhere'. I said there is a PKI(RSA) chosen plaintext attack through which one can obtain the private key used to sign DNSSEC records. There is no ambiguity about the existance of that attack, but I will provide an authoritative reference tomorrow. I seem to remember you were going to spend this week producing a demonstration of an actual attack. An actual poisoning of a non-verifing DNSSEC cache, yes. This is pretty trivial; the code demonstrating the kaminsky poisoning will work with some DNSSEC changes. I won't be able to start on that until probably thurs or fri. I first have to find a non-verifying DNSSEC cache. I think BIND may work, but will have to check. If anyone has suggestions for a non-verifying cache, that would be appreciated. Or if some BIND experts have suggestions for making BIND not verify, that would save me some time. If someone wants to volunteer a non-verifying server that is otherwise in the wild for use, that would help. Contact me offlist. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
On Fri, 22 Aug 2008, Blacka, David wrote: If you had actually followed any of the discussions about DNSSEC over that last 13 years, you would know that this is false. Thinking about how it could break is what the vast majority of work on this topic has been about. I have paid attention to many of these discussions, and have recently reviewed some of the ones I didn't pay attention to. And indeed, there hasn't been a thorough analysis. Instead, critics (such as myself and Dr. Bernstein, perhaps others) were silenced. It appears that only Bernstein and myself were noisy about being silenced. Most people would just go away quietly, as many people expected myself and Bernstein to do, and some have even told me as much. Evidence of the lack of critical analysis is found in the several serious flaws identified so far. More evidence of a lack of analysis is found in the repeated cycles of going back to the drawing board and then reporting I think we have it this time, only to 'not have it', still. The tri fecta is found in the acts silencing critics. These acts conclusively discredit the claims that DNSSEC people were genuinely concerned with critical analysis of problems. Yet, despite all these contrary facts, Blacka still asserts DNSSEC advocates were somehow genuinely interested in solving security problem, rather than some other objective. There seems to be an irreconcilable difference of opinion here. Perhaps another example might shed light on the credibility of their approach: I recently read David Blacka's blog entry on Anycast, where Blacka asserted that Anycast had to be proven UNstable before anyone should consider stability questions. Blacka suggests that non-root operators had no experience or data to prove these things unstable--which is true and root operators aren't sharing their data. Hold on! Why should non-root operators have prove Anycast root operations are unstable using root-operations data? Why should anyone ASSUME a new, untested service will be stable? I think most people would agree that high stability operations must have some proof of stability BEFORE deployment of a new service. And once again, we see the same 'assume stability and deploy without extensive testing' as before. And after they asserted that TCP is stable for Anycast, they now want to deprecate TCP for DNS. (RFC 1546, analysis, and testing show TCP Anycast isn't stable) This is a lesson to be applied to DNSSEC deployment plans as well. Deploy untested and hope for the best is really not a credible operations strategy. And the delegation records are unsigned; the resolver has no way to know if they are correct; The delegation was picked so that NSEC3 RR's didn't change with the addition, and so the NSEC3 RRs verify correctly. The bad guy just uses those NSEC3 records 'as-is'. In all forms of DNSSEC (NSEC3 or NSEC) the delegation records are unsigned. I noticed. This is not a problem because, if the delegation is secure (i.e., has a DS RRset), the referred-to zone MUST have a DNSKEY that matches one of the DS records. If not, then the response is considered bogus and (normally) thrown away. It is only 'not a problem' in the ideal case where no one is trying to trick the resolver. But when one is trying to trick the resolver, they can succeed as I described. This is just exactly what is meant by 'non-critcial analysis'. You only considered the ideal case. One can also do this exact same thing on signed delegations provided you have an earlier copy of a covering NSEC3 record signed with the same key. [So operators have to rekey anytime they create a new delegation.] No, you don't. This old NSEC3 (or NSEC) RRset isn't valid forever. The old record valid until its signature expires. As I noted, to avoid the attack, one must rekey everytime a change is made. It is well understood that you are vulnerable to a replay attack while the old RRSIGs are still valid. Which argues for short signature durations, not rekeying. Ok. But when you resign using arbitrary data controlled by the attacker, the private key can be obtained. [There is a crypto attack on rekeying] OOPS!!. Rekeying is out of the question for, say, .com, .net, etc. I guess you didn't know that. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
On Sun, 24 Aug 2008, Dean Anderson wrote: It is well understood that you are vulnerable to a replay attack while the old RRSIGs are still valid. Which argues for short signature durations, not rekeying. Ok. But when you resign using arbitrary data controlled by the attacker, the private key can be obtained. [There is a crypto attack on rekeying] OOPS!!. Rekeying is out of the question for, say, .com, .net, etc. I guess you didn't know that. Correction: The above should say there is a crypto attack on re-SIGNing. ReKEYing is fine. Apologies for the confusion I just created. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question
Both of Ohta-san's points are entirely valid. On Ohta-san's first point: DJB is convinced that 1024bit RSA is crackable with a botnet. And if 1024 isn't crackable now, it probably will be shortly. So it is probably possible or soon will be possible to crack keys and then forge many DNSSEC signatures, given enough determination. Using larger (2048bit) signatures creates more work to verify signatures, and larger responses. [Note: increasing key size has a corresponding impact on the crypto-overload DOS attack that I (Anderson) previously described, and also makes worse the forged query DDOS attack that I described.] On Ohta-san's second point: If the zone is compromised, (which means the attacker has obtained the private key), then the attacker can construct new signatures at will, and being a MitM, can inject these responses at will, also. The response that one gets (or seems to get) from a cache or authority server is not necesarilly the response from an authority server. This can result in a number of problems for DNSSEC, and it is the common factor in several different attacks described by Ohta-san and myself. --Dean On Thu, 21 Aug 2008, David Conrad wrote: *plonk* On Aug 21, 2008, at 3:50 PM, Masataka Ohta wrote: Paul Wouters wrote: Instead, MitM attack on DNSSEC is performed, for example, within intermediate zones with forged signature on child zone with forged end-users data. Oh I see. DNSSEC is broken because we cannot trust RSA, DSA, SHA256, DiffieHellman, and perhaps eliptic curve That is certainly a valid argument. However, it has nothingn to do with the MitM case above because forged signature from a compromized zone is cryptographically valid. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
On Fri, 22 Aug 2008, Matt Larson wrote: Dean, On Fri, 22 Aug 2008, Dean Anderson wrote: It is manadatory in the _proper_ response. Of course, the _forged_ response can have anything the bad guy wants. If the bad guy decides not to follow 4035 (gasp! we never thought the bad guys might not follow RFCs!), and instead responds with a forged response that doesn't have the DS RR, and the delegation and glue records are normally unsigned, then the resolver will conclude the zone is unsigned, and place undeserved trust in the referral. Your analysis is incorrect. A referral from a signed zone either needs to have a DS and RRSIG(DS), indicating the child zone is signed and allowing the chain of trust to continues into the signed child, or an NSEC and RRSIG(NSEC) showing that no DS exists, proving that the child zone is unsigned and insecure. If a referral from a signed zone contains neither DS nor NSEC, the validating resolver assumes that a man in the middle has stripped them and the response is bogus. Good call. However, NSEC and NSEC3 records are static, and RRSIG(NSEC/NSEC3) records are statically calculated. The attacker need only read RFC5155 section 12 for instructions on how to compute a valid hash for use with the (known) NSEC/NSEC3 record. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
On Fri, 22 Aug 2008, Ted Lemon wrote: On Aug 22, 2008, at 7:23 AM, Dean Anderson wrote: Sigh. Above is precisely the sort of non-critical analysis that causes these things to have so many problems. Instead of making fun of other peoples' lack of critical thinking, you might want to take responsibility for your own thinking and let others take responsibility for theirs. I didn't make fun of anyone. The lack of critical analysis is no laughing matter. None of the promoters seems to ever make an effort to consider how things might break. There is far too much cheerleading and far too little of how it could break. The problem with your reasoning is that the resolver is configured with a trust anchor, and the zone with the missing DS records is below that trust anchor. There is no problem with my reasoning. Let me spell it out in more detail: The NSEC/NSEC3 issue has already been explained, but you didn't get the implications. The NSEC/NSEC3 opt-out records just signal that an unsigned zone exists (or could exist) From RFC5155: The presence of Opt-Out in a zone means that some additions or delegations of names will not require changes to the NSEC3 RRs in a zone. o When removing a delegation RRSet, if that delegation does not have a matching NSEC3 RR, then it was opted out. In this case, nothing further needs to be done. o When adding a delegation RRSet, if the next closer name of the delegation is covered by an existing Opt-Out NSEC3 RR, then the delegation MAY be added without modifying the NSEC3 RRs in the zone. And the delegation records are unsigned; the resolver has no way to know if they are correct; The delegation was picked so that NSEC3 RR's didn't change with the addition, and so the NSEC3 RRs verify correctly. The bad guy just uses those NSEC3 records 'as-is'. So one can use poison on a validating DNSSEC resolver to achieve false resolution for any new unsigned zone. Put another way, the bad guy can create new delegations under opt-out NSEC3 records. One can also do this exact same thing on signed delegations provided you have an earlier copy of a covering NSEC3 record signed with the same key. [So operators have to rekey anytime they create a new delegation.] In fact, it seems that rekeying has to be done on any change, else the old NSEC records can be used to poison caches. -- The assertion that validating DNSSEC caches can't be poisoned is false. -- This attack works on non-validating caches as well. -- Also, non-validating DNSSEC-aware caches are trivially poisonable to obtain a DOS attack. -- Key rollover is a much more frequent issue than has been described by promotors of DNSSEC. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
On Tue, 19 Aug 2008, Ted Lemon wrote: On Aug 19, 2008, at 8:15 PM, Dean Anderson wrote: A verifying DNSSEC cache can be poised with bad glue records using the poisoning attack, with only a slight change to the Kaminsky software. Do you mean that it can be convinced that an answer is valid when it is not? I mean that a validating cache can be convinced to think that a delegation is unsigned by getting unsigned glue records without a DS record. This glue can refer to a working (bogus) nameserver, or it can be a DOS on the delegation. I might try to demonstrate this by running code next week sometime. One might be able prevent this only if all zones and all delegations have been preconfigured keys, in which case RFC 4035 says a resolver SHOULD believe a zone is signed if it has a preconfigured key. (so one might still be spoof-able by an implmentation that doesn't reject unsigned responses in zones with preconfigured keys. Of course, updating all these preconfigured keys is going to be a PITA. This is another operational drawback, and significant operational expense. So DNSSEC is probably a self-inflicted DOS in practice after some key changes. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
On Mon, 18 Aug 2008, bert hubert wrote: What's the rush with deprecating DNS/TCP btw? It languished in the shade for 25 years.. TCP doesn't work with Anycast, as was stated in RFC1546. And Root server operators are supposed to offer TCP to everyone, not just those that use the stateless UDP service that works with Anycast. Do you remember that David Kessens, then the Operations Area Director took out a PR action against me to silence discussion about Anycast Root server operations? --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Mon, 18 Aug 2008, Paul Wouters wrote: I wouldn't be using starbucks resolver, since i just installed my own DNSSEC-aware resolver? Ordinarilly , when you get a DHCP-supplied nameserver from starbucks, your stub resolver directs its requests to that caching server. It is indeed possible that your stub resolver could make its own queries, including to the root and TLD servers, but putting this non-cached end-user load on those servers is yet another unanticpated operational problem. No one has accounted for such increased load for DNSSEC. When the internal representation is updated, it is often done one RR at a time. So two responses updating the same two records could be interleaved. This is a simple database problem called a race condition. However, we have TTL's and signature life times, so older entries will only get updated with newer entries, so this race is not a problem. I don't think you understand the programming issues. This has nothing to do with TTLs or signature lifetimes. The point is that DNS servers don't currently perform transactions internally; normally, records don't depend tightly on other records (hence the term 'loosely coherent'). BTW, adding transaction capability greatly slows down database servers. This is probably one of the reasons people like to put stuff in DNS instead of databases. DNS is fast because of its stateless nature. DNSSEC changes that, and imposes speed-reducing demands on server architecture. Or else, won't work right. This change alters DNS from being loosely coherent to tightly coherent, with corresponding performance impacts to get correct operation. You lost me here. Sorry. When the RR isn't the same as the one for which the RRSIG was computed, the DNSSEC-aware stub resolver will reject the record. If it asks the caching server again, it gets the same records. So the resolver will fail, and will continue to fail until the TTL expires. The bad guy just creates two records with long TTL, and you have the DOS attack. Mark and Roy already explained why this is not the case. Who do you mean by 'Mark and Roy'? Mark Andrews and Roy Arends? When? If the caching server checks the signature of all records, its susceptible to a DOS attack by lots of DNSSEC queries that take a lot of computation to check. Seems to be no-win. That's not a DOS attack. That's the price of cryptogrpahically signing the DNS. When your server can't handle the load of all these calculations on millions of queries sent by the attacker, its a DOS attack. So is not getting any traffic because you lost .com due to cache poisoning. True enough. Same problem continues after all the DNSSEC effort, and now we have created the additional problems of the other DDOS attacks using the signed records. Seems to be a giant step backward, with no step forward. In fact, what I understood is that resolvers mostly have problems switching to DNSSEC not due to DNSSEC but due to DNSSEC requiring EDNS0. And mind you, the EDNS0 was released in what? 1999? It's not the crypto that's the resolvers issue. That's easilly solved by adding a cpu or a box. The transition issue you speak of is a different problem. The DOS attack I speak of is when your caching server gets lots of requests for DNSSEC records, which it then must verify. These requests aren't 'legitimate' in the sense that users made these queries genuinely trying to get information. These requests are bogus, generated only with the purpose of creating load on the server. Verifying the crypto keys is not easy. Verifying millions is impossible. Now imagine the target spoofed IP's are the nameservers of, say yourdomain.com. When the roots (or TLDs, etc) get millions of forged UDP packets, the roots can't block the incoming packets---that would severely harm the target IP addresses. On the other end, the target IP addresses can't block the root servers---that would also seriously harm the target IP addresses. The target just has to 'take it'. The greater the amplification factor (Response size / request size-- perhaps only 64 bytes), the more damaging this attack is. Since there are (or may be--probably will be) a number of additional (and large) DNSSEC records in a response, the response could get quite large, causing significant damage. So yes, that is a reason not to deploy DNSSEC. This has also been explained earlier. Just get a botnet that's 100x the size to accomplish the same. This argument amounts to something like let's not do HDTV because the home user DSL might not be able to download it in real time anyway. No, actually, it isn't like that at all. If there is no amplification, the botnet will simply use ICMP or something it already has a program to do. When there is amplification (perhaps up to 100x in this case) a very small botnet can do a very great deal of damage, for a much longer time. A great deal of effort
Re: [DNSOP] Pointless FUD and confusion about DNSSEC deployment
On Mon, 18 Aug 2008, Jim Reid wrote: On 18 Aug 2008, at 05:11, Dean Anderson wrote: Ok, I agree that totally DNSSEC-oblivious servers won't be a problem for DOS, but of course remain susceptible to poisoning even if the stub resolver and the authority server both implement DNSSEC. Kindly explain how is this any different from when poisoning occurs when stub resolver and authority server don't implement DNSSEC. Its not any different; its exactly the same problem. And DNSSEC creates more problems, without solving any. The fact is DNSSEC is the *only* game in town for preventing cache poisoning. TCP is another 'game in town'. We may also be able to invent other 'games', as DJB suggests. So to go back to David's original question: will deploying DNSSEC break anything that's already in use that doesn't support DNSSEC? Yes: DNSSEC enables DDOS attacks that didn't exist before, and doesn't eliminate any attacks that previously existed. Now if that resolving server does pay attention to the DO bit, it will set it on the query it makes to the authoritative server. That makes the authoritative server return an answer which will contain the new RRSIG and the resolving server's cache is updated accordingly. Ok. So what about caching servers that do understand the DO bit but don't actually verify the responses? They just cache the response for the stub resolver to verify? These servers can still be poisoned with invalid record combinations that they pass on to stub resolvers, resulting in the DOS. Such servers may still be subject to the race condition I described. How is this different from a resolving server not getting the correct answer because it queried an authoritative server that hasn't seen the latest version of the zone on the master? In that scenario, the old data is consistent. In my scenario, poisoning has created inconsistent data on the non-verifying DNSSEC cache. In fact in the somewhat contrived scenario you pose, the stub resolver gets a validation failure. So they at least know something has gone wrong. Which has to be a great leap forward from getting bad (poisoned) data and not having the slightest clue that has happened. The resolver 'knows' perhaps, but the user doesn't know anything. They just know that they typed in 'www.yahoo.com' and got no IP address. That's a DOS. And its no leap forward. In the original cache poisoning case, the user either gets, nothing, a non-working IP or they get the wrong server. If they get the wrong server, their SSL verification and trust procedure will exclude that server from use. That's a DOS, too. Ahhh. I see it now. Someone will deploy DNSSEC in their stub resolver. But then they'll make that query a resolving server that doesn't speak DNSSEC whenever their stub resolver wants to do a DNSSEC-aware lookup. Right. Makes perfect sense. [Add scarcasm to taste.] No, I already agreed that a totally DNSSEC-oblivious wasn't going to pose a DNSSEC problem. Your sarcasm is misplaced. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Pointless FUD and confusion about DNSSEC deployment
On Mon, 18 Aug 2008, Paul Hoffman wrote: At 1:27 PM +0100 8/18/08, Jim Reid wrote: The fact is DNSSEC is the *only* game in town for preventing cache poisoning. Note the subject of this particular thread. A more carefully-worded sentence would be The fact is DNSSEC is the *only* game in town for completely preventing cache poisoning. We have methods to reduce an attacker's ability to poison caches effectively. If the DNSSEC cache doesn't verify the records it caches, it is still suceptible to poisoning. DNSSEC caches that verify are subject to a crypto-overload attack by large numbers of queries. Both kinds of attacks ultimately result in a DOS --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Sat, 16 Aug 2008, Ted Lemon wrote: On Aug 16, 2008, at 9:35 PM, Dean Anderson wrote: - If Mal cracks someone else's server, that server still doesn't have the bank's certificate, and won't have the bank's dns domain, either. So the browser should think that it got the wrong certificate. No, that wasn't my point. My point is that sometimes browsers will warn you if you submit a form to a non-SSL server. So an attacker can get rid of that warning by suborning an SSL server and directing your response toward it. You won't get a warning that your data is being submitted over an insecure link, because it's not. The link is perfectly secure - the problem is that it's the wrong link, and someone's listening on the other end who shouldn't be. Anytime the browser takes a certificate that is not user-checkable as being both secure and trusted, there will be problems. So any attack that can make things not look funny is a valuable attack. And the Kaminsky attack is such an attack. You're right that it's not the only one, but eliminating it still has appreciable value. One can live with things that are untrustworthy, so long as you know they are untrustworthy and takes the appropriate steps to avoid placing trust decision on untrustworthy information. SSL/TLS certificate procedures the appropriate steps to obtain secure and trusted communication. Changing DNS doesn't eliminate the attack of misplaced trust. It merely eliminates one method we know of for accomplishing the attack, at great expense and great risk, I might add. Addressing the misplaced trust attack in the wrong place incorrectly signals to users/browsers that they don't need to check the certificates for trustworthiness. DNS spoofing isn't the only way to accomplish a misplaced trust attack. Cross site scripting and javascript viruses are another way. Cryptographic verification just proves the CA issued the certificate. Checking that the verified identity is one we trust is what ensures trustworthiness. The combination of both checks the only thing that ensures trustworthiness. One can't eliminate either check and remain trustworthy. Every certificate that a browser uses for trustworthiness has to be both verified cryptographically and checked by the user for trust. Multi-site secure operations have to either have multiple certificate checks, or depend on a private CA whose certificates are always trusted. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Sun, 17 Aug 2008, Jaap Akkerhuis wrote: Also, a well behavng resolver has way less request to the root servers then to other servers. Why, do you think, that servers other than the root servers won't reply with oversized messages? Don't twist my words. I never said that. That you didn't say that, I think is the point. Other, non-root, servers may respond with oversized messages. I agree with what Masataka is saying. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Sun, 17 Aug 2008, Ted Lemon wrote: On Aug 17, 2008, at 9:24 AM, Dean Anderson wrote: Changing DNS doesn't eliminate the attack of misplaced trust. It merely eliminates one method we know of for accomplishing the attack, at great expense and great risk, I might add. You may not add that unless you are willing to justify the assertion, which thus far you have not done. Changing DNS protocol is considered by many to be expensive and risky. Are you saying its not expensive or risky? That seems to be a far more bold assertion. And if you argue that we shouldn't close the DNS hole, your argument applies equally to these problems. Are you arguing that we shouldn't address them either? It may well impossible to close the problems of cross site scripting and javascript viruses. However, misplaced trust attacks can only be avoided by preventing the sending of trusted information to untrusted sites. Solve this problem correctly (which is entirely doable) and none of these attacks will be effective at obtaining trusted information. Changing DNS protocol is not necessary to prevent misplaced trust attacks. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Sun, 17 Aug 2008, Ted Lemon wrote: On Aug 17, 2008, at 4:12 PM, Dean Anderson wrote: Changing DNS protocol is considered by many to be expensive and risky. Are you saying its not expensive or risky? That seems to be a far more bold assertion. Actually, you and Ohta-san seem to be taking that position. That's not many. I just deployed DNSSEC. My servers are ticking over happily, and I haven't had any complaints from users. So I guess I don't think it's all that risky, no. It may be that I'm wrong, but you haven't said anything surprising yet, so I'm still waiting for the revelation that will convince me that your fears are justified. I'm always amazed when advocates of something come out and say I did it, and I'm still here, and assume that means that it can be done worldwide for free and that it also means there are no issues with scaling their effort, and that it means there are no downsides that might come to light after a lot of sites do what they did. SPF script DOS attacks come to mind as a good example. But if only myself and Ohta-san think changing DNS protocol is expensive and risky, then perhaps we should change the protocol even more and do it more often. However, misplaced trust attacks can only be avoided by preventing the sending of trusted information to untrusted sites. Solve this problem correctly (which is entirely doable) and none of these attacks will be effective at obtaining trusted information. Forgive me for pointing this out, but about three exchanges ago you said that solving this problem was provably impossible. Have you changed your mind, or am I missing something? You are indeed missing something. Constructing a system free of covert channels is not the same as limiting the distribution of trusted information. To put it another way, its fairly easy to limit the To: list on sending email, but its much harder to keep spam out of your mailbox. One problem is doable. The other isn't. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Sun, 17 Aug 2008, Paul Wouters wrote: On Sun, 17 Aug 2008, Dean Anderson wrote: There are two more problems with this. First, Putting any kind of large record in the root creates the opportunity to use root servers in a DOS attack by sending queries for the large records to the root servers. Because of Root Anycasting, there are over 100+ root servers spread around the world that will respond to queries. A botnet distributed worldwide should be able to send queries to most or all of these servers. Most or many of these servers have very high bandwidth connections. Same would be true for TLD servers, and large, high traffic domains like microsoft.com, etc. It is very hard, if not impossible, to mitigate attacks coming from root, TLD or other significant sites. If it is TCP, due to large DNSSEC answers, you won't easilly be able to use these for amplifying your DOS attack. If the answer would fit in UDP, you wouldnt really have an issue. I'm not sure you understand EDNSO. EDNSO UDP can be 8KB in size. TCP isn't susceptible to this kind of attack at all. TCP spoofing is just about impossible if you aren't in the path, because there is a 32bit random sequence ID. If you don't get that sequence id, you won't get the connection established, and the target won't get the DNS response. A botnet spread worldwide mostly won't be in the path. Second, as I start to look closer at DNSSEC It keeps amusing me how people who have critisied DNSSEC for years, end up asking me things like so how does it work? or in your case I actually looked at it now. This seems strange only if you don't know the history of DNSSEC. Because they keep messing up in major ways, and keep starting over on the protocol, what I looked at years ago has no bearing on DNSSEC now. And I thought it was a dumb idea years ago, too. , there appears to be a problem in the DNSSEC protocol in that if caching servers don't care about DNSSEC, then caches could store RRSIG records that are out of sync with the RR they sign. When the security-aware resolver obtains both records from the caching server, the resolver that finally checks one record against the other will find that the signature doesn't match. This is not the case, but if so, why would you bootstrap a DNSSEC enabled server using a non-DNSSEC forwarder? You haven't been following along with the discussion. There may be DNSSEC-aware authority zones and DNSSEC-aware stub resolvers that might use DNSSEC-oblivious intermediate caches. For example, suppose example.com signs its zone, and you install a DNSSEC-aware resolver on your laptop. Now suppose you go to starbucks, which didn't do DNSSEC and has a DNSSEC-oblivious caching server. Next you try to access example.com using the starbucks caching server. The DNSSEC-oblivious cache will just cache the records as ordinary (very large) records. This scenario could happen by accident during zone updates between master and slaves after the RR was changed, if the cache gets one RR from the master and receives the RRSIG from another server (one might Don't you get the RRSIG as Authoritive or Additional data when getting the new RR? I'm not entirely sure it works that way. I didn't see that specified. But it certainly could work that way, as I said below. try to avoid this by adding RRSIG records as additional, but there is still a race on the internal representation if multiple responses are received from different servers). When the internal representation is updated, it is often done one RR at a time. So two responses updating the same two records could be interleaved. This is a simple database problem called a race condition. Transaction isolation and locking is used to protect against this. DNS servers usually aren't designed to support transactions on the update of multiple records in one response. Or it could happen on purpose using a cache poisoning attack. Once the incorrect records are cached, a DOS occurs. (its only an attack if its on purpose) You lost me here. Sorry. When the RR isn't the same as the one for which the RRSIG was computed, the DNSSEC-aware stub resolver will reject the record. If it asks the caching server again, it gets the same records. So the resolver will fail, and will continue to fail until the TTL expires. The bad guy just creates two records with long TTL, and you have the DOS attack. If the caching server checks the signature of all records, its susceptible to a DOS attack by lots of DNSSEC queries that take a lot of computation to check. Seems to be no-win. That's not a DOS attack. That's the price of cryptogrpahically signing the DNS. When your server can't handle the load of all these calculations on millions of queries sent by the attacker, its a DOS attack. The first problem is reason enough not to deploy DNSSEC. The second problem is serious, too, but I think only affects DNSSEC
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Sat, 16 Aug 2008, Ted Lemon wrote: On Aug 16, 2008, at 4:56 PM, Dean Anderson wrote: For example, besides the previously mentioned key rollover issue, I understand that DNSSEC also doesn't allow the protocol to be changed securely. And we do expect the protocol to be changed. As a non-expert in DNSSEC, I have to admit that I am not aware of an expectation that the protocol will change. Can you expand on this? I'm also a non-expert on DNSSEC. I take this excerpt from Olaf Kolkman's message of December 1, 2007: as indicating that it will need to change: Begin quote == Please speak up if this change is of concern to you. If no one speaks up by Dec 7'th I will tell our AD the changes are fine. So the change is that the basic-4 steps procedure was removed and replaced with text that amounts to We'll solve this when we get to this. For those who are not up to speed with the issue that is being addressed, the thread causing all this starts here: http://ops.ietf.org/lists/namedroppers/namedroppers.2007/msg00553.html To me it is clear that the current text postpones dealing with the problem that starts with the premisses in Sam Weiler's observation: but we aren't (as far as I can tell) requiring that an NSEC3- SHA256-capable resolver also support NSEC3-SHA1 If the requirement to support old algorithms would exist, then the rollover is one that we currently understand. End quote === Also, is there a way to build the protocol so that it can be changed securely? Hopefully, there is. Though mainly, I think the problem is the hash change problem. I would think that the way this would happen would be that the resolver would ask different, or additional, questions. Does the current protocol preclude that? I suppose not. But changing resolvers repeatedly is a big problem, because you have to support the old resolvers. The zones are quite large with the current records. The hype surrounding the Kaminsky report is unjustified. For example, one can't steal bank information with this attack, as the mainstream press has reported. This isn't true, because if I can convince you that a naive user that he or she is talking to your bank, I can get them to enter their information into a web page that isn't protected by SSL. Alternatively, I can find a server that has a valid SSL cert, crack it, set up a redirect that sends the user's password through that server. They wind up doing an SSL-validated transaction that appears to be completely fine, but is not. Since I've suborned an existing server, even once the hack is discovered, if it is, it can't be traced back to me through the SSL cert trust chain. The above attacks aren't dependent on DNS attacks. - If the user is naive and doesn't check that connection is secure and that the certificate belongs to their bank, then they are subject to any number of schemes. - If Mal cracks someone else's server, that server still doesn't have the bank's certificate, and won't have the bank's dns domain, either. So the browser should think that it got the wrong certificate. The user should always check that they have the right certificate and that it verifies correctly. If the user doesn't do that, no amount of DNS security will save them from a variety of phishing or similar-URL/similar-domain attacks. Every browser that I know of allows the user to examine the certificate and its validation. If the user fails to check this, they lose. This thread is quite interesting: http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00853.html There has been some assertions that SMTP anti-spam security depends on DNS security. These schemes don't hold water. In 2003, I showed that the information theory result that no communication system can be proven free of covert channels implies that no communication system can be designed 'spam-free'. I think you carry this argument a bit farther than is justified. It's probably true that no security system can be perfect. Locks don't keep out determined lock pickers. They certainly don't keep out people with fire axes. But they do raise the cost of entry. I'll try to keep it pertinent to DNSSEC. In this case, the cost of entry is the botnet, and the cost isn't altered at all by DNSSEC, or by SMTP alteration, micropayments, estamps, SPF, or what have you. Once the computer is controlled by a virus, the attacker has the user's credentials--all of the credentials. Adding more layers of authentication can't change anything. People seem to have a hard time understanding that the virus on their computer is, electronically, _them_. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
This message seems to answer many of the questions over the last few days. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- Forwarded message -- Date: 10 Aug 2008 00:28:22 - From: D. J. Bernstein [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Kaminsky on djbdns bugs Last week's surveys by the DNSSEC developers (SecSpider) have found a grand total of 99 signed dot-com names out of the 70 million dot-com names on the Internet. Am I the only person amazed by this? We've had fifteen years of forgeries, fifteen years of concentrated work on DNSSEC, and we can't even get simple cryptographic signatures deployed. What an embarrassment for cryptography! Jos Backus writes: http://cr.yp.to/djbdns/forgery.html states: My top priority for djbdns is to support nym-based security. Hmmm. This reminds me that some web-page updates are overdue; it's time for me to announce the results of the attacks that the entire Internet will be panicking about in 2015. :-) When I wrote that web page several years ago, I focused on deployment difficulties (which are obviously a huge issue) and delegating security to poorly managed central Internet servers (which is a big issue for high-security sites). But there are other reasons, maybe more important reasons long term, to be dissatisfied with DNSSEC, motivating the development of DNSSEC2 and DNSSEC3: * RFC 4033, Section 4: DNSSEC provides no protection against denial of service attacks. In fact, DNSSEC makes denial of service even easier than it was before. The basic problem is that DNSSEC signs _records_ but provides no protection for _packets_. After several packets a DNSSEC cache can see that it doesn't have the expected signatures and that there must have been forgeries, but the cache simply fails at that point; it doesn't have any way to find the right data. With DNSSEC2, every response packet has an immediately and efficiently verifiable high-security cryptographic signature. Forged packets are simply discarded. * RFC 4033, Section 4: DNSSEC is not designed to provide confidentiality. DNSSEC doesn't even try to encrypt packets. In fact, DNSSEC makes private DNS data _much_ easier for attackers to see than before, because it exposes a huge amount of information through NSEC, and creates interoperability failures if NSEC is disabled. The latest NSEC3 adds even more complications but does essentially nothing to repair the privacy leaks; NSEC3 might be successful at its marketing goal of stopping European privacy regulators but it will almost never be successful at the security goal of stopping attackers. With DNSSEC3, every request and response packet has high-security encryption and authentication. Both DNSSEC2 and DNSSEC3 completely avoid the NSEC privacy leaks. * Although the DNSSEC protocol allows some conservative cryptographic options that won't be broken in the near future, what DNSSEC users are actually being told to deploy---to partially compensate for serious speed problems in DNSSEC---is something that big companies and botnet operators can _already_ break, namely 1024-bit RSA. We're still years away from a _public_ announcement of a successful 1024-bit RSA factorization, but I think that telling people to use 1024-bit RSA today is completely irresponsible. These issues are separate from the question of how keys are distributed. DNSSEC, DNSSEC2, and DNSSEC3 distribute public keys through parent servers (as simple NS names in the case of DNSSEC2 and DNSSEC3), so of course the parent servers can substitute any data they want. DNSSEC2 and DNSSEC3 have the extra option of embedding public keys into URLs so that parent servers can't do more damage than turning off service. ---D. J. Bernstein, Professor, Mathematics, Statistics, and Computer Science, University of Illinois at Chicago ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
On Mon, 11 Aug 2008, Paul Wouters wrote: [Paul Wouters is a frequent NANOG poster.] DNSSEC has been deployed on large scale by some TLD's and RIR's already. It is very much operational. Not very much--99 domains out of 70 million in .com. Your argument would be stronger if you identified which TLD's and which RIR's. Bernstein said that DNSSEC offers a surprisingly low level of security while causing severe problems for DNS reliability and performance. Let's not argue about the subjective suprisingly. But what is this low level of security? Is a fully trusted path 'low level'? If so, what is 'high level'? I think http://cr.yp.to/talks/2004.04.28/slides.pdf might help. I think the recent message from Dr. Bernstein that I posted answers this far more clearly than I could. How long do we hack around a system before before making a protocol change? Sure, not every day, as EDNS0 proves, but surely using TXT records and source port numbers for the next 25 years sounds like overshooting it at the other end of the spectrum. This is a very good point. We had an opportunity to replace the protocol entirely in IPv6. That opportunity was squandered. Perhaps more questions should be asked about this squandered opportunity in the right forums, or maybe on a different subject line in this forum. 1) What is more broken with DNSSEC then on DNS? The question really should be 'What is LESS broken with DNSSEC than with DNS?' This shows more an unwillingness to discuss then anything else. This is a completely irrational claim. DNSSEC offers secure transport over plaintext channels of DNS data. Perhaps not in a method you prefer, but that was not part of questions 1). So at most here, you can answer more cpu and more bandwidth and more error prone by administrators. The first two are a direct consquence of any solution that adds cryptography to a previous solution not using cryptography. The error proneness is (and this is a subjective opinion of mine) something we have to deal with, and DNSSEC seems to be a reasonable approach to this, even if we're lacking a little in proper tools to make it easier. Equally broken is bad, too. 'More broken' is clearly a disaster. 'Not broken' is the goal. I'm not talking about English Lit. classes here. Stay on target please. I don't know what English Lit. has to do with anything. Clearly these degrees of brokeness of DNSSEC are relevant to a debate about DNSSEC problems. 2) If DNSSEC is flawed, where is a better alternative? I think there are indeed better alternatives. Bernstein calls for development of alternatives. So there are better alternatives, but even Mr. Bernstein wants to develop alternatives, suggesting to me that tehre are currently no alternatives. Nice circular logic there. Which again leads to you requiring more proof of 1) before shooting down DNSSEC. If there is nothing better, and DNSSEC does not make it worse (and some complexity in return for fixing the recent Kaminsky class bugs seems pretty acceptable to me), then it is you who needs to do the work of developing these 'better alternatives' that you so desire. Consensus and Running Code? The logic if nothing better, therefore DNSSEC does not make it worse is a fallacy. There can indeed be no alternative (and thus nothing better), while DNSSEC still makes things worse. But to find alternatives, IETF has to stop silencing the people who can figure out solutions, merely because those people oppose the BIND cartel. I'm skipping the conspiracy theory discussion bit. I see many clever people who dare to stand up and show mistakes and propose alternatives. You just said there were no alternatives. Dismissing the definite overt acts of misconduct as conspiracy theory is merely a tricky attempt to avoid the facts. There is nothing hypothetical about the facts of the misconduct in silencing persons who opposed the BIND cartel. There is nothing hypothetical about the government documents that show the common control in the BIND cartel The BIND cartel gave us the flawed solutions; However, after I asked you to show these flaws, I was not answered. See above. You were answered about flaws; I referred you to documents describing the flaws. The recent message from Dr. Bernstein more clearly answers the 'flaws issue'. deployment of another broken solution. Time and again we've seen this same pattern: Someone essentially yells Emergency! Lets rush out this (non) solution! No time to think things through!. You are the first person I've ever heard say that DNSSEC was rushed. The other 99.9% of people complained it took us more then 10 years. DNSSEC was a series of mistakes over a 15 year period. The current rushing is the DNS is insecure! Adopt DNSSEC NOW!!! drumbeat. Take our patches without thinking or questioning our wisdom!!! This drumbeat is no different from the 2003 There is SPAM! Adopt SPF
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
On Tue, 12 Aug 2008, Mark Andrews wrote: TCP, port randomisation, 0x20, EDNS PING etc. all leave gapping holes in the security model which are being exploited today. I don't know of any TCP exploits today. Though TCP is not secure against anyone in the path of the packets, its pretty invulnerable to spoofing attacks conducted if the attacker can't see the packets. TCP is vulnerable to other kinds of DOS attacks such as synflood or connection reset. Synfloods are handled by existing mitigation techniques. The shorter the transaction, the harder it is to effect connection reset, but connection caching improves efficiency. TCP is pretty robust in most situations. TCP: Get truth or nothing, unless liar in the path UDP: Get something, even a lie from anywhere DNSSEC: Everybody might get nothing, but the TLD and root operators are entrenched. No alternate roots. Pick your poison (pun intended ;-) --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
On Sat, 9 Aug 2008, Paul Wouters wrote: DNSSEC, a cryptographic version of DNS, has been in development since 1993 but is still not operational. It seems that Mr. Bernstein also suffers from the America is the not the world syndrome. ??? Bernstein said that DNSSEC offers a surprisingly low level of security while causing severe problems for DNS reliability and performance. Let's not argue about the subjective suprisingly. But what is this low level of security? Is a fully trusted path 'low level'? If so, what is 'high level'? I think http://cr.yp.to/talks/2004.04.28/slides.pdf might help. We need to stop wasting time on breakable patches, Bernstein said. He called for development of DNSSEC alternatives that quickly and securely reject every forged DNS packet. This statement even goes so far as to suggest DNSSEC is a breakable patch In general, for all those people who claim DNSSEC is not the solution, I have a few questions 1) What is more broken with DNSSEC then on DNS? The question really should be 'What is LESS broken with DNSSEC than with DNS?' Equally broken is bad, too. 'More broken' is clearly a disaster. 'Not broken' is the goal. 2) If DNSSEC is flawed, where is a better alternative? I think there are indeed better alternatives. Bernstein calls for development of alternatives. But to find alternatives, IETF has to stop silencing the people who can figure out solutions, merely because those people oppose the BIND cartel. The BIND cartel gave us the flawed solutions; It did this by silencing the opposition to create a false consensus on their ideas. The cartel continues to exercise control of (at least) IETF DNSEXT and continues to silence its critics, even though its credibility at solving these problems should have been exhausted a long time ago. Silencing the cartel's critics was improper. Without answering those questions, you can't really reject DNSSEC over the alternative of keeping to run DNS as we have so far. Sure you can reject DNSSEC. One broken solution doesn't justify deployment of another broken solution. Time and again we've seen this same pattern: Someone essentially yells Emergency! Lets rush out this (non) solution! No time to think things through!. In almost every case, there is usually no emergency, and the 'solution' is frequently worse than the problem. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
FYI: It would be nice if someone could repost this the namedroppers. This might inform some of the discussion going on there. Both DJB and I have problems posting to namedroppers for basically the same reasons---opposing the BIND cartel. However, getting this information distributed seems to be important enough to be widely distributed. Make sure you read the UIC announcement included at the end. I'm greatly enjoying the Olympics; have fun! --Dean -- Forwarded message -- Date: 8 Aug 2008 03:42:28 - From: D. J. Bernstein [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Kaminsky on djbdns bugs Kyle Wheeler writes: That makes it easier for an attacker to guess the right number, but only somewhat (your chances per-guess go from one in four billion to, say, thirty in four billion). This criticism of djbdns seems somewhat... well, specious. http://cr.yp.to/djbdns/forgery.html has, for several years, stated the results of exactly this attack: The dnscache program uses a cryptographic generator for the ID and query port to make them extremely difficult to predict. However, * an attacker who makes a few billion random guesses is likely to succeed at least once; * tens of millions of guesses are adequate with a colliding attack; etc. The same page also states bilateral and unilateral workarounds that would raise the number of guesses to practically impossible; but then focuses on the real problem, namely that attackers with access to the network would still be able to forge DNS responses. I suppose I should be happy to see public awareness almost catching up to the nastiest DNS attacks I considered in 1999. However, people are deluding themselves if they think they're protected by the current series of patches. UIC is issuing a press release today on this topic; see below. ---D. J. Bernstein, Professor, Mathematics, Statistics, and Computer Science, University of Illinois at Chicago DNS still vulnerable, Bernstein says CHICAGO, Thursday 7 August 2008 - Do you bank over the Internet? If so, beware: recent Internet patches don't stop determined attackers. Network administrators have been rushing to deploy DNS source-port randomization patches in response to an attack announced by security researcher Dan Kaminsky last month. But the inventor of source-port randomization said today that new security solutions are needed to protect the Internet infrastructure. Anyone who knows what he's doing can easily steal your email and insert fake web pages into your browser, even after you've patched, said cryptographer Daniel J. Bernstein, a professor in the Center for Research and Instruction in Technologies for Electronic Security (RITES) at the University of Illinois at Chicago. Bernstein's DJBDNS software introduced source-port randomization in 1999 and is now estimated to have tens of millions of users. Bernstein released the DJBDNS copyright at the end of last year. Kaminsky said at the Black Hat conference yesterday that 120,000,000 Internet users were now protected by patches using Bernstein's randomization idea. But Bernstein criticized this idea, saying that it was at best a speed bump for blind attackers and an extremely poor substitute for proper cryptographic protection. DNSSEC, a cryptographic version of DNS, has been in development since 1993 but is still not operational. Bernstein said that DNSSEC offers a surprisingly low level of security while causing severe problems for DNS reliability and performance. We need to stop wasting time on breakable patches, Bernstein said. He called for development of DNSSEC alternatives that quickly and securely reject every forged DNS packet. Press contact: Daniel J. Bernstein [EMAIL PROTECTED] -30- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
I'm not confusing zone boundardies with label boundaries. 32 levels is the worst case. In practice, it'll probably be much more than 3 or 4 levels, but probably in most cases fewer than 32. But it is widely expected to be very problematic to maintain, and has always been problematic to maintain, even in IPv4. Hence the efforts on RFC1788(IPv4) and RFC4620(IPv6) --Dean On Sun, 6 Jul 2008, Joe Abley wrote: On 6 Jul 2008, at 18:16, Dean Anderson wrote: Oh yeah--That's right. 32 levels--Much worse than I said. No. To reiterate the point that I saw Fred making... I wrote up many of the issues with reverse dns about 1.5 years ago. I submitted it to the IETF, but there was no interest in publishing this information. http://www.av8.net/draft-anderson-reverse-dns-status-01.txt The following example was taken from RFC3596: 4321:0:1:2:3:4:567:89ab would be b.a. 9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6. ARPA. ... such a PTR record would most likely be obtained by following four (root - ip6.arpa - RIR sever - LIR server - assignee server) or three (root - ip6.arpa - RIR server - assignee server) delegations. I doubt this is substantially different, in aggregate, from IPv4. You seem to be confusing label boundaries with zone cuts in your analysis. Joe -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
Oh yeah--That's right. 32 levels--Much worse than I said. I wrote up many of the issues with reverse dns about 1.5 years ago. I submitted it to the IETF, but there was no interest in publishing this information. http://www.av8.net/draft-anderson-reverse-dns-status-01.txt The following example was taken from RFC3596: 4321:0:1:2:3:4:567:89ab would be b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6. ARPA. On Mon, 30 Jun 2008, Frederico A C Neves wrote: Mr. Anderson, On Sat, Jun 28, 2008 at 05:36:04PM -0400, Dean Anderson wrote: A number of the points you raise have already been addressed. The IPV6 Reverse resolution question has been discussed at length in DNSEXT previously. In fact, it was proposed to remove reverse resolution entirely from IPV6 for just the reason Dr. Huang notes. A 128 bit IPV6 address is 16 octets. To perform reverse resolution requires traversing 16 levels of DNS tree. Not exactly. The reverse delegation is at the 4 bits boundary, so the correct is 32 possible levels, but this possibility doesn't impose all these levels. Half of the levels are unlikely to be used and the other half you'll see normally the average of 3 to 4 as we see it today for IPv4. The amount of delegations levels are driven by the IP distributions layers (IANA-RIR-NIR-ISP), not by the address space. Fred ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
A number of the points you raise have already been addressed. The IPV6 Reverse resolution question has been discussed at length in DNSEXT previously. In fact, it was proposed to remove reverse resolution entirely from IPV6 for just the reason Dr. Huang notes. A 128 bit IPV6 address is 16 octets. To perform reverse resolution requires traversing 16 levels of DNS tree. Even the delegations impose significantly larger trees on the registries. It is recognized that this isn't going to be very scalable, or even possible. IPV6 proposes to use ICMP Node Identification query instead. At present, there is an IPV6 reverse tree, but it is not guarenteed it will stay. It is for transition--so that gethostbyaddr() still works on IPv6 during transition. See for example the discussions here: http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00931.html http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01828.html --Dean On Sat, 28 Jun 2008, Phil Regnauld wrote: 2.3 Reverse Resolution Reverse Resolution uses .IN-ADDR.ARPA domain today. In IPv6, .IP6.ARPA was defined by [RFC3152], and more detail information can be found in [RFC3596]. Because IPv6 has a huge Name Space, it is difficult to keep reverse RRs in today's architecture. Question: Why ? Yes, IPv6 space is immense, but for the foreseeable future, only a very small part of it will be populated. Same goes for IP6.ARPA. But there are no data, either by you or others, supporting the claim that it will be more difficult to accomodate reverse information as IP6.ARPA grows. Do you have some simulation, model or other data-based prediction that can be used to illustrate this problem ? -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
On Wed, 25 Jun 2008, Stephane Bortzmeyer wrote: On Wed, Jun 25, 2008 at 04:58:18PM +0800, ?? [EMAIL PROTECTED] wrote a message of 85 lines which said: Thanks, Dean, Lican, I must tell you that associating with a known troll like D. A. is not a good idea to spread your ideas. Almost everything in his message is completely wrong (for instance, in the Nanog discussion he talked about, *one* network operator made the mistake to identify DNS+TCP with AXFR and he was promptly corrected by everyone else). Since my credibility is challenged, let me respond to that challenge: In the recent NANOG discussion, there were several 22 people involved and 33 messages on the subject over 3 days from June 13 to June 16. At least 2 were asserting that DNS doesn't use TCP for anything but AXFR and would be very concerned to find TCP queries. Many more seemed to feel that TCP was only a fallback when UDP failed, which is also incorrect. So Mr. Bortzmeyer can't even accurately report a discussion. By contrast, my reports are consistently reliable and correct. I've been vindicated on many controversial issues. Mr. Bortzmeyer's reports have not been so reliable, and he has not been so vindicated. For example, the fibre cables connecting US with China was broken by earthquake, then almost all web pages was unreachable even the machine was in China because of root servers are located in USA. Like in your Internet-Draft, this sentence shows a big lack of knowledge about the DNS you pretend to fix. There are root servers instance in China for many years. Anyway, a few seconds after it starts, any DNS resolver in China has certainly the names and addresses of .cn name servers in its cache and can lose connectivity with the root without big problems. I can think of no reason why anyone outside of ISC should know what ISC doesn't report to ICANN. So Mr. Bortzmeyer's criticism of Dr. Huang's lack of knowledge of ISC customers seems to be baseless. It is indeed rumored, and I've seen several people from ISC report that there are indeed copies of F-root in China. However, this is a commercial operation of ISC, not a decision of IANA. ISC could remove those Anycast servers at any time. ISC is not obligated or regulated in any way regarding the location of these servers. As far as I know, ISC only reports the number, not the locations of the servers or the ISC customers to the ICANN RSSAC. Indeed, it is my understanding that in some cases, the ISC customer only allows the Anycast route inside its network. In those cases, those ISPs have a root copy for their own use, benefiting them and no one else, except of course, ISC. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
According to this page, both F-root servers in China are local nodes, meaning they don't advertise their route outside of the ISP they are connected to. In fact, all copies of F-root except 2 (below) are local nodes, and the two that aren't, are quite close geographically. ISC doesn't publish the customers or sites of these two servers, either. PAO1Palo Alto, CA, USA IPv4 and IPv6 Global Node SFO2San Francisco, CA, USA IPv4 and IPv6 Global Node And we don't know if the two servers in China are in the same ISP in different physical locations, or if they have different ISPs. What Hierachical Anycast (the scheme variant used by ISC) in this case means, is that a user in China may see either 3 or 4 F-root servers (depending on how the two China F-root copies are deployed--a fact that ISC does not report). Indeed, it is possible that some users in China may only see the 2 global copies, both of which are located in the SF Bay area. Any disruption between or involving China and the SF Bay area would isolate many users in China from F-root, so Dr. Huang's hypothetical scenario is indeed possible. Anycasting F-root would not help *nearly* as much as is asserted by ISC. They seem to be talking out their backside, as it were. BTW, the two China ISPs that purchased copies of F-root could alternatively run their own copies of F-root privately, if only ICANN were to publish the root zone publicly instead of only to root server operators. Indeed, if this information were public, all ISPs could run their own private copies of root servers this way, and we could dispense entirely with global root servers, and the threat on global root servers. One wonders why ICANN/IANA doesn't publish this root DNS information for public consumption. --Dean On Wed, 25 Jun 2008, Joao Damas wrote: On Jun 25, 2008, at 10:58 AM, é»çç¿ wrote: For example, the fibre cables connecting US with China was broken by earthquake, then almost all web pages was unreachable even the machine was in China because of root servers are located in USA. Not so. Have a look at http://www.isc.org/ops/f-root/ for the part that refers to f.root-servers.net There are at least 2 other Internet root server instances in mainland China, and additional ones in the Hong Kong area. Lack of access to root servers was definitely not at the source of any unreachability. Joao Damas ISC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Why deny AXFR from root servers?
On Wed, 25 Jun 2008, David Conrad wrote: On Jun 25, 2008, at 3:20 PM, Dean Anderson wrote: So why deny AXFR from roots, then? AXFR constitutes a significantly greater load on a name server than simply answering normal queries. As such, independent root server operators may decide to restrict zone transfer from their root servers. A single AXFR constitutes a greater load than a single query. However, it seems unlikely that 30,000 ISPs doing AXFR of the root zone would be less than all the root queries from all the nameservers in the world. BTW, did the root zone actually change today (2008062500)? VeriSign regenerates the root zone twice a day regardless of whether there are root zone changes. One would think that could be more efficient. BTW, can you explain what these zones are? XN--KGBECHTV. NS A.IANA-SERVERS.NET. XN--KGBECHTV. NS B.IANA-SERVERS.NET. XN--KGBECHTV. NS C.IANA-SERVERS.NET. XN--HLCJ6AYA9ESC7A. NS A.IANA-SERVERS.NET. XN--HLCJ6AYA9ESC7A. NS B.IANA-SERVERS.NET. XN--HLCJ6AYA9ESC7A. NS C.IANA-SERVERS.NET. XN--11B5BS3A9AJ6G. NS A.IANA-SERVERS.NET. XN--11B5BS3A9AJ6G. NS B.IANA-SERVERS.NET. XN--11B5BS3A9AJ6G. NS C.IANA-SERVERS.NET. XN--JXALPDLP. NS A.IANA-SERVERS.NET. XN--JXALPDLP. NS B.IANA-SERVERS.NET. XN--JXALPDLP. NS C.IANA-SERVERS.NET. XN--DEBA0AD. NS A.IANA-SERVERS.NET. XN--DEBA0AD. NS B.IANA-SERVERS.NET. XN--DEBA0AD. NS C.IANA-SERVERS.NET. XN--G6W251D. NS A.IANA-SERVERS.NET. XN--G6W251D. NS B.IANA-SERVERS.NET. XN--G6W251D. NS C.IANA-SERVERS.NET. XN--HGBK6AJ7F53BBA. NS A.IANA-SERVERS.NET. XN--HGBK6AJ7F53BBA. NS B.IANA-SERVERS.NET. XN--HGBK6AJ7F53BBA. NS C.IANA-SERVERS.NET. XN--80AKHBYKNJ4F. NS A.IANA-SERVERS.NET. XN--80AKHBYKNJ4F. NS B.IANA-SERVERS.NET. XN--80AKHBYKNJ4F. NS C.IANA-SERVERS.NET. XN--ZCKZAH. NS A.IANA-SERVERS.NET. XN--ZCKZAH. NS B.IANA-SERVERS.NET. XN--ZCKZAH. NS C.IANA-SERVERS.NET. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
On Wed, 25 Jun 2008, Joe Abley wrote: On 25 Jun 2008, at 16:08, Dean Anderson wrote: According to this page, both F-root servers in China are local nodes, meaning they don't advertise their route outside of the ISP they are connected to. The ISP is misleading; both F-root nodes in the PRC are connected to popular exchange points in their respective locations, Peering points in this case just gives ISC access to more ISPs at (presumably) less cost. There is nothing misleading in The ISP. The number of many ISPs is unimportant, so long as it is not universal. The key factor is that these are Local Nodes that but only offer services to a specific ISP (or ISPs) rather then all of China and Asia. and ISC is known to operate open peering policies. I was under the impression that you charge for operating these servers. How does that charging work? Do you charge the peering facility and offer services to ISPs at that peering point for free? Do you charge for peering? I'm very curious about that. As to whether the F-root nodes in Hong Kong and Beijing actually exist, I can vouch for them being decidedly non-imaginary since in both cases I was part of the team that installed them. I fully expect this to do nothing to enhance their credibility in your eyes, however, and there's no need to point that out. Gee, I thought you left ISC, yet you can still speak for ISC... So, what does it cost to peer with ISC root servers? I've heard some speculations, but no figures. Of course, Mr. Abley's non-imaginary existance proposition is entirely frivolous. I guess Joe is just trying to get a laugh, somehow. My point is that given these Anycast servers are located in PRC today, there is no guarantee that they will be there next week or next month or next year---That's because ISC doesn't have to ask anyone's permission to remove them, nor does ISC even have to notify anyone (except perhaps the peering ISPs) when it removes these servers. We do not know ISC's contract status on these servers, and we have no influence over those contracts, if any. And furthermore, these two China servers don't benefit any ISP in China that doesn't peer with ISC, so Dr. Huang's hypothetical scenario is true, as previously demonstrated, despite Mr. Abley's humorous assertions about their non-imaginary existance. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
Dr. Lican Huang It is perfectly clear now that the current IPv6 Root DNS architecture is deeply flawed. It is strange that Paul Vixie asserts that there are no future load problems, since Paul Vixie has previously asserted that DNS Anycast is a solution to these future load problems. RFC1546 states, and it has been experimentally demonstrated that Anycast doesn't work for TCP connections. Recent discussion on NANOG has shown that operators were under the mistaken impression that only AXFR uses TCP, and that ordinary DNS queries are never performed over TCP. Perhaps this explains why they think that DNS Anycast might be stable when TCP Anycast is not stable; it seems they think (incorrectly) that DNS only uses UDP. Furthermore, in support of Dr. Lican Huang premise: As IPv6 records are added to already limited priming and NS responses at the expense of IPv4 servers, IPv4 stability is reduced. Any reduction in the number of IPv4 servers in these responses imposes stability problems on the respective IPv4 root, TLD, and other Domains. On the other hand, adding fewer IPv6 nameservers in NS and priming responses similarly compromises IPv6 DNS stability. This is a hobbsian choice. This choice is only imposed because of the mixing IPv6 and IPv4 records on the same set of root and DNS servers. There is no need or requirement for such mixing. Using entirely separate IPv4 and IPv6 resolvers avoids the hobbsian choice caused by the mixing. So, I think that a complete set of IPv6 root nameservers should be created, and that the scalability solution proposed by Dr. Lican Huang should be seriously considered as a solution to the scalability problems already experienced in IPv4, so that IPv6 DNS over TCP can be handled reliably. --Dean On 24 Jun 2008, Paul Vixie wrote: thank you for your work on this. i find no support for this assertion: 1. Introduction Although DNS becomes a vital component in today's Internet infrastructure, the existing DNS architecture will encounter problems in the future for the growth of the Internet. ... DNS implementation currently used may encounter overload traffic in root DNS servers. ... therefore while i find your proposed solution to be of high quality, there is a cost in overall system complexity for adding a virtual routing layer to the DNS, which would have to be justified by a much more complete problem statement and an objective analysis of more than one alternative. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
On Wed, 11 Jun 2008, Gervase Markham wrote: Dean Anderson wrote: That's unfortunate; but I must say this upset was not communicated to me. Probably that's because you are using SORBS to filter your email. SORBS has an unusually high number of false positives, and for example, falsely claims that that 130.105/16 and 198.3.136/21 are hijacked. You can find more information about SORBS on http://www.iadl.org/ No-one can have control over and knowledge of everything their ISP does with relation to the services they provide. Actaully, I looked into the 'Our ISP blocked our mail without our knowledge' claim. [I'm always interested in the cases where this is true]. In fact, Mozilla's email is handled by mailservers on 63.245.208/20, which is a /20 assigned to Mozilla.org. It struck me as quite odd that quite strange that Mozilla.org has 4096 IP addresses, and that it got this assignment in 2006, under what should have been very strict usage and allocation rules...I wonder how Mozilla.org justifies 4k public IP addresses---Question for a different forum. Anyway, using SORBS isn't a decision you can blame on your ISP. Its Mozilla.org's mailserver, not an outsourced ISP mailserver. Mozilla.org has control over its email filtering, and it seems likely a Mozilla.org admin configured SORBS. It was not their ISP. This affects at least my view of your credibility. I confess I've only ever vaguely heard the name SORBS, and had no idea that my provider was using it. But I don't believe that using it makes me uncontactable. My phone number and address are on my personal web page. I can hardly imagine some TLD administrator saying I'm so irritated about Firefox's TLD IDN whitelist. I'm going to send Gerv a nasty email. Hang on, my email's been rejected. Oh well, I guess I'll just have to live with it. Well, somehow they managed to convey their upset'ness to ICANN, but not convey that to Mozilla. I don't know exactly why that was. But people often don't try very hard to overcome communication problems to tell someone that they are unreasonably off in the weeds. A SORBS bounce would tend to confirm the effort is pointless. That policy of ours should have no effect whatsoever on TLDs with a responsible attitude to homographs. Our registration requirements are not onerous. ??? This statement doesn't seem very credible. What authority do you have to decide what a 'responsible attitude to homegraphs' would be? What's your answer to that question? (Hint: the answer no-one is equivalent to the answer the registries, which has been shown not to work. See http://www.shmoo.com/idn/ .) I don't see that the answer is no-one, nor that the registries has been shown not to work, as you claim. However, if you think there is a problem and you have a solution that should be imposed on the TLDs, you should take the matter up with ICANN. Your unilateral exercise is certainly no solution. Mozilla.org doesn't represent the internet industry nor any government or governing organization. No, we represent our users, and we make all sorts of security decisions for them on a regular basis. Hmm. Worrisome, given the apparent lack of serious thought put into some of those security decisions, and the lack of credible, serious thought put into even anti-spam choices, and the blaming of things on your ISP. One of the reasons Firefox is popular is precisely because it doesn't wimp out of security decisions with user-irritating popup questions they have no information to answer. I also use firefox, but certainly not for those reasons. I use it because it came with Linux, and it displays HTML pretty reasonably. I didn't know it might have other dubious agendas hard-coded. But, as someone else has said, if people don't like the decisions we make, they can either become part of we and seek to change them, or they can change or build their copy, or can distribute an alternative browser. Actually, I said that. Perhaps others did, too. Why should TLD's think they need to register with Mozilla.org? They don't have to. Why should TLDs think they have an automatic right to have Firefox display domains they have issued which allow our users to be fooled or defrauded? You have no justification to form that conclusion. The TLDs aren't defrauding anyone; The TLDs aren't aiding in the fraud of anyone. And your scheme isn't even shown to stop fraudulent websites. So Mozilla.org seems to have little to no justification whatsoever for its extremely unilateral actions. The people who register their domains with any certified TLD do have an automatic right to have Firefox display their websites. You have no right to assert they are fraudulent when they aren't and you have no evidence they are. I don't get a good feeling about Mozilla.org, anymore. The unrealistic, unilateral attitude reminds me of other kinds of similar extremism, that was also found to be unsubstantiated
[DNSOP] FYI, more comments on IETF not having members
The frivolous, dishonest, and false statements in the January 15, 2008 IESG Appeal Response found at [http://www.ietf.org/IESG/APPEALS/appeal-response-dean-anderson-01-15-2008.txt] must be corrected. Persons are begining to incorrectly claim that the IETF has no members, and no ability to make official statements. In fact numerous Official IETF documents refer to IETF members, and the IETF is part of the Internet Society, Inc, a U.S. non-profit corporation. The ISOC is engaging in improper trade practices by misrepresenting its both its incorporation status and its status as a part of a non-profit membership corporation. Dean Anderson CEO AV8 Internet, Inc -- Forwarded message -- Date: Mon, 9 Jun 2008 10:17:36 -0400 From: Edward Lewis [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Gervase Markham [EMAIL PROTECTED], dnsop@ietf.org, [EMAIL PROTECTED] Subject: Re: [DNSOP] Public Suffix List At 16:00 +0200 6/9/08, Yngve Nysaeter Pettersen wrote: On Mon, 09 Jun 2008 15:32:11 +0200, Patrik Fältström [EMAIL PROTECTED] wrote: The problem with any such mechanisms is that the barrier of entry for new players (that does not match the currently used list -- including non-upgraded software) is increased. More than what people think. That is why my subtld-structure draft is suggesting that TLD profiles be downloaded at regular intervals (and at need) from a repository, in order to make it possible to add new TLDs or new registry-like domains under a TLD, and to prevent problems with old software. My drafts also suggest a rule-of-thumb fallback in case a TLD is unknown. This thread is going to go around in circles for quite a while. There's a history of the IETF wanting to define something without fixed boundaries. DNS names is one, IPv6 addresses is another. But when it comes to operations, having fixed boundaries makes mass production much easier. E.g., in IPv6, IETFer's (as we know, the IETF doesn't have any official statement source and no members, so I refer to those in the debate that brandish IETF credentials) would say that the days of classful addressing are behind us, so IPv6 addresses ought to be treated as nothing but a string of 128 bits. But RIR policy writers wanted to know whether to recommend /48's, /54's, /32's, etc. for certain types of uses. (Uses not users.) Shifting back to DNS, there's not going to be a scientific differentiation between one zone and another. During the DNSSEC development days we wanted to declare some zones as widely delegated (such as .com) from other zones - to alleviate the issues we see with NSEC, NSEC3, etc. that are apparent still now. There's nothing in DNS to differentiate, at a protocol level, one zone from another, but at the operational end of the stick, there are many differentiators (like whether the administration interface is on paper or via EPP). I doubt that you'll find any repository that can be used to register registry-like zones. The DNS lacks anything like a RADB, RPSL, etc., mechanism employed by the routing infrastructure. Partly because, unlike IP addresses, there is no organizational link through all parts of the Domain administrations. ICANN does not have it's thumbs on all the TLDs - many ccTLDs do not operate under any agreement with ICANN. I admire and respect the effort of web browser implementers to try to improve their code to make it harder to abuse. Even if the desired tactic is on target, it may still fail because the information is just not available. Worse is broken security which will just frustrate the users and make the situation even more fertile for abuse (through uncertainty and confusion). The domain name industry is more complex than one would think. It's not technical, it's a market place with operators, wholesalers, resellers, etc. I think the answers to building a domain's reputation lie more in what happens at an ICANN meeting than an IETF meeting. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC: Considerations for the use of DNS Reverse Mapping
I oppose this document. I won't go into details since none of my objections have ever been addressed, other than to say We addressed your objection with a frivolous change or no change at all. Reposting the details seems an utter waste of time. If this document is eventually approved by the WG, I will file a detailed objection with the IESG. I see no point in further detailed discussion until that event transpires, except to note that I remain opposed. I don't expect my opposition to change unless the previously noted problems are addressed, and so far, they've either been ignored or frivolously handled. I believe the objections of others have also been ignored or frivolously handled. Thanks, --Dean On Fri, 14 Mar 2008, Peter Koch wrote: Dear WG, in accordance with the roadmap posted the other day, this is to initiate a working group last call on Considerations for the use of DNS Reverse Mapping draft-ietf-dnsop-reverse-mapping-considerations-06.txt ending Friday, 2008-04-04, 18:00 UTC. The document is aimed at a status of BCP. Please review the draft and send comments and/or statements of support or non-support to the WG mailing list. We have taken names of volunteers, but everyone is encouraged to review. There will be a five reviewer threshold and _no_ default action. -Peter [co-chair hat on] ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Draft Charter
What clause would DNS Root Anycast stability fall under? --Dean On Fri, 14 Mar 2008, Peter Koch wrote: Dean, If you could support this observation by tangible textual reference, that would be appreciated. As a side note, there is an IETF liaison to ICANN, independent of whatever WG charter. I'm not sure what you mean to dispute. The text of the charter I quoted cites This will include root zone name servers, gTLD name servers [...] I don't think it can be made plainer. the fact that name servers dealing with a certain level in the DNS hierarchy or with certain parts of the DNS tree are not or are no longer explicitly mentioned does not imply that they could not taken into special consideration where appropriate. The liason role is communicative; the liason communicates the consensus of (in this case) DNSOP. The person of liason has not previously been the sole technical expert provided by the IETF. But if that becomes so, this isn't what is described in the MoU. The IETF technical expertise IETF Liaisons are appointed by and report to the IAB. There is an IAB statement regarding the IETF's Liaison to the ICANN Board of Directors at http://www.iab.org/liaisons/icann/icann-liaison.html. Neither DNSOP nor any other IETF WG is mentioned there and is at the sole discretion of the IAB to consult with IETF WGs in its (the IAB's) role of assisting the Liaison in executing their duties. I asked you to provide tangible reference (i.e. chapter and verse) to support your view of DNSOP having a special role w.r.t. root server operations. I fail to see this information having been provided. Also, there was no support of your view. Therefore I consider this issue closed. People in favor of changing the charter indeed held the position you describe. But my recollection is that the charter wasn't changed; those people didn't have a consensus to change the charter that way at that time. The sad fact is that me dropped the ball on the charter work. Note however, that the charter as proposed would _not_ prevent the DNSOP WG from, say, updating RFC 2870. Under what provision of the new charter would RFC 2870 fall under? The general clause The DNS Operations (DNSOP) Working Group will develop and review guidelines for the correct, efficient and secure configuration, administration, and operation of DNS authoritative servers, resolvers, and DNSSEC validators. would certainly cover this. -Peter [with hat] -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Draft Charter
So root and gTLD DNS server operations supervision is off the charter? It used to be the first item. This appears to affect ISOC IETF commitments to ICANN to provide this technical role. I'm not certain I'm against that--I just want to clarify that this isn't an oversight. 1. Define the processes by which Domain Name System (DNS) software may be efficiently and correctly administered, configured, and operated on Internet networks. This will include root zone name servers, gTLD name servers, name servers for other DNS zones, iterative DNS resolvers, and recursive DNS resolvers. As part of this effort, the group will produce documents explaining to the general Internet community what processes and mechanisms should be employed for the effective management and operation of DNS software. --Dean On Tue, 11 Mar 2008, Peter Koch wrote: Dear WG, after several attempts, here is the most recent version of the new DNSOP charter to be discussed in tomorrow's WG session: - The DNS Operations (DNSOP) Working Group will develop and review guidelines for the correct, efficient and secure configuration of DNS authoritative servers, resolvers, and DNSSEC validators. Target audiences for those guidelines are zone administrators as well as software developers who provide tools for DNS zone administration or (default) server/resolver/validator configuration. The group will perform the following activities: 1) develop or review guidelines for chosing zone configuration parameters that affect inter-server or server-resolver communication, including but not limited to SOA RR parameters, TTL values, and glue information 2) develop or review guidelines for any DNSSEC specific operational parameters, such as key length or key validity periods 3) investigate and identify requirements of DNSSEC to the lower layers, both transport and network 4) develop or review operational guidelines that address the specifics of IPv4/v6 coexistence and transition 5) review the use of existing DNS frameworks (SRV, DDDS) in other protocols, especially focussing on operational consequences and scalability, most importantly when these frameworks are used in other wg's protocol proposals. 6) develop and review guidelines for resolver (stub and full) behaviour, including search path and timing issues as well as query strategies. 7) establish terminology and methodology for performance measurements of servers, resolvers or the service as such. 8) identify the requirements for a name server configuration and control protocol. To avoid overlap with the DNS Extensions working group, the DNSOP group will not change the on the wire behaviour of the DNS. Terminology issues will, where appropriate, be addressed in coordination with DNSEXT. - This version is expected to take into account the feedback given on the list and during the WG meetings in and after 2006 as well as recent additions to the set of active work items. -Peter ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Draft Charter
On Tue, 11 Mar 2008, Joe Abley wrote: On 11-Mar-2008, at 10:37, Dean Anderson wrote: So root and gTLD DNS server operations supervision is off the charter? I'm not sure it was ever on the charter. The paragraph you quoted seems to suggest that the attention of the working group is equally-focussed on root, TLD and all other nameservers, whether authority-only servers or not. I didn't say the charter was exclusively oriented to root and gTLD operations. But the current charter explicitly includes them, and the proposed new charter does not. This is not the first time we've discussed these issues. The last time changes to the charter were proposed, I brought up the same issue. Back then I opposed removing root and gTLD operations from the charter. Now, I'm not so certain it isn't a good idea. As I wrote back then: It seems to me the issues outlined in the current charter element above are still a fundamental and important part of the DNSOP mission, particularly with respect to the ICANN MoU and RFC 2870, which give a substantial role to the IETF on DNS Root server operations. There is still an effect on the ICANN MoU and RFC 2870. For one thing, updating RFC 2870 would appear to be out of scope in the proposed new DNSOP charter. The change in my position is that I'm no longer quite so certain root and gTLD operations are a vital part of the IETF or DNSOP mission. I think the subject of root and gTLD supervision is a vital part for _someone_ or _something_, but perhaps not the IETF. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-reflectors-are-evil-05.txt
On Wed, 12 Dec 2007, Peter Koch wrote: The main task of the WG w.r.t. this draft is now to consider the issues raised and support the editors in addressing and resolving the concerns voiced in LC. I have reviewed the IESG comments. Besides removing the false claim I previously noted about authority servers (which is partly covered by Cullen Jennings in his discuss comment), I think the draft should explain the qualitative differences between authority attacks and recursor attacks. As previously noted, it is much more difficult, if not impossible, to mitigate attacks which use authority servers. This feature makes the authority attack much more fearsome. Closing open recursors does not eliminate these attacks. I seem to note 3 ways of searching for open recursors: 1) walk in-addr.arpa, and test those authority servers to find those that also do recursion. This produces a subset of authority servers. 2) scan by brute force the entire internet for recursors. This method seems unattractive, and likely to be too difficult or too time consuming for script kiddies. 3) collect recursor data from queries at root and TLD server sites. This vector is very limited due to the relatively small number of people who have the necessary access. I note that the most likely vector for finding open recursors (number 1 above) requires searching authority servers. Plainly, obtaining large authority records is just as easy as obtaining the list of recursors, if not easier. The following seem to be obvious: X Some people will need to run open recursors. X Few people can obtain lists of open recursors more easily than searching authority servers. X it seems like a reasonable assumption there will be plenty of large DNS records on authoritative servers without the attacker needing to create them. (Cullen Jennings) None of these is really noted or explained in the draft. I have no problem with the WG offering operational advice on this subject. I do think a recommendation _could_ be helpful, if it is based on _fact_ and rational, transparent analysis, and ultimately helps administrators understand the attack and what they can do about it. This draft does not do that. Instead, it promotes unfounded religous views that aren't even reflective of the WG views--if WG members can't recommend closing open recursors, one wonders how a WG consensus was achieved to send it to the IESG. Sometimes I get the feeling that some people support advancement of drafts as favors to the authors, rather than on the technical merits of the draft. This draft starts with a conclusion, and tries to support that conclusion despite the contrary evidence that shows this conclusion is unwise and unnecessary. I think the focus of the draft should be on helping administrators with methods of how to address such attacks when they happen, rather than on ineffective reactions telling people needlessly to close open recursors; something most people won't do anyway. This document promotes a particular solution; one which wasn't very well thought out to begin with, and one which can easily be seen to be ineffective, inadequate, and completely unhelpful to the administrator who is concerned about or subjected to this type of attack. Sam Hartman writes in his comment: Please add security considerations text to address Paul's issue without making a recommendation about whether the practice is advisable. I think the entire draft should be rewritten to be informative without being religious. Despite the document name, open recursors are neither good, nor evil. They are tools which like other tools, can be abused. Information about how they can be abused and what can be done would be helpful. But that description can't ignore the more fearsome attacks available for authority servers. For example, while dealing with any DNS DOS attack, one must avoid blocking authority servers because there are additional consquences to doing that. Authority operators must also avoid blocking queries when they detect abuse, since there are additional consequences in that case, too. These issues, quite important to anyone actually dealing with an attack, are ignored and dismissed. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt (fwd)
On Mon, 8 Oct 2007 [EMAIL PROTECTED] wrote:
On Sun, 7 Oct 2007 [EMAIL PROTECTED] wrote:
The diagram looks like:
Ax Bx
||
Xa---Xb
||
LBa--LBb
\ /
B{1..n} (backend) servers 1 through N
On Xa, the preferred path for S is - LBa.
On Xb, the preferred path for S is - LBb.
The load balancers do not have unique IP addresses. They have the same
IP address, call it S1. No other IP addresses from S are in use.
The load balancers in this picture are not Anycast. I think you
misunderstand both Anycast and HSRP/VRRP. The second one takes over IP
address S1 when the primary fails.
The diagram above was created by me. I said both LBa and LBb have the
same IP address, and that the two LB's are independent.
Well, that's probably where you are wrong. The LBs probably aren't
independent. At least, they aren't _normally_ independent. They use a
health monitoring protocol to make sure that only one is doing the work
and the other is a hot standby. When the health monitoring indicates a
failure, the standby takes over the primary IP address. The load
balancers would normally share a lan on the router side, and a lan on
the backend server side.
This means that they operate *without knowledge* of each other's state,
and only inter-operate at the routing level - both announce S into their
IGP (e.g. OSPF). BGP announces the prefix, once only, and only from the
ASN in question (X).
I suppose it is possible to turn off the HSRP/VRRP/etc health monitoring
protocols and actually Anycast Load Balancers, but that would be quite
unusual. It would suffer the usual problems with Anycast:
An ISP Z that used BGP multipath with A and B would send subsequent tcp
packets to LBa and LBb. Only one of the LBs received the syn packet, and
the other one would send a reset back, closing the connection.
Z
/ \
Ax Bx
||
Xa---Xb
||
LBa--LBb
\ /
B{1..n} (backend) servers 1 through N
I'm not aware of any vendors that would recommend your scheme.
Certainly F5 doesn't.
While I've seen stranger things, my hunch is that you didn't set it up
and that it isn't actually Anycast, but rather instead that you just
don't know the difference between pictures that are similar.
BTW, It is _possible_ for a vendor make a state maintanence protocol
that keeps the state of each tcp connection in sync on both systems. In
fact, linux clustering technology does this. However, this isn't Anycast
either, but is a single cluster computer assembled out of generic
computers with a special operating system that makes them work as a
single computer system. I don't know of any loadbalancer vendor that
does this. The F5 LTM doesn't do this.
--Dean
--Dean
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
___
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt (fwd)
On Thu, 4 Oct 2007, Brian Dickson wrote: bill fumerola wrote: not all load balancers work the same. direct server return aka one-arm load balancing does no translation or rewrite of any headers (l3 or l4). all it does is make a switching decision based on health check and other weighting criteria. Just to clarify, for those who aren't familiar with the basic idea: Perhaps you should leave the clarification until _you_ are more familiar with the basic idea. By leaving the IP headers unmodified, the individual servers all expect to receive packets that look like they came directly from the internet (and in fact, did) unmodified. The return packets are thus suitable for being sent straight out without needing any rewritee, and thus without touching the LB. The F5 BigIP LTM models I've looked at that do that are the 6400 and 6800 series, running 9.* level code. There's nothing secret about it - it's a generic, vanilla function they ship with. The documentation is on-line. Google for l4 fast bigip. (I have no connection with F5 other than being employed by a satisfied customer.) http://www.f5.com/products/big-ip/product-modules/local-traffic-manager.html It means that the servers are configured identically, are reachable without NAT, and are, in effect, anycast. The Load Balancer is making a stateful decision about which individual server to send each stream to, in the case of TCP, and stateless in the case of UDP. Neither of these models use Anycast in their implementation. Anycast isn't a stateful technique. See RFC 1546. A load balancer that keeps TCP state will work correctly with TCP. But Anycast doesn't keep TCP state, nor state for UDP fragmentation. This is why it doesn't work for stateful protocols (TCP and UDP) It operates in exactly the same way, as if there were two equal cost routes to two or more routers, each advertising the existence of one of these servers, on the other side of a PPLB router - except that it has the ability to handle the state issue for TCP. The F5 LTM box doesn't operate the way you describe. The LTM doesn't advertise two routes to routers. There is a nifty flash demo on the F5 website, for those who are still interested. The LTM isn't anycast. It isn't 'effectively anycast'. You clearly don't know what anycast is. 'operates the same way' doesn't mean that it is implemented the same way. You suffer from an unfortunately common affliction of junior operators and administrators: the inability to distinguish a high level operational effect from actual implementation. This defect is only a serious problem when the operator assumes (incorrectly) that because some things have similar high level objectives and uses, that they are the actually the same. Anyone who operates a network with PPLB towards *external* routes, via BGP multipath, would have to be an idiot or a fool, and would certainly have trouble retaining customers with clue. Really? What do you suppose BGP multipath is meant to do? Let me give you a hint: It installs equal cost routes into the router for loadbalancing across peers. http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t11/ft11bmpl.htm The BGP Multipath Load Sharing for eBGP and iBGP feature allows you to configure multipath load balancing with both external BGP (eBGP) and internal BGP (iBGP) paths in Border Gateway Protocol (BGP) networks that are configured to use Multiprotocol Label Switching (MPLS) Virtual Private Networks (VPNs). This feature provides improved load balancing deployment and service offering capabilities and is useful for multi-homed autonomous systems and Provider Edge (PE) routers that import both eBGP and iBGP paths from multihomed and stub networks. Once again, you seem to be uniquely mistaken in your definition of what would constitute an idiot or a fool. Often, that is the sign of an idiot or a fool. Brian P.S. I do not respond to trolls. P.P.S. I will not respond the troll. I will try not to respond to junior system administrators who are without a clue about the differences between certain network equipment and certain networking techniques, but are still adamant about their views despite evidence to the contrary and despite their lack of experience. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt (fwd)
On Thu, 4 Oct 2007, bill fumerola wrote: On Wed, Oct 03, 2007 at 08:10:03PM -0400, Dean Anderson wrote: But none of this is relevant to the claims that Hickson made. no, but they're directly relevant to the claims that you made: direct server return aka one-arm load balancing does no translation or rewrite of any headers (l3 or l4). all it does is make a switching decision based on health check and other weighting criteria. Header rewriting? as in http header rewriting? That isn't anycast either. you said a load balancers is actually a stateful NAT. it's not. And indeed, I agreed with you. You are correct: only some load balancers are stateful NATs. There are indeed other kinds of load balancers, as you pointed out. But none of them are implemented with Anycast. But by contrast, Dickson said: And a load balancer is by definition doing *anycast*. which is still incorrect. By contrast, I admitted to correction in my incomplete taxonomy of load balancers. Yet Dickson _still_ claims that certain devices use Anycast in spite of evidence to the contrary. It seems that you cannot admit to mistakes. as far as no load balancers use anycast. many do route health injection which when you add more than one load balancer injecting the same route then you have BTW, (HSRP) Hot Swap Redundancy Protocol, and (VRRP) Virtual Router Redundancy Protocol, aren't Anycast either. But apparently you are defining stateful load balancers as Anycast and then claiming success. That isn't success for Anycast, since it isn't Anycasting. But F root, K root, etc are in fact doing Anycasting. They are not using load balancers like the LTM to provide services. that thing you claim is a complete failure and can never work but somehow plenty of installations use it with success when configured properly within their environment. I never asserted the term Complete failure for Anycast. I asserted Anycast was __unreliable__ for stateful services. We don't have to show complete failure to criticize the Root and TLD operations. We just have to show their services are unreliable. Indeed, Anycast DNS services are unreliable: I've shown in theory why Anycast is unreliable for stateful services, and I've collected data that shows that the real world matches the theory. Root and TLD operators and their crony's have used hardball techniques to try to suppress that information. Next, I'd like to collect NSID data on root and TLD anycast servers to have direct data on root and tld operations. And Hickson's dispute isn't relevant to anything about reflector attacks. You apparently digress. i just must be a fraud and liar, not to mention a junior sysadmin. I try not to mistake simple ignorance for fraud and lies. But both indeed deserve correction. A false statement becomes a lie after you can no longer claim ignorance that the statement isn't true. Scientific fraud comes in two types: fabricated data and fabricated conclusions. If the data wasn't collected as reported, then the reported data is fabricated. If the collected data doesn't imply the conclusion, then the conclusion is fabricated. Fraud, such as civil and criminal sort, has even more elements that are necessary for a well-founded accusation. I won't go into those. I don't expect you to meet scientific standards. However, I do expect that you can reason and discover simple facts, such as whether the LTM uses Anycast. I also expect you to be able to admit mistakes. I don't think that is too much. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt (fwd)
On Thu, 4 Oct 2007, bill fumerola wrote: i just must be a fraud and liar, not to mention a junior sysadmin. There's nothing wrong with being a junior admin. I was one once, too. I was a programmer before I was an admin, and I sort of became an admin because I screwed up. Well, this wasn't my _first_ experience with IT, but its a good junior IT story: In 1989 I went to work for the Open Software Foundation in the systems engineering department. Basically, this meant I fixed bugs in Motif, then OSF/1, then DCE (It was a very small department, and I introduced each new technology). Maintenance programming is usually kind of yuck, and at the time I had a impressive job as an IBM mainframe 'online programmer' doing TSO user interface programming in PL/1 with ISPF and DB2; doing design and implementation work. This was a top of the line dream job for what I trained to do in the mid 80's. Most mainframe programming was batch-oriented druggery. But the OSF job was unique---I got access to the Internet with a 56K (a big pipe in those days---through another 56K to Dec, we were an internet backbone backup for Nearnet). Anyway what really made it worthwhile was that I got access to Unix SysVr2,r3,r4, AIX, BSD etc source code, which was a special thing in those days. So skipping foward, I became friends with IT folks, and I fixed bugs, wrote tests, and assisted OSF member companies like Dec to get OSF/1 and Motif updates and patches and other miscellaneous things. Occasionally, I had to make tapes to send to vendors. So, one night, I was making a tape for something. It was 9 track tape, which was made on our Vax. We had no access control to the computer room in those days. People made their own tapes and stuff at OSF in those days. We had operators, but they just did backups. There was a big sign on the console that said don't type ctrl-e (if I recall), because that started the monitor, like L1-A on a sparc. So, while the tape was running, I was bored, and leaned up against one of the Vax disk drives. These were the size of refrigerator, about 5 feet tall by 3 feet wide. There was a long row of them. Each drive cabinet had 3 buttons, about 1in square each. I accidentally leaned on the power button, and immediately heard the declining whir of the big platters spinning down, and my stomach quickly matched the sinking pitch. Oops. I went right to the console, which was unresponsive. Crap doesn't quite do it. Kids today probably can't appreciate the feeling of total work stoppage that a multiuser computer caused in those days. There would be people in Japan and California using that computer. So, I called a friend of mine, an IT guy, at home (pre-cellphone) and said Mark, I did a bad thing, and explained what happened. He said Dean, tonight you get to learn how to boot a vax 8550. After that, I was on the root password update list, and gradually became sucked into IT and networking. The moral is, Its not what you do wrong, its what you do after you screw up that really makes the difference for IT. I also have a good IT story about Jeff Schiller and X Window from about 1987 or 1988. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt (fwd)
On Tue, 2 Oct 2007, John Kristoff wrote: On Tue, 2 Oct 2007 21:59:33 -0400 (EDT) Dean Anderson [EMAIL PROTECTED] wrote: In fact, using authority servers is _less_ risk to the abuser, because to compose the reflector attacks, s/he has to crack into a server, craft a record, One can create a large record anwhere in the namespace. There are many free DNS services available. If for some reason that won't work, miscreants can and routinely do, use fraudulent financial credentials to purchase DNS, hosting, or whatever they need elsewhere. If that won't work, were you aware that there are numerous providers who for one reason or other either cater to miscreants or will tolerate it to the point that their only response is to simply terminate the harmful service after a litany of complaints and the damage has been done? These all leave forensic trails. and search 3.7 million IP addresses for a list of reflectors. That is less than a /8. Piece of cake. It can be done with hardly any effort and in almost no time at all. No? All of these things leave a forensic trail. Not in the real world. Yes. In the real world. You are merely failing to distinguish the mere miscreant that doesn't merit investigation with the genuine criminal that does. You assume that because your miscreants aren't caught, that it is because it isn't possible to find them. In fact, it is __your__ powers that are limited, not the powers of the government to find real criminals. As I've told you before, in practice this just isn't an issue for a miscreant. Hardly anyone is logging or noticing valid, even repeated queries, TXT or otherwise, that land in their address space. Yes, actually people are making such logs. That they don't use those logs to track your mere annoyance doesn't mean those logs aren't there. Do you have a forensic trail of the queries I sent to your address space and servers? I can confirm the timestamps and source addresses offlist if you'd like. Could be in logs. I don't have any inclination to look. But I have noticed strange activity from ultradns before. Any one of which might lead back to the bad guy. Probably not. You think the bad guy is running probes from his home computer? Doesn't matter. Perhaps you recall the 'great northeast power failure' a few years ago. It coincided with a virus release, and briefly, it was thought the virus was responsible. The virus wasn't responsible, but the suspicion caused the various LEAs to get the 14 year responsible for the virus. It took about 3 days to get the kid, which includes the time to become suspicious of the virus, and then begin to find it. At great effort, a DNS researcher has compiled a list of about 2 open recursors by brute force search of 3.7 billion IP addressses. That does sound pretty sad. My experience doesn't echo that at all. What effort and what researcher are you referring to? And give you a list of 2 open recursors? I think not. I have built a tool. I have run it. And I have detected anycast open recursors. Is the tool, the data, a presentation or paper in a peer-reviewed journal available? Not yet. The tool and the data will be published soon. Yes, I know that 90% was a example. But the 97% was a statistic from a real (optimistic) paper on HTTP anycast presented by a proponent on Nanog. 3% loss is unacceptable performance for root and tld nameservers. As far as I know, that was a presentation by a some folks who were sharing their operational experience with TCP and anycast. Not a formal refereed paper. Do you have a pointer to a paper? A paper presented to a professional organization, as Nanog claims to be, is indeed a professional paper, subject to professional standards. Peer-review is just an assurance that those standards were actually met. I don't know for sure whether Nanog does peer-review, though, it seems to have a committee that does that. http://www.nanog.org/mtg-0606/pdf/matt.levine.pdf -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt (fwd)
On Wed, 3 Oct 2007, bill fumerola wrote: On Wed, Oct 03, 2007 at 12:33:09PM -0400, Dean Anderson wrote: No, that isn't anycast. A loadbalancer is actually a stateful NAT with several different hosts behind the load balancing NAT. Those loadbalancer devices you buy from cisco and other companies are specialized NAT boxes. The servers behind the load balancer have all have different ip addresses. The loadbalancer makes it appear they servers share the same address through stateful address translation techniques. not all load balancers work the same. I agree. However, there aren't any load balancer devices that are implemented with Anycast. A make and model number, if you know of one. direct server return aka one-arm load balancing does no translation or rewrite of any headers (l3 or l4). all it does is make a switching decision based on health check and other weighting criteria. Header rewriting? as in http header rewriting? That isn't anycast either. i'll leave the annals of IETF archives as sufficient documentation about how wrong you are about anycast. Hey, we agree! I'm good with that. They never have to play hardball with the whistleblowers who were in fact, wrong. as for load balancers, just because some of them perform NAT in some configurations does not mean that load balancer = NAT. I agree with that, too. Especially if you broaden the notion to http load balancing schemes. However, I've never heard of any load balancer device that uses Anycast, as Brian Hickson asserted. But none of this is relevant to the claims that Hickson made. And Hickson's dispute isn't relevant to anything about reflector attacks. You apparently digress. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP
On Fri, 28 Sep 2007, Paul Wouters wrote: On Fri, 28 Sep 2007, Dean Anderson wrote: Maybe its not mentioned because its not a practical solution. But whatever the reason it isn't mentioned, a 25 million user VPN is not going to happen with 10/8. A comcast person recently complained on PPML that there wasn't enough RFC1918 space for their internal network. Time for them to migrate to IPv6? :) There was an extended discussion of that. It was suggested that IPv6 would be killed by IPv4 IP address exhaustion through route table expansion. I suggested that maybe IPv6 was already dead, and that one might consider instead CLNP/TUBA (RFC1347, RFC1561, et al) because it works already. One would use ISIS and IDRP instead of OSPF and BGP. Then add IPv4 proxy gateways and client support as necessary, etc. I was surprised to find that this is about as much work as what remains for IPv6, and we know that CLNP is stable. I digress. I wrote a detailed message posted on 9/10 on the subject if anyone is interested. Contact me offlist, or look in the ppml archives at arin.net. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: comparison of drafts: was Re: [DNSOP] Confirmation of Chicago decision on draft-anderson-reverse-dns-status
This has developed into a debate on the merits of Sullivan's document draft-dnsop-reverse-mapping-considerations and my (Anderson's) document draft-anderson-reverse-dns-status. Inline: On Fri, 17 Aug 2007, Andrew Sullivan wrote: I have read Dean's comments, and I believe they reveal that Dean and I have fundamentally different ideas about reasoning and knowlege. That much is clear. I (Anderson) follow the scientific method. This is the mainstream view of civilization for the pursuit of science and engineering. My view is that there are vast areas of human experience in which knowledge is not well-defined as justified true belief. This is all well and good for religion and politics. It is not the case for scientific inquiry and engineering. In the fields of science and engineering, we are concerned with facts and reasoning. I believe that I am in the mainstream of contemporary epistemology in this view. Unless you consider the mainstream to be represented by intelligent design, you are not in the mainstream. And this view is what underpins my critique of the proposed -anderson- draft: I think it too often dresses up as certain truth propositions about which competent practitioners of the art sometimes disagree. Competency is the ability to give facts. Credibility relates to the veracity or truth of the facts given. Telecom, like most industries, is organized into science, engineering, and craft. Skills and competency as a craftsman do not always translate into skills and competency as an engineer, particularly when that person doesn't accept the scientific method as the means of conducting science and engineering, and proposes to replace the analysis of facts and logic by nothing but fervent belief. If the argument isn't based in fact and reason, then it is hard to consider one making such irrational argument as a competent and credible practitioner of any subject that is categorized as 'science and engineering'. Indeed, certainly they are not a credible practitioner of science and engineering. Regardless of their title as engineer, they are not performing or producing anything that could be categorized as 'science and engineering'. The only objections to the statements of fact in my (Anderson's) document have been of 'fervent opinion', not contrary fact. In contrast, Sullivan's document is marked by false claims made vague and ambiguous. I think that competent practitioners can disagree, and that a document that purports to offer advice about current practices should outline how those disagreements might have practical effects. Competent practitioner's can't disagree without evidence and facts supporting their views. Fervent belief is not a competent or credible basis for disagreement. The label of Opinion only applies to those things which _can't_ be proven true or false. Offering up views as 'opinion' which have been proven false is not something a competent, credible engineer would ever do. Offering up as 'fact' claims which haven't been proven true is also something that a competent, credible engineer wouldn't do. Competent and credible practitioner's can certainly disagree about speculation, opinion, and even facts. Disagreement often spurs further inquiry. However, they can't substitute opinion and fervent belief for fact, and they can't dismiss objections to their unsubstantiated claims as mere disagreement. I believe there is a current working group document on reverse mapping that offers exactly such an outline. Sullivan's document offers views that aren't based in fact, and obscures facts known to be true and claims known to be false; causing a reasonable, but uninformed person to impute as fact things that actually aren't fact, but are even known to be false. Sullivan's document misleads readers. I do, however, have to take special issue with one claim Dean Anderson makes, because it's a particularly pernicious form of scientism, and one that I think must not be left unchallenged. Actually, assertions about scientific and judicial reasoning are exactly what make up a valid argument. A valid argument is merely an argument whose premises, if true, would entail the conclusion. This statement is true of the logic of the argument. The argument is logically valid when the premises, if true, would entail the conclusion. The validity of an argument is classically entirely unrelated to the truth of its premises or conclusion. For instance: The classically has nothing to do with it. It isn't the case that 'once we used logic, and now we don't.' You are confusing logical validity with soundness. Let me give you some definitions, from a course I took in Logical Analysis by Dr. Leroy Meyer. Valid Argument: Premises imply the conclusions Sound Argument: Valid with actually true premises. An unsound argument is a kind of fallacy. I have no idea whether the conclusion or any premise is true, because I don't know what gerwuffle and blort
Re: [DNSOP] Confirmation of Chicago decision on draft-anderson-reverse-dns-status
On Tue, 7 Aug 2007, Andrew Sullivan wrote: Dear colleagues, On Mon, Aug 06, 2007 at 04:33:18PM -0400, Dean Anderson wrote: Would it be too much to ask the 12 people who read the draft, what problems they have with the draft? What changes would be necessary to obtain support? hat=none I have read the draft. Dean, do you solicit my feedback as to what changes would be necessary to obtain my (individual) support? If so, I will send those remarks. /hat Yes, thanks. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS pinning, anti-pinning and rebinding in DNSOP?
This attack is at once more nefarious and less nefarious than article documents. It is more nefarious because many 'single site' schemes based on DNS trust *.somedomain.tld as IP resources belonging to somedomain.tld. You don't have to rebind even. The site www.attacker.com gives a script that accesses www1.attacker.com, and www1.attacker.com has internal ip addresses. This is just another in a series of mistaken assumptions made about DNS, and (mis) using DNS for trust purposes. In this case, the trust that the same name resolves to (essentially) the same site is misplaced. I think the correct solution for browsers is not to open additional connections based on requests from external scripts, but to hold open the original connection. External scripts should not be long lived, and not longer than the original connection. If the script should live longer, the original IP address should be used for connection, not the DNS entry. The external script has no business outlasting the external web server. Cross Site Scripting is a serious and tough problem, and DNS rebinding is a very small part of it. But the core of both problems is misplaced assumptions of trust. The difficulty with XSS is that the malicous code has access to the document model, and can alter other scripts, access other fields, and do quite a lot. Infection is not just limited to visiting a suspicious web site. The malicious code can be placed in your own database, or some other sites database, and output to your browser. It can be placed in pdfs, in anything that does javascript. And the malicious code doesn't even have to exploit vulnerabilities in the local javascript interpreter to steal passwords and other confidential information (though, that's also possible). I've been saying this for many years: Depending on DNS to determine trust questions is always going fail or, as in this case, introduce vulnerabilities. This isn't a protocol problem or DNS operations problem. Btw, 1-to-1 reverse DNS also won't prevent this attack. it should be quite easy for such a script to spoof the reverse DNS response to the browser, since it knows the timing of the request, and can see if the response is the one wanted. So it can lather, rinse, repeat with the known timing and other information to get the desired response to the browser. And spoofing may not be the only target of the 'lather, rinse, repeat' process. DDOS is another possiblity. Indeed, the possibilities are limitless. --Dean On Wed, 8 Aug 2007, Stephane Bortzmeyer wrote: I'm afraid that we will be sollicited one day or the other to write a RFC about DNS practices to limit rebinding? It seems trendy. Do note that many advices in Protecting Browsers from DNS Rebinding Attacks (http://crypto.stanford.edu/dns/dns-rebinding.pdf) belong in our perimeter (some remind me of draft-ietf-dnsop-reverse-mapping-considerations, some ask for a violation of the DNS protocol). Advices? ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comment to ns-communication-00
On Mon, 23 Jul 2007, Harald Tveit Alvestrand wrote: I'm sorry, but I do not understand in what context is 277 operations per second a large number? AFAIK, a REFRESH operations (for no zone change) is a lightweight operation. Its a fairly high number of transactions per second for DNS servers backed by databases. Especially when you suppose that is just the zone checking, and not actual queries for the real content records. The content queries (that is, the A records, etc guts in the zones that people want) would raise the TPS by orders of magnitude. The zone checking would still be a (relatively) small number compared to everything else. However, a million authority zones on a single server is probably also unrealisticly high. No one has that many zones on one server. I'm somewhat dubious of the claim that there are 50,000 zones on a single server. 50,000 zones in one hosting provider doesn't surpise me. Of course, if they use something like powerDNS with database backing, all zones _can_ appear on every server. But it would seem a poor idea to do that, at some point. Database backed systems have the advantage that they don't need to do zone transfers, but can use database replication behind the scenes. I've even seen people put cache data in databases. I found this while searching for anycast recursive servers. [yes, that also means that anycast clones can be detected, meaning stateful anycast isn't stable, since if TCP detects two servers with the same IP address, the connection fails.] Anyone who did have a million zones, I think, wouldn't have it on a single server. Or, if they did, would have some better way to improve their transaction rates. I can think of a few ways, but none that require protocol changes. I'll have to look into this draft more closely. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Request for IETF69 DNSOP Agenda Items
I would like to have the WG discuss taking up my draft (draft-anderson-reverse-dns-status) as a WG document. Thanks, --Dean On Wed, 4 Jul 2007, Peter Koch wrote: Dear WG, dnsop will meet in Chicago during the Tuesday morning slot (09:00 - 11:30), see https://datatracker.ietf.org/meeting/69/agenda.html. Please submit requests for agenda slots to Rob and me. An agenda outline is available at http://www3.ietf.org/proceedings/07jul/agenda/dnsop.txt. The agenda will grow there and a draft will be posted to this list next Wednesday, 2007-07-11. Thanks, Peter ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adopt draft-koch-dnsop-resolver-priming as WG work item?
On Thu, 14 Jun 2007, Alan Barrett wrote: On Wed, 13 Jun 2007, Dean Anderson wrote: There has been no technical discussion of Moreau's proposal. There had been no technical discussion on May 10th, when Austein offficially directed the authors to disregard the proposal. I see only one message from Rob Austein dated 10 May 2007. In that message he did not direct any authors to do anything. He made a prediction about his own future behaviour if there was not strong support from disinterested WG participants. Rob Austein wrote on May 10th, 2006: Absent strong support from disinterested WG participants for having Peter's draft explore M. Moreau's putatively encumbered idea, I will direct Peter to decline M. Moreau's suggestion, at least until M. Moreau has filed his IPR statement and it is possible for a disinterested person to reach an independent opinion on the extent, relevance, and validity of M. Moreau's IPR claims. If you mean this text from Austein's May 10th, message, then there is a element of future tense about it. However, Jeff Schiller has outlined the conditions for such direction: The inability of a working group to make a decision. By contrast, Austein's condition is absent strong support. Austein's direction is inappropriate in both the future and past, so the tense is irrelevant. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adopt draft-koch-dnsop-resolver-priming as WG work item?
There has been no technical discussion of Moreau's proposal. There had been no technical discussion on May 10th, when Austein offficially directed the authors to disregard the proposal. All of the opposition has been FUD and false claims. I have a longer report in progress detailing these issues. I am inclined to be concerned about the FUD and irregularity opposing Moreau's proposal, and I think the proposal therefore deserves greater attention. As a general rule, its my experience that bad ideas have obvious technical problems, while good ideas cannot be so opposed, and so are opposed by FUD and process irregularities. I'd say the odds are that Moreau has a good idea. Mr. Moreau, in his first message of April 30th, disclosed his patent and offered free, universal, and unlimited terms [though I must qualify this, as we haven't yet seen the actual license. It may yet turn out to not actually be as good as it sounds now.] Speaking as President of the LPF and as an ISOC member, there can be no better patent terms than free, universal, and unlimited. I applaud his license terms, and his immediate disclosure and forthright approach. Some people, offlist, have suggested to me that it is Mr. Moreau who has acted unethically. Mr. Moreau has not acted unethically, but his actions in this particular subject have been exemplary. I also note the people who raised patent issues recently aren't usually anti-patent advocates; most of them have participated in (at least two incidents that I know of) discussions in which they either supported drafts with patents with onerous terms, or were not opposed to non-disclosure of patents in drafts, or were opposed to RFC3979 anti-patent provisions. Or they've explicitly told me they supported software patents. Most/all of what they stated was incorrect or FUD. [incorrect/FUD, btw, does not promote an anti-patent agenda. Facts promote an anti-patent agenda. The pro-patent opposition would quickly discredit FUD. Some facts can be found at http://lpf.ai.mit.edu or http://progfree.org]. While I'm always pleased to have new converts to the LPF cause, I am uncertain if their opinions represent a change of view or just convenient ammunition. Particularly, I would like to say that non-participation in the IETF (or W3C, etc) does not prevent patents. Only __publication__ prevents patents. The law [in the U.S. and most countries] strongly encourages patents and strongly disadvantages those without patents. [That is one reason the law must be changed.] We (the LPF) do not expect people not to get patents. We encourage people to __publish__ rather than patent, but we understand that this isn't always possible. The LPF works to educate people so that the patent laws will get changed. People with patents are urged to forgo using patents for profit, and to make those patents free with a free, universal, and unlimited license. Those that do, like Mr. Moreau, are applauded. --Dean On Wed, 13 Jun 2007, Rob Austein wrote: At Tue, 12 Jun 2007 20:47:57 -0400, Thierry Moreau wrote: Now that the draft-koch-dnsop-resolver-priming is adopted as as WG work item, and that an IPR disclosure has been filed [2], I would request Rob to revisit his (premature) directive regarding this work [3], and retract it. Thanks for looking into this. hat wg-chair=on To date I have seen no support for M. Moreau's suggestion from anyone other than M. Moreau, nor have I seen anyone other than M. Moreau disagree with my analysis that his suggestion is only peripherally related to the topic of Peter's draft. If anyone other than M. Moreau -does- wish to see Peter's draft incorporate M. Moreau's suggestion, please say so, and state: a) Why you think that the topic belongs in this draft, and b) Whether M. Moreau's IPR disclosure addressess whatever concerns (if any) you might have with respect to the IPR issues related to M. Moreau's suggestion (if you have no IPR concerns, say so). /hat ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adopt draft-koch-dnsop-resolver-priming as WG work item?
On Tue, 12 Jun 2007, Alan Barrett wrote: On Mon, 11 Jun 2007, Dean Anderson wrote: There is an appearance of impropriety because Austein is on both sides of the transaction: For ISC and also for IETF DNSOP WG. What transaction are you referring to? Please be specific. I was not aware of any exchange of services, money, patents, trademarks, or anything else, between ISC and the DNSOP working group. The transaction here is the business before the WG. In this WG business, ISC (includes Austein) opposes an addition to the draft (one side), and ISC (Austein) is directing WG decisions to reject the addition to the draft (the other side). The ethics of the transaction is independent of the value of the transaction. The issue of transaction value and fairness of the value would be the subject of a claim seeking restitution of a fraud. I don't have any opinion on whether fraud has actually occurred and I don't know that fraud has occurred. Often, the details establishing a value and fairness are discovered as a result of investigation of the ethical issue. I'm working on a longer analysis of the issues and the dispute. I'll put this on the web, but I haven't decided a URL yet. There are some curious and interesting things in the dispute. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adopt draft-koch-dnsop-resolver-priming as WG work item?
On Tue, 12 Jun 2007, Andrew Sullivan wrote: Which brings me to my second problem. As nearly as I can tell, there are no clear conflict of interest guidelines for working groups in general, and the IETF has previously concluded that such a state of affairs is a good thing. I don't know where or when the IETF concluded that self-dealing was a good thing. Maybe you could post that RFC. One doesn't need explicit conflict of interest guidelines to know that self-dealing is unethical. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adopt draft-koch-dnsop-resolver-priming as WG work item?
On Mon, 11 Jun 2007, Paul Vixie wrote: Austein needs to avoid participating in issues that affect his company, its financial position, or that of his co-workers. Should Rob recuse himself from *any* matter that Paul's sent an email about? What about opinions Paul may have discussed with Rob privately? Or just things he's vaguely thought about, without saying anything? I didn't see the whole message with the above comment in it, so I don't know who said it or what else they said. However: Rob should avoid discussing DNSOP issues with ISC. ISC people should take up their DNSOP issues with the non-conflicted co-chair. If they don't, Rob should inform them of his conflict of interest, and direct them to discuss the matter with someone who isn't conflicted. In the case where both co-chairs are conflicted, that conflict should be unmistakeably disclosed to the WG and discussed carefully and with the guidance of the disinterested Area Director or disinterested IESG members. i'm left wondering how TAKREM could affect isc's finances, or the finances of any of rob's coworkers. is it possible for isc to make less money from DNS software than what we already don't make? These aren't the question at issue, unless someone asserts actual fraud. The ethical question is whether ISC's interests are different from those of the IETF DNSOP WG. The answer is: Yes. So a conflict of interest exists. There is a difference between appearance of self-dealing and actual fraud. There is an appearance of impropriety because Austein is on both sides of the transaction: For ISC and also for IETF DNSOP WG. Austein appears to be self-dealing. That mere __appearance__ is evidence of an ethical deficit. Whether ISC benefited more, or whether IETF benefited more, or whether the transaction was actually fair is irrelevant to the question of __appearance__ and self-dealing. Actual unfairness justifies the assertion of actual fraud. The mere appearance of self-dealing is merely unethical. It is Austein who promoted the appearance by failing to recuse himself from issues in which he is conflicted. Austein should know better than to be on both sides of a transaction, and should have avoided that. i think it's time to declare troll alert! and move on. I'm sure you do want to ignore the issue. A common clue or hint of a unethical activity is the unwillingness to discuss ethics. Unethical people hate ethics. Dislike of ethics isn't a necessary and sufficient condition for concluding unethical behavior but, in my experience, has been a common, co-incident feature with unethical behavior. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adopt draft-koch-dnsop-resolver-priming as WG work item?
I have asked the IESG and the ISOC Attorney to intervene in this matter, informally. What Olafur says below is just complete nonsense. I also make a living, consult to companies that seek patents, and serve a non-profit anti-patent organization. My company also does IT consulting to companies that we provide Internet Service to. (IT usually selects the ISP). These occasionally lead to conflicts of interest, and I avoid being on both sides of transaction by defering to others when I have a conflict of interest and by proper disclosure. Nearly everyone who volunteers or works for several organizations will find themselves in a conflict position at one time or another. Tens of thousands of people do the right thing every day. It is never impossible to act ethically, and ethical standards do not cut down on the number of volunteers to non-profit organizations. There are no conspiracy theories. There is a fact that Rob Austein is on both sides of the transaction, and there is a fact that Austein hasn't recused. Austein's name is where it is only because Austein is on both sides of a transaction, and Austein knew he was on both sides, and Austein didn't do the right thing. It's that simple. --Dean On Mon, 11 Jun 2007, Olafur Gudmundsson wrote: This is getting silly, where Rob works, who Rob works with, who Rob talks to, are all irrelevant. Rob is a co-chair of the working group and serves at the pleasure of the AD, he can be terminated at any moment, if he engages in anything that the AD perceives as un-professional, un-ethical or just does not like something about Rob. Lets stop discussing possible conspiracy theories and stick to facts. It would be impossible to fill all IETF WG chair and/or AD slots if none of them worked for (or had stock in) a company that could possibly gain something by the work produced in a working they chair/oversee. In that world no one from Cisco could be a chair of any IETF working group, just to take one example. Dean, if you or anyone has problem with anyone's actions as CHAIR of any IETF working group: step zero: bring it to the WG attention step one: ask the co-chair to intervene step two: if that fails complain to the AD. step three: if that fails complain to the IESG step four: if that fails complain to the IAB Disclaimer: I have been a victim of allegations similar to this one in the past so I feel Rob's pain and agony of having his name dragged into the mud for no reason other than trying to make a living and at the same time give back to the community by serving as a volunteer in a job that does not get many thanks. For the record: Rob and Peter you are doing fine job and I see no problem with your associations or actions. Dean, You have made important contributions in the past, but people would listen more closely to you if your volume of mail was less and you restricted your commentary to technical points. Paul, I feel your pain too and applaud your well reasoned polite response. Olafur At 15:53 11/06/2007, Dean Anderson wrote: On Mon, 11 Jun 2007, Paul Vixie wrote: Austein needs to avoid participating in issues that affect his company, its financial position, or that of his co-workers. Should Rob recuse himself from *any* matter that Paul's sent an email about? What about opinions Paul may have discussed with Rob privately? Or just things he's vaguely thought about, without saying anything? I didn't see the whole message with the above comment in it, so I don't know who said it or what else they said. However: Rob should avoid discussing DNSOP issues with ISC. ISC people should take up their DNSOP issues with the non-conflicted co-chair. If they don't, Rob should inform them of his conflict of interest, and direct them to discuss the matter with someone who isn't conflicted. In the case where both co-chairs are conflicted, that conflict should be unmistakeably disclosed to the WG and discussed carefully and with the guidance of the disinterested Area Director or disinterested IESG members. i'm left wondering how TAKREM could affect isc's finances, or the finances of any of rob's coworkers. is it possible for isc to make less money from DNS software than what we already don't make? These aren't the question at issue, unless someone asserts actual fraud. The ethical question is whether ISC's interests are different from those of the IETF DNSOP WG. The answer is: Yes. So a conflict of interest exists. There is a difference between appearance of self-dealing and actual fraud. There is an appearance of impropriety because Austein is on both sides of the transaction: For ISC and also for IETF DNSOP WG. Austein appears to be self-dealing. That mere __appearance__ is evidence of an ethical deficit. Whether ISC benefited more
Re: [DNSOP] comment on reverse-mapping-considerations-03.txt
Ed, having reviewed the document, can you assure us that it doesn't contain any language that might be understood as implying that reverse DNS records are somehow required? Can you assure us that it doesn't contain any language that might be understood as implying that using reverse DNS for security is anything but a crock'? (as Ted Lemon wrote) Can you assure us that Mr. Sullivan, despite his advocacy of making in-addr required, despite his advocacy of using reverse DNS for security, and despite his advocacy of irrational decision-making processes (cf discussion on DNSOP February March '07), hasn't used this draft as a platform to obtain an the IETF RFC credential to promote discredited practices and thereby mislead people about reverse DNS? --Dean On Fri, 8 Jun 2007, Edward Lewis wrote: http://ietf.org/internet-drafts/draft-ietf-dnsop-reverse-mapping-considerations-03.txt Filename : draft-ietf-dnsop-reverse-mapping-considerations-03.txt I would change the wording from this #3.1 Examples of effects of missing reverse mapping # # Following are some examples of some of the uses to which reverse to this #3.1 Examples of effects of missing reverse mapping # # Following are some examples of uses to which reverse That's the only comment I have on the draft. The one change I have is only wording (some used twice in the same sentence) - nothing of substance and certainly a change I could live without seeing made. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
[DNSOP] Copies of Drafts for draft-ietf-dnsop-inaddr-required?
The datatracker doesn't have these drafts. (why not?) Does anyone have copies of each draft? I'm trying to chart the draft claims and the discussions and disputes, so that I can easily respond to assertions regarding the current incarnation of this draft. Thanks, --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Proposed text for reverse-mapping-considerations draft
I urge people to support my draft (draft-anderson-reverse-dns-status). My draft encourages Reverse DNS, improves understanding of Reverse DNS, informs about discredited practices, and recommends good practices. My draft accomplishes the purpose charted by the WG much better than the Sullivan draft and doesn't have any of the drawbacks of Sullivan's draft. Inline On Tue, 5 Jun 2007, Andrew Sullivan wrote: I believe you suggested that your draft should be considered entirely alternate text. That is not a modification of the text, it is a wholesale replacement; and a replacement that engages (as I already noted in my comments to you) a somewhat different set of topics than the reverse-mapping-considerations draft. I (Anderson) copied some text from Sullivan's draft, and rewrote those parts that were wrong, and I included some information about Reverse DNS that was informative. So my draft really just has an entirely different editor. My draft engages in the topic that the working group decided to work on: Encouraging Reverse DNS. I agree Sullivan's draft has a slightly different set of topics that deviates from the topic of Encouraging DNS IN-ADDR as charted by the WG. based on extended and repeated experiences, that your goal is to mislead people about specific uses of reverse DNS, while simultaneously trying to convince critics of the draft that their concerns have been addressed and that discredited claims have been removed. To be clear: that is not my goal. That leaves a lack of writing skills as the cause of the problems. But there is a element of willfulness over the repeated experiences that can't be entirely ignored. But I do agree we are not here to teach writing skills; Just to diagnose the problem that prevents effective writing of the draft and correct that problem. Once we conclude there is a problem, we don't need to further investigate the root causes of the problem. I'm also not entirely sure what motivation has to do with the result, which is supposed to be a text that stands on its own. If I didn't know better, I would imagine you to be attempting to impugn my character instead of addressing the text. I'm disputing Sullivan's abilities and disposition to correctly report facts, statements, and opinions of others. Those abilities are relevant and requisite skills for the task of editing this draft. The group has repeatedly rejected the claims in the draft that you just edited once it is detailed how the draft supports discredited claims. I am not sure what your evidence is for this claim (especially since we have seen precisely one response so far to the -03 draft, and a number of responses this year suggesting broad agreement with the -02 draft). If you wish to press that claim, I would urge you to point me to the mailing list messages that support your view. I think Mr. Sullivan well knows the history of this draft from its previous incarnation as the draft-ietf-dnsop-inaddr-required, and Sullivan knows that the version number was reset when the draft was renamed and re-submitted under the new name. Sullivan knows that the name was changed to address concerns about the implication of the name, even after explicit calls to 'require in-addr' were supposedly removed from the draft. Sullivan knows that the WG didn't support that the notion that inaddr was required, nor did it support any other discredited notions. So Mr. Sullivan knows the past claims that were very explicitly rejected. This is yet another example of a failure to report accurately. Indeed, The history of the in-addr draft dates back to 2000: Robert Elz stated it best (7 years ago and still relevant): 8/13/2000 http://www1.ietf.org/mail-archive/web/dnsop/current/msg00544.html Sorry people, this draft is a total waste of time. I'm an absolute supporter of properly running in-addr.arpa domains, and if someone wanted to write an RFC to explain to people what they're useful for, and why the data needs to be maintained, that would be fine. For 7 years, we've had the same argument, as advocates try to mislead people about the contents of the draft, and people (such as myself, Elz, and a host of others) have picked up each new draft to find essentially the same set of discredited claims. So, I finally wrote a draft that says the right things. BTW, these same 'broad statements of support' for the purposes of Sullivan's draft, (similar to Elz's quoted above) can also be considered to support the statements in my draft as well: People support status and encouragement of Reverse DNS. People don't support the claims that either depend on false assumptions, discredited practices, or require in-addr.arpa. Indeed, a serious problem is that people don't understand that they have been misled about the contents of Sullivan's draft; instead people, (rather like Elz in 2000, support honest information; to the extent they have been misled, people think Sullivan et al
Re: [DNSOP] Proposed text for reverse-mapping-considerations draft
On Fri, 1 Jun 2007, Andrew Sullivan wrote: Hello Dean, On Fri, Jun 01, 2007 at 12:07:48AM -0400, Dean Anderson wrote: On Thu, 31 May 2007, Andrew Sullivan wrote: The popular TCP Wrapper package was originally conceived to discover the network location of an attacker [Venema1992]. No. Early TCP wrappers just provided logs of activity, and then later to provide access control. You may have overlooked the sentence in the paper that says, I decided, however, that it would be more productive to maintain the service and to find out where the finger requests were coming from. No; I looked further into the context of that statement, and I cited that context to you in my previous message: The purpose of the TCP Wrappers tool was to provide _logs_ for programs which didn't produce logs and for which source code wasn't available. I showed you the logs produced by the tool which were given as examples in the paper. My draft also points out the flaw of using Reverse DNS for logging, and so the 1992 TCP-wrappers' tool is discredited in that regard. This is a major difference between our drafts: Your draft presents discredited practices as credulous, while I provide the full context, including the fact that these practices were discredited. What you regard as a myth others regard as a useful clue. A myth is something which isn't true. False claims can certainly be useful clues, but only to identify those other dependent ideas that also aren't true. But I think the history of the Venema paper is probably important, and I'm going to add it to my draft, as well. Thanks for the suggestion. That was a very good item. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Proposed text for reverse-mapping-considerations draft
On Thu, 31 May 2007, Andrew Sullivan wrote: The popular TCP Wrapper package was originally conceived to discover the network location of an attacker [Venema1992]. It used the reverse mapping of a connecting host to provide the hostname of that host in its output. No. Early TCP wrappers just provided logs of activity, and then later to provide access control. This paper presents a simple tool to monitor and control incoming network traffic. [...] Services such as finger do not require a password, and almost never keep a record of their use. That explains why all his fingering activity had remained unnoticed. Access control: 5. First extension: access control. [...] /etc/hosts.deny: ALL: terminus.lcs.mit.edu hilltop.rutgers.edu monk.rutgers.edu ALL: comserv.princeton.edu lewis-sri-gw.army.mil ALL: ruut.cc.ruu.nl 131.211.112.44 ALL: tip-gsbi.stanford.edu ALL: tip-quada.stanford.edu ALL: s101-x25.stanford.edu ALL: tip-cdr.stanford.edu ALL: tip-cromemaa.stanford.edu ALL: tip-cromembb.stanford.edu ALL: tip-forsythe.stanford.edu TCP Wrappers did do access control based on reverse DNS, but that was soon discovered to be insecure. I note that the original 1992 didn't know that: oProtection against hosts that pretend to have someone elses name (name server spoofing). This is important for network services such as rsh and rlogin whose authentication scheme is based on host names. When a host name or address mismatch is detected the connec- tion is dropped even before the access-control files are consulted. The TCP wrapper program did not succeed at stopping nameserver spoofing, nor could it. The author (Venema) just didn't know enough about DNS to know that. This is the origin of the reverse DNS security myth. Years and much effort has been expended to dispel the myth, but true believers are hard to dissuade. That is a monument to something, but I don't know what. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: Fwd: [DNSOP] Re: I-D ACTION:draft-ietf-dnsop-reverse-mapping-considerations-02.txt
On Mon, 26 Mar 2007, Robert Story wrote: On Fri, 23 Mar 2007 18:39:59 -0400 (EDT) Dean wrote: DA Real anti-spam groups at large ISPs don't use reverse DNS for spam DA filtering. There have been attempts to do so in the past, but those DA ended in (sometimes well-publicized) disasters. This is patently and provably false. AOL clearly states that AOL's mail servers will reject connections from any IP address that does not have reverse DNS (a PTR record). They may claim this, but it isn't true. SpamHaus is a rather well know spam-fighting organization, and they clearly state that having reverse DNS is 'highly desirable.' [2] They have been associated with other lame ideas. DA Assuming an 'apparent inability to update reverse tree' is a false DA assumption: But you can't dictate other peoples assumptions. Assumptions are often based on ones personal experiences, and it's perfectly reasonable for different people to make different assumptions. Sorry. Wrong. Its not 'perfectly reasonable' to make false assumptions. DA The fact that the reverse tree doesn't match something the DA remote site thinks should be there, doesn't mean that the IP address DA user is unable to update the reverse. Nobody is saying that that is the case. Ted said that. What the spam-fighters are saying is based on my own experiences, more often than not a system (without reverse DNS|with a reverse DNS record matching a certain pattern) is not a valid source of mail. In some cases, they may be wrong. But its their decision to make. Its their decision to make in a free society. They are free to be unreasonable (some constraints--can't violate laws, etc). However, it is quite another thing to describe unreasonable assumptions as being scientificially honest and reasonable. DA Further, the definition of what is useful to the IP user doesn't have to DA be useful to the remote site for spam-filtering. Indeed. Neither side can force the other side to do what they want. But a mail admin is completely within their rights to say if you can't bother to provide reverse DNS, I won't accept your mail. They may be within their rights. They may not be within their rights. Laws control the situation when the admin works for an ISP. Laws also control the situation where the admin participates in a unlawful group boycott. But assuming are within their rights to be unreasonable, then they can be unreasonable. They just can't tell others that they are 'scientifically reasonable'. This is no different that a restaurant with a No shirt, no shoes, no service policy. Sorry. Wrong. Laws apply to ISPs serving the public who have a contract with their customers. However, public health policy requires no shirt, no shoes, no service. That policy has a scientific basis. The arbitrary, capricious, and unreasonable 'no reverse dns' policy has no scientific basis. DA So reverse DNS entries provide no information on which a spam-score can DA be based. This is why using reverse DNS for spam-scoring has been a DA disaster everytime it has been tried. [the proponents who say it works DA don't use it on a large scale, and don't care if a great deal non-spam, DA legitimate email is lost] I again refer you to [1], which is certainly a large scale mail system. Except that they don't practice that policy. And there is still no reasonable scientific basis for such a policy. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: Fwd: [DNSOP] Re: I-D ACTION:draft-ietf-dnsop-reverse-mapping-considerations-02.txt
On Wed, 21 Mar 2007, Ted Lemon wrote: On Mar 20, 2007, at 8:05 PM, Evan Hunt wrote: But spam fighters are a real constituency, who (so I'm told) get real and useful information from reverse DNS, and they don't seem to be very well-represented here. Spam fighters are very well represented here. However, one doesn't actually get useful information from reverse DNS for spam-scoring; The difference is, here (as opposed to say, spam-l), they have to scientifically show such views are reasonable and responsible, and they have a big problem doing either. See www.iadl.org for more information on general 'reasonable and responsible' issues. See my alternate draft at http://www.av8.net/IETF-watch/Drafts/draft-anderson-reverse-dns-status-00.txt for a report on what is actually known to be true about reverse DNS. Real anti-spam groups at large ISPs don't use reverse DNS for spam filtering. There have been attempts to do so in the past, but those ended in (sometimes well-publicized) disasters. Recently, I have been studying law and evidence. I've found a better way to explain this. As Judge Young explained in a lecture on evidence, there are three questions for experts: Do you have an opinion on this case to a reasonable certainty? What is that opinion? What are the bases for that opinion? We then question: 1) is it junk science? 2) is this a junk scientist? 3) is this junk opinion? Spam-scoring on reverse DNS is junk science. There is no scientific data showing a relationship between spam and reverse DNS maintenance. Second, society doesn't deal with the persons making such claims as experts (at least not anymore--they've been discredited), and so those making such claims aren't credible scientists. Finally, there is no scientific basis for the opinion that using reverse DNS for spam-scoring is useful. Science can't say that such tests are useful. In the original message you were responding to, I believe I said that noticing that someone can't update their reverse tree is arguably useful for spam scoring. So perhaps the reason that you aren't seeing more discussion on the part of spam assassins here is not that they aren't represented in the working group, but rather that nothing controversial was said. :') Assuming an 'apparent inability to update reverse tree' is a false assumption: The fact that the reverse tree doesn't match something the remote site thinks should be there, doesn't mean that the IP address user is unable to update the reverse. Several other cases are possible: -- The IP user may have a useful scheme that doesn't match. This may be the case if the site is multi-homed and cannot be made to match. Or there may be some other scheme used. -- It may be the IP user could update the reverse, but has made a financial decision not to do so. -- It may be the case that the ISP chooses not to provide reverse, or provides a reverse that doesn't match. -- Reverse may be autogenerated. -- matching forward entries may be autogenerated. Further, the definition of what is useful to the IP user doesn't have to be useful to the remote site for spam-filtering. So reverse DNS entries provide no information on which a spam-score can be based. This is why using reverse DNS for spam-scoring has been a disaster everytime it has been tried. [the proponents who say it works don't use it on a large scale, and don't care if a great deal non-spam, legitimate email is lost] One might as well spam-score on the phase of the moon; it has the same degree of relevance and information. Indeed, the phase of the moon is probably better then reverse DNS for spam-scoring because human behavior seems to vary a little bit with the phase of the moon, while reverse DNS maintenance has no relationship to spam whatsoever. --Dean ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
[DNSOP] Archive links not working
Can we get these links to archived messages in the old archive working again? Otherwise, we should have to repost the original messages instead of links so that they can be read in the future. Thanks, --Dean -- Forwarded message -- Date: Mon, 30 Oct 2006 02:46:53 -0500 (EST) From: Dean Anderson [EMAIL PROTECTED] To: Peter Koch [EMAIL PROTECTED] Cc: IETF DNSOP WG dnsop@lists.uoregon.edu Subject: Re: [dnsop] WGLC for draft-ietf-dnsop-reflectors-are-evil-02.txt I've reviewed the draft, and do not find it suitable for publication. I strongly oppose the draft for the reasons described in: http://darkwing.uoregon.edu/~llynch/dnsop/msg03891.html http://darkwing.uoregon.edu/~llynch/dnsop/msg03893.html http://darkwing.uoregon.edu/~llynch/dnsop/msg03902.html A great number of issues, logic flaws and false assumptions identified previously with the document, have not been addressed nor corrected. During 2 sessions of discussion, the authors made assertions for which there is no basis in fact. In the second session, the authors and proponents simply repeated claims discredited in May, as though those arguments had no prior opposition whatsoever. They just repeated a mantra, as if repeating it often and ignoring the contrary evidence somehow makes the mantra true. Documents published by the ISOC should be based on facts, not on disputed, unsupported, even illogical assertions, and should be as accurate as possible. High standards of fidelity are required. This document does not meet such standards. Documents should also have a high degree of community interest, which hasn't been seen for this document. Many of the messages and most of the support has been from persons closely associated with the authors. In my opinion, this working group should not be in the business of uncritically approving documents which cannot stand critical examination, and will, therefore, be subsequently discredited. It may take some time to discredit such a faith-based belief, especially in the face of promotion using the ISOC's credibility, but time passes, and the results are permanent. Dean Anderson Av8 Internet, Inc On Thu, 26 Oct 2006, Peter Koch wrote: Dear WG, this message initiates a working group last call for Preventing Use of Recursive Nameservers in Reflector Attacks draft-ietf-dnsop-reflectors-are-evil-02.txt to be published as a BCP. The WGLC will end Sat, 2006-11-11 23:59 UTC. Please review and comment on this draft on this mailing list. The chairs will not forward the document to the AD unless at least five reviewers have indicated their support (for both the draft and the intended status). Vendors' indication to follow (or not) the recommendation would be appreciated. Please also include editorial comments; there will be a -03 anyway since the current draft does not yet have an IANA considerations section. Given the title, the history and the purpose of this draft (remember the attacks launched at the beginning of this year?), vulnerability of other systems or server types to (becoming an accomplice in) reflection or amplification attacks and their specific counter measures is out of scope for this particular document. -Peter . dnsop resources:_ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] updated draft agenda for Prague
On Wed, 14 Mar 2007, Douglas Otis wrote: On Mar 13, 2007, at 11:00 AM, Dean Anderson wrote: On Sat, 10 Mar 2007, Douglas Otis wrote: The higher gain attacks leverage a large RR not normally found in most authoritative DNS. This assertion isn't true. Several examples were given of common large record types frequently found on authority servers. A distributed attack requires some number of servers publishing RRs large enough to pose a higher gain threat. No. Just one on a 10GigE is probably just fine. If that isn't enough, several hundred anycast root servers on high bandwidth links at key points in the internet ought to do pretty good. Several servers can be a problem, but not at the same level as with tens of thousands. There aren't tens of thousands of domains with large SPF records? Really? Some others claim SPF is widely deployed. Some from you company I think. Perhaps you should check around the office and get the 'real story' about SPF deployment. There aren't high volume servers with large records? Really. Thats amazing. Defending against a broadly distributed attack becomes more difficult. Blocking recursive servers also disrupts services for a greater number of valid recipients. This is what I said. I think you must mean blocking during an attack, in which case, one blocks queries from the 'target/victim' And so the answer to that is no: Blocking queries from a 'victim' could harm only the victim, and only if they are really a user of the recursor. You don't need to block the recursor from everything. By contrast, blocking the victim from the roots, or a large authority server could be more disruptive than the attack. My customers want to see CNN. I'm not going to block CNN because someone is blasting CNN with forged queries from my nameservers. Every open recessive server can become a proxy for the worst of the worst RR. One poorly considered RR can then be fodder for tens of thousands of open recursive servers. Blocking a problematic authoritative server at least directly affects the entity creating the problem. Perhaps this could become a self healing problem. This assumes the authority server has no legitimate purpose in creating a large DNS record. Obviously, I think, this assumption is false, and you cannot base an argument on a false assumption. Once a suitably large RR is found, open recursive servers can become tens of thousands of sources for this single RR. You have to find them first. Its much easier to find tens of thousands of large DNS records, or better, a few records on some very key high bandwidth servers. There is a neat list of 13 IP addresses that will net several hundred high bandwidth servers that 1) have large records, and 2) can't be easily blocked by the recipient. Which is harder? Finding a distribution of large RRs that greatly exceed the MTU, or finding recursive servers? You contend finding recursive servers is harder, but attacks seem to demonstrate otherwise. Yes. That is interesting, isn't it. It's clear now that a certain small group of people can find recursors more easily than the rest of the world. Funny coincidence, isn't it. Why would a DOS attacker try to search out recursors, which can be mitigated, when the attacker could launch a much more devastating attack with much less work? This has been a concern with Sender-ID of course, but in the case of open recursive servers, an attempt to mitigate open recursive attacks will also be highly disruptive as well. You contend that finding open recursive DNS is difficult, and that finding an ample distribution of large RRs is comparatively easier. Consider me to be skeptical. Further, 'closing' the recursors creates additional problems, including opportunity for additional DOS attacks. Do you mean that when a provider's DNS is taken out of service, then finding an alternative will become more difficult? I mean that many people have staticly configure DNS addresses, and when they travel to starbucks with their laptop, they won't be able to use their home servers if everyone follows this proposed draft. I mean that when you turn off recursion, you still get a referral to authority servers, which can be large, especially if the query asked it to be DNSSEC signed. Sometimes, as was noted with another previous SPF problem, the 'not recursing' is worse than the recursion. You haven't addressed any of these harms. As I said, your proposed solution is worse than the original problem. Limiting access to recursive DNS is not my proposed solution. This draft proposes limiting public access to recursive DNS. BCP38 is another solution that comes to mind, but just as with limiting access to recursive DNS, BCP38 represents a type of hygiene that works best when everyone is diligent. I agree. Of course, getting people to follow recommendations
Re: [DNSOP] updated draft agenda for Prague
to authoritative nameservers, I strongly object to this draft. Dean Anderson Av8 Internet, Inc -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] reverse-mapping-considerations: ambiguity?
On Feb 6, 2007, at 3:43 PM, Andrew Sullivan wrote: The first view is that reverse mappings provide no information of any utility whatsoever. There is no reason ever to use them except for convenience; certainly, one should never make any decisions on the basis of information included in the reverse tree. The idea here is that, because the reverse tree itself does not offer much in the way of security (and because it is relatively easy to hide bad behaviour anyway), there is no real utility in reverse mappings. Moreover, any use of them at all in making decisions about how to proceed is in fact a security hole that needs to be plugged with haste. The reverse mapping tree doesn't have any bearing on whether behavior is bad. So, it can't 'hide bad behavior'. The reverse mapping tree of Site B is specifically of 'no utility', as distinguished from 'no real utility', to administrator A for making _decisions_ about Site B. The mapping tree of Site B is only useful to Site _B_. Site B may use any reverse mapping scheme it pleases. There are many mapping schemes besides the '1:1' scheme favored by anti-spammers. Further, the '1:1' scheme isn't universally possible. The reverse mapping entry of Site B may be useful for Administrator A to _document_, but only as a secondary source in addition to the IP address, and the _documentation_ is only useful to improve subsequent communication with Site B. That's it. The second view is that the reverse tree sometimes contains information that might be useful in making decisions about a host on the Internet. It is not to be regarded as canonical information, and it should certainly never be used as a primary source of data. But it IS regarded by the draft proponents as canonical. We just heard Mr. Story exclaim just that. I think most people on the Working Group don't want to encourage persons with similar views. This draft will encourage that view. The draft wording in Section 4 is vague, but can be read to encourage that view. I've given text to disambiguate the draft, but that text was refused by the author. I think most people on the Working Group agree with the statements in my proposed text. That said, the reverse tree can sometimes be useful. Some site administrators, under certain circumstances, might legitimately use the (non-)maintenance of reverse mappings as a clue, on the basis of which they do additional processing. Exactly wrong. There is no legitimacy in such use; Mr. Story explicitly describes an example using dialup. This practice should not be encouraged or seemingly legitimized by this Working Group in the approval of this draft. In other words, the draft as written says, I think, that administrator of site A is perfectly entitled to make decisions about site B on the basis of reverse mappings, _but_, the administrator of site A is cautioned that there are plenty of pitfalls in that strategy, and they ought to be taken into consideration. I'd like to know whether people think that is a reasonable thing to say. If the answer is, No, then I'm not sure what we can say about reverse mappings at all. Administrator A is __entitled__ as I previously pointed out, to wear a tinfoil hat and tell people it protects him from aliens. However, there is no rational basis for that belief. There is a big difference between what one is entitled to do, and what one is rationally justified in doing. This working group should, per requirements of RFC2026, restrict itself to statements in drafts that are true and rational, and should reject statements that are neither true nor rational. Dean Anderson Av8 Internet, Inc -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] reverse-mapping-considerations: ambiguity?
On Tue, 6 Feb 2007 09:43:18 -0500 Andrew wrote: AS [...] In other words, the draft as written says, I think, that AS administrator of site A is perfectly entitled to make decisions about AS site B on the basis of reverse mappings, _but_, the administrator of AS site A is cautioned that there are plenty of pitfalls in that AS strategy, and they ought to be taken into consideration. AS AS I'd like to know whether people think that is a reasonable thing to AS say. If the answer is, No, then I'm not sure what we can say about AS reverse mappings at all. It is never reasonable to describe unreasonable behavior as somehow reasonable. Everyone is entitled to be unreasonable in their personal decisions; its a free society. So, in that sense, administrator A is _entitled_ to make decisions based on the reverse mappings of site B. Administrator A is also _entitled_ to wear a tinfoil hat. The entitlement to do an act does not make that act reasonable. However, it is quite another thing to say that those decisions are reasonable. Reasonable decisions are well-founded on the basis of actual facts and deductive logic. Decisions that are not based on actual facts and deductive logic are, by definition, unreasonable. There are no facts or deductions regarding security that can be properly inferred by administrator A based on the reverse mapping entries of site B. The decisions described in the draft's examples that administrator A could take on the reverse mapping entries of site B are therefore _unreasonable_. There is no way around that. You are merely confusing administrator A's _entitlement_ to make a decision with administrator's A access to actually true facts and use of deductive logic. One is entitled to be irrational, but being irrational is the opposite of being reasonable. Being reasonable _requires_ actually true facts and deductive logic. Reverse mapping entries do not provide one with actually true facts, nor do they provide one with necessary and sufficient conditions on which to base deductions about the security of site B. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] question from a newbie
I suggest you look into LOC DNS record type. Then you update the loc record for the domainname as it moves around physically. Here is a good link: http://www.ckdhr.com/dns-loc/ Alternately, I'm guessing you want to do VOIP call routing. You really need an h323 gatekeeper network to do this function. At the moment at least, H323 far excels SIP over call routing. SIP has recented added some QSIG and SS7 support, but h323 has this for about 7 years now. If you are using SIP, I suggest looking at the SIP/H323 gateway from the openh323 project at voxgratia.org (This gateway just converts call signaling, not codec formats). H323 has a steeper learning curve, but call routing is complicated business. Adapting DNS for VOIP call routing is probably a long shot, but good luck. If you go the LOC record route (pun intended;), please let me know how it works out. --Dean On Mon, 8 Jan 2007, Alok wrote: Hi, I dont know if it is fine to ask this question on an OPS list but here goes anyways: A typical connection that a customer sees is as follows: CPE/Phone---IPswitch-IPSwitch---RemoteCPE/Phone || DNS--DNS so i want to talk to remote-cpe.hisdomain.com I do a gethostbyname to get remote-cpe.hisdomain.com it returns the IP/A record however if remote CPE moves around say, remote-cpe.itspostaladdress.com is now remote-cpe.itsnewaddress.com is there a way one can give CNAME across domains more like remote-cpe.hisdomain.com IN CNAME remote-cpe.itsnewaddress.com I know DynDNS does this easily at the A level, but is this possible at the CNAME level -thanks Alok ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-ietf-dnsop-reverse-mapping-considerations-01.txt
On Thu, 4 Jan 2007, Joe Abley wrote: On 4-Jan-2007, at 13:15, Dean Anderson wrote: In general, the DNS response to a reverse map query for an address ought to reflect what is supposed to be seen at the address by the machine initiating the query. There is no exact definition of what is supposed to be seen at the address by the machine initiating the query. I'm not sure I understand why you think this is a problem. I suggest you review the (or your personal) archives of the in-addr discussion. This was all discussed. I think you participated, if memory serves. The correct answer to what is supposed to be seen is _site_ dependent. Assuming you mean the site responsible for the address concerned, then surely this presents no great problem. That is exactly the problem. To refresh and review: The debate is over the right answer given for reverse DNS queries. The position of the security/spam crowd is that no reverse anwser is wrong, and that if forward doesn't match reverse, that is also wrong. They assert that matching forward/reverse imply security and trustworthiness, at least for spam filtering. The opposing position is that any PTR answer is optional, and that there is no rule that says reverse and forward must match; that there are cases where it is convenient and useful for forward and reverse not to match. There are also very good reasons for having no reverse DNS (cost being only one), and there is no reason for considering the absence of matching forward/reverse to be insecure or untrustworthy. Further, there is no inference of security when forward/reverse do match, and the use of such an inference is itself a security _vulnerability_ that should be highlighted as a _bad_ practice rather than encouraged. PTR records are also more impractical in IPV6, certainly more expensive, and there was some talk they may even be removed altogether in favor of the HOSTINFO ICMP. [This is somewhat old, and I haven't checked this in a while--there may be an update---I'll try to look into this next week.] [NB: I rather favor the HOSTINFO ICMP approach, since the information is always there and doesn't depend on DNS which may not be available during a network outage. Network outages are when I find reverse DNS information most helpful] If I left out anything important in this short summary of a long discussion, I apologize. Hopefully, this jogs your memory. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-ietf-dnsop-reverse-mapping-considerations-01.txt
DNS to illustrate the diversity of reverse DNS provisioning. There are no valid assumptions for what should be found when one makes a PTR query. So many of the use cases you describe are based on invalid assumptions. Drafts should not contain invalid assumptions. PTR records are like a box of chocolate. You never know what you'll get --Dean Anderson (2007) [you can put that in the draft ;-)] I did discuss this at the San Diego meeting, and I note the discussion made it into the jabber notes and the minutes. I also have put all the issues into the tracker, so you could have a look at them there if you'd like. Thanks. I tried to connect to jabber at the montreal meeting, but I couldn't get any of 3 different windows clients to workI'm not a jabber user. Too bad there isn't an IRC gateway... --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
