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.
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
On Tue, 19 Aug 2008, Masataka Ohta wrote:
You mean all the DNSSEC clients should directly ask authoritative
nameservers and all the firewalls preventing so should be modified.
(distributed) point to point encryption (or validation) is the future!
Let's assume all the clients agree with you a
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 t
On Aug 18, 2008, at 5:21 PM, Masataka Ohta wrote:
The fact is DNSSEC is the *only* game in town for preventing cache
poisoning.
Not at all.
Which game do you propose?
If a caching server is not required to perform public key computation
to verify RRs before caching, ...
Then the caching s
> 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 c
Jim Reid wrote:
> The fact is DNSSEC is the *only* game in town for preventing cache
> poisoning.
Not at all.
If a caching server is not required to perform public key computation
to verify RRs before caching, cache poisoning won't be detected by
the caching server, average clients of which su
> 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
Andrew,
On Aug 18, 2008, at 6:29 AM, Andrew Sullivan wrote:
When the CTO receives the incident report, the CTO is going to say,
"So if
we never turned on DNSSEC, this wouldn't have happened? Ok. New
policy: no DNSSEC."
In today's Internet, most network engineers (at least at real
compani
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.
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 po
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 administ
On Mon, 18 Aug 2008, Andrew Sullivan wrote:
avoid susceptibility to DoS." Or something like that. After all,
resource-exhaustion attacks are also possible against DNSSEC-oblivious
systems. DNSSEC does open a new line of such attack, and one needs to
provision for it. No?
A factor of 100 is
> > 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
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-fo
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
> 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
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 syst
bert hubert wrote:
The server I mean by the way is microsoft exchange, which likes to do DNS
over TCP.
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.
On Mon, Aug 18, 2008 at 01:56:09PM -0400, Dean Anderson wrote:
> DNSSEC caches that verify are subject to a crypto-overload attack by
> large numbers of queries.
Surely another way to express the same thing is, "DNSSEC-enabled
servers and caching recursors require many more resources in order to
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 someth
On Aug 18, 2008, at 11:26 AM, Joe Baptista wrote:
The best way to secure DNS recursive servers is to integrate a smart
IDS and firewall solution.
Hard shell, gooey interior? You're kidding, right?
___
DNSOP mailing list
DNSOP@ietf.org
https://www.
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
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 server both implement DNSSEC.
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
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.
Cou
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, including mine, is not up to s
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, 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. TCP is a first class
DNS citizen
[EMAIL PROTECTED] (Paul Hoffman) writes:
> At 4:46 PM +0200 8/18/08, Peter Koch wrote:
>>Of course, one might claim that anybody using ANY in any production system
>>(pun intended) gets what they deserve.
>
> Fully agree. Maybe a BCP document titled "Asking for ANY Considered
> Unwise" would be u
At 4:46 PM +0200 8/18/08, Peter Koch wrote:
Of course, one might claim that anybody using ANY in any production system
(pun intended) gets what they deserve.
Fully agree. Maybe a BCP document titled "Asking for ANY Considered
Unwise" would be useful.
--Paul Hoffman, Director
--VPN Consortium
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 poisonin
On Fri, Aug 15, 2008 at 11:29:13AM -0700, David Conrad wrote:
> However, because of DO, folks who don't configure their resolvers to
> do DNSSEC shouldn't ever see any DNSSEC goop.
so, one question is whether the "DO" bit actually signals understanding of
the correct version of DNSSEC and what
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
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 w
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 l
37 matches
Mail list logo
