On Thu, 11 Sep 2008, Mans Nilsson wrote:
> Subject: Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
> Date: Thu, Sep 11, 2008 at 03:39:09PM -0400 Quoting Ron Bonica ([EMAIL
> PROTECTED]):
> > Folks,
> >
> > This is a reminder that only two questions are on the table. These ar
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 otherw
On Fri, 12 Sep 2008, Roy Arends wrote:
> On Sep 10, 2008, at 9:17 PM, Ron Bonica wrote:
> In defense of publishing draft-ietf-dnsop-reflectors-are-evil I'd like
> to put forward the following article that was part of a paper I co-
> authored in 2005. I do this to show that the publication of t
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
On Thu, 11 Sep 2008, Kurt Erik Lindqvist wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> (CC trimmed)
>
> Having worked for a tier-1 provider and started two ISPs in the past,
> I am certain that BCP38 won't be universally deployed as that is
> operationally very hard and cos
g 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 ha
On Thu, 11 Sep 2008, Olaf Kolkman wrote:
> I do not have first hand experience from being under attack but I have
> seen enough arguments that reflector attacks are not only
> hypothetically possible but they also happen in real life. Not only
> from private conversations but also from, for
hile
> 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:
>
> >
&
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 b
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 t
On Tue, 9 Sep 2008, Dean Anderson wrote:
>
> > > 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 wron
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.
>
>
On Tue, 9 Sep 2008, Ron Bonica wrote:
> Bill,
>
> That why in the next paragraph I said:
>
> > If you think that you have an alternative plan for mitigating this
> > attack, you might be able to resurrect open resolvers with a new draft
> > that describes this mitigation.
>
> Also, if Dean feel
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
Anytime you discover that the facts asserted and relied on for a
document are false, or the sources of those facts and assurances
discredited, that's a "new" fact. A good example was the discovery in
TLS-AUTHZ that the assurances made by the document authors that patents
were disclosed according to
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 d
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)
-
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 t
On Wed, 3 Sep 2008, Danny McPherson wrote:
> Dean, I'm not going to argue this point by point with you, I simply
> provided data points on what folks who do this as part of their day
> job have observed and reported. You can choose to accept this, or
> not.
I choose to report on why this data is
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 se
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 uncoun
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
On Tue, 2 Sep 2008, Danny McPherson wrote:
> On Sep 2, 2008, at 9:47 AM, Joe Abley wrote:
> >>
> >> 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 whic
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 ha
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 ha
On Mon, 1 Sep 2008, David Conrad wrote:
> > This draft reminds me of the claims that open relays somehow
> > promoted spam.
> [Trademark Dean Anderson paranoiac drivel deleted]
You misuse the word paranoid. The word 'paranoid', means one has an
unjustified fear. I
On Mon, 1 Sep 2008, Paul Hoffman wrote:
> Or perhaps not. Dan's views of what facts are obvious for patents are
> irrelevant to whether or not someone would want to challenge a
> patent-holder in a costly patent fight;
One can't challenge a patent's validity merely by claiming that it is
'irr
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
auth
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
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 fragme
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 W
able to perform the check. DNSSEC
caches are cursed, either way.
--Dean
On Wed, 27 Aug 2008, Andrew Sullivan wrote:
> On Tue, Aug 26, 2008 at 05:25:44PM -0400, Dean Anderson wrote:
>
> > An actual poisoning of a non-verifing DNSSEC cache, yes. This is pretty
>
&g
On Tue, 26 Aug 2008, Ted Lemon wrote:
> On Aug 26, 2008, at 1:06 PM, Dean Anderson wrote:
> > 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?
&
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
> > ar
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 DNSSE
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 U
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
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
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 arbit
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 t
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 critic
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 (gas
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 signatu
On Thu, 21 Aug 2008, Frederico A C Neves wrote:
> On Thu, Aug 21, 2008 at 10:09:50AM -0400, Dean Anderson wrote:
> > On Tue, 19 Aug 2008, Ted Lemon wrote:
> >
> > > On Aug 19, 2008, at 8:15 PM, Dean Anderson wrote:
> > > > A verifying
> > > >
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
The claims that verifying DNSSEC caches can't be poisoned isn't true
after all.
On Tue, 19 Aug 2008, Masataka Ohta wrote:
> A property of Kaminsky's attack that it is effective against a single
> target is useful, here.
I don't know if anyone noticed, but in fact, according to RFC4035 the
deleg
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 UD
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
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
On Mon, 18 Aug 2008, bert hubert wrote:
> On Sun, Aug 17, 2008 at 11:42:39PM -0400, Dean Anderson wrote:
>
> > TCP isn't susceptible to this kind of attack at all. TCP spoofing is
>
> While this is true, it turns out the current crop of authoritative
> nameservers, in
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 th
On Mon, 18 Aug 2008, Jim Reid wrote:
> And why would these caching servers be signing anything? It's the
> master server that signs the zone.
I never said otherwise.
Ok, I agree that totally DNSSEC-oblivious servers won't be a problem for
DOS, but of course remain susceptible to poisoning even
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 sen
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.
On Fri, 15 Aug 2008, David Conrad wrote:
>
> Let me try to (hopefully) more clearly articulate my question: given
> the fact that caching servers only care about DNSSEC if they're
> explicitly configured to do so, does anyone anticipate any stability/
> security concerns to those folks who _h
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,
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 wo
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
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
People who think they don't care about DNSSEC now, should still be
concerned about any changes to root and TLD servers and should be
concerned about the consequences of those changes in the future. There
really are no changes that have zero impact.
> That is, if you don't care about DNSSEC, do
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 invulnera
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 wh
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.
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
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 i
FYI, Two people (myself and Dr. Bernstein) who have often cited the
insecurity of DNS, and this attack in particular, are currently or have
been previously blocked from namedroppers, and so can't discuss the
proper solutions to these problems. I have been following the
namedroppers discussion with
o 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
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 reso
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.
I'm not a dnssec operator, yet, either. But I think updating a flawed
document is better done sooner than later. I'm for updating it.
--Dean
On Thu, 26 Jun 2008, Paul Hoffman wrote:
> Greetings. I had a brief discussion with Olaf Kolkman about some
> deficiencies in RFC 4641, a
On Wed, 25 Jun 2008, Joe Abley wrote:
>
> On 25 Jun 2008, at 21:42, Dean Anderson wrote:
>
> > There is nothing misleading in "The ISP".
>
> Apart from the fact that it's singular, which was the basis of the
> only technical point it seemed to me th
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 connecte
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
So why deny AXFR from roots, then?
;File start: 24620
; The use of the Data contained in Verisign Inc.'s aggregated
; .com, and .net top-level domain zone files (including the checksum
; files) is subject to the restrictions described in the access Agreement
; with Verisign Inc.
. INSOA A
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
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
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 stat
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 nu
On Tue, 10 Jun 2008, Gervase Markham wrote:
> Kim Davies wrote:
> > This thread sounds remarkably like deja vu. Indeed, the TLD community was
> > rather upset a few years ago by Mozilla taking unilateral action to
> > introduce a hard-coded white-list of acceptable IDN TLDs without prior
> > consu
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
Err, lets try to keep the facts straight: not all were positive. Besides
JINMEI Tatuya, my evaluation was also very much a thumbs down.
If this document is/was approved, I will probably file an appeal with
the IESG, and a place a discrediting page on IETF-watch. If anyone wants
to join me in the a
On Tue, 8 Apr 2008, Jaap Akkerhuis wrote:
> > We investigated that situation on request and found some F-root
> > instances were receiving very high volume of queries for invalid TLD.
>
> I'm wondering why those ip's aren't distributing their queries across
> all the roots.
>
On Tue, 1 Apr 2008, Sebastian Castro wrote:
> On Tue, Apr 01, 2008 at 01:51:54PM -0400, Edward Lewis wrote:
> > At 10:35 -0700 4/1/08, Sebastian Castro Avila wrote:
> >
> > >Sorry for the late response. About this matter, using the data collected
> > >at the root server instances participating in
On Fri, 21 Mar 2008, bill fumerola wrote:
> if i felt the use of anycast by root server operators is causing
> instability, i would take that up with the individual root server
> operator(s) that i was experiencing instability with. but i'm not.
Are you using TCP DNS? Most people don't use TCP D
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,
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,
On Tue, 11 Mar 2008, Peter Koch wrote:
> Dean,
>
> > So root and gTLD DNS server operations supervision is off the charter?
>
> to the extent that is has never been there, yes.
>
> > It used to be the first item. This appears to affect ISOC IETF
> > commitments to ICANN to provide this techn
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 s
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 proces
I think it is well known that Round robin DNS load balancing is not a
guaranteed behavior. The "severe operational problems" from its
non-support are the fault of unreasonable reliance on insufficient
testing and insufficient analysis of the requirements of DNS resolvers.
I think the solution h
On Thu, 13 Dec 2007, Stephane Bortzmeyer wrote:
> directly to say that the only solution is to allow ORNS, ignoring the
> other solutions mentioned in the draft.
Instead of more tedious acronyms and jargon, how about just using 'open
recursors' to mean 'open recursors'?
Anyway, the comment was go
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 abou
On Mon, 10 Dec 2007, Matt Larson wrote:
> Much against my better judgement, I'm replying to an author who
> repeatedly shows himself incorrigible.
This seems to be a personal attack.
But in anycase, I have demonstrated the math governing the size of the
attack, and the math proves that there i
On Mon, 10 Dec 2007, Matt Larson wrote:
> Much against my better judgement, I'm replying to an author who
> repeatedly shows himself incorrigible. But lest his continued
> repetition of a false claim--that authority servers can be used to
> mount as large an attack as open servers--begin to give
On Tue, 4 Dec 2007, Edward Lewis wrote:
> http://www.ietf.org/internet-drafts/draft-ietf-dnsop-reflectors-are-evil-05.txt
>
> 1) (Somewhat jokingly) I would strike the first word ("Recently") as
> the attacks were almost two years ago now.
Yes. And those attacks seemed to be contrived at the
On Thu, 8 Nov 2007, Mark Andrews wrote:
> > RFC 3833 Section 1:
> >
> >- While some participants in the meeting were interested in
> > protecting against disclosure of DNS data to unauthorized parties,
> > the design team made an explicit decision that "DNS data is
> > `public'"
On Wed, 7 Nov 2007, Antonio Querubin wrote:
> With all the on-going discussion in various circles going on about IPv6
> it's a pity the root hints is still missing IPv6 addresses.
There's no room for IPv6 hints. The 512 byte maximum size is full.
Turning on ENDSO or requiring TCP connections e
On Wed, 7 Nov 2007, Kim Davies wrote:
> Dean Anderson wrote:
> > The ICANN announcement doesn't seem to have come through on DNSOP as
> > Patrick indicated. I can't find it in my archive Did anyone else
> > get it?
>
> The announcement was posted on 24 O
The ICANN announcement doesn't seem to have come through on DNSOP as
Patrick indicated. I can't find it in my archive Did anyone else
get it?
--Dean
-- Forwarded message --
Date: Tue, 6 Nov 2007 16:26:07 -0500
From: Patrick W. Gilmore <[EMAIL PROTECTED]>
To: "
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
1 - 100 of 175 matches
Mail list logo
