HDTenEightyP/NetNews huggingface dataset:
From: pz@modtor.uucp (Peter Ziobrzynski)
Subject: Re: YP/DNS problem with Suns&DECstations
Organization: Godcorp
Date: Fri, 22 Jan 1993 05:03:06 GMT

callahan@vax.oxford.ac.uk writes:

>I have a problem setting up DNS on a network of Suns running SunOS 4.1.1
>and DECstations running Ultrix v4.2a.  These share a single YP domain
>and there are servers among both the Suns and the DEC machines.

>The problem is setting up the Sun clients to use DNS.  As I understand
>it (and as I have done before), I should tell ypserv to issue DNS
>requests on behalf of its clients by giving the -b option to makedbm
>in the YP makefile.

>The catch is that when the Sun clients start up, some of them at least
>end up getting bound to a DEC machine.  Now, the Ultrix YP software doesn't
>know how to do DNS lookups, since in the DEC scheme the clients do
>this themselves.  The net result (so to speak!) is that some Sun clients
>don't get DNS service.

>What can I do? 

I have just finished almost exactly the same setup: 2 of SUN10/SunOS 4.1.3
and 4 of DEC5000/Ultrix4.3.
The solution is to run the YP and DNS master and slave servers on the SUN.
In this way all DEC and SUN ypbind bind to the SUN and SUN get the right
YP->DNS mapping.
The other way is to upgrade your SUN to Solaris 2.x and you will get the
right DNS/YP operation.

(Sun should be sued for damages caused by this YP/DNS fuckup).

-- 
Peter Ziobrzynski, pz@modtor.uucp, peter@sni.ca, Toronto, Ont. Canada
Newsgroups: comp.protocols.tcp-ip.domains
From: jbryans@csulb.edu (Jack Bryans)
Subject: Re: Positional data within DNS
Organization: Cal State Long Beach
	<VIXIE.93Jan24005212@cognition.pa.dec.com>
Distribution: inet
Date: Tue, 26 Jan 1993 17:56:01 GMT

In article <VIXIE.93Jan24005212@cognition.pa.dec.com> vixie@pa.dec.com (Paul A Vixie) writes:
> radians are a more rational (in my opinion) way to represent polar
> coordinates, but they are generally fractional.

Rational, yes, though a transcendental bent helps to see it that way.

Expressing an angle as a fraction of a circle has a number of computational
advantages.  Conversion amongst radians for math, DMS for maps & people, and
grads for arty are simple & straightforwrd.  Additionally, the properly
signed minor arc difference between two angles can be computed in 5
instructions, from load to store.

Scaling is not a problem, as the binary point is always after the sign bit.

Jack
Newsgroups: comp.protocols.tcp-ip.domains
From: hunen@brc.medtronic.com (Roger Hunen)
Subject: Re: Zone X'fer of the root  zone
Organization: Bakken Research Center BV
Date: Thu, 21 Jan 1993 11:44:18 GMT

In article <1993Jan20.063325.5722@sserve.cc.adfa.oz.au> Christopher.Vance@adfa.oz.au (Christopher JS Vance) writes:
>From: Christopher.Vance@adfa.oz.au (Christopher JS Vance)
>Subject: Re: Zone X'fer of the root  zone
>Date: Wed, 20 Jan 1993 06:33:25 GMT
>In article <1993Jan19.223905.22319@schbbs.mot.com> mshah@next3.corp.mot.com writes:
>| Is there a utility that I could use to do zone x'fer of the root zone. I  
>| tried DIG but it did not work. I also tried named-xfer but that did not  
>| work either. Any pointers ???
>
>You need to use ftp to get domain/root.zone from nic.ddn.mil.
>
>I don't know why a zone transfer doesn't work, but it doesn't.  I also
>wish it did, but don't know how hard it is to fix.  (Like, is it just
>BIND, or is it a problem with the way zone cuts are defined?)

Maybe root-zone transfers are restricted to secondary root servers? Just a 
long shot...

