Re: DNS .US outage

[Rodney Joffe]

Er.


On 7/6/05 10:00 PM, "Church, Chuck" <[EMAIL PROTECTED]> wrote:

> 
> Thanks.  Didn't have any *NIX boxes laying around to 'dig' any deeper.
> When I checked networksolutions' whois for neosystems.us and state.ny.us
> , both returned:
> " We are unable to process your request at this time. Please try again
> later."
> 
> Figured something was up.

You meant this in passing only, right? You clearly did not intend to
correlate an issue with .us DNS with whois data for .us, right?

RE: DNS .US outage

[Randy Bush]

> Thanks.  Didn't have any *NIX boxes laying around to 'dig' any deeper.

i believe even windoze has dig at the command line, though i don't
know in what directory it lies.

randy

Re: OMB: IPv6 by June 2008

[Alexei Roudnev]

IPv6 is an excellent example of _second system_ (do you remember book,
written by Brooks many years ago?) Happu engineers put all their crazy ideas
together into the second version of first 9succesfull) thing, and they
wonder why it do not work properly.
OS/360 is one example, IPv6 will be another.

IPv6 address allocation schema is terrible (who decided to use SP dependent
spaces?), security is terrible (who designed IPSec protocol?) and so so on.

Unfortunately, it can fail only if something else will be created, which do
not looks so.
- Original Message - 
From: "Daniel Golding" <[EMAIL PROTECTED]>
To: "Scott McGrath" <[EMAIL PROTECTED]>; "David Conrad"
<[EMAIL PROTECTED]>
Cc: 
Sent: Wednesday, July 06, 2005 8:58 AM
Subject: Re: OMB: IPv6 by June 2008


>
>
> There is an element of fear-mongering in this discussion - that's why many
> of us react poorly to the idea of IPv6. How so?
>
> - We are running out of IPv4 space!
> - We are falling behind <#insert scary group to reinforce fear of Other>!
> - We are not on the technical cutting edge!
>
> Fear is a convenient motivator when facts are lacking. I've read the above
> three reasons, all of which are provable incorrect or simple fear
mongering,
> repeatedly. The assertions that we are falling behind the Chinese or
> Japanese are weak echoes of past fears.
>
> The market is our friend. Attempts to claim that technology trumps the
> market end badly - anyone remember 2001? The market sees little value in
v6
> right now. The market likes NAT and multihoming, even if many of us don't.
>
> Attempts to regulate IPv6 into use are as foolish as the use of fear-based
> marketing. The gain is simply not worth the investment required.
>
> - Daniel Golding
>
> On 7/6/05 11:41 AM, "Scott McGrath" <[EMAIL PROTECTED]> wrote:
>
> >
> >
> > You do make some good points as IPv6 does not address routing
scalability
> > or multi-homing which would indeed make a contribution to lower OPEX and
> > be easier to 'sell' to the financial people.
> >
> > As I read the spec it makes multi-homing more difficult since you are
> > expected to receive space only from your SP there will be no 'portable
> > assignments' as we know them today.  If my reading of the spec is
> > incorrect someone please point me in the right direction.
> >
> > IPv6's hex based nature is really a joy to work with IPv6 definitely
fails
> > the human factors part of the equation.
> >
> > Scott C. McGrath
> >
> > On Wed, 6 Jul 2005, David Conrad wrote:
> >
> >> On Jul 6, 2005, at 7:57 AM, Scott McGrath wrote:
> >>> IPv6 would have been adopted much sooner if the protocol had been
> >>> written
> >>> as an extension of IPv4 and in this case it could have slid in
> >>> under the
> >>> accounting departments radar since new equipment and applications
> >>> would
> >>> not be needed.
> >>
> >> IPv6 would have been adopted much sooner if it had solved a problem
> >> that caused significant numbers of end users or large scale ISPs real
> >> pain.  If IPv6 had actually addressed one or more of routing
> >> scalability, multi-homing, or transparent renumbering all the hand
> >> wringing about how the Asians and Europeans are going to overtake the
> >> US would not occur.  Instead, IPv6 dealt with a problem that, for the
> >> most part, does not immediately affect the US market but which
> >> (arguably) does affect the other regions.  I guess you can, if you
> >> like, blame it on the accountants...
> >>
> >> Rgds,
> >> -drc
> >>
>
> -- 
> Daniel Golding
> Network and Telecommunications Strategies
> Burton Group
>
>

RE: DNS .US outage

[Church, Chuck]

Thanks.  Didn't have any *NIX boxes laying around to 'dig' any deeper.
When I checked networksolutions' whois for neosystems.us and state.ny.us
, both returned:
" We are unable to process your request at this time. Please try again
later."

Figured something was up.  But when I tried nslookup with a server on
yet a 4th ISP just now, it worked ok.   Thanks again.  


Chuck 


