Date: Tue, 30 Nov 93 04:30:04 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #309
To: tcp-group-digest
TCP-Group Digest Tue, 30 Nov 93 Volume 93 : Issue 309
Today's Topics:
Barry's IP Problem
Domain resolution (5 msgs)
subscribe
subsctribe
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Tue, 30 Nov 93 11:09:11 UTC
From: vk4grl@vk4grl.clayfield.ampr.org
Subject: Barry's IP Problem
To: tcp-group@ucsd.edu
R:931130/1109z @:VK4GRL.QLD.AUS.OC [Clayfield, Qld]
I seem to recall that one of the NOS versions had a VC mode connection using
"ipcam" i.e. camouflaged ip using the text PID. If you used that there would
be no way the digi could determine that you were carrying IP - the sysop
would be forced to do it manually. Would he eventually give up?
In Australia there is a requirement the all stations licensed as repeaters
be made available for use by ALL amateurs. This could conceivably give
some statuory protection to our right to use a digipeater.
Graham
------------------------------
Date: Mon, 29 Nov 93 13:30:11 EST
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: Domain resolution
To: gateways@mpg.phys.hawaii.edu
I was wondering how user are configuring the domain lookup,
especially in regard to NOS. Because of local restrictions
at the moment I need to point the local troops domain lookup
to a machine on our class B network. This machine uses JNOS.
IT in turn uses a VAX on the class B as it lookup.
What is happenning is that the JNOS domain cache and also
updating of domain.txt is making the lookup fail in some cases.
If a bad address gets stuck in the cache and then later gets
written to domain.txt, it never seems to expire and gets used
in lieu of going on to the VAX dns. I can set the cache size to
1 and the 'dom wait' to some very large number and this should
stop it. Is this what I should do?
I have to look at the code - a command that would be really nice
is a 'domain cache flush' Sometimes it is nearly impossible to
get an address out of the cache. I would like to turn the cache
off altogether in this machine, so that it is merely a go between
of the 44 and local class B network.
The other problem seems to go beyond the local issue. IT seems
that the ampr.org addresses do not propagate very quickly when
they are updated at ucsd. Also the expiration values are very
large (800,000+ seconds) and NOS never seems to get rid of them.
Is anyone else having these problems?
Doug
------------------------------
Date: Mon, 29 Nov 93 10:09:56 HST
From: Antonio Querubin <tony@mpg.phys.hawaii.edu>
Subject: Domain resolution
To: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
> What is happenning is that the JNOS domain cache and also
> updating of domain.txt is making the lookup fail in some cases.
>
> If a bad address gets stuck in the cache and then later gets
> written to domain.txt, it never seems to expire and gets used
> in lieu of going on to the VAX dns. I can set the cache size to
> 1 and the 'dom wait' to some very large number and this should
> stop it. Is this what I should do?
Does 'domain clean on' expire the bad records or are they so badly
mangled that they just stick. Also, do you re-initialize your
domain.txt from a clean startup file upon bootup? If you have a
reliable connection to the local DNS, you don't really need to be
saving the added domain.txt entries.
> The other problem seems to go beyond the local issue. IT seems
> that the ampr.org addresses do not propagate very quickly when
> they are updated at ucsd. Also the expiration values are very
> large (800,000+ seconds) and NOS never seems to get rid of them.
Re-initialize your domain.txt. Then at least NOS wont hang onto them
(between boots). I've seen old DNS entries linger for several weeks
around here. BTW, NOS will look like a non-authoritative server for
the entries it has cached. That might confuse other DNS on the same
network.
Tony
------------------------------
Date: Mon, 29 Nov 93 15:38:00 EST
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: Domain resolution
To: crompton@NADC.NADC.NAVY.MIL, tony@mpg.phys.hawaii.edu
Ok Tony,
I have set my 'dom ca 1' in autoexec and have no domain.txt
file. Also I set the 'dom ca wait 32000' so that it will not
update the local domain file. This seems to work - I will let
you know.
The problem right now is that my home address wa3dsp.ampr.org
is stuck in the dns system somewhere as 44.80.8.75 - it should
be 44.80.8.120 and I updated ucsd (twice) over 6 days ago. So
much for dynamic changes.
Doug
------------------------------
Date: Mon, 29 Nov 93 15:38:00 EST
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: Domain resolution
To: crompton@NADC.NADC.NAVY.MIL, tony@mpg.phys.hawaii.edu
Ok Tony,
I have set my 'dom ca 1' in autoexec and have no domain.txt
file. Also I set the 'dom ca wait 32000' so that it will not
update the local domain file. This seems to work - I will let
you know.
The problem right now is that my home address wa3dsp.ampr.org
is stuck in the dns system somewhere as 44.80.8.75 - it should
be 44.80.8.120 and I updated ucsd (twice) over 6 days ago. So
much for dynamic changes.
Doug
------------------------------
Date: Mon, 29 Nov 1993 21:41:40 -0500 (EST)
From: John Stewart <JSTEWART@umiami.ir.miami.edu>
Subject: Domain Resolution
To: gateways@mpg.phys.hawaii.edu, tcp-group@ucsd.edu
As of one of the recent jnos versions, there is a command:
domain update off
This should solve the problem of creating a large domain.txt.
____________________________________
John, n4qi
Internet: jstewart@umiami.ir.miami.edu
AmprNet: n4qi@n4qi.ampr.org
------------------------------
Date: Mon, 29 Nov 93 08:01:03 CST
From: "John Martin" <martin@server.cdpa.state.ms.us>
Subject: subscribe
To: tcp-group@ucsd.edu
Please add me to your list.
73 -- John KB5GGO
------
_______
/ |
John W. Martin / | INTERNET:
Systems Programmer / | martin@server.cdpa.state.ms.us
Mississippi Central Data | C | oamartin@vm.cc.olemiss.edu
Processing Authority \ D | PACKET:
301 North Lamar Street | P | kb5ggo @ k5qne.ms.usa.na
301 Building, Suite 508 / A |
Jackson, MS 39201-1495 / | PHONE: (601) 359-2641
|______ | FAX: (601) 354-6016
/ |
\____|
------------------------------
Date: 29 Nov 93 11:18:04 EST
From: MITCHELL.T@OCF.compuserve.com
Subject: subsctribe
To: <tcp-group@ucsd.edu>
*Message:
From: MITCHELL.T at CCPO.KCPO
Date: 11/29/93 10:04AM
To: internet:tcp-group@ucsd.edu at OCF_INFORM
Subject: subsctribe
Contents:
subscribe tcp-group
------------------------------
End of TCP-Group Digest V93 #309
******************************
******************************