On Tue, Oct 02, 2007 at 12:40:31PM -0400,
Sam Hartman [EMAIL PROTECTED] wrote
a message of 17 lines which said:
I'd appreciate it if you took Paul's comments a lot more seriously
and looked at whether the dnsop view on this issue extends to other
parts of the ietf. To the extent that it
On Fri, 28 Sep 2007, Jaap Akkerhuis wrote:
There are two major reasons for an organization to not want roaming
users to trust locally-assigned DNS servers.
Open recursive servers doesn't help in against man in the middle
attacks. If you want to avoid that use VPN's or (for DNS) TSIG.
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
On Fri, 28 Sep 2007, Joe Abley wrote:
I'm surprised by that comment.
I think it's a common use case that organisations who deploy VPNs have split
DNS; that is, namespaces available through internal network resolvers that do
not appear in the global namespace. In my experience, it is normal
On Fri, Sep 28, 2007 at 05:29:43PM -0400, 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
Stephane == Stephane Bortzmeyer [EMAIL PROTECTED] writes:
Stephane But suggesting ORNS (Open Recursive Name Servers) for
Stephane the solution to this issue is, indeed, a bad idea (do
Stephane note I did not say the N word), for the reasons
Stephane explained in
Joao == Joao Damas [EMAIL PROTECTED] writes:
Joao It does indeed as Stephane pointed out. Opening up your
Joao resolver so you can server roaming users, without further
Joao protection, is, at best, naive.
I'd appreciate it if you took Paul's comments a lot more seriously and
On Sun, Sep 30, 2007 at 10:32:39PM -0600,
Danny McPherson [EMAIL PROTECTED] wrote
a message of 51 lines which said:
Section 4's reference to BCP 84, in part, creates a false sense of
useful action on part of the operator,
This could be said of all the parts of the I-D which mentions non-DNS
On Oct 1, 2007, at 1:52 AM, Stephane Bortzmeyer wrote:
On Sun, Sep 30, 2007 at 10:32:39PM -0600,
Danny McPherson [EMAIL PROTECTED] wrote
a message of 51 lines which said:
Section 4's reference to BCP 84, in part, creates a false sense of
useful action on part of the operator,
This could
As for the TSIG or SIG(0) recommendation, I'm not sure what
the numbers are for client support today, but I suspect it's at
best an negligible sample.
Well all Windows XP/2003/Vista boxes can be configured to
support TSIG, with free software, if not natively.
All
On Oct 1, 2007, at 7:42 PM, Mark Andrews wrote:
As for the TSIG or SIG(0) recommendation, I'm not sure what
the numbers are for client support today, but I suspect it's at
best an negligible sample.
Well all Windows XP/2003/Vista boxes can be configured to
support TSIG,
On Oct 1, 2007, at 7:42 PM, Mark Andrews wrote:
As for the TSIG or SIG(0) recommendation, I'm not sure what
the numbers are for client support today, but I suspect it's at
best an negligible sample.
Well all Windows XP/2003/Vista boxes can be configured to
support TSIG,
I do support this document being published as BCP.
A couple of minor comments:
Section 4's reference to BCP 84, in part, creates a false sense of
useful action on part of the operator, IMO (in addition, there's a
typo; s/were/where/).
In situations were more complex network setups are in
On Fri, Sep 28, 2007 at 05:29:43PM -0400,
Paul Wouters [EMAIL PROTECTED] wrote
a message of 10 lines which said:
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? :)
That's exactly what
On Thu, Sep 27, 2007 at 06:45:55PM -0700,
Paul Hoffman [EMAIL PROTECTED] wrote
a message of 36 lines which said:
It ignores one of the main reasons that many organizations purposely
choose to provide recursive lookup to the public, namely for their
own roaming users.
No, it is *not*
At 18:45 27-09-2007, Paul Hoffman wrote:
The Security Considerations section for this document is much too
narrow. It ignores one of the main reasons that many organizations
purposely choose to provide recursive lookup to the public, namely
for their own roaming users. Without an open,
At 9:19 AM +0200 9/28/07, Stephane Bortzmeyer wrote:
On Thu, Sep 27, 2007 at 06:45:55PM -0700,
Paul Hoffman [EMAIL PROTECTED] wrote
a message of 36 lines which said:
It ignores one of the main reasons that many organizations purposely
choose to provide recursive lookup to the public,
It does indeed as Stephane pointed out.
Opening up your resolver so you can server roaming users, without
further protection, is, at best, naive.
Joao
On 28 Sep 2007, at 12:15, Jaap Akkerhuis wrote:
There are two major reasons for an organization to not want
roaming
users to
On 28-Sep-2007, at 1136, Paul Hoffman wrote:
It is not obvious, at least to some of the people I have spoken
with. It is also not obvious to VPN vendors; otherwise, they would
have easy-to-use settings to make it happen.
I'm surprised by that comment.
I think it's a common use case that
At 12:04 PM -0400 9/28/07, Joe Abley wrote:
On 28-Sep-2007, at 1136, Paul Hoffman wrote:
It is not obvious, at least to some of the people I have spoken
with. It is also not obvious to VPN vendors; otherwise, they would
have easy-to-use settings to make it happen.
I'm surprised by that
There are two major reasons for an organization to not want roaming
users to trust locally-assigned DNS servers.
Open recursive servers doesn't help in against man in the middle
attacks. If you want to avoid that use VPN's or (for DNS) TSIG.
I seem to remember that the ID actually
On 28-Sep-2007, at 1136, Paul Hoffman wrote:
It is not obvious, at least to some of the people I have spoken
with. It is also not obvious to VPN vendors; otherwise, they would
have easy-to-use settings to make it happen.
I'm surprised by that comment.
I'm not. As it happens I've used
On 28-Sep-2007, at 1516, Dean Anderson wrote:
Not widely supported in clients. Therefore, not a solution.
In fact, it's quite feasible in operating systems which can run a
local instance of (say) BIND9. It would be fair to say that
installing and configuring BIND9 on an average laptop is
The Security Considerations section for this document is much too
narrow. It ignores one of the main reasons that many organizations
purposely choose to provide recursive lookup to the public, namely
for their own roaming users. Without an open, known-good nameserver
at a fixed address,
--On Thursday, 27 September, 2007 18:45 -0700 Paul Hoffman
[EMAIL PROTECTED] wrote:
The Security Considerations section for this document is much
too narrow. It ignores one of the main reasons that many
organizations purposely choose to provide recursive lookup to
the public, namely for their
The IESG has received a request from the Domain Name System Operations
WG (dnsop) to consider the following document:
- 'Preventing Use of Recursive Nameservers in Reflector Attacks '
draft-ietf-dnsop-reflectors-are-evil-04.txt as a BCP
The IESG plans to make a decision in the next few
26 matches
Mail list logo