-Original Message-
From: Suresh Ramasubramanian [mailto:[EMAIL PROTECTED] 
Sent: Thursday, July 07, 2005 12:34 AM
To: Church, Chuck
Cc: nanog@merit.edu
Subject: Re: DNS .US outage

On 07/07/05, Church, Chuck <[EMAIL PROTECTED]> wrote:
>  
> Anyone else having issues with .US right now  (~12AM EST)?  NSlookup,
etc
> show various .us destinations as unknown domains...  
>   

nslookup is not the best tool to troubleshoot dns issues

works for me though -

[EMAIL PROTECTED] 10:02:22 [~]$ dig us NS

; <<>> DiG 8.3 <<>> us NS
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;;  us, type = NS, class = IN

;; ANSWER SECTION:
us. 1d23h59m46s IN NS  A.GTLD.BIZ.
us. 1d23h59m46s IN NS  B.GTLD.BIZ.
us. 1d23h59m46s IN NS  C.GTLD.BIZ.

;; Total query time: 3 msec
;; FROM: frodo.hserus.net to SERVER: default -- 127.0.0.1
;; WHEN: Thu Jul  7 10:02:25 2005
;; MSG SIZE  sent: 20  rcvd: 76

and a random .us domain -

[EMAIL PROTECTED] 10:02:25 [~]$ dig help.us

; <<>> DiG 8.3 <<>> help.us
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;;  help.us, type = A, class = IN

;; ANSWER SECTION:
help.us.58m46s IN A 66.98.178.79

;; Total query time: 2 msec
;; FROM: frodo.hserus.net to SERVER: default -- 127.0.0.1
;; WHEN: Thu Jul  7 10:03:30 2005
;; MSG SIZE  sent: 25  rcvd: 41


-- 
Suresh Ramasubramanian ([EMAIL PROTECTED])

Re: DNS .US outage

[Randy Bush]

Doc-2.2.3: doc -p -w us
Doc-2.2.3: Starting test of us.   parent is .
Doc-2.2.3: Test date - Wed Jul  6 18:42:03 HST 2005
Note: Skipping parent domain testing
Found 3 NS and 3 glue records for us. @a.root-servers.net. (non-AUTH)
Using NSlist from parent domain server a.root-servers.net.
NS list summary for us. from parent (.) servers
  == a.gtld.biz. b.gtld.biz. c.gtld.biz.
soa @a.gtld.biz. for us. serial: 2002445162
soa @b.gtld.biz. for us. serial: 2002445163
soa @c.gtld.biz. for us. serial: 2002445163
WARN: Found 2 unique SOA serial #'s for us.
Authoritative domain (us.) servers agree on NS for us.
NS list from us. authoritative servers matches list from
  ===  first parent (.) nameserver queried
Checking 0 potential addresses for hosts at us.
  == 
Summary:
   WARNINGS issued for us. (count: 1)
Done testing us.  Wed Jul  6 18:42:08 HST 2005

[ lotso detail deleted ]

Re: DNS .US outage

[Suresh Ramasubramanian]

On 07/07/05, Church, Chuck <[EMAIL PROTECTED]> wrote:
>  
> Anyone else having issues with .US right now  (~12AM EST)?  NSlookup, etc
> show various .us destinations as unknown domains...  
>   

nslookup is not the best tool to troubleshoot dns issues

works for me though -

[EMAIL PROTECTED] 10:02:22 [~]$ dig us NS

; <<>> DiG 8.3 <<>> us NS
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;;  us, type = NS, class = IN

;; ANSWER SECTION:
us. 1d23h59m46s IN NS  A.GTLD.BIZ.
us. 1d23h59m46s IN NS  B.GTLD.BIZ.
us. 1d23h59m46s IN NS  C.GTLD.BIZ.

;; Total query time: 3 msec
;; FROM: frodo.hserus.net to SERVER: default -- 127.0.0.1
;; WHEN: Thu Jul  7 10:02:25 2005
;; MSG SIZE  sent: 20  rcvd: 76

and a random .us domain -

[EMAIL PROTECTED] 10:02:25 [~]$ dig help.us

; <<>> DiG 8.3 <<>> help.us
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;;  help.us, type = A, class = IN

;; ANSWER SECTION:
help.us.58m46s IN A 66.98.178.79

;; Total query time: 2 msec
;; FROM: frodo.hserus.net to SERVER: default -- 127.0.0.1
;; WHEN: Thu Jul  7 10:03:30 2005
;; MSG SIZE  sent: 25  rcvd: 41


-- 
Suresh Ramasubramanian ([EMAIL PROTECTED])

DNS .US outage

[Church, Chuck]

Anyone else having 
issues with .US right now  (~12AM EST)?  NSlookup, etc show various 
.us destinations as unknown domains...  
 
Chuck ChurchLead Design EngineerCCIE #8776, 
MCNE, MCSENetco Government Services - Design & Implementation 
Team1210 N. Parker Rd.Greenville, SC 29609Home office: 
864-335-9473Cell: 703-819-3495[EMAIL PROTECTED]PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D 

 

Re: OMB: IPv6 by June 2008

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, Iljitsch van Beijn
um writes:
>
>On 7-jul-2005, at 0:18, Joe Abley wrote:
>
>> With great hindsight it would have been nice if the multi6/shim6  
>> design exercise had come *during* the IPv6 design exercise, rather  
>> than afterwards: we might have ended up with a protocol/addressing  
>> model that accommodated both the address size problem and also the  
>> DFZ state bloat issue. Oh well.
>
>Well, maybe I'm too optimistic here, but I believe that if a real  
>solution to the DFZ problem presents itself, the IETF will bend over  
>backwards and then some to shoehorn it into IP.
>

There were people who tried, way back when.  We were outvoted...  (The 
situation in the IETF has indeed changed.)

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

RE: Need BOGIES list

[Mark Foster]

>>
>> I went to http://www.iana.org/assignments/ipv4-address-space and grep-ed
>> for APNIC (Asia-Pacific Network Information Center) to get the following
>> list.  For the church email site that I support I block wholesale /8 IP
>> address ranges.  I assume that for our church we will never get email
>> from an APNIC site.
>>
>
> *snip*
>
> Great, if you intend to never correspond with 202/8, 203/8 and 210/8 you
> just nuked most of New Zealand and a lot of Australia at the same time.
>
> You might find that being a _tad_ more specific is useful. Believe it or
> not, theres a lot of legit business conducted between Australasia and the
> rest of the world...
>
> Mark.
>

Sorry for replying again, but a quick google revealed this:

http://www.okean.com/asianspamblocks.html
(note the paragraph reccomending not blocking greater than /16 at a time)

And more specifically:

http://www.okean.com/china.html

This is probably what you're after, if you wish to block only China.

Mark.

RE: Need BOGIES list

[Mark Foster]

>
> I went to http://www.iana.org/assignments/ipv4-address-space and grep-ed
> for APNIC (Asia-Pacific Network Information Center) to get the following
> list.  For the church email site that I support I block wholesale /8 IP
> address ranges.  I assume that for our church we will never get email
> from an APNIC site.
>

*snip*

Great, if you intend to never correspond with 202/8, 203/8 and 210/8 you
just nuked most of New Zealand and a lot of Australia at the same time.

You might find that being a _tad_ more specific is useful. Believe it or
not, theres a lot of legit business conducted between Australasia and the
rest of the world...

Mark.

(Who has historically had a LOT of trouble convincing some providers that
denying comms with New Zealand is a good way to get a whole nation up in
arms, especially if you're a big name telco in the US who is dropping IP
from a big name telco here...)

Re: OMB: IPv6 by June 2008

[David Conrad]

On Jul 6, 2005, at 3:34 PM, Iljitsch van Beijnum wrote:
Well, maybe I'm too optimistic here, but I believe that if a real  
solution to the DFZ problem presents itself, the IETF will bend  
over backwards and then some to shoehorn it into IP.


I'd say yes.  You are too optimistic.  :-).

But it certainly looks like a small DFZ table and portable address  
space are fundamentally incompatible.


Well, yes.  Of course.  If you make the routing locator also be the  
endpoint identifier, then _of course_ you must deal with the  
topological significance of the endpoint identifier.  It sort of  
follows.  You can't have your cake and eat it too.


Unfortunately, I do not believe a host-based solution like shim6 will  
ever be operationally deployable as it requires a rewrite of kernel  
stacks and such.  I'm told people are already deploying IPv6 stacks  
that do not support the "mandatory" IPSEC goop and there is an  
expectation stack developers are going to tack on an optional bit of  
black magic that is used only in very rare circumstances?  I have to  
admit some skepticism.


Rgds,
-drc

Re: SORBS & deaggregation

[Patrick W. Gilmore]

On Jul 6, 2005, at 6:51 PM, David Barak wrote:


Perhaps the networks are disconnected? Perhaps there
is insufficient
bandwidth between the cities to carry inter-city
traffic?



So, why would GRE not be a reasonable (temporary)
solution here?  If the islands are going to remain
disconnected long term, why not get additional AS
numbers?


It is non-trivial to get additional ASNs, even if you are multi-homed  
in multiple sites.


Doesn't mean it can't be done.

But AS exhaustion is far more critical than IP exhaustion.  (Or even  
RIB/FIB/proc exhaustion through additional prefixes, IMHO.)  So if  
they want to be .. uh, well, a good 'Netizen and use one AS with  
static routes or defaults or something to route between them, that's  
better than a slew of ASes with the same prefix info we have today.


--
TTFN,
patrick

Re: SORBS & deaggregation

[Alex Rubenstein]

Perhaps the networks are disconnected? Perhaps there is insufficient 
bandwidth between the cities to carry inter-city traffic?


So, why would GRE not be a reasonable (temporary) solution here?  If the 
islands are going to remain disconnected long term, why not get 
additional AS numbers?


I don't believe the fact of having multiple ASNs solves this issue, I 
believe ARIN looks at allocated space per OrgID.



I find blaming 250 extra routes WITH EXACTLY THE SAME PATH INFO on ARIN 
pretty unconvincing...


Personally, I (or my routers) don't have a problem -- at least at the 
moment. You could always filter.






--
Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben
Net Access Corporation, 800-NET-ME-36, http://www.nac.net

Re: SORBs

[Matthew Sullivan]

Sanfilippo, Ted wrote:

We have been asking them to fix it for over a month now.  

 


Got a SORBS Ticket number?

(If you've been asking us you should have)

I suspect it might be related to some wrong ARIN records  (I know there 
has been an issue with a Canadian ISP that doesn't exist anymore - 
Others on this list contacted me over the issue a while back), or a lack 
of a support ticket.


Regards,

Mat


-Original Message-
From: Suresh Ramasubramanian [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 06, 2005 9:51 AM

To: Sanfilippo, Ted
Cc: nanog@merit.edu
Subject: Re: SORBs

On 06/07/05, Sanfilippo, Ted <[EMAIL PROTECTED]> wrote:
 


Does anyone know of an easier way to remove IP blocks from a
   


blacklist?
 

We received a /16 from ARIN in May and have been trying to get SORB's 
to remove the blacklist association on these addresses. They seem to 
take forever to remove the blacklist association.


   



If it is a whole /16 you probably bought some old dynamic IP space that
was recycled - and then reassigned it to a datacenter, probably?

SORBS does respond, eventually.

--
Suresh Ramasubramanian ([EMAIL PROTECTED])
 

RE: SORBS & deaggregation

[Hannigan, Martin]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> David Barak
> Sent: Wednesday, July 06, 2005 6:51 PM
> To: nanog@merit.edu
> Subject: SORBS & deaggregation
> 
> 
> 
> 
> 
> --- Alex Rubenstein <[EMAIL PROTECTED]> wrote:
> 
> > 
> > 

[ SNIP ]


I would've made this a private note to y'all except:

Would you mind using "Was:" if you're going
to change the subject? I'd appreciate it. I bet others
would too...

Hint: killfiles.


-M<

SORBS & deaggregation

[David Barak]

--- Alex Rubenstein <[EMAIL PROTECTED]> wrote:

> 
> 
> Perhaps the networks are disconnected? Perhaps there
> is insufficient 
> bandwidth between the cities to carry inter-city
> traffic?

So, why would GRE not be a reasonable (temporary)
solution here?  If the islands are going to remain
disconnected long term, why not get additional AS
numbers?  

I find blaming > 250 extra routes WITH EXACTLY THE
SAME  PATH INFO on ARIN pretty unconvincing...


David Barak
Need Geek Rock?  Try The Franchise: 
http://www.listentothefranchise.com

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: OMB: IPv6 by June 2008

[Daniel Roesen]

On Thu, Jul 07, 2005 at 12:34:53AM +0200, Iljitsch van Beijnum wrote:
> But it certainly looks like a small DFZ table and portable address  
> space are fundamentally incompatible.

At least if you want all the advantages that real BGP multihoming has.
Not surprising. :-)


Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0

Re: OMB: IPv6 by June 2008

[Iljitsch van Beijnum]

On 7-jul-2005, at 0:18, Joe Abley wrote:

With great hindsight it would have been nice if the multi6/shim6  
design exercise had come *during* the IPv6 design exercise, rather  
than afterwards: we might have ended up with a protocol/addressing  
model that accommodated both the address size problem and also the  
DFZ state bloat issue. Oh well.


Well, maybe I'm too optimistic here, but I believe that if a real  
solution to the DFZ problem presents itself, the IETF will bend over  
backwards and then some to shoehorn it into IP.


But it certainly looks like a small DFZ table and portable address  
space are fundamentally incompatible.

Re: OMB: IPv6 by June 2008

[Joe Abley]

On 6 Jul 2005, at 11:41, Scott McGrath wrote:

You do make some good points as IPv6 does not address routing 
scalability
or multi-homing which would indeed make a contribution to lower OPEX 
and

be easier to 'sell' to the financial people.

As I read the spec it makes multi-homing more difficult since you are
expected to receive space only from your SP there will be no 'portable
assignments' as we know them today.  If my reading of the spec is
incorrect someone please point me in the right direction.


The spec in this case is RIR policy, which seems designed to 
accommodate the last-known word from the IETF on the subject, which is 
a pure aggregation model such as you described.


The fact that the pure aggregation model is insufficient in the real 
network has been widely recognised in IETF-land, and this was the 
reason that the multi6 working group was chartered. The multi6 working 
group produced a series of recommendations which in turn has led to the 
shim6 working group being formed. The shim6 working group has its first 
meeting in Paris in August.


If all this sounds like a lot of talking without much action then, 
well, yes. The problem being solved is not trivial, though, and shim6 
is actually working towards something that could be implemented, rather 
than simply trying to throw ideas at the problem, so there is progress.


IPv6's hex based nature is really a joy to work with IPv6 definitely 
fails

the human factors part of the equation.


The phrase "IPv6's hex based nature" very pithily sums up the problem 
that IPv6 was designed to solve.


With great hindsight it would have been nice if the multi6/shim6 design 
exercise had come *during* the IPv6 design exercise, rather than 
afterwards: we might have ended up with a protocol/addressing model 
that accommodated both the address size problem and also the DFZ state 
bloat issue. Oh well.



Joe

Re: Enable BIND cache server to resolve chinese domain name?

[Jay R. Ashworth]

On Mon, Jul 04, 2005 at 05:21:47PM +, Paul Vixie wrote:
> > Every public root experiment that I have seen has always
> > operated as a superset of the ICANN root zone.
> 
> not www.orsn.net.

Well, their website looks a lot better than the equivalent one.  :-)

But note that their site does *not* say that they are not a strict
superset; merely that their current operating policy doesn't
*guarantee* it.

Their language certainly implies that they're not out to be
intentionally perverse, at least to me.

Cheers,
-- jra
-- 
Jay R. Ashworth[EMAIL PROTECTED]
Designer  Baylink RFC 2100
Ashworth & AssociatesThe Things I Think'87 e24
St Petersburg FL USA  http://baylink.pitas.com +1 727 647 1274

  If you can read this... thank a system administrator.  Or two.  --me

Re: Enable BIND cache server to resolve chinese domain name?

[Jay R. Ashworth]

On Mon, Jul 04, 2005 at 01:25:57PM +0100, [EMAIL PROTECTED] wrote:
> Personally, I think that the Internet is too young
> and we have too little experience with multilingual
> naming to engineer an Internationalised Domain Naming
> solution that solves the problem once and for all. 
> This means that we should be ready for more than one
> iteration to get to the solution. 

Alas, we didn't get it done before the 'consumers' noticed...

which means there will be much more pain involved in getting the
engineering right.

Cheers,
-- jra
-- 
Jay R. Ashworth[EMAIL PROTECTED]
Designer+-Internetworking--+--+   RFC 2100
Ashworth & Associates   |  Best Practices Wiki |  |'87 e24
St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274

  If you can read this... thank a system administrator.  Or two.  --me

Re: E-Mail authentication fight looming: Microsoft pushing Sender ID

[Douglas Otis]

On Wed, 2005-07-06 at 15:23 -0400, Rich Kulawiec wrote:
> [late followup, sorry]
> 
> On Thu, Jun 23, 2005 at 05:42:17AM -0700, Dave Crocker wrote:
> > The real fight is to find ANY techniques that have long-term, global 
> > benefit in reducing spam.
> 
> We've already got them -- we've always had them.  What we lack is
> the guts to *use* them.
> 
> As we've seen over and over again, the one and only technique that has
> ever worked (and that I think ever *will* work) is the boycott --
> whether enforced via the use of DNSBLs or RHSBLs or local blacklists or
> firewalls or whatever mechanism.  It works for a simple reason: it makes
> the spam problem the problem of the originator(s), not the recipient(s).
> It forces them to either fix their broken operation (any network which
> persisently emits or supports spam/abuse is broken) or find themselves
> running an intranet.

The looming battle is not about a reluctance to utilize reputation.
This "authentication" effort is a shift from using the remote IP address
into utilizing the domain name.  This changes the nature of how
reputation affects shared servers.  A name is more specific, and at the
same time, more pervasive.  This change to the use of domains is
progress.

However, path registration is really just an "authorization" mechanism.
Calling this an "authentication" mechanism presumes the domain owner
enjoys exclusive use of their domain on the server.  While this may
satisfy the typical bulk email distributor, the average domain owner may
discover they remain prone to forgery.  Such domain owners may also be
harmed publishing server authorization in this case, while creating a
support nightmare.

The user-feedback reputation schemes suggested overlook the uncertainty
created when which header or parameter being assured by the sender is
unknown, or when domain exclusivity is not maintained at the server.  In
an era where networks are often populated by zombie systems, this
oversight is troubling.  Unless the domain owner administers their own
servers, and doesn't expect messages to forwarded accounts not to be
lost, then they should consider using a signature based alternative
instead.  In addition, signatures will likely represent less overhead
than path registration.

Path registration, due to the need to place higher priority on unseen
headers, will not offer effective anti-phishing solutions either.
Signature based alternatives again hold greater promise for
anti-phishing as well.  There are few email recipients that do not use
various types of black-hole lists.  As this battle shifts into using
domain names, be careful.  Make sure you can defend your domain's
reputation.  If not, a name-based reputation system directing your
domain's email to a "junk" folder will having you longing for the good
ol' days of black-hole lists.

-Doug

Re: E-Mail authentication fight looming: Microsoft pushing Sender ID

[trainier]

> As we've seen over and over again, the one and only technique that
has
> ever worked (and that I think ever *will* work) is the boycott --
> whether enforced via the use of DNSBLs or RHSBLs or local blacklists
or
> firewalls or whatever mechanism.  It works for a simple reason:
it makes
> the spam problem the problem of the originator(s), not the recipient(s).
> It forces them to either fix their broken operation (any network which
> persisently emits or supports spam/abuse is broken) or find themselves
> running an intranet.
> 

I agree that the "boycott" approach is effective.
 It does not, however, completely resolve
the issue that is SPAM.  First and foremost,
it does not make the spam a problem of the
originator at all times.  The issue is directly
illustrated with smtp servers
that are RFC ignorant and don't notify the sender
that an error occurred.  Sure, there's
not too much work involved, I'm asked about a message
that was supposed to be delivered,
nope it wasn't, must be an issue on your end.  It
still requires me to look into the
problem.  The second issue with boycotting, is
the false positives.  And dhcp makes
this a nightmare issue because some blacklists are
retarded about how long entries
are left in the list.

Quite honestly, I think a good blacklist lookup and
some sane bogon filters is
relatively effective.  Just be careful about
what blacklist sites you use.

Some blacklist sites require you to pay them to have entries removed.  You
can gurantee
a lot of false positives arise from using sites like
these.

Or simply build your own.  Rich is correct.  The design and technology
has been in
place for at least a couple of decades.  It does
work, for the most part.

Tim

Re: OMB: IPv6 by June 2008

[Iljitsch van Beijnum]

On 6-jul-2005, at 19:55, Edward Lewis wrote:




At 19:23 +0200 7/6/05, Iljitsch van Beijnum wrote:







With the chicken little-ing again...




?



You are approaching the problem at the wrong end by asking "what's  
in it for
me to adopt IPv6 now". The real question is "is IPv6 inevitable in  
the long

run".






Pardon my skepticism, but I recall hearing about the coming of the  
world due to pollution in the 1970's and the end of the oil supply  
by the 1980's.





That's nice, but maybe we should judge this issue own its own merits  
rather than adopt the position that since other people talking about  
other issues made mistakes in the past, surely there is a mistake  
this time too.


We know how many IPv4 addresses there are. We know how many are  
unusable (although this number isn't 100% fixed). We know how many  
were given out. We know how many are given out now each year. What  
kind of magic do you expect will make this problem that's coming go  
away?


And that's discounting that we already have a problem NOW. People are  
already moderating their requests because they know they can't get  
what they really want.




The point isn't whether IPv6 is good or not - it's that long-range  
predictions are often wrong.





It's very simple. IPv4 addresses will become scarce and expensive,  
unless either this internet fad blows over or a new technology  
replaces IPv4. Tell me how this "prediction" can be wrong. Are there  
hidden pockets of yet undiscovered address space? Is some government  
agency working on secret technology that lets you communicate over  
the net without the need for addresses?




My experiences were that IPv6 was painful - I ran into a lot of  
application bugs, OS's didn't deal with it well, and the ISP's were  
tough to deal with - as in, not many suppliers, not enough  
expertise to deliver on promises.







Maybe things are better now (note the use of past tense in the  
previous paragraph), I don't deal with IPv6 at this time.





It's getting better all the time, but there are still strange bugs in  
the applications, OSes and even the standards. IPv6 works very well  
for many things but not so well for others. Fortunately, there is  
still plenty of time to work out all the kinks before we need IPv6 to  
step up to the plate. In the mean time, we need SOME IPv6 so that the  
early adopters can find those kinks, and that part is right on track.


We who are running IPv6 salute you.

Re: E-Mail authentication fight looming: Microsoft pushing Sender ID

[Jason Frisvold]

On 7/6/05, Rich Kulawiec <[EMAIL PROTECTED]> wrote:
> I grow rather tired of people whining about the spam (and abuse) problem
> on the one hand...while refusing to take simple, well-known, and proven
> steps to push the consequences back on those responsible for it.  While we
> may no longer be in a position to remove particularly egregious networks
> from the Internet, we most certainly are in a position to remove the
> Internet from them via coordinated group action -- producing an
> equivalent result.

It's the group interaction this requires that is the problem.  For
instance, as a small ISP, it's hard to make a difference at all if you
block someone like, say, comcast or verizon (not pointing fingers,
just using examples)  ...  A small ISP could, conceivably put
themselves out of business doing something like that..

Coordinating something like that is difficult to begin with, but if
you're on the receiving end, I'm sure there will be lawsuits involved.
 Regardless of the legality, a lawsuit costs money, money a smaller
ISP may not have.

Then there's the problem with getting everyone to agree to block
someone ..  Not everyone is going to agree that company X needs to be
blocked.

Overall it's a great idea, but I don't think it's practical ...  I've
stuck to using blocklists and intelligent filtering.  I've spent a
great deal of time over the past few years developing our system and I
think it's doing a fine job at the moment..  :)

> ---Rsk


-- 
Jason 'XenoPhage' Frisvold
[EMAIL PROTECTED]

Re: E-Mail authentication fight looming: Microsoft pushing Sender ID

[Rich Kulawiec]

[late followup, sorry]

On Thu, Jun 23, 2005 at 05:42:17AM -0700, Dave Crocker wrote:
> The real fight is to find ANY techniques that have long-term, global 
> benefit in reducing spam.

We've already got them -- we've always had them.  What we lack is
the guts to *use* them.

As we've seen over and over again, the one and only technique that has
ever worked (and that I think ever *will* work) is the boycott --
whether enforced via the use of DNSBLs or RHSBLs or local blacklists or
firewalls or whatever mechanism.  It works for a simple reason: it makes
the spam problem the problem of the originator(s), not the recipient(s).
It forces them to either fix their broken operation (any network which
persisently emits or supports spam/abuse is broken) or find themselves
running an intranet.

We've known that this works for 20-odd years.  It hasn't stopped working;
what's stopped is the willingness to use it en masse, and to endure the
consequences of thereof.  And no new technology, however clever, is a
substitute for the will to make this happen when necessary.

I grow rather tired of people whining about the spam (and abuse) problem
on the one hand...while refusing to take simple, well-known, and proven
steps to push the consequences back on those responsible for it.  While we
may no longer be in a position to remove particularly egregious networks
from the Internet, we most certainly are in a position to remove the
Internet from them via coordinated group action -- producing an
equivalent result.

It's gonna come down to this sooner or later anyway.  We might as well
do it now, rather than waste another decade fiddling around with
clever-but-useless technical proposals and worthless legislation
while the problem continues to proliferate and diversify.

---Rsk

RE: Need BOGIES list

[O'Neil,Kevin]

I went to http://www.iana.org/assignments/ipv4-address-space and grep-ed
for APNIC (Asia-Pacific Network Information Center) to get the following
list.  For the church email site that I support I block wholesale /8 IP
address ranges.  I assume that for our church we will never get email
from an APNIC site.
 
058/8   Apr 04   APNIC   (whois.apnic.net)
059/8   Apr 04   APNIC   (whois.apnic.net)
060/8   Apr 03   APNIC   (whois.apnic.net)
061/8   Apr 97   APNIC   (whois.apnic.net)
124/8   Jan 05   APNIC   (whois.apnic.net)
125/8   Jan 05   APNIC   (whois.apnic.net)
126/8   Jan 05   APNIC   (whois.apnic.net)
202/8   May 93   APNIC   (whois.apnic.net)
203/8   May 93   APNIC   (whois.apnic.net)
210/8   Jun 96   APNIC   (whois.apnic.net)
211/8   Jun 96   APNIC   (whois.apnic.net)
218/8   Dec 00   APNIC   (whois.apnic.net)
219/8   Sep 01   APNIC   (whois.apnic.net)
220/8   Dec 01   APNIC   (whois.apnic.net)
221/8   Jul 02   APNIC   (whois.apnic.net)
222/8   Feb 03   APNIC   (whois.apnic.net)

Here is my procmail recipe if that helps:

:0 H
* ^Received:.*\[(58\.|59\.|60\.|61\.|\
124\.|125\.|126\.|\
202\.|203\.|\
210\.|211\.|\
218\.|219\.|\
220\.|221\.|222\.)
{
 /dev/null
}

...Kevin O'Neil
 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Geoff White
Sent: Wednesday, July 06, 2005 2:50 PM
To: nanog@merit.edu
Subject: Need BOGIES list


Hello All.
I'm having trouble with Cracking Attempts  and DoS attacks from a lot of

places in China :)
My client doesn't do any business in that region so they don't mind If I

block the entire sub-continent :)
Does anyone have a bad-guy list (or part of one) that I can use to get 
started?
I'm using pf under OpenBSD 3.7 as a firewall box.
E-mailing me off line is fine


geoffw

Re: Need BOGIES list

[william(at)elan.net]

On Wed, 6 Jul 2005, Geoff White wrote:


Hello All.
I'm having trouble with Cracking Attempts  and DoS attacks from a lot of 
places in China :)
My client doesn't do any business in that region so they don't mind If I 
block the entire sub-continent :)
Does anyone have a bad-guy list (or part of one) that I can use to get 
started?