Regards,
-Roger
(I speak for myself)
From: mah@ic.co.at (Michael Haberler)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Bind & Dialup IP
Date: 24 Jan 1993 00:53:49 GMT
Organization: EUnet EDV-Dienstleistungsgesellschaft m.b.H
Distribution: world
Reply-To: mah@ic.co.at
NNTP-Posting-Host: ic.co.at

I'm looking for people's experience/opinions/setup recommendations
on DNS operation at a dialup-on-demand IP site.

I'd like to have our dialupIP subscribers use DNS, so they can use 
FQDN's instead of adresses for e.g. ftp. This works fine but has the
disadvantage of causing a dialup by nameserver traffic also for other
non obvious reasons. E.g. the reverse lookups generated by many applications
cause a dialup just for this query.

Another aspect: If the subscriber site has an authoritative NS for their
zone and we run secondaries, we could do a zone transfer only if the 
site is connected but not when our nameserver thinks he needs a xfer. We
dont want to dial the subscriber in general, and not for a zone xfer in
particular.

What do other people do in this situation?

-michael

-- 
Michael Haberler 			mah@eunet.co.at
EUnet Austria Ltd
A-1010 Vienna, Austria, Schottenring 33
Tel: +43 (1) 346184                             fax: +43 (1) 3104462
Newsgroups: comp.protocols.tcp-ip.domains,comp.sys.dec,comp.sys.sun.admin
From: sjaak@athena.research.ptt.nl (Sjaak Schilperoort)
Subject: Re: YP/DNS problem with Suns&DECstations
Originator: sjaak@athena.research.ptt.nl
Reply-To: J.W.Schilperoort@research.ptt.nl
Organization: PTT Research, The Netherlands
Date: Tue, 26 Jan 1993 20:23:45 GMT

pz@modtor.uucp (Peter Ziobrzynski) writes:

>callahan@vax.oxford.ac.uk writes:

>>I have a problem setting up DNS on a network of Suns running SunOS 4.1.1
>>and DECstations running Ultrix v4.2a.  These share a single YP domain
>>and there are servers among both the Suns and the DEC machines.

>>The problem is setting up the Sun clients to use DNS.  As I understand
>>it (and as I have done before), I should tell ypserv to issue DNS
>>requests on behalf of its clients by giving the -b option to makedbm
>>in the YP makefile.

>>The catch is that when the Sun clients start up, some of them at least
>>end up getting bound to a DEC machine.  Now, the Ultrix YP software doesn't
>>know how to do DNS lookups, since in the DEC scheme the clients do
>>this themselves.  The net result (so to speak!) is that some Sun clients
>>don't get DNS service.

>>What can I do? 

>I have just finished almost exactly the same setup: 2 of SUN10/SunOS 4.1.3
>and 4 of DEC5000/Ultrix4.3.
>The solution is to run the YP and DNS master and slave servers on the SUN.
>In this way all DEC and SUN ypbind bind to the SUN and SUN get the right
>YP->DNS mapping.
>The other way is to upgrade your SUN to Solaris 2.x and you will get the
>right DNS/YP operation.

Or get resolv+-2.1 from your nearest ftp-site. It replaces the resolver-
routines in the SunOS shared library. It supports a /etc/host.conf file,
much like the Ultrix /etc/svc.conf file. 

We are running with a DNS- and NIS-master on an Ultrix-server,
DNS-secondary and NIS-slave on the Sun-server and DNS-client and
NIS-client on all Sun/Ultrix workstations.

You can disable DNS-usage by setting an environment variable before
starting a program. We had to do that for mountd and sendmail.

>(Sun should be sued for damages caused by this YP/DNS fuckup).

Yeah.

>-- 
>Peter Ziobrzynski, pz@modtor.uucp, peter@sni.ca, Toronto, Ont. Canada

			Sjaak.
-- 
Sjaak Schilperoort                   J.W.Schilperoort@research.ptt.nl
PTT Research, The Netherlands
Newsgroups: comp.protocols.tcp-ip.domains,comp.sys.dec,comp.sys.sun.admin
From: tmurphy@convex.com (Tom Murphy)
Subject: Re: YP/DNS problem with Suns&DECstations
Organization: CONVEX Computer Corporation, Richardson, Tx., USA
Date: Tue, 26 Jan 1993 21:38:04 GMT
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

