I got the idea Randy was looking for info like appears in the BCP
that describes root server operations requirements, except as applies
to our DLV zone (and probably not an IETF document).
actually, i think it most important that a proposed dlv service
make very clear its security policy and
Earlier this month my daughters Ibook was stolen, oh well that is life I
guess.
Anyway updated mail server software for full debug and IP log since
noticed
that mail account was accessed yesterday.
It's a UNIX machine. You own it. You know
the password. If you had only set up an
SSH server
Actually, it seems this his how you get stolen items back in the internet age
;-).
http://www.evanwashere.com/StolenSidekick/
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, June 13, 2006 5:32 AM
To: [EMAIL PROTECTED]
On Fri, Jun 09, 2006 at 03:49:50PM -0700, Matthew Petach wrote:
(I think these were the toughest to take notes on, since they went
by so fast; took the most cleaning up afterwards. But they were also
the best talks of the 3 days. I wish we could have flipped, and taken
more time on
Moving to nanog-futures. Or trying, anyway.
On Mon, Jun 12, 2006 at 04:45:30PM +0200, Henk Uijterwaal wrote:
On the DLV thread, but not responding to anybody in particular.
As soon as you allow people to attend 1 talk for free, then you opened the
door for people attending without
On Tue, Jun 13, 2006 at 01:18:06AM -0700, Randy Bush wrote:
actually, i think it most important that a proposed dlv service
make very clear its security policy and process in vetting the
correctness of the data it serves, i.e. the trust anchors for
dependent zones.
Oh, you're asking
Hi,
On Jun 13, 2006, at 8:47 AM, David W. Hankins wrote:
Do you imagine that, if IANA/ICANN/USDOT/someone were told to
implement a policy to sign the root, that they would have trouble
identifying the owners of the TLD's reliably?
Yes. And it isn't a question of signing the root -- that
I think this is an artificial problem that arises only for ISC
since we're out of the delegation loop (except where we can
authenticate registries and receive trust anchors from them).
if other non-delegators run dlv services, they will have the same
issues. and if you are a delegator, why
On 13-Jun-2006, at 13:27, Randy Bush wrote:
the isc web page now says
Before it is accepted into the dlv.isc.org zone, ISC will
perform checks to ensure the keys are being used in the
requested zone, that the persons making the request are who
they claim to be and that they
I don't profess to speak for ISC here, but it may be worth noting
that ISC staff continue to spend a lot of time travelling to operator
meetings, workshops, root server installations and RIR and ICANN
meetings. Outreach and community participation is one of the core
things that ISC
On 13-Jun-2006, at 14:37, Randy Bush wrote:
I don't profess to speak for ISC here, but it may be worth noting
that ISC staff continue to spend a lot of time travelling to operator
meetings, workshops, root server installations and RIR and ICANN
meetings. Outreach and community participation
With the current trust policy, it seems to me that DLV is a
bootstrap mechanism intended to promote bottom-up pressure for
DNSSEC deployment, and to give people a chance to get to grips
with things like key rollover and zone signing.
well, unlike ipv6 marketing efforts, at least it does not
On Jun 13, 2006, at 11:55, Randy Bush wrote:
but what leaves me wondering is why this is all so difficult.
Possibly because many people find writing formal security policies,
which I think is what we're really talking about here, to be a dry
and unpleasant experience, much less fun that
On Tue, Jun 13, 2006 at 11:37:08AM -0700, Randy Bush wrote:
...
can you say does not scale? ...
...
I think ISC very clearly already said that. They do not WANT it to
scale. They _WANT_ DNSSEC to succeed and take over. This is a
bootstrap mechanism to get DNSSEC rolling.
--
Joe Yao
At 11:37 -0700 6/13/06, Randy Bush wrote:
can you say does not scale? or how about works poorly when a
zone is transferred?
There are two ways to look at scaling. Scaling in volume and
scaling across generations. DLV definitely does not scale across
generations with such a
can you say does not scale?
Indeed.
this is why we're trying to sign up some registrars, starting with alice's,
who can send us blocks of keys based on their pre-existing trust
relationships.
--
Paul Vixie
On Tue, Jun 13, 2006 at 10:27:49AM -0700, Randy Bush wrote:
if other non-delegators run dlv services, they will have the same
issues.
Absolutely.
and if you are a delegator, why play dlv as you can
directly sign?
I think Paul answered this question (it's because of the way
DNSSEC-bis proves
... and alice has been working on deploying the .org DNSSEC testbed for
6 months now. Thus far my experence with deploying DNSSEC is: its just
hard, not fun and for a lack of a better word... it SUCKS.
In the last 6months since we deployed it, not one sole has clicked on
the [now broken]
On Tue, 13 Jun 2006, Rick Wesson wrote:
... and alice has been working on deploying the .org DNSSEC testbed for
6 months now. Thus far my experence with deploying DNSSEC is: its just
hard, not fun and for a lack of a better word... it SUCKS.
In the last 6months since we deployed it, not
[EMAIL PROTECTED] (Brian McMahon) writes:
why can isc not simply say we plan to vet zones as follows:. and we
plan to manage maintenance of key rollover as follows: etc.?
Would it help if I volunteered to talk to folks and help write
something up?
not at the moment. joao heard this
can you say does not scale?
Indeed.
this is why we're trying to sign up some registrars, starting with alice's,
who can send us blocks of keys based on their pre-existing trust
relationships.
so a key roll or change of delegation requires two levels of human
intervention to work?
randy
On Tue, 13 Jun 2006, Randy Bush wrote:
can you say does not scale?
Indeed.
this is why we're trying to sign up some registrars, starting with alice's,
who can send us blocks of keys based on their pre-existing trust
relationships.
so a key roll or change of delegation requires two
... we're trying to sign up some registrars, starting with alice's,
who can send us blocks of keys based on their pre-existing trust
relationships.
so a key roll or change of delegation requires two levels of human
intervention to work?
no.
in the normal, non-DLV DNSSEC-bis
please reconcile
no bank in its right mind, for example, would allow its identity
to be held or represented by a middleman whose security policies
weren't auditable.
with
this is why we're trying to sign up some registrars, starting
with alice's, who can send us blocks of keys based on
therefore registrars (like alice's... remember alice? this is a song about
alice) have no place to go with registrant KSK data at this time. this in
turn keeps most registrars from bothering to collect or store this useless
data. ISC proposes to accept this KSK data (in the form of DLV RRs)
From: Randy Bush [EMAIL PROTECTED]
Date: Tue, 13 Jun 2006 15:16:50 -0700
To: Paul Vixie [EMAIL PROTECTED]
Cc: nanog@merit.edu
Subject: Re: wrt joao damas' DLV talk on wednesday
therefore registrars (like alice's... remember alice? this is a song about
alice) have no place to go
thanks for actual technalia.
i've also been warned that this isn't ops-related and told to move elsewhere.
( first, i suspect much of the confusion could come from your
thinking that the place up on skyline is *the* alice's restaurant.
*the* alice's restaurants are the ones in our own
therefore registrars (like alice's... remember alice? this is a song about
alice)
( first, i suspect much of the confusion could come from your
thinking that the place up on skyline is *the* alice's restaurant.
it isn't. the real one was in stockbridge, mass, and rather
short-lived. so
On Tue, Jun 13, 2006 at 03:21:23PM -0700, Gregory Hicks wrote:
From: Randy Bush [EMAIL PROTECTED]
Date: Tue, 13 Jun 2006 15:16:50 -0700
To: Paul Vixie [EMAIL PROTECTED]
Cc: nanog@merit.edu
Subject: Re: wrt joao damas' DLV talk on wednesday
therefore registrars (like alice's...
thanks for actual technalia.
i've also been warned that this isn't ops-related and told to move
elsewhere.
if it was not from the ml committee, tell whoever to foad. they
would not know ops if it bit them on the bleep.
i think if you amplified on and detailed the above, and went into
how
I'm ashamed to call myself a participant in NANOG, IETF and ICANN.
every once in a while I get to participate in something that moves
forward the network just a bit;
please refrain from this thread -- a few folks are attempting to move
DNSSEC ahead; we will fail, but would appreciate any
I'm ashamed to call myself a participant in NANOG, IETF and ICANN.
every once in a while I get to participate in something that moves
forward the network just a bit;
please refrain from this thread -- a few folks are attempting to
move DNSSEC ahead; we will fail, but would appreciate any
On Tue, 13 Jun 2006, Martin Hannigan wrote:
I'm not. Consensus usually comes after the party, not before.
I guess you've never been to IETF ...
--
William Leibzon
Elan Networks
[EMAIL PROTECTED]
please refrain from this thread -- a few folks are attempting to move
DNSSEC ahead; we will fail, but would appreciate any constructive
criticism on the pitfalls to deploy before we are all dead.
i am amazed that you do not consider open discussion of security
policies and procedures to be
http://thespamdiaries.blogspot.com/2006/02/new-host-cloaking-technique-used-by.html
Does seem to have potential, because at least one large webhost says
they got bit hard by this (when they asked me to unblock one of their
/24s) - and I've been seeing the same type of spam for quite some time
On Wed, 14 Jun 2006, Suresh Ramasubramanian wrote:
http://thespamdiaries.blogspot.com/2006/02/new-host-cloaking-technique-used-by.html
* Monitor your local network for interfaces transmitting ARP
responses they shouldn't be.
how about just mac security on switch ports? limit the number
That was not my advice btw - just forwarding on what I saw.
What you say does seem like a must do all right - but putting ARP
filters in is actually a reasonable idea.
On 6/14/06, Christopher L. Morrow
[EMAIL PROTECTED] wrote:
On Wed, 14 Jun 2006, Suresh Ramasubramanian wrote:
On Wed, 14 Jun 2006, Suresh Ramasubramanian wrote:
That was not my advice btw - just forwarding on what I saw.
oh,. apologies, i did cut the message down quite a bit :( I understood you
were quoting from the spamdiaries website, I apologize to the other
listeners (readers?) if it confused
It sure seems like this is a good demo of the best practice of having customers
on their own VLANs with their own subnets. We have been doing this since we
started offering colo services, is this less common than I thought?
John
-Ursprüngliche Nachricht-
Von: Christopher L. Morrow
On 6/14/06, Christopher L. Morrow
[EMAIL PROTECTED] wrote:
Atleast it'd trim down the 'problem' to the single customer subnet, I
assume that dedicated hosting folks don't just drop machines behind a
switch on one big flat subnet? That's probably a naive assumption though
:( Perhaps this is
On 2006-06-14-00:23:15, Christopher L. Morrow [EMAIL PROTECTED] wrote:
[...]
I assume that dedicated hosting folks don't just drop machines
behind a switch on one big flat subnet? That's probably a naive
assumption though
I've long been a proponent of a per-customer VLAN or L3 interface,
On Wed, 14 Jun 2006, Adam Rothschild wrote:
On 2006-06-14-00:23:15, Christopher L. Morrow [EMAIL PROTECTED] wrote:
[...]
I assume that dedicated hosting folks don't just drop machines
behind a switch on one big flat subnet? That's probably a naive
assumption though
I've long been a
That’s a very good question... I was also under the assumption that most
providers would have adopted new practices rather then simply dumping
customers on a single subnet/vlan... unless were going back in time :P
As far as the special daemon program goes.. any packet sniffer will
reveal
On Wed, 14 Jun 2006, Christopher L. Morrow wrote:
is it really that hard to make your foudry/extreme/cisco l3 switch vlan
and subnet??? Is this a education thing or a laziness thing? Is this
perhaps covered in a 'bcp' (not even an official IETF thing, just a
hosters bible sort of thing) ?
JvO Date: Tue, 13 Jun 2006 21:35:14 -0700
JvO From: John van Oppen
JvO It sure seems like this is a good demo of the best practice of
JvO having customers on their own VLANs with their own subnets. We
JvO have been doing this since we started offering colo services, is
We actually go so far
CLM Date: Wed, 14 Jun 2006 04:46:31 + (GMT)
CLM From: Christopher L. Morrow
CLM is it really that hard to make your foudry/extreme/cisco l3 switch vlan
CLM and subnet???
Of course not.
CLM Is this a education thing or a laziness thing?
Both.
Eddy
--
Everquick Internet -
46 matches
Mail list logo