I'm using pf under OpenBSD 3.7 as a firewall box.


IP blocks allocated to organizations in various countries (updated daily):
 http://www.completewhois.com/statistics/data/ips-bycountry/rirstats/

Configuring firewall (openbsd way on the buttom, replace bogon example
with appropriate other list you want):
 http://www.completewhois.com/bogons/using_bogon_lists.htm#firewall_examples

CIDR -> firewall scripts for some systems (not needed for openbsd which
accepts cidr ip block list directly with ph):
 http://www.completewhois.com/bogons/data/scripts/

P.S. Still looking for somebody to document and if necessary provide 
scripts on how to do it with netbsd, aix, hpux. Volunteers?

(and I'll do solaris myself if I ever get around to it...)

--
William Leibzon
Elan Networks
[EMAIL PROTECTED]

Re: Need BOGIES list

[Mark Owen]

On 7/6/05, Geoff White <[EMAIL PROTECTED]> wrote:
> 
> Hello All.
> I'm having trouble with Cracking Attempts  and DoS attacks from a lot of
> places in China :)
> My client doesn't do any business in that region so they don't mind If I
> block the entire sub-continent :)
> Does anyone have a bad-guy list (or part of one) that I can use to get
> started?
> I'm using pf under OpenBSD 3.7 as a firewall box.
> E-mailing me off line is fine
> 
> 
> geoffw
> 
> 
> 

