[nos-bbs] FTP wierd socket from domain.txt

[Jay Nugent]

Greetings,

On Sat, 26 May 2007, (Skip) K8RRA wrote:

> My neighbor is Dave (who also reads this reflector) and maybe he would
> attach a copy of it to email for you.  It probably originated from you
> but got revised by having the update switch ON.  As of today the update
> switch is OFF. 

   domain.txt is the DNS cache.  If you leave 'dom update off' then
anything new that gets looked up (by going out to the Internet for a
resolve) will *never* get written into the cache (domain.txt).  So now
EACH time someone needs to look that same host up will have to go through
the whole resolve process over and over and over again. 


> I have edited it - there were several things I threw
> away, plus two lines got concatenated somehow.  I need to chat with him
> before my edited version goes live - so I'll ask him to email you both
> versions for your inspection.

   Sounds like some write errors have occured.  I guess it can happen.  
Just edit out the cruft and put the file back in service, or grab a fresh 
copy off the DRG website:

      http://www.mi-drg.org/domain.txt

   This file was produced from all the Michigan 44.102/16 addresses in the
DNS as of March 21st 2007.  It should 'prime' your DNS cache quite nicely.


 
> >    # host 206.112.100.132
> >      132.100.112.206.in-addr.arpa is an alias for 132.128.100.112.206.in-addr.arpa.
> >      132.128.100.112.206.in-addr.arpa domain name pointer unknown.
> > 
> >    Looks like the DNS 'ptr' record points to another record which then 
> > points to no where :(
>
> Hey - some day you might want to lead me thru that 40-bit address above
> - neither 32 nor 64 bit / I don't want to know today...

   That's *not* a 40-bit address.  It's an FQDN (Fully Quallified Domain 
Name) just like "Hamgate.Ottawa.AMPR.org".  Just because it has numbers in 
it doesn't make it an IP address, though granted it does look like one.  
It could say anything, like "I.want.my.I.want.my.MTV.k8rra.net'  :-/

   So where we would use the following line to map an FQDN to an IP:
      hamgate.ottawa.ampr.org.  IN  A  44.102.132.1

   We us a similar record to map an IP to an FQDN (for reverse lookup):
      44.102.132.1  IN  PTR  1.132.102.44.in-addr.arpa.
          -- or --
      44.102.132.1  IN  PTR  hamgate.ottawa.ampr.org.

   It is just a pairing of IP-v-FQDN in the DNS database, one for a
"forward" lookup, the other for a "reverse" lookup.  *Usually* they should
match (except where the upstream owner of a block of IP addresses maps
portions of that block to its customers - and that's a whole 'nother
disertation).



> >    So please fill me in as to what this has anything to do at all with 
> > regard to the 'rtimer' setting which controls the "IP reassembly 
> > time-out"?

> Here it is:
> Dave WA8RSA has been my link to the world for a year + and as you know
> we have struggled with thruput and reliability.  For example right now I
> have SMTP traffic for ve1ama in queue for the past 20 hrs.  His mail
> goes out sporadically at best, but eventually the path will clear and it
> will go (as in the past?).  Also there is mail for wa8rsa that already
> has been delivered 4 times and not removed from my queue.  I am waiting
> for SMTP to clear the queue so I can see the transaction difference from
> a trace I am running.

   Mail that gets delivered over and over and over usually is because by
the time the SMTP session is finishing up, the 'smtp timer' expires and
tries doing the whole dang process all over.  If you give the process more
time to finish it will complete the SMTP handshake indicating the message
has been passed and remove the job from the mqueue.  So up your smtp timer
to wait longer before trying again.

   smtp timer 900      <--- 15 minutes (was probably set to 5 mins)


   Another way to help getting SMTP mail through a bad RF connection is to
limit the box to only ONE session at a time by setting the maxclients to
1.

   smtp maxclients 1

   If you had 3 SMTP messages in the mqueue, when 'smtp timer' expires the
first job in the mqueue (lowest job number -- 123.wrk) will create a TCP
connection to the delivery destination, then pass the message over this
TCP connection using the SMTP protocol.

   The next time the 'smtp timer' expires, the next job in the mqueue
will be passed (via SMTP over a TCP connection).  And similarly the 3rd 
job will be passed on the next cycle, etc.

   By pacing them out this way it may take a little bit longer to get all
the messages delivered, but they won't all be trying to extablish
simultainious TCP connections and SMTP streams and tromple over one
another vying for the limited bandwidth on a poor RF path.



   But now that were're done with SMTP, back to FTP.  Which I'll answer in 
a seperate email.

      --- Jay Nugent  WB8TKL

"Getting rid of terrorism is like getting rid of dandruff.  It cannot
 be done completely no matter how hard you try." -- Gore Vidal
+------------------------------------------------------------------------+
| Jay Nugent   jjn at nuge.com    (734)484-5105    (734)544-4326/Fax        |
| Nugent Telecommunications  [www.nuge.com]     (734)649-0851/Cell       |
|   Internet Consulting/Linux SysAdmin/Engineering & Design/ISP Reseller |
| ISP Monitoring [www.ispmonitor.net] ISP & Modem Performance Monitoring |
| Web-Pegasus    [www.webpegasus.com] Web Hosting/DNS Hosting/Shell Accts|
| LinuxNIC, Inc. [www.linuxnic.net]   Registrar of the .linux TLD        |
+------------------------------------------------------------------------+
  6:01pm  up 76 days, 14:05,  3 users,  load average: 0.19, 0.06, 0.01