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
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 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
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
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
as the attack
itself, and because the attack is merely an example of a broader
category of attacks already addressed elsewhere, and because the draft
contains false statements about the threats to authoritative
nameservers, I strongly object to this draft.
Dean Anderson
Av8 Internet, Inc
--
Av8
: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
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
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
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.
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
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
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
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
--
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
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
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
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
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
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
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
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
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
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
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
, 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
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 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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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.
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, 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
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
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.
, 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
, 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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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, 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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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 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.
93 matches
Mail list logo