You can also do a ypset on the sun clients to force them to bind to a
sun server.   It is a lot less work :-)

tgm
--
================================================================================
Tom Murphy - tmurphy@convex.com       |  I am sorry I forgot.  I do have a
CONVEX System Integration and Support |  photographic memory, but I ran
Product Specialist                    |  out of film 8-)
From: cudep@csv.warwick.ac.uk (Ian Dickinson)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: Positional data within DNS
Date: 28 Jan 1993 11:14:16 -0000
Organization: Team Limpid's Meathead With Aptitude - Kunst und Wahnsinn
Distribution: inet
NNTP-Posting-Host: spatula.csv.warwick.ac.uk

In article <CKD.93Jan18123333@loiosh.eff.org> ckd@eff.org (Christopher Davis) writes:
>That said, returning to more substantive (and immediate) concerns, I like
>the idea of having a real, binary-format LL record to indicate location
>instead of overloading TXT.  Now, the real question; who'll write the RFC
>and put the code into BIND?

Not me unfortunately... but I would like to see this happen.

Of course, it would have to be optional, but I think enough people would
install the RR accurately for it to be useful.  Be nice to have a visual
ftp browser, and Brian Reids maps might stand a better chance of including
the non-UUCP-registered hosts...

Cheers,
-- 
\/ato - Ian Dickinson - NIC handle: ID17                   No-one is to molest
vato@csv.warwick.ac.uk  ...!mcsun!uknet!warwick!vato           the wombat when
/I=I/S=Dickinson/OU=CSV/O=Warwick/PRMD=UK.AC/ADMD= /C=GB/            anyone is
@c=GB@o=University of Warwick@ou=Computing Services@cn=Ian Dickinson  watching.
Newsgroups: comp.protocols.tcp-ip.domains
From: cary@scripps.edu (Steve Cary)
Subject: libresolv++ for SunOS 4.1.[23]
Reply-To: cary@scripps.edu
Organization: The Scripps Research Institute, La Jolla, CA
Date: Thu, 28 Jan 1993 01:15:02 GMT

Could somebody send me a pointer to the best version
of libresolv to be patched into a SunOS libc,
version 4.1.[23]..  I don't run NIS on my DNS master,
so I'd like to set things up to use DNS for every host lookup..

I know I have seen several references, but I can't seem to
put my hands on (or grep) them in my archives!

Thanks!!!!!!!!!

	-Steve
From: rich9256@mary.cs.fredonia.edu (Devin    Richards)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: TCP/IP to Ada interface????
Date: 28 Jan 93 18:55:53 GMT
Organization: Math / CS, State Univ. of N. Y. College at Fredonia
X-Newsreader: Tin 1.1 PL3


I am looking for packages or any type of software that would allow me to
interface TCP/IP with Ada.  Any help would be appreciated.
Please send me vendors/names/anything else!

Thanks in advance.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-
Devin Richards					SUNY College at Fredonia

          INTERNET: rich9256@mary.cs.fredonia.edu
          UUCP:  {ucbvax,rutgers}!sunybcs!mary!rich9256

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   It rolls down stairs alone or in pairs it runs over your neighbor's dog.
   It fits on your back it's great for a snack it's Log Log Log. 
   It's Log Log it's big it's heavy it's wood.
   It's Log Log it's better then bad it good!
   New Log from Blammo.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Newsgroups: comp.protocols.tcp-ip.domains
From: anton@analsyn.gts.org (Anton J Aylward)
Subject: Re: Positional data within DNS
Reply-To: anton@lethe.gts.org
Organization: ASCI: UNIX Database and Communications
X-Newsreader: TIN [version 1.1 PL8]
Distribution: inet
Date: Fri, 22 Jan 1993 21:25:33 GMT

