Text 15, 134 rader
Skriven 2004-03-07 08:36:12 av Mike Luther (1:117/3001.0)
     Kommentar till text 13 av Peter Knapper (3:772/1.10)
Ärende: Privoxy - Ijfire help?
==============================
Mikey is trying to learn some more here..

 PK> Thats not surprising, a Firewall does not NEED a DNS 
 PK> to do its stuff, it may use one, but it does not HAVE 
 PK> to have one, and if it does, then it should NOT hold 
 PK> up operation if it can't resolve a name! I can see a 
 PK> FW needing a DNS for reverse lookups, but not forward 
 PK> lookups, and it should not impact on other application 
 PK> performance.

I'm not totally clear on this yet.  Studying this more externally to the
message here.  But there is documentation in the Injoy forewall which says
something about not being able to currently use reverse lookups.

Thus ... alarm bell is ringing in puppy's ears here.  If the host DNS server
has been set up, as some now are, I think I recall, to require reverse DNS
lookup for certification of authenticity, as part of the growing 'protection'
from smash and dash, is this how the Privoxy and firewalled boxes might be
failing from timing errors?

Thus maybe the IP is using reverse DNS for such authentication and differences
in timing from dis and dat evoke this failure?  They use it on the caching
second tier servers and not the primary?  Wondering..

 PK> The resolv file will be for the dialer, and it
 PK> probably gets massaged each dial-up depending on what 
 PK> DNS is fed from the PPP connection. Remember that 
 PK> InJoy will be massaging your Routing whenever a dial-
 PK> up connection is established, hence why the file 
 PK> date/timestamp changes.

Well so I've thought.  But then I don't drink coffee.  I never did anything my
Dad told me to do as a kid - he learned to tell me the opposite to get me to do
things, grin!  So he told me to drink coffee, larger grin!  And for the gist of
this, see Will Honea's answer to me on what JAVA does with this "resolv" file. 
And also see what else I'm curious about in my answer to him as to how one
might hijack an OS/2 box virally via java wich I don't know enough about as
yet?   Puppy is curious.

 PK> That should be irrelevant, a PRIMARY DNS Server will 
 PK> only be Primary for the Domain(s) it directly 
 PK> services, for all other domains, it is the same as a 
 PK> caching server anyway... Now it may be that they have 
 PK> a problem specfic to the caching only server(s), and 
 PK> this is sounding plausible, especially if they tie in 
 PK> with the DHCP Server.

I need some teaching here.  I don't pretend to be any expert at any of this.
Can you help teach me what a "caching" server is and does so I can better
understand this answer and my own question, grin?

 PK> You have a static IP, yes? If so, does that Static address keep being 
 PK> "updated" at semi-regular intervals,

Yep.

 PK> and if so, are
 PK> those updates co-inciding with your loss of DNS 
 PK> resolution?

Betcha that is involved.  But to test this I'll have to go down to COX locally
here in BC-S and sit down in person with the network folks.  When it gets to
this detail level, I've found that about the only way I can dig at it in detail
enough to solve things is physically go talk to them here.  In order to answer
this it looks like I have to have proof that the "update" took place at a given
time and the failure time matched it.  On DHCP, not fixed addresses, they
originally started out making updates every two hours on this cable area!  
This was (is) their largest cable market in the USA at a given location what
with Texas A&M and all the students.  They were losing so many connections to
Aggie hacking and sharing of addresses with roomies and whatever, they felt
like they had to force re-issue that often or even sooner to catch the perps! 
As well, they extended that concept to my fixed address at one time.  It was a
disaster here with OS/2.

I originally ran into this update issue and loss of DNS in my DHCP connection
to them both with the fixed address as well as dialup at remote and sometimes
unattended sites.  So they eventually backed off and allowed the commercial
sites they serve to be updated on what I think finally became a two day cycle. 
As part of this mess, to stabilize the connection 24X7 that is when I first
installed the ZyXel on the master fixed-address cable site.

 PK> If so, then there is probably a link
 PK> between the DHCP Server updates and the DNS server 
 PK> updates, and there is a synchronisation issue 
 PK> somewhere between them. Perhaps the primary Servers 
 PK> are being updated ok, but not the pure caching Servers.

Remember, I'm learning or trying to learn here from everyone, Peter.  And from
listening carefully to the tech support gent on the phone, I think this is
exactly what is happening that is breaking this.  The master site at Tyler is
given the priority and the secondary sites are not updated until later, maybe
much later.

 PK> Also, what happens if your ISP DHCP updates WHILE 
 PK> Injoy is connected, who wins that tug-o-war???

That is what was going bonk originally.  You'd be connected.  Every two hours
the ISP DHCP would be updated, actually every TWENTY MINUTES when this first
started with the Aggie pranging.  Then they capitulated and went to an hour,
then two hours.  Which was still a total disaster for the remote communications
sites which might need to be up all night and so on.  So in the huddle, we
agreed that for the COMMERCIAL folks' connections with side-straddle dial-up
back support, they would go to a two day cycle time. That's exactly how I
finally got my remote site where the ham station is to be able to survive a
whole DX contest weekend solid connect without the whole logging program and
inter-related cluster and logging operations failing mid-contest.  After
testing with me for a while, they eventually adopted the change in policy and
differential re-up time system wide, so they told me, for their fixed-IP
accounts.

 ML> You have to be assigned service and 
 ML> connected to a for-real server pair and not a caching 
 ML> server!

 PK> I think you will find this is not strictly the case, I 
 PK> use a caching DNS here and it works flawlessly for me, 
 PK> but only when I had it set up correctly.

I don't deny this, now that I am learning some more.  But, as I've seen here
the concept of 'correctly' is the subject of emotional coloration at times it
seems, chuckle.

See my answer to Will Honea for something else which has surfaced I'm curious
about in re this "resolv" file issue, please.

Thanks.,.


--> Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001

--- Maximus/2 3.01
 * Origin: Ziplog Public Port (1:117/3001)