DShield is a good one.
http://www.dshield.org/block_list_info.php
-- 
Mark Owen

Re: Need BOGIES list

[Jon Lewis]

On Wed, 6 Jul 2005, Geoff White wrote:

>
> Hello All.
> I'm having trouble with Cracking Attempts  and DoS attacks from a lot of
> places in China :)
> My client doesn't do any business in that region so they don't mind If I
> block the entire sub-continent :)
> Does anyone have a bad-guy list (or part of one) that I can use to get
> started?
> I'm using pf under OpenBSD 3.7 as a firewall box.

data from blackholes.us may be useful.  As luck would have it, I can't
load their web page at the moment.

--
 Jon Lewis   |  I route
 Senior Network Engineer |  therefore you are
 Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Need BOGIES list

[trainier]

You might start with blacklists.  There's
a lot of them out there.
http://ahbl.org is one of them.





Geoff White <[EMAIL PROTECTED]>

Sent by: [EMAIL PROTECTED]
07/06/2005 02:49 PM




To
nanog@merit.edu


cc



Subject
Need BOGIES list









Hello All.
I'm having trouble with Cracking Attempts  and DoS attacks from a
lot of 
places in China :)
My client doesn't do any business in that region so they don't mind If
I 
block the entire sub-continent :)
Does anyone have a bad-guy list (or part of one) that I can use to get

started?
I'm using pf under OpenBSD 3.7 as a firewall box.
E-mailing me off line is fine


geoffw

Need BOGIES list

[Geoff White]

Hello All.
I'm having trouble with Cracking Attempts  and DoS attacks from a lot of 
places in China :)
My client doesn't do any business in that region so they don't mind If I 
block the entire sub-continent :)
Does anyone have a bad-guy list (or part of one) that I can use to get 
started?

I'm using pf under OpenBSD 3.7 as a firewall box.
E-mailing me off line is fine


geoffw

Re: Report: Major Newspaper Sites Hobbled by Power Woes

[Kevin]

Fergie writes:
> A power outage at an Advance Internet hosting facility
> has hobbled the web sites for the company's chain of
> more than 30 newspapers, including many large metropolitan
> dailies. The Advance newspapers have switched to text-based
> sites to continue publishing, but are currently unable to
> display advertising, making the outage a potentially costly event. 
> http://news.netcraft.com/archives/2005/07/06/major_newspaper_sites_hobbled_by_power_woes.html

On 7/6/05, Steve Sobol <[EMAIL PROTECTED]> wrote:
> Yes, but Advance Internet isn't an ISP, it's a division of Newhouse
> Newspapers and exists primarily to service the Newhouse new media outlets.
> Cleveland.com, for example, is co-owned with the Cleveland _Plain Dealer_.
> 
> You'd think the company would be more careful about protecting a major
> extension to its core business.

In Newhouse's defense, they do seem to have a plan to get the news out
even after losing their hosting facility, just not how to make money from it :)

If you pick just about any major newspaper group and do reverse lookups
and traceroutes on the IP addresses of their public "news" web sites, you
will likely find the same situation for many newspaper chains -- all their eggs
in one basket.  I've seen similar outages for other groups, just never quite
this long-lasting.

Advance may have thought this exposure through, and determined the
risk of hosting all their web sites in a single data center was worth the
cost savings over building and maintaining identical deployments at two
physically diverse hosting facilities, but did CYA and build a DR site
with just enough horsepower to get the news out, but not enough to keep
the revenue coming in, betting that most outages would be short lived.

Not all bets can be winners.

Kevin Kadow

Re: OMB: IPv6 by June 2008

[Edward Lewis]

At 19:23 +0200 7/6/05, Iljitsch van Beijnum wrote:

With the chicken little-ing again...


You are approaching the problem at the wrong end by asking "what's in it for
me to adopt IPv6 now". The real question is "is IPv6 inevitable in the long
run".


Pardon my skepticism, but I recall hearing about the coming of the 
world due to pollution in the 1970's and the end of the oil supply by 
the 1980's.  (E.g., see http://www.ncpa.org/pub/bg/bg159/ for a 
discussion on the latter, albeit written before the most recent oil 
'scare.')


