Re: Managing large http_access lists: alternative methods

>>>>> 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.

Just looking for other options at the moment. Dancer's idea is a
little sick & twisted, but that's good. 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.

(Or am I misunderstanding you, Dancer?)

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.

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

-Scott
Received on Mon Apr 13 1998 - 20:01:40 MDT