Re: Managing large http_access lists: alternative methods

Scott Lystig Fritchie wrote:
>
> >>>>> On Thu, 09 Apr 1998 17:01:40 +1000, Lincoln Dale <ltd@interlink.com.au> said:
>
> ld> Why not implement the 'block filter' on your border routers? one
> ld> statement, and will always work.
>
> That would involve a fight with my fellow senior engineers here, who
> have some definite ideas about what core routers should and should not
> be doing. In theory, as we finish the in-progress transition so that
> "core" routers are actually only doing "core" router stuff, there
> might be enough CPU leftover to make the pessimistic engineers say,
> "OK". :-) ... Though I seem to recall an argument over use of input
> vs. output filters on Ciscos, and the "output filters take less work"
> argument won ... which, if true, would make the "ip access-group N in"
> fight more difficult to win.

Hmm, yeah. You've got to watch the filtering on Ciscos, otherwise you
suddenly wind up shoved from hardware to software switching without
notice.

> Just looking for other options at the moment. Dancer's idea is a
> little sick & twisted, but that's good.

Ooo, you smooth-talking devil, you... :)

> The idea would make all
> in-addr.arpa queries weird, which would probably be OK. (Only logging
> by IP now anyway.) To limit the amount of weirdness, I'd have to have
> one of these bastard name servers running locally on each of my caches
> and thus have the hassle of updating each of them.

Assuming they're all within easy network reach of each-other, you can
just install it on one, and have the others refer all DNS queries back
to it.

> (Or am I misunderstanding you, Dancer?)

You spotted that the idea was sick and twisted..that speaks volumes for
your comprehension :)

> But to take a slightly different approach ... if I were to make a
> small hack to Squid such as:
>
> acl legit_customers revdomainhack squidok.mr.net
>
> ... which would work similarly to the in-addr.arpa domain or Vixie's
> maps.vix.com anti-SPAM blackhole method. If a query comes in from
> A.B.C.D, assume that the "D" is irrelevant (to make the DNS zones
> smaller), then look up C.B.A.squidok.mr.net (or A.B.C.squidok.mr.net).
> If there's a PTR record there, then OK, otherwise deny the request.

Hmm. There's a distinct element of cleverness in that. There's also the
possibility of actually modifying the dnsserver, I daresay.

> Would involve source hackery, but I'm not above doing that, and it
> would keep me clear of the core router jockeys.... :-)

Indeed. Being a lazy guy at heart (mark my words: Fitness enthusiasts
did not invent power-tools, or escalators) I look for simple,
straightforward solutions...on the principle that they are likely to be
less fragile than more complex solutions, as well as more maintainable.
Of course, if a more complex way is obviously The Right Thing(tm), then
that's the way to go. But I'm still very keen on simple. Even if it _is_
a little sick and twisted :)

D

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GAT d- s++: a C++++$ UL++++B+++S+++C++H++U++V+++$ P+++$ L+++ E-
W+++(--)$ N++ w++$>--- t+ 5++ X+() R+ tv b++++ DI+++ e- h-@
------END GEEK CODE BLOCK------
Received on Mon Apr 13 1998 - 20:24:58 MDT