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, including mine, is not up to serving thousands of
requests/second over TCP. Or at
On Fri, Aug 15, 2008 at 04:07:03PM -0700, David Conrad wrote:
intervention) or they'll turn off DNSSEC. So, in the worst case, they'll
get bitten and revert back to the same level of security (or lack thereof)
they have today.
Is this worth blocking DNSSEC deployment?
It seems to me that
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
bert hubert wrote:
On Mon, Aug 18, 2008 at 04:34:30PM +, Paul Vixie wrote:
and let's also make explicit that TCP is not to be used unless UDP returns
TC or unless QTYPE=AXFR or unless UDP QTYPE=IXFR returned only one SOA.
This means disabling one of the more widely used MTAs.
On Mon, Aug 18, 2008 at 05:27:24PM +, Paul Vixie wrote:
TCP/53 a redheaded stepchild and its uses are all dangerous or unscalable.
(that initiators do the close, and that responders have a minimum 2-minute
timeout, says that any conformant implementation can be slapped down hard
with a
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, Aug 18, 2008 at 12:02 PM, Paul Hoffman [EMAIL PROTECTED]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
On Mon, Aug 18, 2008 at 07:20:16PM +, Paul Vixie wrote:
We've just had it easy over the past years, and it shows.
it *can't* scale. laws of physics.
'When a distinguished but elderly scientist states that something is
possible, he is almost certainly right. When he states that something
On Aug 18, 2008, at 12:51 PM, Joe Baptista wrote:
No. I was thinking more of a smart porcupine with attitude. At
least use the IDS to notify the system administrator an attack is in
progress. I've attached a document that uses snort to log the
event. That could be used to notify the
Paul's original proposal, C (if I interpret it correctly) applies to
resolver-authority-server communications, not stub-resolver
communications.
no, i was pretty much ruling them out period. especially (RA=1 AND RD=0).
however, i could accept a SHOULD NOT for ADNS vs. a SHOULD for RDNS
On Mon, Aug 18, 2008 at 01:45:43PM -0400, Brian Dickson wrote:
The problem, I think, is TCP itself, not TCP support within
implementations. E.g. resource limits per IP address (16 bits of port
number) don't scale to current-size Internet scale.
It is possible to host 10 connections on 1
On Mon, Aug 18, 2008 at 07:49:20PM +, Paul Vixie wrote:
so what does microsoft exchange do when it tries to talk to a tinydns
service like everydns.net who doesn't implement TCP/53 at all?
It doesn't need to - it speaks to resolvers.
what would it do if it had a TCP-forbidding
what would it do if it had a TCP-forbidding firewall between it and its
RDNS?
Dunno, but when PowerDNS had TCP bugs in its resolver code, all the
complaints I got were from Exchange users.
they'll cope.
What's the rush with deprecating DNS/TCP btw? It languished in the shade for
25
On Mon, 18 Aug 2008, Joe Baptista wrote:
No. I was thinking more of a smart porcupine with attitude. At least use the
IDS to notify the system
administrator an attack is in progress. I've attached a document that uses
snort to log the event. That could be
used to notify the system
On Mon, 18 Aug 2008, bert hubert wrote:
On Mon, Aug 18, 2008 at 01:45:43PM -0400, Brian Dickson wrote:
The problem, I think, is TCP itself, not TCP support within
implementations. E.g. resource limits per IP address (16 bits of port
number) don't scale to current-size Internet scale.
It is
On Mon, Aug 18, 2008 at 06:11:14PM -0400, Paul Wouters wrote:
It is possible to host 10 connections on 1 IP address and 1 port, and
this happens in practice. Think, again, of webservers, which all have to
listen on port 80, yet support lots of clients simultaneously.
Bad example. One of
Bad example. One of the reasons we don't see more crypto per default on
web browsing is precisely the limitations of SSL/CA's on using SSL with
virtual host web sites. I'd hardly call the lack of port 443 a success
story.
we don't need a reason to deprecate tcp/53 beyond what's written in
David Conrad wrote:
If a caching server is required to perform public key computation to
verify RRs before caching, it can't support much clients and will be
a so easy victim of DDOS.
Hence, one of the reasons for the desire to push DNSSEC towards the end
user.
You mean all the DNSSEC
Paul Wouters wrote:
(distributed) point to point encryption (or validation) is the future!
It's no future.
I see no problem for port 53 through NAT's.
NAT often captures and modifies packet to port 53.
But really, so many desktop applications
do direct DNS now themselves with disregard of
On Aug 18, 2008, at 8:22 PM, Masataka Ohta wrote:
You mean all the DNSSEC clients should directly ask authoritative
nameservers
Yes.
and all the firewalls preventing so should be modified.
The vast majority of firewalls allow 'connections' (even UDP ones) to
be initiated from the inside.
21 matches
Mail list logo