Paul A Vixie (vixie@pa.dec.com) wrote:
: that is an EXCELLENT idea.  anybody for T_LL?  how about:

: xxx	in	ll	ddd.mm.ss.ew ddd.mm.ss.ns

If this is going to be used in geographical calculation
wouldn't radians or something make sense?  Or is the factor
one of can we look it up in the printed maps in the local library?

--
Anton J Aylward	
	"The body politic is swerving from left to right and right to
	 left looking for quick fixes for systemic problems."
	   - Paul Palango, Journalist, ex The Globe and Mail
From: andersa@Riga.DoCS.UU.SE (Anders Andersson)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: Positional data within DNS
Date: 22 Jan 93 19:40:06 GMT
Distribution: inet
Organization: Uppsala University, Sweden
NNTP-Posting-Host: riga.docs.uu.se

In article <1jghnrINNl8v@daisy.ee.und.ac.za>, barrett@daisy.ee.und.ac.za (Alan P Barrett) writes:
> Now that we are considering a 32 bit structure, why not just use a signed
> 32 bit value to represent multiples of 2**-23 degrees?  (Or think of it
> as a fixed point format:  sign bit, 8 integer bits, 23 fraction bits.)

I agree to the single value (makes for simpler processing), but I
think the base unit should be the second, and not the degree, to
avoid unintuitive rounding of what is displayed after the user
has entered integer degrees, minutes and seconds (ok, the display
routine could probably make an educated guess as to what the
original data was, but why make it difficult in the first place).

To cram even more data into the bits, the fractional second might
be something different from a mere power of two.
--
Anders Andersson, Dept. of Computer Systems, Uppsala University
Paper Mail: Box 325, S-751 05 UPPSALA, Sweden
Phone: +46 18 183170   EMail: andersa@DoCS.UU.SE
Newsgroups: comp.protocols.tcp-ip.domains,comp.unix.large
From: vixie@pa.dec.com (Paul A Vixie)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: Positional data within DNS
Date: 24 Jan 93 00:52:12
Organization: DEC Network Software Lab
Distribution: inet
NNTP-Posting-Host: cognition.pa.dec.com
In-reply-to: anton@analsyn.gts.org's message of Fri, 22 Jan 1993 21:25:33 GMT

> If this is going to be used in geographical calculation
> wouldn't radians or something make sense?  Or is the factor
> one of can we look it up in the printed maps in the local library?

radians are a more rational (in my opinion) way to represent polar
coordinates, but they are generally fractional.  i'm not sure this
matters, since the best idea i've heard so far is to allocate N bits
for the coordinate and then choose a unit that will maximize 
resolution for the neccessary range.  thousandths of seconds would fit
in an unsigned 32-bit integer, for example.  my bit-field idea was
over-designed.  if we use radians rather than degrees, we have to pick
an implied decimal point, or we need someone who knows more than i do
about floating point arithmetic to pick the encoding.  i suppose we
could define it as a network-byte-order 32-bit IEEE float (that's a
joke, please, nobody shoot me.)
--
Paul Vixie, DEC Network Systems Lab	
Palo Alto, California, USA         	"Don't be a rebel, or a conformist;
<vixie@pa.dec.com> decwrl!vixie		they're the same thing, anyway.  Find
<paul@vix.com>     vixie!paul		your own path, and stay on it."  -me
From: vixie@pa.dec.com (Paul A Vixie)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: Decimal units in DNS (was Re: Positional data within DNS)
Date: 27 Jan 93 15:35:48
Organization: DEC Network Software Lab
Distribution: inet
NNTP-Posting-Host: cognition.pa.dec.com
In-reply-to: jcurran@nic.near.net's message of 26 Jan 1993 21:39:36 -0500

> Would anyone object if the mapping for pseudo-decimals were fixed
> in the future?

the 4.8.3 implementation allows these decimal-like numbers _everywhere_,
not just in serial numbers.  in 4.9 they will be accepted only for serial
numbers and the decimal interpretation will be a compile-time option 
(shipped "enabled" by default).