The point isn't whether IPv6 is good or not - it's that long-range 
predictions are often wrong.  For every "memex" 
(http://www.iath.virginia.edu/elab/hfl0051.html) there's an oil 
crisis, Ada, GOSIP, economic default of New York City (Ford to City: 
Drop Dead! - NY Daily News, Oct 30, 1975)...



So by all means, be an IPv6 hold out as long as you like, but don't assume
that just because adopting IPv6 doesn't make economic sense for you now, it
isn't going to happen at some point in the next decade. No rush, though.


http://www.nanog.org/mtg-0405/augmentation.html

Been there, done that, documented and shared results.  (Yes, got the 
T-Shirt too.  It was a NANOG, after all.)  That wasn't even the first 
go-round I had with IPv6.


My experiences were that IPv6 was painful - I ran into a lot of 
application bugs, OS's didn't deal with it well, and the ISP's were 
tough to deal with - as in, not many suppliers, not enough expertise 
to deliver on promises.


Maybe things are better now (note the use of past tense in the 
previous paragraph), I don't deal with IPv6 at this time.


--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis+1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.

Re: OMB: IPv6 by June 2008

[Jay R. Ashworth]

On Wed, Jul 06, 2005 at 07:23:01PM +0200, Iljitsch van Beijnum wrote:
> In any event, in the year 2020 we're NOT going to run IPv4 as we know  
> it today. It's possible that the packets that travel over the wires  
> still look like regular IPv4/TCP/UDP packets and all the complexity  
> is pushed out to the application or political/economic layers, but  
  ^
> that's not a possibility that appeals to me.

Is that layer 8?

Does anyone have a stateful firewall that works at that layer?

Cheers,
-- jra
-- 
Jay R. Ashworth[EMAIL PROTECTED]
Designer+-Internetworking--+--+   RFC 2100
Ashworth & Associates   |  Best Practices Wiki |  |'87 e24
St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274

  If you can read this... thank a system administrator.  Or two.  --me

Re: OMB: IPv6 by June 2008

[Iljitsch van Beijnum]

On 6-jul-2005, at 17:56, Edward Lewis wrote:

The Internet serves society, society owes nothing to the Internet.  
Members of this list may prioritize communications technology,  
other members of society may prioritize different interests and  
concerns. That is why IPv6 must offer a benefit greater than it's  
cost.


You are approaching the problem at the wrong end by asking "what's in  
it for me to adopt IPv6 now". The real question is "is IPv6  
inevitable in the long run".


It's hard to be sure that the answer for that question is "yes",  
since all kinds of things can happen between now and, say, 2020. But  
it certainly looks like IPv4 addressing issues are becoming more and  
more painful over time. For instance, so far this year 98 million  
IPv4 addresses were assigned or allocated by RIRs. There are  
currently 1.1 - 1.2 billion usable addresses marked "reserved" (=  
"unused") by the IANA, so at this rate IANA be flat out in 2011. Now  
it's possible that the past 6 months were a fluke and it will take  
twice as long, or it's the start of a new trend and it's going to go  
even faster.


In any event, in the year 2020 we're NOT going to run IPv4 as we know  
it today. It's possible that the packets that travel over the wires  
still look like regular IPv4/TCP/UDP packets and all the complexity  
is pushed out to the application or political/economic layers, but  
that's not a possibility that appeals to me.


So by all means, be an IPv6 hold out as long as you like, but don't  
assume that just because adopting IPv6 doesn't make economic sense  
for you now, it isn't going to happen at some point in the next  
decade. No rush, though.

IANA IPv4 allocations and bogon updates: 89/8, 90/8 and 91/8

[Rob Thomas]

-BEGIN PGP SIGNED MESSAGE-


[ Apologies to those of you who receive this note in multiple forums. ]

Hi, team.

The numerous Team Cymru bogon projects have been updated as of 30 JUN 2005 to
reflect the following IANA allocation made on 30 JUN 2005:

  089/8   Jun 05   RIPE NCC(whois.ripe.net)
  090/8   Jun 05   RIPE NCC(whois.ripe.net)
  091/8   Jun 05   RIPE NCC(whois.ripe.net)

IANA allocations change over time, so please check regularly to ensure you have
the latest filters if you are not using the bogon BGP feed(s).  We do announce
updates to the bogon projects to sundry lists, such as the bogon-announce list.
We can not stress this point strongly enough - these allocations change. If you
do not adjust your filters, you will be unable to access perhaps large portions
of the Internet.  Worse yet, you may end up blocking access for people who
transit through you.

Please do not apply any filters or blocks to your network without carefully
considering the ramifications of doing so.

As a point of reference, the Team Cymru master Bogon Reference Page can be found
here:

  

A quick summary of the documents and projects that have been updated include the
following:

  HTTP
The Bogon List
- 
The Text Bogon Lists
- 
- 
Secure BIND Template
- 
Secure IOS Template (Cisco)
- 
Secure BGP Template (Cisco)
- 
Secure JUNOS Template (Juniper)
- 
Secure JUNOS BGP Template (Juniper)
- 
Ingress Prefix Filter Templates, Loose and Strict (Cisco)
- 
Ingress Prefix Filter Template, Loose (Juniper)
- 
Ingress Prefix Filter Template, Strict (Juniper)
- 

  BGP
Bogon route-server for AUTOMATED updates of bogon filters
- All bogon route-server peers have already received the
  appropriate BGP prefix updates.
- 

  RADb
fltr-unallocated
fltr-martian
fltr-bogons
- 

  RIPE NCC
fltr-unallocated
fltr-martian
fltr-bogons
- 

  DNS
Bogon (bogons.cymru.com) zone
- 

  Monitoring
Bogon prefix monitoring
- 
Bogus ASN monitoring
- 

Please feel free to contact Team Cymru <[EMAIL PROTECTED]> with any comments,
questions, or concerns.

Thank you for your continued support.

Thanks!
Rob.
- -- 
Rob Thomas
http://www.cymru.com
Shaving with Occam's razor since 1999.


-BEGIN PGP SIGNATURE-
Version: PGP 6.5.2

iQCVAwUBQswL+1kX3QAo5sgJAQHcQgP/RDehEvRBiaN0nFApyeQroJzb6NfOmd88
VScVbNj08xn7jkovVjXndQ8roQzDEVhLZyhHa0+dp8cLEETnjVYXNd6Ir9/bajRj
3mybhQefzaPlKJjLOhjWmoU3maUMN8oTrWGkE5YQOe+6Ef8HDrI0inT+mhhyqdhF
V/I5kb6mNBw=
=qVJI
-END PGP SIGNATURE-

[OT] Re: Recall: SORBs

[Brad Knowles]

At 9:33 AM -0700 2005-07-06, Gregory Hicks wrote:


 Yeah BUT!  A message can only be "recalled" if it has NOT been read.


By a compatible Microsoft client.


 If the message goes to a 'list' of people, the ones that have NOT read
 the message will not see it.


	If they use a compatible Microsoft client, and if that "recall" 
protocol works exclusively through the use of the key word "recall" 
and the specific subject to be recalled.  Given how many people post 
or send how many messages with the same subject, would you really 
like to recall every message you've sent in a given thread?  What if 
someone has been on vacation for a while and hasn't read their 
massive backlog of NANOG messages?  And how do you handle this within 
an archive system?


	I sure hope that Microsoft is smarter than that, and instead 
works at the message-id level, or something else relatively unique.



 So it really doesn't do what one would think it does.


	I've heard about this feature.  Microsoft is at least being 
honest about the ability to recall messages which have/have not been 
read.  So, as far as that's concerned, I don't think there's any 
disingenuity here.


	But there are more fundamental issues to be concerned about. 
Implementation method is one.



	Of course, this is all off-topic, so if anyone wishes to continue 
discussing this subject we should probably find a more appropriate 
list.


--
Brad Knowles, <[EMAIL PROTECTED]>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755

  SAGE member since 1995.  See  for more info.

Re: Report: Major Newspaper Sites Hobbled by Power Woes

[Steve Sobol]

MARLON BORBA wrote:
This leads us to the old fact that several ISPs and hosting providers protect their servers 
with every network perimeter security resource (firewalls, IPSs, virus-and-spam-appliances etc) 
but forget that "availability" as a security principle requires adequate physical and utility 
safeguards


Yes, but Advance Internet isn't an ISP, it's a division of Newhouse 
Newspapers and exists primarily to service the Newhouse new media outlets. 
Cleveland.com, for example, is co-owned with the Cleveland _Plain Dealer_.


You'd think the company would be more careful about protecting a major 
extension to its core business.


--
JustThe.net - Steve Sobol / [EMAIL PROTECTED] / PGP: 0xE3AE35ED
Coming to you from Southern California's High Desert, where the
temperatures are as high as the gas prices! / 888.480.4NET (4638)

"Life's like an hourglass glued to the table"   --Anna Nalick, "Breathe"

Re: Recall: SORBs

[Gregory Hicks]

> Date: Wed, 6 Jul 2005 21:20:10 +0530
> From: Suresh Ramasubramanian <[EMAIL PROTECTED]>
> 
> On 06/07/05, Alex Rubenstein <[EMAIL PROTECTED]> wrote:
> > What is scarier --
> > 
> > a) microsoft providing this feature
> > 
> > b) someone with the ability to type "conf t, router bgp",
> > connected to the global internet, and thinking
> > that recalling a message would work?
> 
> [b] most assuredly
> 
> [a] has its uses, when used internally in an exchange groupware
> environment

Yeah BUT!  A message can only be "recalled" if it has NOT been read.
If the message goes to a 'list' of people, the ones that have NOT read
the message will not see it.  Those that HAVE read it, get to keep the
original message.

So it really doesn't do what one would think it does.

Regards,
Gregory Hicks

> 
> -- 
> Suresh Ramasubramanian ([EMAIL PROTECTED])
> 

-
Gregory Hicks   | Principal Systems Engineer
Cadence Design Systems  | Direct:   408.576.3609
555 River Oaks Pkwy M/S 6B1 | Fax:  408.894.3479
San Jose, CA 95134  | Internet: [EMAIL PROTECTED]

I am perfectly capable of learning from my mistakes.  I will surely
learn a great deal today.

"A democracy is a sheep and two wolves deciding on what to have for
lunch.  Freedom is a well armed sheep contesting the results of the
decision." - Benjamin Franklin

"The best we can hope for concerning the people at large is that they
be properly armed." --Alexander Hamilton

Re: Report: Major Newspaper Sites Hobbled by Power Woes

[MARLON BORBA]

This leads us to the old fact that several ISPs and hosting providers protect 
their servers with every network perimeter security resource (firewalls, IPSs, 
virus-and-spam-appliances etc) but forget that "availability" as a security 
principle requires adequate physical and utility safeguards also (backup site, 
automated failover, redundant communication links between sites and backbones, 
capable UPS, air-conditioning, fire-extinguishing...). Not all, as you see, are 
computer-related "per se", but they are "sine-qua-non" for 24x7 availability.



Abraços,
Marlon Borba, CISSP.
--
Nova campanha:
Centro de Resposta a Incidentes de
Segurança da Justiça Federal - Vamos criar!
--
>>> "Fergie (Paul Ferguson)" <[EMAIL PROTECTED]> 07/06/05 1:12 PM >>>


Netcraft reports that:

[snip]

A power outage at an Advance Internet hosting facility
has hobbled the web sites for the company's chain of
more than 30 newspapers, including many large metropolitan
dailies. 
[...]

Report: Major Newspaper Sites Hobbled by Power Woes

[Fergie (Paul Ferguson)]

Netcraft reports that:

[snip]

A power outage at an Advance Internet hosting facility
has hobbled the web sites for the company's chain of
more than 30 newspapers, including many large metropolitan
dailies. The Advance newspapers have switched to text-based
sites to continue publishing, but are currently unable to
display advertising, making the outage a potentially costly
event.

Affected sites include NJ.com, Michigan Live, Cleveland.com,
The Portland Oregonian and the online classifieds site
BestLocalJobs.com and Best LocalAutos.com. One of the
affected papers, The New Orleans Times-Picayune, is in
the midst of covering the impact of Tropical Storm Cindy,
which hit the New Orleans area yesterday and has left more
than 240,000 local residents without power as well.

[snip]

http://news.netcraft.com/archives/2005/07/06/major_newspaper_sites_hobbled_by_power_woes.html

- ferg

--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 [EMAIL PROTECTED] or [EMAIL PROTECTED]
 ferg's tech blog: http://fergdawg.blogspot.com/

Re: OMB: IPv6 by June 2008

[Edward Lewis]

At 10:57 -0400 7/6/05, Scott McGrath wrote:


IPv6 would have been adopted much sooner if the protocol had been written
as an extension of IPv4 and in this case it could have slid in under the
accounting departments radar since new equipment and applications would
not be needed.


