Text 19, 136 rader
Skriven 2004-03-08 20:06:06 av Peter Knapper (3:772/1.10)
     Kommentar till text 15 av Mike Luther (1:117/3001.0)
Ärende: Privoxy - Ijfire help?
==============================
Hi Mike,

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

 ML> I'm not totally clear on this yet. 

Forward lookups point a Name at an Address, Reverse lookups point an address at
a Name. If the reverse result is the SAME as the original query, then you have
a good confirmation that the IP address provided by the original query is
probably genuine. The catch to this is that you will find more and more sites
may be using a "leased" address which will point back at the lease supplier,
not the lease user.

 ML> But there is 
 ML> documentation in the Injoy forewall which says 
 ML> something about not being able to currently use reverse 
 ML> lookups.

That may be just a warning about the above situation...

 ML> is this how 
 ML> the Privoxy and firewalled boxes might be failing from 
 ML> timing errors?

I doubt it, validating DNS entries has to be done with care, and the "home
user" is rarely in a position to be able to guarantee this.

 ML> Thus maybe the IP is using reverse DNS for such 
 ML> authentication and differences in timing from dis and 
 ML> dat evoke this failure?  

Nope, I am pretty sure they are unrelated.

 ML> And also see 
 ML> what else I'm curious about in my answer to him as to 
 ML> how one might hijack an OS/2 box virally via java wich 
 ML> I don't know enough about as yet?   Puppy is curious.

I note from recent announcements (like in the last week or so), that Java does
have some sort of security issue that people are in a flap about but I am not a
big Java user so can't say sorry...

 ML> I need some teaching here. 

A brief reply might be...

There are several ways in which a DNS server can work, a PRIMARY or SECONDARY
server are AUTHORITATIVE for the DOMAINS they serve, IE they contain the real
live genuine data. Any other DNS server that holds and provides that info is
NON-AUTHORITATIVE. If you use NSLOOKUP and access the PRIMARY DNS server for
your ISP, then any query for an ISP resource should NOT include the line
         Non-authoritative answer:
in the reply. Query a resource NOT owned by your ISP (EG: www.ibm.com) and you
should see that line.

NSLOOKUP is not the best of such tools, but its the most common provided.
Within NSLOOKUP, try doing -
  server "your isp's primary name server"
then query a domain your ISP serves. Then try a domain they do NOT serve. Then
do -
  server A.ROOT-SERVERS.NET
and repeat the lookup. This will give you an idea of how long to query a domain
starting from the root. You will find A.ROOT... down to M.ROOT...

A DNS server can also be a Caching server (actually all DNS's cache, but some
ONLY cache, they are non-authoritative for ALL replies. If a DNS does not have
the info it is asked for, then usually it asks the ROOT DNS server for details
of the DOMAIN OWNERS DNS server, however some cacheing servers are told to
point to another server first. The search process repeats down the domain
owners chain until a query times out or a reply comes back from either the
PRIMARY server for the target DOMAIN, or from a cached reply somewhere. If you
want to guarantee an authoritative reply, then you need to find the name
servers FOR a Domain, and just query them.

Thats it in a very brief nutshell. To "prove" your DNS problem, you could
install your own Cacheing DNS, and feed it ONLY the ROOT DNS Servers, leaving
ALL other DNS servers out of the picture. The down side to this is you will
have to wait for the Domain resolution process to run whenever you request info
for a new DOMAIN. However this will be offset once your own Cache is full
(until the info expires). If you have reasonably frequent (IE less than the
expire time for the records) contact with about 80% of your regular DNS
references, then you should notice little difference in performance, and this
may in fact improve performance (particularly if your ISP has real DNS issues),
but it WILL prove the theory about your ISP's DNS methodolgy.

NOTE: DNS expire times for static names are usually measured in days, if not
weeks. Even some dynamic DNS servers only update every 12 hours, others update
every 15 - 30 mins (but thats excessive IMHO). Using NSLOOKUP, set type=any and
query a domain, you should see a lot of detail in those records. Interesting,
do this for YOUR domain, the expire time should be the same as your DHCP update
time if your ISP is hosting your domain...

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

 ML> Yep.

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

 ML> Betcha that is involved. 

Do you know if YOUR ISP links its DNS Servers, to its DHCP Servers in any way?
I am wondering if they are flooding their own DNS with a mass of "dynamic"
updates, and this is forcing their DNS's to empty their own Cache, meaning they
have to re-load all following queries from scratch. It takes time for this to
propogate to the "slave" servers you use, hence why you have these long pauses.
This is really basic DNS stuff and I would be amazed that an ISP is not aware
of this type of situation.


 ML> In order to 
 ML> answer this it looks like I have to have proof that the 
 ML> "update" took place at a given time and the failure 
 ML> time matched it.  

Does the ZyXel date/timestamp the DHCP updates? If so compare those with your
DNS delay issues, AND then your ISP records...

The ONLY reason for such frequent DHCP updates that I can see, relates to a
security issue over DHCP leases, and that is simply a bad choice of delivery
architecture. It sounds like they are authenticating at the Layer 2 level, and
that is so easy to "break" its not funny. If they authenticated at the Layer 3
level, then they would have a much better chance of securing the links.
Unfortunately this would probably mean a large expense to re-equipe their
network.

Cheers.........pk.


--- Maximus/2 3.01
 * Origin: Another Good Point About OS/2 (3:772/1.10)