i, like john, would like to know if anyone will miss them.
--
Paul Vixie, DEC Network Systems Lab	
Palo Alto, California, USA         	"Don't be a rebel, or a conformist;
<vixie@pa.dec.com> decwrl!vixie		they're the same thing, anyway.  Find
<paul@vix.com>     vixie!paul		your own path, and stay on it."  -me
Xref: sparky comp.protocols.tcp-ip.domains:914 comp.sys.dec:7168 comp.sys.sun.admin:10849
From: whg@inel.gov (Bill Gray)
Newsgroups: comp.protocols.tcp-ip.domains,comp.sys.dec,comp.sys.sun.admin
Subject: Re: YP/DNS problem with Suns&DECstations
Date: 27 Jan 93 18:50:20 GMT
Organization: Idaho National Engineering Laboratory, Idaho Falls, Idaho

In article <tmurphy.728084284@mikey>, tmurphy@convex.com (Tom Murphy) writes:
|> You can also do a ypset on the sun clients to force them to bind to a
|> sun server.   It is a lot less work :-)

Yes,  but if and when that server gets slow (or unavailable -- the ultimate
slow),  then the client re-binds.  Then you are back to square 1.

========== long legal disclaimer follows, press n to skip ===========

Neither the United States Government or the Idaho National Engineering
Laboratory or any of their employees, makes any warranty, whatsoever,
implied, or assumes any legal liability or responsibility regarding any
information, disclosed, or represents that its use would not infringe
privately owned rights.  No specific reference constitutes or implies
endorsement, recommendation, or favoring by the United States
Government or the Idaho National Engineering Laboratory.  The views and
opinions expressed herein do not necessarily reflect those of the
United States Government or the Idaho National Engineering Laboratory,
and shall not be used for advertising or product endorsement purposes.
From: barrett@lucy.ee.und.ac.za (Alan Barrett)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: Bind & Dialup IP
Date: 27 Jan 93 08:08:15 GMT
Distribution: inet
Organization: Elec. Eng., Univ. Natal, Durban, S. Africa
NNTP-Posting-Host: lucy.ee.und.ac.za

In article <1jspatINNbqa@hp4at.eunet.co.at>,
mah@ic.co.at writes:
> I'm looking for people's experience/opinions/setup recommendations on
> DNS operation at a dialup-on-demand IP site.

An interesting problem.  I have some ideas, but no answers.

> I'd like to have our dialupIP subscribers use DNS, so they can use
> FQDN's instead of adresses for e.g. ftp. This works fine but has the
> disadvantage of causing a dialup by nameserver traffic also for other
> non obvious reasons. E.g. the reverse lookups generated by many
> applications cause a dialup just for this query.

Most of the isolated systems could be configured to use a single host
as a forwarder, and this forwarder system could be authoritative for
all the zones that refer to hosts in the isolated area.  That should
cope with the forward and the in-addr.arpa lookups generated by one of
the isolated hosts asking about another of the isolated hosts.

> Another aspect: If the subscriber site has an authoritative NS for
> their zone and we run secondaries, we could do a zone transfer only
> if the site is connected but not when our nameserver thinks he needs
> a xfer. We dont want to dial the subscriber in general, and not for a
> zone xfer in particular.

You could use a wrapper around named-xfer to handle this.  Rename
named-xfer to named-xfer.real, and write a wrapper named-xfer that does
whatever magic is needed to check whether the desired primary server is
connected.  If it is not connected, then check whether the zone is
about to expire, and if it is still reasonably fresh then exit with the
appropriate error status.  If the server is connected, or if the zone
is getting stale, then exec named-xfer.real

--apb
Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
RFC822: barrett@ee.und.ac.za
From: jcurran@nic.near.net (John Curran)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Decimal units in DNS (was Re: Positional data within DNS)
Date: 26 Jan 1993 21:39:36 -0500
Organization: New England Academic and Research Network
Distribution: inet
NNTP-Posting-Host: nic.near.net