Sliding anything past the accountants is bad practice.  Is the goal 
to run IPv6 or to run a communications medium to support society?  If 
it costs $1M to adopt IPv6 in the next quarter, what would you take 
the $1M from?  (I used to work at a science research center.  Having 
a good network wasn't the goal, doing science was.  Without good 
science, there would be no FY++ budget for a better network.)


The Internet serves society, society owes nothing to the Internet. 
Members of this list may prioritize communications technology, other 
members of society may prioritize different interests and concerns. 
That is why IPv6 must offer a benefit greater than it's cost.


--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis+1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.

Re: OMB: IPv6 by June 2008

[Daniel Golding]

There is an element of fear-mongering in this discussion - that's why many
of us react poorly to the idea of IPv6. How so?

- We are running out of IPv4 space!
- We are falling behind <#insert scary group to reinforce fear of Other>!
- We are not on the technical cutting edge!

Fear is a convenient motivator when facts are lacking. I've read the above
three reasons, all of which are provable incorrect or simple fear mongering,
repeatedly. The assertions that we are falling behind the Chinese or
Japanese are weak echoes of past fears.

The market is our friend. Attempts to claim that technology trumps the
market end badly - anyone remember 2001? The market sees little value in v6
right now. The market likes NAT and multihoming, even if many of us don't.

Attempts to regulate IPv6 into use are as foolish as the use of fear-based
marketing. The gain is simply not worth the investment required.

- Daniel Golding

On 7/6/05 11:41 AM, "Scott McGrath" <[EMAIL PROTECTED]> wrote:

> 
> 
> You do make some good points as IPv6 does not address routing scalability
> or multi-homing which would indeed make a contribution to lower OPEX and
> be easier to 'sell' to the financial people.
> 
> As I read the spec it makes multi-homing more difficult since you are
> expected to receive space only from your SP there will be no 'portable
> assignments' as we know them today.  If my reading of the spec is
> incorrect someone please point me in the right direction.
> 
> IPv6's hex based nature is really a joy to work with IPv6 definitely fails
> the human factors part of the equation.
> 
> Scott C. McGrath
> 
> On Wed, 6 Jul 2005, David Conrad wrote:
> 
>> On Jul 6, 2005, at 7:57 AM, Scott McGrath wrote:
>>> IPv6 would have been adopted much sooner if the protocol had been
>>> written
>>> as an extension of IPv4 and in this case it could have slid in
>>> under the
>>> accounting departments radar since new equipment and applications
>>> would
>>> not be needed.
>> 
>> IPv6 would have been adopted much sooner if it had solved a problem
>> that caused significant numbers of end users or large scale ISPs real
>> pain.  If IPv6 had actually addressed one or more of routing
>> scalability, multi-homing, or transparent renumbering all the hand
>> wringing about how the Asians and Europeans are going to overtake the
>> US would not occur.  Instead, IPv6 dealt with a problem that, for the
>> most part, does not immediately affect the US market but which
>> (arguably) does affect the other regions.  I guess you can, if you
>> like, blame it on the accountants...
>> 
>> Rgds,
>> -drc
>> 

-- 
Daniel Golding
Network and Telecommunications Strategies
Burton Group

Re: Recall: SORBs

[Suresh Ramasubramanian]

On 06/07/05, Alex Rubenstein <[EMAIL PROTECTED]> wrote:
> What is scarier --
> 
> a) microsoft providing this feature
> 
> b) someone with the ability to type "conf t, router bgp",
> connected to the global internet, and thinking
> that recalling a message would work?
> 

[b] most assuredly

[a] has its uses, when used internally in an exchange groupware environment

-- 
Suresh Ramasubramanian ([EMAIL PROTECTED])

Re: OMB: IPv6 by June 2008

[Scott McGrath]

You do make some good points as IPv6 does not address routing scalability
or multi-homing which would indeed make a contribution to lower OPEX and
be easier to 'sell' to the financial people.

As I read the spec it makes multi-homing more difficult since you are
expected to receive space only from your SP there will be no 'portable
assignments' as we know them today.  If my reading of the spec is
incorrect someone please point me in the right direction.

IPv6's hex based nature is really a joy to work with IPv6 definitely fails
the human factors part of the equation.

Scott C. McGrath

On Wed, 6 Jul 2005, David Conrad wrote:

> On Jul 6, 2005, at 7:57 AM, Scott McGrath wrote:
> > IPv6 would have been adopted much sooner if the protocol had been
> > written
> > as an extension of IPv4 and in this case it could have slid in
> > under the
> > accounting departments radar since new equipment and applications
> > would
> > not be needed.
>
> IPv6 would have been adopted much sooner if it had solved a problem
> that caused significant numbers of end users or large scale ISPs real
> pain.  If IPv6 had actually addressed one or more of routing
> scalability, multi-homing, or transparent renumbering all the hand
> wringing about how the Asians and Europeans are going to overtake the
> US would not occur.  Instead, IPv6 dealt with a problem that, for the
> most part, does not immediately affect the US market but which
> (arguably) does affect the other regions.  I guess you can, if you
> like, blame it on the accountants...
>
> Rgds,
> -drc
>

Re: SORBs

[Alex Rubenstein]

Perhaps the networks are disconnected? Perhaps there is insufficient 
bandwidth between the cities to carry inter-city traffic?


Sounds somewhat familiar to

http://www.arin.net/policy/proposals/2004_5.html



On Wed, 6 Jul 2005, Andre Oppermann wrote:



Sanfilippo, Ted wrote:
It belonged to some Canadian ISP, I believe it was a cable company. 
Regarding the aggregation/deaggregation mess. This is due to the fact

that ARIN is rather strict with IP assignements and how we route
internally. Because ARIN wants us to use 80% of our ip blocks, before we 
can request

new assignments from them we have to dole out addresses in /22's to each
city we have, in order to use them up appropriately. Its been a bit of a
nightmare trying to meet ARIN's policies and also try to meet the
Internet Communities policies. Believe me, I would much rather advertise
a /16 prefix out to the Internet, rather then a /22. We have not been
able to accommodate this unfortunately. 


Err...  Why do you say you need to advertise a /22 for each city rather
than the /16 for your entire network?  What's inside your network and
how you distribute your addresses there is not of concern for anyone
outside of your network.  Why don't you advertise the /16 via BGP and
then let the IGP handle the /22 distribution to each city?




--
Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben
Net Access Corporation, 800-NET-ME-36, http://www.nac.net

Re: OMB: IPv6 by June 2008

[David Conrad]

On Jul 6, 2005, at 7:57 AM, Scott McGrath wrote:
IPv6 would have been adopted much sooner if the protocol had been  
written
as an extension of IPv4 and in this case it could have slid in  
under the
accounting departments radar since new equipment and applications  
would

not be needed.


IPv6 would have been adopted much sooner if it had solved a problem  
that caused significant numbers of end users or large scale ISPs real  
pain.  If IPv6 had actually addressed one or more of routing  
scalability, multi-homing, or transparent renumbering all the hand  
wringing about how the Asians and Europeans are going to overtake the  
US would not occur.  Instead, IPv6 dealt with a problem that, for the  
most part, does not immediately affect the US market but which  
(arguably) does affect the other regions.  I guess you can, if you  
like, blame it on the accountants...


Rgds,
-drc

Re: Recall: SORBs

[Alex Rubenstein]

On Wed, 6 Jul 2005, Sanfilippo, Ted wrote:


Sanfilippo, Ted would like to recall the message, "SORBs".





What is scarier --

a) microsoft providing this feature

b) someone with the ability to type "conf t, router bgp",
connected to the global internet, and thinking
that recalling a message would work?


/action crawls back into his hole





--
Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben
Net Access Corporation, 800-NET-ME-36, http://www.nac.net

RE: SORBs

[Jon Lewis]

On Wed, 6 Jul 2005, Sanfilippo, Ted wrote:

> Regarding the aggregation/deaggregation mess. This is due to the fact
> that ARIN is rather strict with IP assignements and how we route
> internally.
> Because ARIN wants us to use 80% of our ip blocks, before we can request
> new assignments from them we have to dole out addresses in /22's to each
> city we have, in order to use them up appropriately. Its been a bit of a

Are you saying you have POPs in dozens of cities and do not have your own
network connecting them, but instead buy transit from verio, cogent, and
at&t in each city and announce /22 subnets to them from each of these POPs
using the same (15270) origin ASN with ASN loop detection disabled?

 > nightmare trying to meet ARIN's policies and also try to meet the