In article <VIXIE.93Jan24005212@cognition.pa.dec.com> vixie@pa.dec.com (Paul A Vixie) writes:
>radians are a more rational (in my opinion) way to represent polar
>coordinates, but they are generally fractional.  i'm not sure this
>matters, since the best idea i've heard so far is to allocate N bits
>for the coordinate and then choose a unit that will maximize 
>resolution for the neccessary range.  thousandths of seconds would fit
>in an unsigned 32-bit integer, for example.  my bit-field idea was
>over-designed.  if we use radians rather than degrees, we have to pick
>an implied decimal point, or ...

On a tangential topic:
 
   In the bind beta code, is the zone file read routine (db_load.c) still
disfunctional with respect to decimal SOA records?  Last time I looked,
the code was as such:

	while (digit or .) {
		if (ch=digit) n=n*10+digit_val
		if (ch=.) n=n*1000
        }

which works great for most values ('1.2' becomes 10002, etc.), but overflows
for such things as '9212.001' (which becomes 9212000001 !).  Would anyone
object if the mapping for pseudo-decimals were fixed in the future?

/John
From: D.Nash@utexas.edu (Donald L. Nash)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: Zone X'fer of the root  zone
Date: 25 Jan 93 23:56:36 GMT
Organization: University of Texas System Office of Telecommunication Services


In article <1993Jan20.063325.5722@sserve.cc.adfa.oz.au>,
Christopher.Vance@adfa.oz.au (Christopher JS Vance) writes:
>I don't know why a zone transfer doesn't work, but it doesn't.

Zone transfers of the root zones don't work because the root nameservers
have zone transfers disabled.  This is to keep people from transferring
the huge root and first-level zones and thus overloading the
already-overworked root nameservers.  As it was pointed out, the root
zone files are available via FTP, and this is how they want you to get them.

                                Donald L. Nash

Internet:  D.Nash@utexas.edu    The University of Texas System
BITNET:    DON@THENIC           Office of Telecommunication Services
Newsgroups: comp.protocols.tcp-ip.domains
From: fcawth@wam.umd.edu (Alfred B. Cawthorne)
Subject: Domain name for uucp site
Organization: University of Maryland, College Park
Date: Mon, 25 Jan 1993 20:25:43 GMT

Does anybody know if it is possble to register a domain name for a uucp site?
I've seen messages saying something like "uucp maps being replaced by routing 
tables, etc", but I have no idea who to contact for such a request.  
The site in question has a reliable uucp feed from an internet site, but they
don't want to have to get a leased line since there is limited traffic.
I'd like to get it on the .EDU domain if that's possible.  If not, I remember 
something about a .US domain that people have used, but I lost the info on that
somewhere...  

Any info would be greatly appreciated.

   Thanks.
  fcawth@delphi.umd.edu
From: vixie@pa.dec.com (Paul A Vixie)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: Zone X'fer of the root  zone
Date: 26 Jan 93 19:39:46 GMT
	<1993Jan20.063325.5722@sserve.cc.adfa.oz.au> <86627@ut-emx.uucp>
Distribution: inet
Organization: DEC Network Systems Lab
NNTP-Posting-Host: cognition.pa.dec.com
In-reply-to: D.Nash@utexas.edu's message of 25 Jan 93 23:56:36 GMT

>Zone transfers of the root zones don't work because the root nameservers
>have zone transfers disabled.  This is to keep people from transferring
>the huge root and first-level zones and thus overloading the
>already-overworked root nameservers.  As it was pointed out, the root
>zone files are available via FTP, and this is how they want you to get them.
>
>                                Donald L. Nash

well, there's that, but there's also a nasty bug in BIND 4.8.3 (fixed in 4.9,
thanks to Alan Barrett) that keeps root zone transfers from working at all,
regardless of administrative restrictions.
--
Paul Vixie, DEC Network Systems Lab	
Palo Alto, California, USA         	"Don't be a rebel, or a conformist;
<vixie@pa.dec.com> decwrl!vixie		they're the same thing, anyway.  Find
<paul@vix.com>     vixie!paul		your own path, and stay on it."  -me
Newsgroups: comp.protocols.tcp-ip