> Internet Communities policies. Believe me, I would much rather advertise
> a /16 prefix out to the Internet, rather then a /22. We have not been
> able to accommodate this unfortunately.
>
> -Original Message-
> From: Jon Lewis [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 06, 2005 10:31 AM
> To: Sanfilippo, Ted
> Cc: nanog@merit.edu
> Subject: Re: SORBs
>
> On Wed, 6 Jul 2005, Sanfilippo, Ted wrote:
>
> > Does anyone know of an easier way to remove IP blocks from a
> blacklist?
> > We received a /16 from ARIN in May and have been trying to get SORB's
> > to remove the blacklist association on these addresses. They seem to
> > take forever to remove the blacklist association.
>
> --- 06Jul05 ---
> ASnum  NetsNow  NetsAggrNetGain % Gain
> Description
> AS1527031159  25281.0%
> AS-PAETEC-NET - PaeTec.net -a division of PaeTecCommunications, Inc.
>
> Any chance of this deaggregation mess getting cleaned up?
>
> I've contacted sorbs on your behalf, assuming the /16 concerned is
> 63.138.0.0/16.  This raises a question that interests me as someone who
> had to deal with recently bogon space last time I got ARIN space.
>
> 63/8 was assigned to ARIN in 1997.  Much of it appears to have been
> assigned to ARIN members in the late 90s and very early 2000's.  How did
> Paetec happen to get a /16 from 63/8 in 2005?  Was this recently
> reclaimed from some defunct company (which could explain the sorbs dul
> listing), and Paetec just got lucky?
>
> --
>  Jon Lewis   |  I route
>  Senior Network Engineer |  therefore you are
>  Atlantic Net|
> _ http://www.lewis.org/~jlewis/pgp for PGP public key_
>

--
 Jon Lewis   |  I route
 Senior Network Engineer |  therefore you are
 Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: SORBs

[Andre Oppermann]

Sanfilippo, Ted wrote:
It belonged to some Canadian ISP, I believe it was a cable company. 


Regarding the aggregation/deaggregation mess. This is due to the fact
that ARIN is rather strict with IP assignements and how we route
internally. 
Because ARIN wants us to use 80% of our ip blocks, before we can request

new assignments from them we have to dole out addresses in /22's to each
city we have, in order to use them up appropriately. Its been a bit of a
nightmare trying to meet ARIN's policies and also try to meet the
Internet Communities policies. Believe me, I would much rather advertise
a /16 prefix out to the Internet, rather then a /22. We have not been
able to accommodate this unfortunately.  


Err...  Why do you say you need to advertise a /22 for each city rather
than the /16 for your entire network?  What's inside your network and
how you distribute your addresses there is not of concern for anyone
outside of your network.  Why don't you advertise the /16 via BGP and
then let the IGP handle the /22 distribution to each city?

--
Andre

Recall: SORBs

[Sanfilippo, Ted]

Sanfilippo, Ted would like to recall the message, "SORBs".

RE: SORBs

[Sanfilippo, Ted]

It belonged to some Canadian ISP, I believe it was a cable company. 

Regarding the aggregation/deaggregation mess. This is due to the fact
that ARIN is rather strict with IP assignements and how we route
internally. 
Because ARIN wants us to use 80% of our ip blocks, before we can request
new assignments from them we have to dole out addresses in /22's to each
city we have, in order to use them up appropriately. Its been a bit of a
nightmare trying to meet ARIN's policies and also try to meet the
Internet Communities policies. Believe me, I would much rather advertise
a /16 prefix out to the Internet, rather then a /22. We have not been
able to accommodate this unfortunately.  

-Original Message-
From: Jon Lewis [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 06, 2005 10:31 AM
To: Sanfilippo, Ted
Cc: nanog@merit.edu
Subject: Re: SORBs

On Wed, 6 Jul 2005, Sanfilippo, Ted wrote:

> Does anyone know of an easier way to remove IP blocks from a
blacklist?
> We received a /16 from ARIN in May and have been trying to get SORB's 
> to remove the blacklist association on these addresses. They seem to 
> take forever to remove the blacklist association.

--- 06Jul05 ---
ASnumNetsNow  NetsAggrNetGain % Gain
Description
AS15270311  59  25281.0%
AS-PAETEC-NET - PaeTec.net -a division of PaeTecCommunications, Inc.

Any chance of this deaggregation mess getting cleaned up?

I've contacted sorbs on your behalf, assuming the /16 concerned is
63.138.0.0/16.  This raises a question that interests me as someone who
had to deal with recently bogon space last time I got ARIN space.

63/8 was assigned to ARIN in 1997.  Much of it appears to have been
assigned to ARIN members in the late 90s and very early 2000's.  How did
Paetec happen to get a /16 from 63/8 in 2005?  Was this recently
reclaimed from some defunct company (which could explain the sorbs dul
listing), and Paetec just got lucky?

--
 Jon Lewis   |  I route
 Senior Network Engineer |  therefore you are
 Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: OMB: IPv6 by June 2008

[Scott McGrath]

We are already behind in innovation as most networks these days are run by
accountants instead of people with an entrepaneur's sprit.   We need good
business practices so that the network will stay afloat financially I do
not miss the 'dot.com' days.

But what we have now is an overemphasis on cost-cutting and like it or not
IPv6 implementation is seen as a 'frill' which will not reduce OPEX.  I
really fear we have lost the edge here in the west due to too much
emphasis on the cost side of the equation ironically this has been driven
by the current network where financial information is available instantly
for decision making whereas in the past financial information about
far-flung operation took up to a year to to arrive so if a division was
profitable it was 'left alone' now with the instant availability we are
seeing profitable divisions of companies shut down because the numerical
analysis shows the capital could be used to generate a higher return
elsewhere.

Innovation is expensive and it does not return an immediate benefit and
right now all the average corporation cares about is the next quarter's
figures not whether the company will be profitable in 5 years.   We are
seeing many instances of companies eating their seed corn instead of
investing in the future.

IPv6 would have been adopted much sooner if the protocol had been written
as an extension of IPv4 and in this case it could have slid in under the
accounting departments radar since new equipment and applications would
not be needed.





Scott C. McGrath

On Thu, 30 Jun 2005, Fred Baker wrote:

>
> On Jun 30, 2005, at 5:37 PM, Todd Underwood wrote:
> > where is the service that is available only on IPv6? i can't seem to
> > find it.
>
> You might ask yourself whether the Kame Turtle is dancing at
> http://www.kame.net/. This is a service that is *different* (returns a
> different web page) depending on whether you access it using IPv6 or
> IPv4. You might also look at IP mobility, and the routing being done
> for the US Army's WIN-T program. Link-local addresses and some of the
> improved flexibility of the IPv6 stack has figured in there.
>
> There are a number of IPv6-only or IPv6-dominant networks, mostly in
> Asia-Pac. NTT Communications runs one as a trial customer network, with
> a variety of services running over it. The various constituent networks
> of the CNGI are IPv6-only. There are others.
>
> Maybe you're saying that all of the applications you can think of run
> over IPv4 networks a well as IPv6, and if so you would be correct. As
> someone else said earlier in the thread, the reason to use IPv6 has to
> do with addresses, not the various issues brought up in the marketing
> hype. The reason the CNGI went all-IPv6 is pretty simple: on the North
> American continent, there are ~350M people, and Arin serves them with
> 75 /8s. In the Chinese *University*System*, there are ~320M people, and
> the Chinese figured they could be really thrifty and serve them using
> only 72 /8s. I know that this is absolutely surprising, but APNIC
> didn't give CERNET 72 /8s several years ago when they asked. I really
> can't imagine why. The fact that doing so would run the IPv4 address
> space instantly into the ground wouldn't be a factor would it? So CNGI
> went where they could predictably get the addresses they would need.
>
> Oh, by the way. Not everyone in China is in the Universities. They also
> have business there, or so they tell me...
>
> The point made in the article that Fergie forwarded was that Asia and
> Europe are moving to IPv6, whether you agree that they need to or not,
> and sooner or later we will have to run it in order to talk with them.
> They are business partners, and we *will* have to talk with them. We,
> the US, have made a few my-way-or-the-highway stands in the past, such
> as "who makes cell phones" and such. When the rest of the world went a
> different way, we wound up be net consumers of their products.
> Innovation transfered to them, and market share.
>
> The good senator is worried that head-in-the-sand attitudes like the
> one above will similarly relegate us to the back seat in a few years in
> the Internet.
>
> Call him "Chicken Little" if you like. But remember: even Chicken
> Little is occasionally right.
>

Re: SORBs

[Jon Lewis]

On Wed, 6 Jul 2005, Sanfilippo, Ted wrote:

> Does anyone know of an easier way to remove IP blocks from a blacklist?
> We received a /16 from ARIN in May and have been trying to get SORB's to
> remove the blacklist association on these addresses. They seem to take
> forever to remove the blacklist association.

--- 06Jul05 ---
ASnumNetsNow  NetsAggrNetGain % Gain
Description
AS15270311  59  25281.0%
AS-PAETEC-NET - PaeTec.net -a division of PaeTecCommunications, Inc.

Any chance of this deaggregation mess getting cleaned up?

I've contacted sorbs on your behalf, assuming the /16 concerned is
63.138.0.0/16.  This raises a question that interests me as someone
who had to deal with recently bogon space last time I got ARIN space.

63/8 was assigned to ARIN in 1997.  Much of it appears to have been
assigned to ARIN members in the late 90s and very early 2000's.  How did
Paetec happen to get a /16 from 63/8 in 2005?  Was this recently reclaimed
from some defunct company (which could explain the sorbs dul listing), and
Paetec just got lucky?

--
 Jon Lewis   |  I route
 Senior Network Engineer |  therefore you are
 Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

RE: SORBs

[Sanfilippo, Ted]

We have been asking them to fix it for over a month now.  

-Original Message-
From: Suresh Ramasubramanian [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 06, 2005 9:51 AM
To: Sanfilippo, Ted
Cc: nanog@merit.edu
Subject: Re: SORBs

On 06/07/05, Sanfilippo, Ted <[EMAIL PROTECTED]> wrote:
> 
> Does anyone know of an easier way to remove IP blocks from a
blacklist?
> We received a /16 from ARIN in May and have been trying to get SORB's 
> to remove the blacklist association on these addresses. They seem to 
> take forever to remove the blacklist association.
> 

If it is a whole /16 you probably bought some old dynamic IP space that
was recycled - and then reassigned it to a datacenter, probably?

SORBS does respond, eventually.

--
Suresh Ramasubramanian ([EMAIL PROTECTED])

Re: SORBs

[Suresh Ramasubramanian]

On 06/07/05, Sanfilippo, Ted <[EMAIL PROTECTED]> wrote:
> 
> Does anyone know of an easier way to remove IP blocks from a blacklist?
> We received a /16 from ARIN in May and have been trying to get SORB's to
> remove the blacklist association on these addresses. They seem to take
> forever to remove the blacklist association.
> 

If it is a whole /16 you probably bought some old dynamic IP space
that was recycled - and then reassigned it to a datacenter, probably?

SORBS does respond, eventually.

-- 
Suresh Ramasubramanian ([EMAIL PROTECTED])

SORBs

[Sanfilippo, Ted]

 


Does anyone know of an easier way to remove IP blocks from a blacklist?
We received a /16 from ARIN in May and have been trying to get SORB's to
remove the blacklist association on these addresses. They seem to take
forever to remove the blacklist association.
 
Thanks
 

Ted

Re: The whole alternate-root ${STATE}horse

[Michael . Dillon]

> 1. Security ("man-in-the-middle").

VPNs, SSH tunnels, etc. There are ways to solve
this problem.

> 2. Common interoperability.

We do not currently have common interoperability for a
whole range of protocols. The most obvious examples are
instant messaging and P2P file transfer but there are many
more when you start digging. Often common interoperability
is not desired by the end users and they are the ones who
determine what succeeds at the end of the day.

> 3. *Common sense.*  [Erm, oh yeah, perhaps I shouldn't feed the troll.
>After all, this is the same guy who thinks that resurrecting the
>long dead concept of source routed e-mail is scalable.]

Since when did the NANOG mailing list become your personal
venue for flinging personal insults at other list members?
For the record, I have never suggested that source-routing
is a good idea for email nor have I ever suggested that
source-routing is scalable. Some people who read my comments
on email architecture jumped to knee-jerk conclusions (the
wrong conclusions) that I wanted to resurrect UUCP bang-paths.
God knows where they got that idea from.

> You really should read RFC2826 sometime.  It's quite short, as RFCs go.

I have read it and I appreciate the IAB's comments, but it
was written at a time when we didn't have as much experience
with rootless networks as we do now. The work of various people
in Freenet and other P2P technologies shows that it may indeed
be technically feasible to have a DNS that does not have one
single monolithic root. 

Received wisdom is always interesting, but sometimes it is wrong.
Remember the IETF mantra? Working code and rough consensus.
There are two groups that currently have working code and they
are cooperating with each other which means that the work is
being done in an atmosphere of "rough consensus". The end result
is that they *WILL* *WIN* the debate unless you and other naysayers
can point out specific and unresolvable technical issues with 
their work. The gist of the discussion on this list has been that
people don't *LIKE* the alt roots, that they don't *FEEL* good
about the idea, that they *FEAR* the possible outcomes. Those
are not technical issues.

I realize that there are some people on this list that want
to enforce the one true religion of Internet and discourage
non-believers from joining the club, but I don't agree with
that approach. I believe that it is better to let the free flow
of ideas continue because the Internet is robust enough to
survive and thrive in the face of countless experiments including
people announcing huge AS-paths and people running alternate
DNS roots. Bring it on!

--Michael Dillon

Re: The whole alternate-root ${STATE}horse

[Todd Vierling]

On Wed, 6 Jul 2005, [EMAIL PROTECTED] wrote:

> >The reverse problem is more difficult to deal with -- that of
> > people wanting to access Chinese (or whatever) sites that can only be
> > found in the Chinese-owned alternative root.
>
> There was a time when email service was almost universally
> bundled with Internet access service. Nowadays it is
> quite common for people to get their email service from
> a different supplier than their access. There is no reason
> why DNS resolution could not similarly be unbundled from access.

1. Security ("man-in-the-middle").

2. Common interoperability.

3. *Common sense.*  [Erm, oh yeah, perhaps I shouldn't feed the troll.
   After all, this is the same guy who thinks that resurrecting the
   long dead concept of source routed e-mail is scalable.]

You really should read RFC2826 sometime.  It's quite short, as RFCs go.

> If the Internet is to become a global universal network then, by
> definition, it must become balkanized.

Fragmenting the namespace with "alternate" TLDs, breaking common
interoperability, is hardly a path to "universal."  BZZZT, try again.

-- 
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: OT? /dev/null 5.1.1 email

[Brad Knowles]

At 1:27 AM -0400 2005-07-06, [EMAIL PROTECTED] wrote:


 And in fact, given that most link hiccups *are* transitory, the chances
 are *good* that if our attempts at the first MX fail, the link will be
 back before we finish running through the MX's - at which point we find
 ourselves talking to a spamtrap.


	Which is why I prefer to set up a tarpit as my high-MX spamtrap, 
but not make it do anything permanent or even long-lasting.  If 
you're a legitimate sender talking to my tarpit, it'll take you a 
while to discover that you can't make it through, and you should be 
able to successfully retransmit at a later time.  If you're a 
spammer, it'll take you a while to discover you can't make it 
through, but then you probably won't try again.


--
Brad Knowles, <[EMAIL PROTECTED]>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755

  SAGE member since 1995.  See  for more info.

Re: OT? /dev/null 5.1.1 email

[Tony Finch]

On Wed, 6 Jul 2005, Pekka Savola wrote:
> On Tue, 5 Jul 2005, Adi Linden wrote:
> >
> > Make your secondary mx aware of all the valid recipient addresses.
>
> Are there mechanisms in postfix or sendmail to do this automatically, or
> should this be done out-of-band?  I've tried looking for this feature, but
> found nothing; maybe I don't know the right terms to search for.

Exim supports call-forward recipient verification, using syntax like
"require verify = recipient/callout". This is very useful if you have any
kind of organizational complexity in your email system which makes it hard
for an MX to know which local parts are valid in all of its domains.

For example, my MXs relay email to about 50 departmental email servers and
act as a secondary MX for some other domains. We have no special knowledge
of which addresses are valid in these domains, and it would be hard to
make that possible because of the variety of software running on the
departmental email servers. However if they are run well such that they
completely verify their recipient addresses during the SMTP conversation,
then so can we.

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

Re: OT? /dev/null 5.1.1 email

[Tony Finch]

On Tue, 5 Jul 2005, Jim Popovitch wrote:
>
> Presumably sending smtp servers do have spools, however given the range
> of things that send email these days... who really knows?

Things that send email without having a spool cannot route email
according to RFC 974, so they are not a problem for MXs.

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

Re: The whole alternate-root ${STATE}horse

[Tony Finch]

On Wed, 6 Jul 2005 [EMAIL PROTECTED] wrote:
>
> There is no reason why DNS resolution could not similarly be unbundled
> from access. Yes, there would be some latency issues to deal with, but
> they are not insurmountable.

There are security problems too.

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

Re: The whole alternate-root ${STATE}horse (was Re: Enable BIND cache server to resolve chinese domain name?)

[Tony Finch]

On Wed, 6 Jul 2005, Brad Knowles wrote:
>
>   There's not much we can do to stop the alternate roots.  They already
> exist, and at least two are currently in operation.  However, I think we can
> look at what it is that they're offering in terms of i18n and see what we can
> do to address those issues from inside the system.

They aren't offering i18n, they're offering l10n, because their systems
only work for a small localized community, not the whole international
Internet.

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

Re: The whole alternate-root ${STATE}horse

[Michael . Dillon]

>The reverse problem is more difficult to deal with -- that of 
> people wanting to access Chinese (or whatever) sites that can only be 
> found in the Chinese-owned alternative root.

There was a time when email service was almost universally
bundled with Internet access service. Nowadays it is 
quite common for people to get their email service from 
a different supplier than their access. There is no reason
why DNS resolution could not similarly be unbundled from access.
Yes, there would be some latency issues to deal with, but they
are not insurmountable.

And as I mentioned before, one easy way around all this is
for people who want to access content in a specific foreign
language to sign up for access with an ISP which provides
specific support for that foreign language. If you want to
get to sites in China using alternate domain names then you
simply buy your DSL line from an ISP who uses the alternate
roots. And as a bonus, you will probably also be able to get
technical support in Chinese as well.

All these people complaining about how this divides the 
Internet and makes it harder for them to talk to someone
in China seem to have missed the fact that there is already
a divide caused by different languages. If the Internet is
to become a global universal network then, by definition, 
it must become balkanized.

--Michael Dillon

Re: The whole alternate-root ${STATE}horse

[Michael . Dillon]

> So, if you're a content provider, why would you use anything other than 
a 
> real ICANN-recognized domain? 

An example was given earlier of a site using xn-- encoding to
use a non-Latin script in the TLD and domain name. If you are
a business in a country which uses non-latin scripts then
it is perfectly understandable why you would want to use
your real name rather than some pidgin representation like
Yoonahytid Steyts uv Amerika.

It is common in the corporate world for new products or
improved products to be "launched" with a marketing effort
through a wide variety of media. One sure way to get lots
of free media coverage would be for a company to use a 
non-ICANN domain and send instructions to ISPs on how 
to "enable" their network for the big new launch. The very
fact that people will have difficulty getting to the site
can be leveraged in a marketing campaign.

And what are domain names after all, if not marketing?

> or when 
> something is rolled out to a large enough self-contained user community 
> that the lack of ability to communicate outside that region won't be a 
> significant barrier.

That's generally how new things get a foothold...

--Michael Dillon

Re: OT? /dev/null 5.1.1 email

[Owen DeLong]

--On Tuesday, July 5, 2005 12:02 -1000 Randy Bush <[EMAIL PROTECTED]> wrote:




The principle purpose of the secondary mx, in this case, is to accept
email for the primary mx during periods where the primary is down


and the sending smtp server has no spool.  i.e. no useful
purpose.

today, the primary purpose of secondary mxs is to receive spam.


Or, perhaps one wants more direct control over the how long you can be down
before things bounce policy.  A secondary MX allows that.  The fuse on the
sending spool is at the discretion of the person running the senders 
mailserver.

The time limit on your secondary MX is, presumably, somewhat under your own
control.

There are other legitimate purposes as well.

Owen


--
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.


pgpGLjl5sjBit.pgp
Description: PGP signature

Worldnic does TCP-before-UDP DNS tricks, breaking powerdns recursor and those w/o TCP connectivity

[bert hubert]

Hi Nanog people,

The PowerDNS recursor has hit a snag resolving www.kde-look.org. It
appears Worldnic has implemented 'TCP-before-UDP' on ns{9,10}.worldnic.com,
whereby it sends out answers with the truncated bit set, and without an
actual answer. Once the client has re-asked the query over TCP, it from then
on allows UDP queries. This is possibly done to prevent DoS attacks.

This hits those people who've been running the pdns recursor w/o heeding the
warning on http://doc.powerdns.com/built-in-recursor.html stating our
inadequacies regarding truncated packets.

But is also hits everybody who only allows UDP port 53, which generally
works fine, except now! Recall the AOL huge packet event from way back. So
make sure your resolvers have TCP connectivity!

And yes, my message may read a bit like djb's back in the time AOL started
to use > 512 byte packets :-) The problem is solved in SVN luckily.

Apologies. But just a heads up that if you suddenly have non-working
Worldnic domains, you now know two possible causes.

A quick solution for PowerDNS recursor users is to run 'dig www.kde-look.org
@ns9.worldnic.com' periodically. Or upgrade to the SVN snapshot mentioned
below, but do note that it is experimental.

Wiki: http://wiki.powerdns.com/projects/trac/
Message: http://mailman.powerdns.com/pipermail/pdns-users/2005-July/002414.html
SVN snapshot solving the problem: http://ds9a.nl/pdns/pdns-2.9.18-svn.tar.gz

-- 
http://www.PowerDNS.com  Open source, database driven DNS Software 
http://netherlabs.nl  Open and Closed source services