From owner-freebsd-net  Sun Dec  6 01:21:50 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id BAA04623
          for freebsd-net-outgoing; Sun, 6 Dec 1998 01:21:50 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from poboxer.pobox.com (port95.prairietech.net [208.141.230.95] (may be forged))
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA04617
          for <net@freebsd.org>; Sun, 6 Dec 1998 01:21:44 -0800 (PST)
          (envelope-from alk@poboxer.pobox.com)
Received: (from alk@localhost)
	by poboxer.pobox.com (8.9.1/8.9.1) id DAA50265;
	Sun, 6 Dec 1998 03:20:19 -0600 (CST)
	(envelope-from alk)
From: Tony Kimball <alk@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Sun,  6 Dec 1998 03:20:18 -0600 (CST)
X-Face: \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.<li^!8ecK]}3L-
	6`ZQW3}kxy*5]B<KA"&iBl58"/$W-0PP`B7c%'XczR)8T0VN47L`rQlu8qBIX4TJ|v'D%:k7GO%v4A
	Os>Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO
	5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed
Reply-To: alk@pobox.com
To: net@FreeBSD.ORG
Subject: resolver behaviour
References: <13929.39477.406338.806610@avalon.east>
	<199812052221.RAA10079@khavrinen.lcs.mit.edu>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <13930.17883.922553.625725@avalon.east>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Quoth Garrett Wollman on Sat, 5 December:
: <<On Sat,  5 Dec 1998 14:48:34 -0600 (CST), Tony Kimball <alk@pobox.com> said:
: 
: > Instead, to the best of my current understanding, the resolver
: > presently returns failure if it encounters a responding nameserver
: > which reports a negative lookup response.  This hardly seems
: > appropriate for systems with interfaces on distinct, unconnected
: > networks!
: 
: That is what the protocol says it must do.  

The network protocol doesn't regulate application behaviour.  In this
light, the issue I raise has nothing to do with network protocol, but
with the usability of the resolver API.

: When an authoritative
: NXDOMAIN is received, the search stops immediately.  

This is an accurate description of the current behaviour of
gethostby*.  I can easily write a routine with functionality which
is superior to that behaviour for the overwhelming majority of
applications, in that it will enable those applications to naively
connect to the remote host to which they are attempting to connect.  I
don't know of any application which would be ill-served by this
enhancement, therefore I suggest that it should be incorporated
into libc as default behaviour.  Is there any reason why it should not?
That depends on how the enhancements are obtained...

: You need to
: decide which side your machine's stub resolver is supposed to sit on.

Upon reflection, I really don't want to run a nameserver on the
firewall at all.  I just want to be able to successfully resolve names
  1) on disjoint networks from a common host, and
  2) in the presence of nameservers returning bad negative responses.
     (a surprisingly common occurence in the present Internet milieu).
One way of doing this is to apply POLA and try the nameservers of
resolv.conf in succession.  In order to avoid waiting for timeouts,
I suggested simultaneous queries...

Quoth Gary Palmer on Sat, 5 December:
: Can you say `packet storm'? I knew you could ... All our servers here run 
: local nameservers, and only have secondary nameserver entries listed for the 
: rare occasions named core dumps. I don't want to go increasing the ammount of 
: UDP traffic...

Then I refine my suggestion:  Rather than making queries simultaneous,
let them be issued in succession with a configurable pause interval
intervening, and stopping if/when a positive response is recieved.

: Seems your problem is not the resolver, but your nameserver setup. 

~99% of the nodes on the Internet are managed by entities with no
control over their DNS environment, which is almost invariably
defective in a variety of ways.  I'd like to improve the behaviour
of applications under FreeBSD in this environment, while avoiding any
untoward effects such as the 'packet storm' you describe.

Frankly, the current behaviour is just plain broken:  Bum nameservers
too often prevent FreeBSD applications from connecting to extant
hosts on the Internet.

: My guess is 
: problems arise from doing lookups on `internal' addresses on `external' 
: nameservers? 

This is one source of problems, but there are others.  Again, the DNS
environment on the Internet as a whole is very poor.

: The correct solution then is to run a nameserver on the firewall, 

I think this is only desirable if there exists a network which depends
upon the firewall for nameservice; otherwise, it is a *kludge* to work
around a bug in gethostby*!

: and force it to bind only to 127.0.0.1. You use that in your resolv.conf, and 
: teach it enough about the topology to answer properly.

But this only pushes the problem out one level, to named.  Archie's
patch then fixes the problem.  (I'd like to see that patch in
current!)  I'd like to also solve the problem at the first line of
defense, gethostby*, because then it is also solved for non-servers.

Quoth Kevin J. Rowett on Sat, 5 December:
: If one nameserver responses name invalid, another responses with
: an address, which would you consider to be the correct answer?

The address, because it often works.  The point is to get the job done.
Any application (if such an application were to exist) which wanted
to assume that a negative reply was valid could rely upon non-default
behaviour in gethostby*.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Sun Dec  6 04:21:50 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id EAA21437
          for freebsd-net-outgoing; Sun, 6 Dec 1998 04:21:50 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from gjp.erols.com (alex-va-n008c079.moon.jic.com [206.156.18.89])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA21430
          for <net@FreeBSD.ORG>; Sun, 6 Dec 1998 04:21:48 -0800 (PST)
          (envelope-from gjp@gjp.erols.com)
Received: from gjp.erols.com (localhost.erols.com [127.0.0.1])
	by gjp.erols.com (8.9.1/8.8.7) with ESMTP id HAA48030;
	Sun, 6 Dec 1998 07:21:45 -0500 (EST)
	(envelope-from gjp@gjp.erols.com)
X-Mailer: exmh version 2.0.1 12/23/97
To: alk@pobox.com
cc: net@FreeBSD.ORG
From: "Gary Palmer" <gpalmer@FreeBSD.ORG>
Subject: Re: resolver behaviour 
In-reply-to: Your message of "Sun, 06 Dec 1998 03:20:18 CST."
             <13930.17883.922553.625725@avalon.east> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 06 Dec 1998 07:21:45 -0500
Message-ID: <48026.912946905@gjp.erols.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Tony Kimball wrote in message ID
<13930.17883.922553.625725@avalon.east>:
> Frankly, the current behaviour is just plain broken:  Bum nameservers
> too often prevent FreeBSD applications from connecting to extant
> hosts on the Internet.

If the local nameserver is bum, then that suggests a local administrative 
failure, does it not? This is exactly the situation you are describing ... the 
local nameserver that the resolver contacts cannot find the information it is 
looking for. If, on the other hand, the local nameserver cannot find 
authoratitive information from a *NON-LOCALLY* hosted zone, then that is a 
failure which no ammout of hackery in libc will be able to overcome because in 
all likelyhood the data you are looking for just *doesn't* exist, because of a 
remote administrative failure. Slowing down the applications acceptance of 
that fact will do nothing to help our users impression of FreeBSD (``It takes 
5 times as long for freebsd to tell me a host doesn't exist as it does for 
linux ... why? YOU SUCK!!!''). I can tell you right now, that apart from the 
*VERY* rare of case of poisoned DNS cache, if you did this change in the 
environment I run at work, that is *exactly* what would happen. We'd have 
sendmail processes hanging around `n' times longer than they should have, 
because our nameserver setup *works*. Going to a different nameserver will get 
you exactly the same answer. It would surprise me that in the majority of the 
situations out there that there would be a significant number of cases where 
your change would help any.

> : My guess is 
> : problems arise from doing lookups on `internal' addresses on `external' 
> : nameservers? 
> 
> This is one source of problems, but there are others.  Again, the DNS
> environment on the Internet as a whole is very poor.

No, I think you are trying to fix the wrong problem here. bind is very good 
about handling internet failures in general. Its not libresolv's job to try 
and second guess what bind is doing. I say again: your nameserver setup is 
broken. You are really confusing the work that bind does with the work that 
libresolv does.

> I think this is only desirable if there exists a network which depends
> upon the firewall for nameservice; otherwise, it is a *kludge* to work
> around a bug in gethostby*!

Perhaps you are suggesting a kludge in gethostby* to work around a broken 
setup? Thats sure the way it reads to me.

> But this only pushes the problem out one level, to named.

I don't follow. You tell named that data for `x' is found on `x's namesevrer, 
and data for everything else is found on `y's nameserver, and it works. Thats 
how named is designed to work! It is *not* how libresolv is designed to work!

> Archie's patch then fixes the problem.  (I'd like to see that patch in
> current!)

If it goes in -current, then it had better be off by default. I firmly believe 
that this is a negatively impacting change for the majority of freebsd users 
out there. Make your appeals to the core team if you like, but I don't think 
that they'll be any more supportive of this change than I am.

Gary
--
Gary Palmer                                          FreeBSD Core Team Member
FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Sun Dec  6 08:10:06 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id IAA09580
          for freebsd-net-outgoing; Sun, 6 Dec 1998 08:10:06 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from lily.ezo.net (lily.ezo.net [206.102.130.13])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA09575;
          Sun, 6 Dec 1998 08:10:04 -0800 (PST)
          (envelope-from jflowers@ezo.net)
Received: from crocus (c3-1d196.neo.rr.com [24.93.233.196])
	by lily.ezo.net (8.8.7/8.8.7) with SMTP id LAA01244;
	Sun, 6 Dec 1998 11:09:51 -0500 (EST)
Message-ID: <000d01be213b$625d6eb0$848266ce@crocus.ezo.net>
From: "Jim Flowers" <jflowers@ezo.net>
To: <freebsd-hackers@FreeBSD.ORG>, <freebsd-net@FreeBSD.ORG>
Subject: Help with TCP listen() function
Date: Sun, 6 Dec 1998 12:10:53 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000A_01BE2111.78BC2770"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01BE2111.78BC2770
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I am trying to port a cable modem (roadrunner) login program written for =
linux to freebsd 2.2.7 before the Dec 15 deadline.  Should have been =
suspicious when it compiled cleanly without error message.

The program runs up to the point of setting up a TCP socket to request a =
login sequence using functions:

socket()
htons()
bind()
listen()

and then quits with errnum for "Operation not supported".

The function calls seem to be correctly written and do not return any =
errors when called (except for listen()).

Is this a correct sequence to establish a passive tcp connection?  Is =
there a better way to do it? Is there a knowledge base for converting =
linux code to run on FreeBSD?  References for the correct way to write =
code to establish tcp connections?

If a review of the code segment would be helpful, it is brief and =
follows.

Thanks
Jim Flowers <jflowers@ezo.net>


//------------------------------------------------------------
// RRListen() - Creates a listen socket for session status and
//              restart requests
int RRListen(unsigned short *listenport)
{
 unsigned short port;
   int s;
   struct sockaddr_in saddr;

   if ((s =3D socket (AF_INET, SOCK_DGRAM, 0)) < 0) {
      syslog(LOG_ERR, "Error creating listen socket: %m");
      return -1;
   }

 // Bind first available port starting at 7770
   port =3D 7770;
   saddr.sin_family =3D AF_INET;
   saddr.sin_addr.s_addr =3D INADDR_ANY;
   do {
    saddr.sin_port =3D htons(port);
      errno =3D 0;
      if (bind(s, (struct sockaddr *) &saddr, sizeof(struct =
sockaddr_in)) < 0) {
 if (errno !=3D EADDRINUSE) {
           syslog(LOG_ERR, "Error binding listen socket: %m");
           close(s);
           return -1;
         } else {
    port++;
         }
      }
 } while (errno =3D=3D EADDRINUSE);

 if (listen(s, 1) < 0) {
     syslog(LOG_ERR, "Error listening on socket: %m");
     close(s);
     return -1;
   }

   *listenport =3D port;
   syslog(LOG_INFO, "Established listener on port: %i", port);
   return s;
)
-------------------------------------------------------------------------=
------

------=_NextPart_000_000A_01BE2111.78BC2770
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>I am trying to port a cable modem =
(roadrunner)=20
login program written for linux to freebsd 2.2.7 before the Dec 15=20
deadline.&nbsp; Should have been suspicious when it compiled cleanly =
without=20
error message.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>The program runs up to the point of setting up a TCP =
socket to=20
request a login sequence using functions:</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>socket()</FONT></DIV>
<DIV><FONT size=3D2>htons()</FONT></DIV>
<DIV><FONT size=3D2>bind()</FONT></DIV>
<DIV><FONT size=3D2>listen()</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>and then quits with errnum for &quot;Operation not=20
supported&quot;.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>The function calls seem to be correctly written and =
do not=20
return any errors when called (except for listen()).</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Is this a correct sequence to establish a passive =
tcp=20
connection?&nbsp; Is there a better way to do it? Is there a knowledge =
base for=20
converting linux code </FONT><FONT size=3D2>to run on FreeBSD?&nbsp; =
References=20
for the correct way to write code to establish tcp =
connections?</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>If a review of the code segment would be helpful, it =
is brief=20
and follows.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Thanks</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Jim Flowers &lt;<A=20
href=3D"mailto:jflowers@ezo.net">jflowers@ezo.net</A>&gt;</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#000000=20
size=3D2>//------------------------------------------------------------<B=
R>//=20
RRListen() - Creates a listen socket for session status=20
and<BR>//&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
restart requests<BR>int RRListen(unsigned short=20
*listenport)<BR>{<BR>&nbsp;unsigned short port;<BR>&nbsp;&nbsp; int=20
s;<BR>&nbsp;&nbsp; struct sockaddr_in saddr;</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp; if ((s =3D socket =
(AF_INET,=20
SOCK_DGRAM, 0)) &lt; 0) {<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
syslog(LOG_ERR,=20
&quot;Error creating listen socket: =
%m&quot;);<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
return -1;<BR>&nbsp;&nbsp; }</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;// Bind first available port =
starting at=20
7770<BR>&nbsp;&nbsp; port =3D 7770;<BR>&nbsp;&nbsp; saddr.sin_family =3D =

AF_INET;<BR>&nbsp;&nbsp; saddr.sin_addr.s_addr =3D =
INADDR_ANY;<BR>&nbsp;&nbsp; do=20
{<BR>&nbsp;&nbsp;&nbsp; saddr.sin_port =3D=20
htons(port);<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; errno =3D=20
0;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (bind(s, (struct sockaddr *) =
&amp;saddr,=20
sizeof(struct sockaddr_in)) &lt; 0) {<BR>&nbsp;if (errno !=3D =
EADDRINUSE)=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
syslog(LOG_ERR, &quot;Error binding listen socket:=20
%m&quot;);<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
close(s);<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 return=20
-1;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } else=20
{<BR>&nbsp;&nbsp;&nbsp;=20
port++;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
}<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<BR>&nbsp;} while (errno =3D=3D=20
EADDRINUSE);</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;if (listen(s, 1) &lt; 0)=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp; syslog(LOG_ERR, &quot;Error listening on =
socket:=20
%m&quot;);<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
close(s);<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
return -1;<BR>&nbsp;&nbsp; }</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp; *listenport =3D =
port;<BR>&nbsp;&nbsp;=20
syslog(LOG_INFO, &quot;Established listener on port: %i&quot;,=20
port);<BR>&nbsp;&nbsp; return s;<BR>)</FONT></DIV>
<DIV><FONT color=3D#000000=20
size=3D2>----------------------------------------------------------------=
---------------</FONT></DIV></BODY></HTML>

------=_NextPart_000_000A_01BE2111.78BC2770--


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Sun Dec  6 08:17:28 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id IAA10327
          for freebsd-net-outgoing; Sun, 6 Dec 1998 08:17:28 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA10322;
          Sun, 6 Dec 1998 08:17:27 -0800 (PST)
          (envelope-from louie@whizzo.transsys.com)
Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1])
	by whizzo.transsys.com (8.9.1/8.9.1) with ESMTP id LAA54526;
	Sun, 6 Dec 1998 11:17:23 -0500 (EST)
	(envelope-from louie@whizzo.transsys.com)
Message-Id: <199812061617.LAA54526@whizzo.transsys.com>
X-Mailer: exmh version 2.0.2 2/24/98
To: "Jim Flowers" <jflowers@ezo.net>
cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG
From: "Louis A. Mamakos" <louie@TransSys.COM>
Subject: Re: Help with TCP listen() function 
References: <000d01be213b$625d6eb0$848266ce@crocus.ezo.net> 
In-reply-to: Your message of "Sun, 06 Dec 1998 12:10:53 EST."
             <000d01be213b$625d6eb0$848266ce@crocus.ezo.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 06 Dec 1998 11:17:22 -0500
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


The problem is that you're not trying to do a TCP "listen" operation; you're
creating a UDP datagram socket, and not a TCP (SOCK_STREAM) type socket.  The
listen system call isn't defined to work on datagram sockets because there
are no new connections to be accepted.

This is probably a freebsd-questions mailing list issue for any follow-up.

louie

> 
> ------=_NextPart_000_000A_01BE2111.78BC2770
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> 
> I am trying to port a cable modem (roadrunner) login program written for =
> linux to freebsd 2.2.7 before the Dec 15 deadline.  Should have been =
> suspicious when it compiled cleanly without error message.
> 
> The program runs up to the point of setting up a TCP socket to request a =
> login sequence using functions:
> 
> socket()
> htons()
> bind()
> listen()
> 
> and then quits with errnum for "Operation not supported".
> 
> The function calls seem to be correctly written and do not return any =
> errors when called (except for listen()).
> 
> Is this a correct sequence to establish a passive tcp connection?  Is =
> there a better way to do it? Is there a knowledge base for converting =
> linux code to run on FreeBSD?  References for the correct way to write =
> code to establish tcp connections?
> 
> If a review of the code segment would be helpful, it is brief and =
> follows.
> 
> Thanks
> Jim Flowers <jflowers@ezo.net>
> 
> 
> //------------------------------------------------------------
> // RRListen() - Creates a listen socket for session status and
> //              restart requests
> int RRListen(unsigned short *listenport)
> {
>  unsigned short port;
>    int s;
>    struct sockaddr_in saddr;
> 
>    if ((s =3D socket (AF_INET, SOCK_DGRAM, 0)) < 0) {
>       syslog(LOG_ERR, "Error creating listen socket: %m");
>       return -1;
>    }
> 
>  // Bind first available port starting at 7770
>    port =3D 7770;
>    saddr.sin_family =3D AF_INET;
>    saddr.sin_addr.s_addr =3D INADDR_ANY;
>    do {
>     saddr.sin_port =3D htons(port);
>       errno =3D 0;
>       if (bind(s, (struct sockaddr *) &saddr, sizeof(struct =
> sockaddr_in)) < 0) {
>  if (errno !=3D EADDRINUSE) {
>            syslog(LOG_ERR, "Error binding listen socket: %m");
>            close(s);
>            return -1;
>          } else {
>     port++;
>          }
>       }
>  } while (errno =3D=3D EADDRINUSE);
> 
>  if (listen(s, 1) < 0) {
>      syslog(LOG_ERR, "Error listening on socket: %m");
>      close(s);
>      return -1;
>    }
> 
>    *listenport =3D port;
>    syslog(LOG_INFO, "Established listener on port: %i", port);
>    return s;
> )
> -------------------------------------------------------------------------=
> ------
> 
> ------=_NextPart_000_000A_01BE2111.78BC2770
> Content-Type: text/html;
> 	charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
> <HTML>
> <HEAD>
> 
> <META content=3Dtext/html;charset=3Diso-8859-1 =
> http-equiv=3DContent-Type>
> <META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
> </HEAD>
> <BODY bgColor=3D#ffffff>
> <DIV><FONT color=3D#000000 size=3D2>I am trying to port a cable modem =
> (roadrunner)=20
> login program written for linux to freebsd 2.2.7 before the Dec 15=20
> deadline.&nbsp; Should have been suspicious when it compiled cleanly =
> without=20
> error message.</FONT></DIV>
> <DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT size=3D2>The program runs up to the point of setting up a TCP =
> socket to=20
> request a login sequence using functions:</FONT></DIV>
> <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT size=3D2>socket()</FONT></DIV>
> <DIV><FONT size=3D2>htons()</FONT></DIV>
> <DIV><FONT size=3D2>bind()</FONT></DIV>
> <DIV><FONT size=3D2>listen()</FONT></DIV>
> <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT size=3D2>and then quits with errnum for &quot;Operation not=20
> supported&quot;.</FONT></DIV>
> <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT size=3D2>The function calls seem to be correctly written and =
> do not=20
> return any errors when called (except for listen()).</FONT></DIV>
> <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT size=3D2>Is this a correct sequence to establish a passive =
> tcp=20
> connection?&nbsp; Is there a better way to do it? Is there a knowledge =
> base for=20
> converting linux code </FONT><FONT size=3D2>to run on FreeBSD?&nbsp; =
> References=20
> for the correct way to write code to establish tcp =
> connections?</FONT></DIV>
> <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT size=3D2>If a review of the code segment would be helpful, it =
> is brief=20
> and follows.</FONT></DIV>
> <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT size=3D2>Thanks</FONT></DIV>
> <DIV><FONT color=3D#000000 size=3D2>Jim Flowers &lt;<A=20
> href=3D"mailto:jflowers@ezo.net">jflowers@ezo.net</A>&gt;</FONT></DIV>
> <DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
> <DIV>&nbsp;</DIV>
> <DIV><FONT color=3D#000000=20
> size=3D2>//------------------------------------------------------------<B=
> R>//=20
> RRListen() - Creates a listen socket for session status=20
> and<BR>//&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
> p;&nbsp;&nbsp;=20
> restart requests<BR>int RRListen(unsigned short=20
> *listenport)<BR>{<BR>&nbsp;unsigned short port;<BR>&nbsp;&nbsp; int=20
> s;<BR>&nbsp;&nbsp; struct sockaddr_in saddr;</FONT></DIV>
> <DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp; if ((s =3D socket =
> (AF_INET,=20
> SOCK_DGRAM, 0)) &lt; 0) {<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
> syslog(LOG_ERR,=20
> &quot;Error creating listen socket: =
> %m&quot;);<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
> return -1;<BR>&nbsp;&nbsp; }</FONT></DIV>
> <DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT color=3D#000000 size=3D2>&nbsp;// Bind first available port =
> starting at=20
> 7770<BR>&nbsp;&nbsp; port =3D 7770;<BR>&nbsp;&nbsp; saddr.sin_family =3D =
> 
> AF_INET;<BR>&nbsp;&nbsp; saddr.sin_addr.s_addr =3D =
> INADDR_ANY;<BR>&nbsp;&nbsp; do=20
> {<BR>&nbsp;&nbsp;&nbsp; saddr.sin_port =3D=20
> htons(port);<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; errno =3D=20
> 0;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (bind(s, (struct sockaddr *) =
> &amp;saddr,=20
> sizeof(struct sockaddr_in)) &lt; 0) {<BR>&nbsp;if (errno !=3D =
> EADDRINUSE)=20
> {<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
> syslog(LOG_ERR, &quot;Error binding listen socket:=20
> %m&quot;);<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
> ;=20
> close(s);<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
>  return=20
> -1;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } else=20
> {<BR>&nbsp;&nbsp;&nbsp;=20
> port++;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
> }<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<BR>&nbsp;} while (errno =3D=3D=20
> EADDRINUSE);</FONT></DIV>
> <DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT color=3D#000000 size=3D2>&nbsp;if (listen(s, 1) &lt; 0)=20
> {<BR>&nbsp;&nbsp;&nbsp;&nbsp; syslog(LOG_ERR, &quot;Error listening on =
> socket:=20
> %m&quot;);<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
> close(s);<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
> return -1;<BR>&nbsp;&nbsp; }</FONT></DIV>
> <DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp; *listenport =3D =
> port;<BR>&nbsp;&nbsp;=20
> syslog(LOG_INFO, &quot;Established listener on port: %i&quot;,=20
> port);<BR>&nbsp;&nbsp; return s;<BR>)</FONT></DIV>
> <DIV><FONT color=3D#000000=20
> size=3D2>----------------------------------------------------------------=
> ---------------</FONT></DIV></BODY></HTML>
> 
> ------=_NextPart_000_000A_01BE2111.78BC2770--
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Sun Dec  6 13:00:26 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id NAA03754
          for freebsd-net-outgoing; Sun, 6 Dec 1998 13:00:26 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from poboxer.pobox.com (port95.prairietech.net [208.141.230.95] (may be forged))
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA03747
          for <net@freebsd.org>; Sun, 6 Dec 1998 13:00:22 -0800 (PST)
          (envelope-from alk@poboxer.pobox.com)
Received: (from alk@localhost)
	by poboxer.pobox.com (8.9.1/8.9.1) id OAA52504;
	Sun, 6 Dec 1998 14:59:06 -0600 (CST)
	(envelope-from alk)
From: Tony Kimball <alk@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Sun,  6 Dec 1998 14:59:05 -0600 (CST)
X-Face: \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.<li^!8ecK]}3L-
	6`ZQW3}kxy*5]B<KA"&iBl58"/$W-0PP`B7c%'XczR)8T0VN47L`rQlu8qBIX4TJ|v'D%:k7GO%v4A
	Os>Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO
	5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed
Reply-To: alk@pobox.com
To: net@FreeBSD.ORG
Subject: Re: resolver behaviour 
References: <13930.17883.922553.625725@avalon.east>
	<48026.912946905@gjp.erols.com>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <13930.53261.509843.979179@avalon.east>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Quoth Gary Palmer on Sun, 6 December:
: Tony Kimball wrote in message ID
: <13930.17883.922553.625725@avalon.east>:
: > Frankly, the current behaviour is just plain broken:  Bum nameservers
: > too often prevent FreeBSD applications from connecting to extant
: > hosts on the Internet.
: 
: If the local nameserver is bum, then that suggests a local administrative 
: failure, does it not? This is exactly the situation you are describing ... the 
: local nameserver that the resolver contacts cannot find the information it is 
: looking for. 

I'm talking about bad nameservers on the Internet at large.

: If, on the other hand, the local nameserver cannot find 
: authoratitive information from a *NON-LOCALLY* hosted zone, then that is a 
: failure which no ammout of hackery in libc will be able to overcome because in 
: all likelyhood the data you are looking for just *doesn't* exist, because of a 
: remote administrative failure. 

The data does exist, just not on all nameservers.

: Slowing down the applications acceptance of 
: that fact will do nothing to help 

The slow-down can be very small relative to human perception while
being quite long enough to avoid the 'packet storm' bugaboo --
actually I don't see the 'packet storm' because there is no cascade
effect -- at this point I'm talking about behaviour of an application
using gethostby*, not about named behaviour.

: if you did this change in the 
: environment I run at work, that is *exactly* what would happen. We'd have 
: sendmail processes hanging around `n' times longer than they should have, 
: because our nameserver setup *works*. 

No, that is misleading at best.  If you are sending mail to
a name that resolves, your sendmail process would not be delayed at
all.  If you are sending mail to a name that resolves on a fallback
server only, with a bogus record on your primary server, the mail
would get through, as opposed to failing.  The only case
in which a longer delay would result is If you are sending mail to
a bogus hostname, which is a very odd and rare case indeed!
In that case it would take not N*M as you imply, but N*F+M, where
F<<M (and hence N*F+M approaches M for fixed N).

: Going to a different nameserver will get 
: you exactly the same answer. 

This simply is not the case.  I have encountered numerous occasions
in recent weeks where resorting to alternate nameservers has resulted
in a successful lookup.  In retrospect, I was observing the same sort
of behaviour of the Internet at large in the mid-80's, so this has
proven to be a long-term condition common to a wide variety of regions
of the global DNS graph.

: about handling internet failures in general. Its not libresolv's job to try 
: and second guess what bind is doing. I say again: your nameserver setup is 
: broken. You are really confusing the work that bind does with the work that 
: libresolv does.

For the sake of illustration, assume that I don't have or want a nameserver:
Nameservers are for network administrators while  I am a user, with an
application -- I want my application to work.

: Perhaps you are suggesting a kludge in gethostby* to work around a broken 
: setup? Thats sure the way it reads to me.

Exactly!  The universe is broken, and gethostby* should recognize that
fact and provide a way to deal with the reality.

Perhaps what is wanting is a novel, orthogonal configuration
parameter --  instead of an expansion of the function of the 'nameserver'
entry in resolv.conf, one might provide a distinct entry type.

nameserver primary.namserver.net
parallel alternate.nameserver.net 
nameserver fallback.nameserver.net
timeout 2000
pausetime 1000

The parallel nameserver entry would specify an alternate nameserver
which would be queried after pausetime milliseconds, if the primary
has not responded, or immediately if the primary gave a negative
response.  If no responses were recieved witin timeout milliseconds of
the initial query, the fallback nameserver would be queried.  The only
type of query which would suffer API latency greater than timeout*N as
a result would be a query for a truly bad name.  All other cases
are improved.  Moreover, this is a configurable parameter.  If you
aren't having problems with your primary nameserver, you don't need
to add a parallel alternate at all.

: > But this only pushes the problem out one level, to named.
: 
: I don't follow. You tell named that data for `x' is found on `x's namesevrer, 
: and data for everything else is found on `y's nameserver, and it works. Thats 
: how named is designed to work! It is *not* how libresolv is designed to work!

Named will try a server, get a negative response, and return a
negative response, just like gethostby*.  The problem still exists.
I can configure named correctly, even with Archie's expanded function
(which is not really relevant to this particular problem),
and unless I provide gethostby* with alternate service, the lookup
will still fail, while it should succeed because it could succeed
if only it were applied to the alternate server.  The problem still
exists because it has not been addressed.

: > Archie's patch then fixes the problem.  (I'd like to see that patch in
: > current!)
: 
: If it goes in -current, then it had better be off by default. I firmly believe 
: that this is a negatively impacting change for the majority of freebsd users 
: out there. 

You might easily have been misled by the fact that my earlier mail
discussed two distinct problems, often switching back and forth
between them, for which I apologize.  Archie's patch does not address
the problem of cache-polluted or otherwise corrupt name server
information.  It merely allows the dns administrator to specify
forwarding servers on a per-zone basis.  This is new optional
functionality.  The problem which it fixes is not the same problem
that I discuss in the context of gethostby*.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Sun Dec  6 13:45:45 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id NAA08469
          for freebsd-net-outgoing; Sun, 6 Dec 1998 13:45:45 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA08462
          for <net@FreeBSD.ORG>; Sun, 6 Dec 1998 13:45:42 -0800 (PST)
          (envelope-from jkh@zippy.cdrom.com)
Received: from zippy.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1])
	by zippy.cdrom.com (8.9.1/8.9.1) with ESMTP id NAA40885;
	Sun, 6 Dec 1998 13:44:53 -0800 (PST)
To: alk@pobox.com
cc: net@FreeBSD.ORG
Subject: Re: resolver behaviour 
In-reply-to: Your message of "Sun, 06 Dec 1998 14:59:05 CST."
             <13930.53261.509843.979179@avalon.east> 
Date: Sun, 06 Dec 1998 13:44:52 -0800
Message-ID: <40881.912980692@zippy.cdrom.com>
From: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

I guess my only real question here is why Paul Vixie isn't being asked
for this feature rather than us.  Since we basically just track BIND
from him and have every intention of continuing to do so, if it's a
feature you can sell to him then it's a feature we're obviously going
to adopt.  If, on the other hand, you *can't* sell the feature to him
then that would be a big doc fork for us at the very least and
probably a showstopper for getting it into FreeBSD anyway.  It's just
too big a win to be able to say "Just go read the BIND docs and stop
pestering me for tech support on 3rd party software."

- Jordan

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Sun Dec  6 13:54:20 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id NAA09477
          for freebsd-net-outgoing; Sun, 6 Dec 1998 13:54:20 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA09472
          for <net@FreeBSD.ORG>; Sun, 6 Dec 1998 13:54:19 -0800 (PST)
          (envelope-from louie@whizzo.transsys.com)
Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1])
	by whizzo.transsys.com (8.9.1/8.9.1) with ESMTP id QAA01615;
	Sun, 6 Dec 1998 16:54:09 -0500 (EST)
	(envelope-from louie@whizzo.transsys.com)
Message-Id: <199812062154.QAA01615@whizzo.transsys.com>
X-Mailer: exmh version 2.0.2 2/24/98
To: alk@pobox.com
cc: net@FreeBSD.ORG
From: "Louis A. Mamakos" <louie@TransSys.COM>
Subject: Re: resolver behaviour 
References: <13930.17883.922553.625725@avalon.east> 
 <48026.912946905@gjp.erols.com> <13930.53261.509843.979179@avalon.east>
In-reply-to: Your message of "Sun, 06 Dec 1998 14:59:05 CST."
             <13930.53261.509843.979179@avalon.east> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 06 Dec 1998 16:54:08 -0500
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


There are more than two types of responses you'll get returned from a
name server when you make a query upon it.  Either you get:

- the data you asked for;
- you get a NXDOMAIN (non-existant domain) error response;
- you might get a "administratively prohibited" error;
- you might get a response indicating that the server won't perform 
  recursion for you;
- you might get a "server failure" message, indicating that a server which 
  is an authoratative server for a zone knows that it's broken.
- or the software performing the query abandoned it waiting for a response,
  perhaps due to a timeout.

The BIND *implementation* model (which differs from the architectural model of
the DNS) presumes that a small stub of code is linked in the application (the
resolver), and has robust connectivity to a name server that's willing to
perform recursive queries on behalf of the resolver.  This implementation model
isolates both state and implemenation complexity outside the application or
process which wishes to perform a DNS query.  There are advantages in doing
this, such as having a cache which persists beyond the lifetime of a single
process, smaller memory footprint for each application, etc.

However, the downside is the inability to retain any state from process to
process; one instance of sendmail has no memory or hints from the previous
one.  The is OK in the BIND implementation model, as the presumption is that
the named daemon (which is running ON THE LOCAL MACHINE) has this cached
state and can do the right thing.  This implementation model presumes robust
connectivity between the resolver and the "local" nameserver that's willing
to perform recursive queries and maintain cache state.

The named daemon already keeps track of "dead" or non-responsive name server;
in fact, for the multiple name servers associated with a zone, it times the
response from each one (when it has occasion to make multiple queries), and
will prefer the one which responds the fastest.  Much of what you want, I
think, is already implemented inside of named.

The mistake, I think, is in loading too much functionality in what is 
intended to be a very simple software module with minimal complexity.  This
is all by design.  The fact that multiple name server can be listed in
/etc/resolv.conf is so that the resolve isn't completely screwed should the
local named process fail; perhaps you backup to some other machine on the
same LAN.  But the underlying presumption is that the connectivity between
the resolver stub and the named process be robust and the failure modes
"simple."

It's just wrong that you would get a non-existant domain error from one
name server, and the correct data from another; multiple authoratative
servers for a zone are supposed to have identical copies of the zone.  If
they don't then there is a problem with the name servers, and not how the
resolvers are behaving.

It's also very dangerous to ignore non-existant domain error responses; if
you do, then you defeat a powerful scaling tool in the DNS which enables 
name servers to cache negative responses.   Having previously operated one
of the root name servers in a previous job, I was amazed as the number of
truly bogus names which are trying to be resolved.  At the time, a whole
bunch of them ended in .BITNET :-)  Negative caching helped this problem
a lot, since the source of many of these bogus names were sendmail 
daemons trying to canonicalize names with various suffixes, sigh.  The
negative cached kept that from happening as an external event very
frequently.

Louis Mamakos



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Sun Dec  6 20:14:11 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id UAA12162
          for freebsd-net-outgoing; Sun, 6 Dec 1998 20:14:11 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from mail.pinboard.com (mail.pinboard.com [194.209.195.7])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA12157
          for <net@FreeBSD.ORG>; Sun, 6 Dec 1998 20:14:09 -0800 (PST)
          (envelope-from Kurt@pinboard.com)
Received: (from uucp@localhost)
	by mail.pinboard.com (8.9.1/8.9.1/19980920-01/KK) with UUCP id FAA03885
	for net@FreeBSD.ORG; Mon, 7 Dec 1998 05:14:02 +0100 (CET)
	(envelope-from: Kurt@pinboard.com)
Received: from beaver.pbdhome.pinboard.com ([192.168.0.7])
	by squirrel.pbdhome.pinboard.com (8.9.1/8.9.1-19980817-01/KK) with SMTP id VAA26522
	for <net@FreeBSD.ORG>; Sun, 6 Dec 1998 21:52:58 +0100 (CET)
	(envelope-from: Kurt@pinboard.com)
Message-Id: <3.0.5.16.19981206214053.683794b8@pop.pbdhome.pinboard.com>
Organization: PINBOARD - http://www.pinboard.com/
X-Sender: kurt@pop.pbdhome.pinboard.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (16)
Date: Sun, 06 Dec 1998 21:40:53
To: net@FreeBSD.ORG
From: Kurt Keller <Kurt@pinboard.com>
Subject: Re: resolver behaviour
In-Reply-To: <13930.17883.922553.625725@avalon.east>
References: <13929.39477.406338.806610@avalon.east>
 <199812052221.RAA10079@khavrinen.lcs.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id UAA12158
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

>: > Instead, to the best of my current understanding, the resolver
>: > presently returns failure if it encounters a responding nameserver
>: > which reports a negative lookup response.  This hardly seems

And more often than not, the negative response is correct. There are
lots of people trying to resolve inexistant hosts, be it because of
typos or because they just try the wrong hostname for a given domain or
they did not append the domain to the hostname.

If someone tries to look up a hostname which simply does not exist (not
every domain has hosts named ftp, mail, ns, pop, smtp...), what do you
expect the resolver to do? Simply try till the end of time?

>Upon reflection, I really don't want to run a nameserver on the
>firewall at all.  I just want to be able to successfully resolve names
>  1) on disjoint networks from a common host, and
>  2) in the presence of nameservers returning bad negative responses.
>     (a surprisingly common occurence in the present Internet milieu).

I also don't want a nameserver on the firewall. If somehow possible,
the firewall should be invisible towards both outside and inside.
Whatever you can see, you can also try to attack and it might give you
a clue that you need to work around that system. Run a DNS server in
your DMZ.

If nameservers give bad responses find out where those bad responses
are coming from and send a friendly explanatory e-mail to the admin. At
least up to now it has always worked for me.

>: problems arise from doing lookups on `internal' addresses on
`external' 
>: nameservers? 
>This is one source of problems

If you have such a problem, then it's your DNS environment which is at
fault, not the resolver.

>Again, the DNS environment on the Internet as a whole is very poor.

Forward lookups usually work, but I agree that many sites are missing
the propper setup for reverse lookup.

>: If one nameserver responses name invalid, another responses with
>: an address, which would you consider to be the correct answer?
>The address, because it often works.

Negative caching is relatively short. Positive caching is usually much
longer. So I would think that if one nameserver says 'no such host' it
is correct. The admin might be about to remove or renumber the host.
The other nameserver saying 'this host has IP X' probably gives you an
answer out of its cache.

Kurt
--
 -------------------------------------------------------------------- 
¦ Kurt@pinboard.com          http://www.pinboard.com/       business ¦
¦                            http://www.pinboard.com/kurt/  private  ¦
¦--------------------------------------------------------------------¦
¦                    Unix and Internet Specialist                    ¦
 -------------------------------------------------------------------- 

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Mon Dec  7 00:05:53 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id AAA00772
          for freebsd-net-outgoing; Mon, 7 Dec 1998 00:05:53 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from poboxer.pobox.com (port95.prairietech.net [208.141.230.95] (may be forged))
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA00767
          for <net@FreeBSD.ORG>; Mon, 7 Dec 1998 00:05:50 -0800 (PST)
          (envelope-from alk@poboxer.pobox.com)
Received: (from alk@localhost)
	by poboxer.pobox.com (8.9.1/8.9.1) id CAA56307;
	Mon, 7 Dec 1998 02:04:19 -0600 (CST)
	(envelope-from alk)
From: Tony Kimball <alk@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Mon,  7 Dec 1998 02:04:19 -0600 (CST)
X-Face: \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.<li^!8ecK]}3L-
	6`ZQW3}kxy*5]B<KA"&iBl58"/$W-0PP`B7c%'XczR)8T0VN47L`rQlu8qBIX4TJ|v'D%:k7GO%v4A
	Os>Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO
	5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed
Reply-To: alk@pobox.com
To: Kurt@pinboard.com
Cc: net@FreeBSD.ORG
Subject: Re: resolver behaviour
References: <13929.39477.406338.806610@avalon.east>
	<199812052221.RAA10079@khavrinen.lcs.mit.edu>
	<13930.17883.922553.625725@avalon.east>
	<3.0.5.16.19981206214053.683794b8@pop.pbdhome.pinboard.com>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <13931.34728.540828.941706@avalon.east>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Quoth Kurt Keller on Sun, 6 December:
: 
: If someone tries to look up a hostname which simply does not exist (not
: every domain has hosts named ftp, mail, ns, pop, smtp...), what do you
: expect the resolver to do? Simply try till the end of time?

No, I'd like the resolver to try all of the nameservers which it is
configured to try, not to do so unnecessarily, but to do so in a
timely manner so that incremental delay is inconsequential.  The
information exists, out there in the DNS graph.  The trick is to
squeeze it out.  I can't count the times that I have had to resort to
manual lookups against alternate nameservers in order to make a
connection -- and this has been going on for at least 15 years by my
experience.

: If you have such a problem, then it's your DNS environment which is at
: fault, not the resolver.

While this is certainly true, fixing other problems in the resolver by
adding configurable new functionality would make it possible to fix
this in the resolver configuration.  The named setup to fix this
doesn't even *exist* in the current BIND 8 distribution, just in 3d pty
patches!

: If nameservers give bad responses find out where those bad responses
: are coming from and send a friendly explanatory e-mail to the admin. At
: least up to now it has always worked for me.

Most users will not know *how* to do this.  Those that do, don't have
the time for it.  Perhaps named should send mail to postmaster when
cache corruption is detected 1/2:-)  In general, the administrator
can't babysit every websurfing lab user to catch the rare lookup failure.

: >Again, the DNS environment on the Internet as a whole is very poor.
: 
: Forward lookups usually work, but I agree that many sites are missing
: the propper setup for reverse lookup.

"Usually" is a telling characterization.  My experience indicates that
"usually" could approach much closer to "always" with a little
tweaking.  

I'm very disappointed with this mailing list.  There is a real
problem which is not technically difficult to solve.  I'm hoping that
by raising the issue on this list, I can elicit some constructive
dialog.  While the critical commentary has been useful, more
*constructive* suggestions would be much more encouraging. 

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Mon Dec  7 03:41:44 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id DAA17710
          for freebsd-net-outgoing; Mon, 7 Dec 1998 03:41:44 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA17705
          for <net@FreeBSD.ORG>; Mon, 7 Dec 1998 03:41:42 -0800 (PST)
          (envelope-from gdonl@tsc.tdk.com)
Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191])
	by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id DAA11739;
	Mon, 7 Dec 1998 03:41:21 -0800 (PST)
	(envelope-from gdonl@tsc.tdk.com)
Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194])
	by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id DAA24712;
	Mon, 7 Dec 1998 03:41:20 -0800 (PST)
Received: (from gdonl@localhost)
	by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id DAA08796;
	Mon, 7 Dec 1998 03:41:19 -0800 (PST)
From: Don Lewis <Don.Lewis@tsc.tdk.com>
Message-Id: <199812071141.DAA08796@salsa.gv.tsc.tdk.com>
Date: Mon, 7 Dec 1998 03:41:19 -0800
In-Reply-To: Tony Kimball <alk@pobox.com>
       "Re: resolver behaviour" (Dec  6,  2:59pm)
X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95)
To: alk@pobox.com, net@FreeBSD.ORG
Subject: Re: resolver behaviour
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

On Dec 6,  2:59pm, Tony Kimball wrote:
} Subject: Re: resolver behaviour
} Quoth Gary Palmer on Sun, 6 December:
} : Tony Kimball wrote in message ID
} : <13930.17883.922553.625725@avalon.east>:
} : > Frankly, the current behaviour is just plain broken:  Bum nameservers
} : > too often prevent FreeBSD applications from connecting to extant
} : > hosts on the Internet.
} : 
} : If the local nameserver is bum, then that suggests a local administrative 
} : failure, does it not? This is exactly the situation you are describing ... the 
} : local nameserver that the resolver contacts cannot find the information it is 
} : looking for. 
} 
} I'm talking about bad nameservers on the Internet at large.

But the name server entries in /etc/resolv.conf point to your local
name servers.  If you send a query to one of your local name servers
for broken-dns.com, and that name server tells you that broken-dns.com
doesn't exist, it does not good to send this query to the rest of
your local servers, since they'll just send a similar set of queries
out to the Internet, get similar responses, and finally tell you that
broken-dns.com doesn't exist.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Mon Dec  7 06:22:31 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id GAA01956
          for freebsd-net-outgoing; Mon, 7 Dec 1998 06:22:31 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA01951
          for <net@FreeBSD.ORG>; Mon, 7 Dec 1998 06:22:30 -0800 (PST)
          (envelope-from louie@whizzo.transsys.com)
Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1])
	by whizzo.transsys.com (8.9.1/8.9.1) with ESMTP id JAA08541;
	Mon, 7 Dec 1998 09:21:59 -0500 (EST)
	(envelope-from louie@whizzo.transsys.com)
Message-Id: <199812071421.JAA08541@whizzo.transsys.com>
X-Mailer: exmh version 2.0.2 2/24/98
To: alk@pobox.com
cc: Kurt@pinboard.com, net@FreeBSD.ORG
From: "Louis A. Mamakos" <louie@TransSys.COM>
Subject: Re: resolver behaviour 
References: <13929.39477.406338.806610@avalon.east> 
 <199812052221.RAA10079@khavrinen.lcs.mit.edu> <13930.17883.922553.625725@avalon.east> <3.0.5.16.19981206214053.683794b8@pop.pbdhome.pinboard.com> <13931.34728.540828.941706@avalon.east>
In-reply-to: Your message of "Mon, 07 Dec 1998 02:04:19 CST."
             <13931.34728.540828.941706@avalon.east> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 07 Dec 1998 09:21:59 -0500
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


> I'm very disappointed with this mailing list.  There is a real
> problem which is not technically difficult to solve.  I'm hoping that
> by raising the issue on this list, I can elicit some constructive
> dialog.  While the critical commentary has been useful, more
> *constructive* suggestions would be much more encouraging. 

You propose to break one of the fundamental DNS scaling mechnaisms by
injecting way too many queries into the system for no good reason.  The
problem you have is broken or misconfigured zones, perhaps out of your
control; broken is broken.  Alternatively, the name server you've pointed
your resolver to is broken, has poor connectivity or is misconfigured.

Fix these things before breaking the architecture of the DNS.  While you
said you've experienced these problems for 15 years, I haven't had
these problems such that doing unnecessary queries would have helped.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Mon Dec  7 07:15:45 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id HAA06468
          for freebsd-net-outgoing; Mon, 7 Dec 1998 07:15:45 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from carp.gbr.epa.gov (carp.gbr.epa.gov [204.46.159.110])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA06458
          for <freebsd-net@freebsd.org>; Mon, 7 Dec 1998 07:15:44 -0800 (PST)
          (envelope-from mjenkins@carp.gbr.epa.gov)
Received: (from mjenkins@localhost)
	by carp.gbr.epa.gov (8.8.8/8.8.8) id JAA21169
	for freebsd-net@freebsd.org; Mon, 7 Dec 1998 09:15:29 -0600 (CST)
	(envelope-from mjenkins)
Date: Mon, 7 Dec 1998 09:15:29 -0600 (CST)
From: Mike Jenkins <mjenkins@carp.gbr.epa.gov>
Message-Id: <199812071515.JAA21169@carp.gbr.epa.gov>
To: freebsd-net@FreeBSD.ORG
Subject: Re: resolver behaviour
In-Reply-To: <199812071421.JAA08541@whizzo.transsys.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

If  I ask ns1.bozo.com does he know mail.bozo.com and he says NO,
and I ask ns2.bozo.com does he know mail.bozo.com and he says YES,
then who is right?

Mike

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Mon Dec  7 07:18:37 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id HAA07176
          for freebsd-net-outgoing; Mon, 7 Dec 1998 07:18:37 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from obie.softweyr.com ([204.68.178.33])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA07171
          for <net@FreeBSD.ORG>; Mon, 7 Dec 1998 07:18:34 -0800 (PST)
          (envelope-from wes@softweyr.com)
Received: from softweyr.com (zaphod.softweyr.com [204.68.178.35])
	by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id IAA02226;
	Mon, 7 Dec 1998 08:17:52 -0700 (MST)
	(envelope-from wes@softweyr.com)
Message-ID: <366BF19F.6B8B267E@softweyr.com>
Date: Mon, 07 Dec 1998 08:17:51 -0700
From: Wes Peters <wes@softweyr.com>
Organization: Softweyr llc
X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: alk@pobox.com
CC: Kurt@pinboard.com, net@FreeBSD.ORG
Subject: Re: resolver behaviour
References: <13929.39477.406338.806610@avalon.east>
		<199812052221.RAA10079@khavrinen.lcs.mit.edu>
		<13930.17883.922553.625725@avalon.east>
		<3.0.5.16.19981206214053.683794b8@pop.pbdhome.pinboard.com> <13931.34728.540828.941706@avalon.east>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Tony Kimball wrote:
> 
> Quoth Kurt Keller on Sun, 6 December:
> :
> : If someone tries to look up a hostname which simply does not exist (not
> : every domain has hosts named ftp, mail, ns, pop, smtp...), what do you
> : expect the resolver to do? Simply try till the end of time?
> 
> No, I'd like the resolver to try all of the nameservers which it is
> configured to try, not to do so unnecessarily, but to do so in a
> timely manner so that incremental delay is inconsequential.  The
> information exists, out there in the DNS graph.  The trick is to
> squeeze it out.  I can't count the times that I have had to resort to
> manual lookups against alternate nameservers in order to make a
> connection -- and this has been going on for at least 15 years by my
> experience.

This seems odd, since DNS isn't yet 15 years old.

In most cases, trying all configured nameservers isn't going to net
anything, since the servers are pretty much heirarchical anyhow.  My
network, which I consider typical, has a local nameserver which is
secondary for my own network.  The primary is at my ISP, which is also
the second nameserver listed in resolv.conf.  My local nameserver is
configured with my ISP nameserver as the forwarding site.  The "fix"
you have described would be incredibly redundant and would only 
increase traffic on my limited PPP connection.


> I'm very disappointed with this mailing list.  There is a real
> problem which is not technically difficult to solve.  I'm hoping that
> by raising the issue on this list, I can elicit some constructive
> dialog.  While the critical commentary has been useful, more
> *constructive* suggestions would be much more encouraging.

You seem to be confusing "nobody cares about what *I think* my problem
is" with "nobody cares that a problem exists."  You have described to
us a special case, which applies to your custom network and multi-
homed hosts on disjoint networks, and then expect us to leap to the
code to fix this problem not encountered by most FreeBSD users?

Since the problem is not technically difficult to solve, we will
patiently wait for YOUR patches to review, and then we can discuss
what is the most constructive way to make them available for other
FreeBSD users who might need them.

-- 
       "Where am I, and what am I doing in this handbasket?"

Wes Peters                                                 Softweyr LLC
http://www.softweyr.com/~softweyr                      wes@softweyr.com

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Mon Dec  7 08:40:31 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id IAA16413
          for freebsd-net-outgoing; Mon, 7 Dec 1998 08:40:31 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA16407
          for <freebsd-net@FreeBSD.ORG>; Mon, 7 Dec 1998 08:40:28 -0800 (PST)
          (envelope-from wollman@khavrinen.lcs.mit.edu)
Received: (from wollman@localhost)
	by khavrinen.lcs.mit.edu (8.9.1/8.9.1) id LAA15107;
	Mon, 7 Dec 1998 11:40:13 -0500 (EST)
	(envelope-from wollman)
Date: Mon, 7 Dec 1998 11:40:13 -0500 (EST)
From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Message-Id: <199812071640.LAA15107@khavrinen.lcs.mit.edu>
To: Mike Jenkins <mjenkins@carp.gbr.epa.gov>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: resolver behaviour
In-Reply-To: <199812071515.JAA21169@carp.gbr.epa.gov>
References: <199812071421.JAA08541@whizzo.transsys.com>
	<199812071515.JAA21169@carp.gbr.epa.gov>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

<<On Mon, 7 Dec 1998 09:15:29 -0600 (CST), Mike Jenkins <mjenkins@carp.gbr.epa.gov> said:

> If  I ask ns1.bozo.com does he know mail.bozo.com and he says NO,
> and I ask ns2.bozo.com does he know mail.bozo.com and he says YES,
> then who is right?

At most one.

-GAWollman

--
Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
wollman@lcs.mit.edu  | O Siem / The fires of freedom 
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA|                     - Susan Aglukark and Chad Irschick

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Mon Dec  7 11:30:04 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id LAA03598
          for freebsd-net-outgoing; Mon, 7 Dec 1998 11:30:04 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from gvr.gvr.org (gvr.gvr.org [194.151.74.97])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA03504
          for <freebsd-net@FreeBSD.ORG>; Mon, 7 Dec 1998 11:29:54 -0800 (PST)
          (envelope-from guido@gvr.org)
Received: (from guido@localhost)
	by gvr.gvr.org (8.8.8/8.8.5) id UAA18552
	for freebsd-net@FreeBSD.ORG; Mon, 7 Dec 1998 20:29:49 +0100 (MET)
Message-ID: <19981207202949.A18531@gvr.org>
Date: Mon, 7 Dec 1998 20:29:49 +0100
From: Guido van Rooij <guido@gvr.org>
To: freebsd-net@FreeBSD.ORG
Subject: Re: IPv6-over-IPv4 auto tunnel
References: <19981207193525.A18185@gvr.org> <2045.913057651@turmeric.itojun.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.93.2i
In-Reply-To: <2045.913057651@turmeric.itojun.org>; from Jun-ichiro itojun Itoh on Tue, Dec 08, 1998 at 04:07:31AM +0900
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

On Tue, Dec 08, 1998 at 04:07:31AM +0900, Jun-ichiro itojun Itoh wrote:
> >> 	One thing we don't implement intentionally is automatic tunnelling
> >> 	(packets to ::10.1.1.1 automatically tunnelled over IPv6-over-IPv4
> >> 	tunnel to 10.1.1.1).
> >Hmm..what does happen when I have a IPV6/V4 host that has an IPV6
> >native address (so no V4 compatible address) that wants to communicate
> >to an IPv4 host? Do I need to set up IPV4 specific routes to
> >a dual stack machine that does the tunneling for me?
> 
> 	Your story has nothing to do with auto tunnel.
> 	Automatic tunnel (::10.1.1.1) is only for communication between two
> 	IPv4/v6 dual stack hosts.

Ah okay. I didnt have my books at hand and I'm kind of new in this area.

> 
> 	For a IPv6-only host (or IPv4/v6 dual stack host without IPv4 address)
> 	to communicate with IPv4 host, you need to have IPv6-to-IPv4
> 	translator (TCP relay server like socks or KAME FAITH, or web proxy)
> 	between two.  There's no magical way.

Thanks for clarifying this.

-Guido

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Mon Dec  7 11:54:08 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id LAA06933
          for freebsd-net-outgoing; Mon, 7 Dec 1998 11:54:08 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from poboxer.pobox.com (port95.prairietech.net [208.141.230.95] (may be forged))
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA06925
          for <net@FreeBSD.ORG>; Mon, 7 Dec 1998 11:54:03 -0800 (PST)
          (envelope-from alk@poboxer.pobox.com)
Received: (from alk@localhost)
	by poboxer.pobox.com (8.9.1/8.9.1) id NAA59299;
	Mon, 7 Dec 1998 13:52:41 -0600 (CST)
	(envelope-from alk)
From: Tony Kimball <alk@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Mon,  7 Dec 1998 13:52:40 -0600 (CST)
X-Face: \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.<li^!8ecK]}3L-
	6`ZQW3}kxy*5]B<KA"&iBl58"/$W-0PP`B7c%'XczR)8T0VN47L`rQlu8qBIX4TJ|v'D%:k7GO%v4A
	Os>Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO
	5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed
Reply-To: alk@pobox.com
To: net@FreeBSD.ORG
Subject: Re: resolver behaviour
References: <13929.39477.406338.806610@avalon.east>
	<199812052221.RAA10079@khavrinen.lcs.mit.edu>
	<13930.17883.922553.625725@avalon.east>
	<3.0.5.16.19981206214053.683794b8@pop.pbdhome.pinboard.com>
	<13931.34728.540828.941706@avalon.east>
	<366BF19F.6B8B267E@softweyr.com>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <13932.10856.425298.58899@avalon.east>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


Quoth Louis A. Mamakos on Mon, 7 December:
: You propose to break one of the fundamental DNS scaling mechnaisms by
: injecting way too many queries into the system for no good reason. 

No, I do not.  This is a straw man.  What motivates it?

: The
: problem you have is broken or misconfigured zones, perhaps out of your
: control; broken is broken.  

Exactly.

: Fix these things before breaking the architecture of the DNS. 

Reconsider your own analysis, please:  "out of your control".
I cannot fix what I cannot control.

: I haven't had
: these problems such that doing unnecessary queries would have helped.

Doing unnecessary queries will never help.  Doing necessary queries 
which are not currently being done will help.  Therefore, I propose
to focus on the issue of how best to issue these necessary queries.
My most recent proposal was something like this:

Provide a configuration option such that the administrator of
a host may specify that negative responses from a nameserver are
to be tried again against a fallback nameserver.  This applies at
the application level, and not to named.  

For the typical case (when configured) of a single fall-back, this
proposal results in one additional query per NXDOMAIN reply.  This
cost would only be incurred in cases where the administrator of the
host had determined that nameservice was sufficiently unreliable to
warrant this cost.  The cost of unreliable name service is this: When
a lookup fails, the user must issue a manual query in order to get the
mapping.  Hence the cost of the additional query is incurred in all
cases, and hence the incremental cost (in units of queries issued) of
implementing my proposal is actually zero.

Having made the cost/benefit very clear and explicit (a ratio of zero,
according to my analysis), I invite comment on the trade-off.  Is it
optimal?  If not, what would be more nearly optimal, and why?


Quoth Wes Peters on Mon, 7 December:
: This seems odd, since DNS isn't yet 15 years old.

Okay, 14 years and 2 months if you want to be pedantic:-).

: In most cases, trying all configured nameservers isn't going to net
: anything, since the servers are pretty much heirarchical anyhow.  My
: network, which I consider typical, has a local nameserver which is
: secondary for my own network.  The primary is at my ISP, which is also
: the second nameserver listed in resolv.conf.  My local nameserver is
: configured with my ISP nameserver as the forwarding site.  The "fix"
: you have described would be incredibly redundant and would only 
: increase traffic on my limited PPP connection.

It would be slightly silly for you to configure your system to
fallback to its original information source, but not completely -- it
would amount to adding a retry.

Would adding a retry be "incredibly redundant" and "only increase
traffic".  I think that's for you to decide:  Configure it if you
wish.  I know of no reason to make this behaviour default.

I don't think your comments apply to my current working proposal,
although the fact that it has evolved through the course of this
thread probably explains why you are missing that moving target.

: You seem to be confusing "nobody cares about what *I think* my problem
: is" with "nobody cares that a problem exists."  You have described to
: us a special case, which applies to your custom network and multi-
: homed hosts on disjoint networks, and then expect us to leap to the
: code to fix this problem not encountered by most FreeBSD users?

I confused you by mentioning two related issues in one email.  I
apologize again for doing this.  Please allow me to help you
overcome this confusion by being very very explicit:  The problem
I described as bullet item 2 is present for everyone who has
no control over their nameservice.  This is the majority of users.
The problem, restated, is this: For reasons which are not always
evident, but probably relating to cache pollution, individual
nameservers have bad data.  NXDOMAIN replies occur for valid names.
Applications relying on libc in FreeBSD are thereby prevented from 
making necessary connections.  The occurrence is rare, but has
become sufficiently annoying to me over time so that I am willing
to fix it.

I don't expect anyone to write any code, I wish to write it myself.  I
do seek constructive dialog regarding the correct way to solve the
problem.

: Since the problem is not technically difficult to solve, we will
: patiently wait for YOUR patches to review, and then we can discuss
: what is the most constructive way to make them available for other
: FreeBSD users who might need them.

I'll supply patches when there is a reasonable consensus as to what
the correct solution is, and not before.  I believe in analysis
before design before programming, and in peer review at all phases.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Mon Dec  7 12:01:34 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id MAA08278
          for freebsd-net-outgoing; Mon, 7 Dec 1998 12:01:34 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from poboxer.pobox.com (port95.prairietech.net [208.141.230.95] (may be forged))
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA08262
          for <freebsd-net@FreeBSD.ORG>; Mon, 7 Dec 1998 12:01:28 -0800 (PST)
          (envelope-from alk@poboxer.pobox.com)
Received: (from alk@localhost)
	by poboxer.pobox.com (8.9.1/8.9.1) id OAA59354;
	Mon, 7 Dec 1998 14:00:10 -0600 (CST)
	(envelope-from alk)
From: Tony Kimball <alk@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Mon,  7 Dec 1998 14:00:10 -0600 (CST)
X-Face: \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.<li^!8ecK]}3L-
	6`ZQW3}kxy*5]B<KA"&iBl58"/$W-0PP`B7c%'XczR)8T0VN47L`rQlu8qBIX4TJ|v'D%:k7GO%v4A
	Os>Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO
	5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed
Reply-To: alk@pobox.com
To: freebsd-net@FreeBSD.ORG
Subject: Re: resolver behaviour
References: <199812071421.JAA08541@whizzo.transsys.com>
	<199812071515.JAA21169@carp.gbr.epa.gov>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <13932.13015.210945.112197@avalon.east>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Quoth Mike Jenkins on Mon, 7 December:
: If  I ask ns1.bozo.com does he know mail.bozo.com and he says NO,
: and I ask ns2.bozo.com does he know mail.bozo.com and he says YES,
: then who is right?

It depends on whether ns2 is providing a working mapping.  
>From the point of view of the closed world of DNS there is
no reason to prefer one answer over another.  Applications,
however, operate in the larger world of the network as a whole.
For an application, a name lookup is just a means to an end:
the formation of a connection to mail.bozo.com, in this case.
Accepting the response of ns1 when ns2 has a good mapping
prevents the application from functioning correctly.  The user
thus encounters the bug.  Accepting the response from ns2
when ns2 has a good mapping avoids the bug.  Accepting the
response from ns2 when ns2 has a bad mapping does no damage
to the user, who again encounters the bug.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Mon Dec  7 12:05:58 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id MAA09405
          for freebsd-net-outgoing; Mon, 7 Dec 1998 12:05:58 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from poboxer.pobox.com (port95.prairietech.net [208.141.230.95] (may be forged))
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA09400
          for <net@FreeBSD.ORG>; Mon, 7 Dec 1998 12:05:56 -0800 (PST)
          (envelope-from alk@poboxer.pobox.com)
Received: (from alk@localhost)
	by poboxer.pobox.com (8.9.1/8.9.1) id OAA59371;
	Mon, 7 Dec 1998 14:04:39 -0600 (CST)
	(envelope-from alk)
From: Tony Kimball <alk@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Mon,  7 Dec 1998 14:04:38 -0600 (CST)
X-Face: \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.<li^!8ecK]}3L-
	6`ZQW3}kxy*5]B<KA"&iBl58"/$W-0PP`B7c%'XczR)8T0VN47L`rQlu8qBIX4TJ|v'D%:k7GO%v4A
	Os>Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO
	5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed
Reply-To: alk@pobox.com
To: net@FreeBSD.ORG
Subject: Re: resolver behaviour
References: <alk@pobox.com>
	<199812071141.DAA08796@salsa.gv.tsc.tdk.com>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <13932.13268.182705.435207@avalon.east>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Quoth Don Lewis on Mon, 7 December:
: } I'm talking about bad nameservers on the Internet at large.
: 
: But the name server entries in /etc/resolv.conf point to your local
: name servers.  

They point to *some* name servers.  They may or may not be local,
depending on what you mean by local and the details of your configuration.

: If you send a query to one of your local name servers
: for broken-dns.com, and that name server tells you that broken-dns.com
: doesn't exist, it does not good to send this query to the rest of
: your local servers, since they'll just send a similar set of queries
: out to the Internet, get similar responses, and finally tell you that
: broken-dns.com doesn't exist.

This is the theory of dns, but in practice this is not the case.
NXDOMAIN replies are issued in cases where a valid mapping exists, and
can be obtained from another name server.  Repeating this fact is
now wearisome.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Mon Dec  7 13:04:27 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id NAA15332
          for freebsd-net-outgoing; Mon, 7 Dec 1998 13:04:27 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from xylan.com (postal.xylan.com [208.8.0.248])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA15321
          for <net@FreeBSD.ORG>; Mon, 7 Dec 1998 13:04:25 -0800 (PST)
          (envelope-from wes@softweyr.com)
Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT]))
	id NAA25468; Mon, 7 Dec 1998 13:03:52 -0800 (PST)
Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB]))
	id NAA00208; Mon, 7 Dec 1998 13:03:56 -0800
Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL]))
	id OAA04199; Mon, 7 Dec 1998 14:03:50 -0700
Message-ID: <366C42B6.F2F7FA0F@softweyr.com>
Date: Mon, 07 Dec 1998 14:03:50 -0700
From: Wes Peters <wes@softweyr.com>
Organization: Softweyr LLC
X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: alk@pobox.com
CC: net@FreeBSD.ORG
Subject: Re: resolver behaviour
References: <13929.39477.406338.806610@avalon.east>
		<199812052221.RAA10079@khavrinen.lcs.mit.edu>
		<13930.17883.922553.625725@avalon.east>
		<3.0.5.16.19981206214053.683794b8@pop.pbdhome.pinboard.com>
		<13931.34728.540828.941706@avalon.east>
		<366BF19F.6B8B267E@softweyr.com> <13932.10856.425298.58899@avalon.east>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Tony Kimball wrote:
> 
> Quoth Wes Peters on Mon, 7 December:
> : This seems odd, since DNS isn't yet 15 years old.
> 
> Okay, 14 years and 2 months if you want to be pedantic:-).

If want to really be pedantic, it wasn't generally fielded until 
1991 - 1992 time frame, when support for HOSTS.TXT was dropped.
Any reports of errors before that can easily be considered startup
problems.

> : In most cases, trying all configured nameservers isn't going to net
> : anything, since the servers are pretty much heirarchical anyhow.  My
> : network, which I consider typical, has a local nameserver which is
> : secondary for my own network.  The primary is at my ISP, which is also
> : the second nameserver listed in resolv.conf.  My local nameserver is
> : configured with my ISP nameserver as the forwarding site.  The "fix"
> : you have described would be incredibly redundant and would only
> : increase traffic on my limited PPP connection.
> 
> It would be slightly silly for you to configure your system to
> fallback to its original information source, but not completely -- it
> would amount to adding a retry.

No, it would amount to keeping traffic off the slow link, and provide
a backup in case the local caching server is off-line.  Redundant, yes,
silly, no.

> Would adding a retry be "incredibly redundant" and "only increase
> traffic".  I think that's for you to decide:  Configure it if you
> wish.  I know of no reason to make this behaviour default.
> 
> I don't think your comments apply to my current working proposal,
> although the fact that it has evolved through the course of this
> thread probably explains why you are missing that moving target.

I haven't missed your moving target, just decided, as apparently everyone
else has, that it is too much a special case to bother with.

> : You seem to be confusing "nobody cares about what *I think* my problem
> : is" with "nobody cares that a problem exists."  You have described to
> : us a special case, which applies to your custom network and multi-
> : homed hosts on disjoint networks, and then expect us to leap to the
> : code to fix this problem not encountered by most FreeBSD users?
> 
> I confused you by mentioning two related issues in one email.  I
> apologize again for doing this.  Please allow me to help you
> overcome this confusion by being very very explicit:  The problem
> I described as bullet item 2 is present for everyone who has
> no control over their nameservice.  This is the majority of users.

Hmmm.  It would seem that the majority of users then need to mutiny
and replace their domain name administrators.  I'm not denying this is
a problem, just that the idea of coding around the stupidity of the 
legions of "IT Professionals" out there would be an impossible, never-
ending task.

> The problem, restated, is this: For reasons which are not always
> evident, but probably relating to cache pollution, individual
> nameservers have bad data.  NXDOMAIN replies occur for valid names.
> Applications relying on libc in FreeBSD are thereby prevented from
> making necessary connections.  The occurrence is rare, but has
> become sufficiently annoying to me over time so that I am willing
> to fix it.

Most of the time when nameservers have bad data, it has little to
do with cache pollution and much to do with incompetent management.
Such is the case with reverse lookups on my domain right now; the
named.boot file has the wrong .IN-ADDR.ARPA domain for my reverse 
file so it cannot possibly work.  Emails to my ISP have netted me
zero results.  Is this what you're talking about?  ;^)

> I don't expect anyone to write any code, I wish to write it myself.  I
> do seek constructive dialog regarding the correct way to solve the
> problem.
> 
> : Since the problem is not technically difficult to solve, we will
> : patiently wait for YOUR patches to review, and then we can discuss
> : what is the most constructive way to make them available for other
> : FreeBSD users who might need them.
> 
> I'll supply patches when there is a reasonable consensus as to what
> the correct solution is, and not before.  I believe in analysis
> before design before programming, and in peer review at all phases.

Ah, now we're making progress.  You are probably fighting some baggage 
found on many FreeBSD lists, where somebody comes up with what they think 
is a brilliant idea and INSISTS somebody run off and implement it for them.  
I think you will find that in the future, if you start off by saying "I 
intend to implement the following behavior, and seek some guidance before 
doing so" you'll get fewer unfriendly brush-offs.  Pardon our density.

I almost wrote in my last reply that such modifications may be of use to
me, as I have a number of machines at my "day job" that are multi-homed
and reside on disjoint networks, and have no way of providing DNS services
on the internal networks without relying on DNS fallback rules.  We
currently work around this by using NIS on the main net and placing all
of the private hosts in the NIS hosts map, but this is an ugly solution
at best.

I'd prefer to see some way of giving the resolver a hint that the name
you're searching for might be on the private network, rather than 
shotgunning name servers, but don't see how you'd implement that.  Perhaps
by using the searchlist and constraining domains to servers, i.e.

	search	foo.com	foo.hack freebsd.org
	nameserver 202.202.202.202	# ns.foo.com
	nameserver 203.203.203.203	# ns.myisp.com
	domainserver foo.hack 192.168.204.204 # ns.foo.hack

where "foo.hack" is your internal network for software development?

-- 
             Where am I, and what am I doing in this handbasket?

Wes Peters                                                     +1.801.915.2061
Softweyr LLC                                                  wes@softweyr.com

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Mon Dec  7 14:19:32 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id OAA24087
          for freebsd-net-outgoing; Mon, 7 Dec 1998 14:19:32 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from carp.gbr.epa.gov (carp.gbr.epa.gov [204.46.159.110])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA24080
          for <freebsd-net@freebsd.org>; Mon, 7 Dec 1998 14:19:28 -0800 (PST)
          (envelope-from mjenkins@carp.gbr.epa.gov)
Received: (from mjenkins@localhost)
	by carp.gbr.epa.gov (8.8.8/8.8.8) id QAA21804
	for freebsd-net@freebsd.org; Mon, 7 Dec 1998 16:19:19 -0600 (CST)
	(envelope-from mjenkins)
Date: Mon, 7 Dec 1998 16:19:19 -0600 (CST)
From: Mike Jenkins <mjenkins@carp.gbr.epa.gov>
Message-Id: <199812072219.QAA21804@carp.gbr.epa.gov>
To: freebsd-net@FreeBSD.ORG
Subject: Re: resolver behaviour
In-Reply-To: <13932.13015.210945.112197@avalon.east>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

So the new resolver algorithm would sort of look like this?

	for i in nameserver-list
	do
		answer=query $i
		case answer in
		timeout)  ;; # try next nameserver
		NXDOMAIN) ;; # try next nameserver
		*) break  ;; # got answer
		esac
	done
	return answer
		
Mike

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Mon Dec  7 16:31:26 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id QAA08630
          for freebsd-net-outgoing; Mon, 7 Dec 1998 16:31:26 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA08624
          for <net@FreeBSD.ORG>; Mon, 7 Dec 1998 16:31:24 -0800 (PST)
          (envelope-from gdonl@tsc.tdk.com)
Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191])
	by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id QAA21442;
	Mon, 7 Dec 1998 16:31:14 -0800 (PST)
	(envelope-from gdonl@tsc.tdk.com)
Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194])
	by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id QAA07334;
	Mon, 7 Dec 1998 16:31:13 -0800 (PST)
Received: (from gdonl@localhost)
	by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id QAA10114;
	Mon, 7 Dec 1998 16:31:08 -0800 (PST)
From: Don Lewis <Don.Lewis@tsc.tdk.com>
Message-Id: <199812080031.QAA10114@salsa.gv.tsc.tdk.com>
Date: Mon, 7 Dec 1998 16:31:08 -0800
In-Reply-To: Tony Kimball <alk@pobox.com>
       "Re: resolver behaviour" (Dec  7,  2:04pm)
X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95)
To: alk@pobox.com, net@FreeBSD.ORG
Subject: Re: resolver behaviour
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

On Dec 7,  2:04pm, Tony Kimball wrote:
} Subject: Re: resolver behaviour
} Quoth Don Lewis on Mon, 7 December:
} : } I'm talking about bad nameservers on the Internet at large.
} : 
} : But the name server entries in /etc/resolv.conf point to your local
} : name servers.  
} 
} They point to *some* name servers.  They may or may not be local,
} depending on what you mean by local and the details of your configuration.

So if you discover that one of netscape.com's servers is broken, you're
going to add a non-broken server to for netscape.com to your /etc/resolv.conf?
Then when you find another broken server, you'll add another entry to
/etc/resolv.conf, etc.

} This is the theory of dns, but in practice this is not the case.
} NXDOMAIN replies are issued in cases where a valid mapping exists, and
} can be obtained from another name server.  Repeating this fact is
} now wearisome.

NXDOMAIN replies are issued by servers that have been configured to
be authoritative for the zone in which the name resides and that name
is not listed in the zone file.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Mon Dec  7 16:49:30 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id QAA11008
          for freebsd-net-outgoing; Mon, 7 Dec 1998 16:49:30 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA11003
          for <net@FreeBSD.ORG>; Mon, 7 Dec 1998 16:49:29 -0800 (PST)
          (envelope-from gdonl@tsc.tdk.com)
Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191])
	by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id QAA21782;
	Mon, 7 Dec 1998 16:48:45 -0800 (PST)
	(envelope-from gdonl@tsc.tdk.com)
Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194])
	by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id QAA07725;
	Mon, 7 Dec 1998 16:48:44 -0800 (PST)
Received: (from gdonl@localhost)
	by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id QAA10175;
	Mon, 7 Dec 1998 16:48:43 -0800 (PST)
From: Don Lewis <Don.Lewis@tsc.tdk.com>
Message-Id: <199812080048.QAA10175@salsa.gv.tsc.tdk.com>
Date: Mon, 7 Dec 1998 16:48:43 -0800
In-Reply-To: Tony Kimball <alk@pobox.com>
       "Re: resolver behaviour" (Dec  7,  1:52pm)
X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95)
To: alk@pobox.com, net@FreeBSD.ORG
Subject: Re: resolver behaviour
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

On Dec 7,  1:52pm, Tony Kimball wrote:
} Subject: Re: resolver behaviour

} Provide a configuration option such that the administrator of
} a host may specify that negative responses from a nameserver are
} to be tried again against a fallback nameserver.  This applies at
} the application level, and not to named.  
} 
} For the typical case (when configured) of a single fall-back, this
} proposal results in one additional query per NXDOMAIN reply.  This
} cost would only be incurred in cases where the administrator of the
} host had determined that nameservice was sufficiently unreliable to
} warrant this cost.  The cost of unreliable name service is this: When
} a lookup fails, the user must issue a manual query in order to get the
} mapping.  Hence the cost of the additional query is incurred in all
} cases, and hence the incremental cost (in units of queries issued) of
} implementing my proposal is actually zero.

What do you do when the first server returns NXDOMAIN and the second
server doesn't answer?  Do you bounce the email because all the responses
that you got were NXDOMAIN?


In the case of connecting to multiple disjoint networks that use split
DNS, I don't believe your scheme is flexible enough.  If example.com
lives in network A, and example.org lives on network B, an MX query for
example.org sent to network A's internal servers may well return the
external DNS information (instead of NXDOMAIN) for network B, when in
fact you want the internal DNS information for network B.  Your
proposal would accept the undesired DNS information and return it to the
application.

Even if you hack FreeBSD so that it does this, what are you going to
do when your boss tells you to make this work with the Windoze,
MAC, or other closed-source machine on his desk?

I think a better scheme would be to write an application that listens
on port 53 and forwards queries to the appropriate server.  It could
do pattern matching on the query name to figure out where to forward
the query.  This has the advantage of not being limited to running
on FreeBSD, and you can point other machines running any arbitrary OS
at it.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Mon Dec  7 17:06:02 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id RAA12905
          for freebsd-net-outgoing; Mon, 7 Dec 1998 17:06:02 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from poboxer.pobox.com (port95.prairietech.net [208.141.230.95] (may be forged))
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA12830
          for <net@FreeBSD.ORG>; Mon, 7 Dec 1998 17:05:58 -0800 (PST)
          (envelope-from alk@poboxer.pobox.com)
Received: (from alk@localhost)
	by poboxer.pobox.com (8.9.1/8.9.1) id TAA61062;
	Mon, 7 Dec 1998 19:04:39 -0600 (CST)
	(envelope-from alk)
From: Tony Kimball <alk@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Mon,  7 Dec 1998 19:04:38 -0600 (CST)
X-Face: \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.<li^!8ecK]}3L-
	6`ZQW3}kxy*5]B<KA"&iBl58"/$W-0PP`B7c%'XczR)8T0VN47L`rQlu8qBIX4TJ|v'D%:k7GO%v4A
	Os>Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO
	5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed
Reply-To: alk@pobox.com
To: net@FreeBSD.ORG
Subject: Re: resolver behaviour
References: <alk@pobox.com>
	<199812080031.QAA10114@salsa.gv.tsc.tdk.com>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <13932.30101.788469.964960@avalon.east>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Quoth Don Lewis on Mon, 7 December:
: So if you discover that one of netscape.com's servers is broken, you're
: going to add a non-broken server to for netscape.com to your /etc/resolv.conf?
: Then when you find another broken server, you'll add another entry to
: /etc/resolv.conf, etc.

My expectation, on the basis of anecdotal experience, is that
two should be quite sufficient, if chosen well.  Name servers
at widely separated locations in the DNS graph rarely (if ever!
for I have never seen it happen) suffer common corruption.  

: NXDOMAIN replies are issued by servers that have been configured to
: be authoritative for the zone in which the name resides and that name
: is not listed in the zone file.

...and by servers which have been misconfigured, or are plain buggy,
and all those who rely upon those servers.

Quoth Mike Jenkins on Mon, 7 December:
: So the new resolver algorithm would sort of look like this?
: 
: 	for i in nameserver-list
: 	do
: 		answer=query $i
: 		case answer in
: 		timeout)  ;; # try next nameserver
: 		NXDOMAIN) ;; # try next nameserver
: 		*) break  ;; # got answer
: 		esac
: 	done
: 	return answer

Thanks.  This is what happens in practice today, only the looping is
done by hand by the end-user, instead of in the library.  I think such
an algorithm introduces too much latency into bad requests (i.e. ones
for which NXDOMAIN is correct), though.  When a person does it
manually, they do it because they *know* the request is valid, and the
server is broken.

read nameserver-list
set alarm at timeout
pausetime = timeout / N
nx = null
select-list = null

trap eintr {
  if nx == null return timeout
  else return nx
}

for i in nameserver-list
do
  query i 
  push i select-list
  select on select-list for pausetime
  for answer in pending replies
  do
    case postive(answer):
       return answer
    case NXDOMAIN:
       nx = answer
       continue
  done
end loop





  







To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Mon Dec  7 17:24:13 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id RAA15824
          for freebsd-net-outgoing; Mon, 7 Dec 1998 17:24:13 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from poboxer.pobox.com (port95.prairietech.net [208.141.230.95] (may be forged))
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA15810
          for <net@freebsd.org>; Mon, 7 Dec 1998 17:24:05 -0800 (PST)
          (envelope-from alk@poboxer.pobox.com)
Received: (from alk@localhost)
	by poboxer.pobox.com (8.9.1/8.9.1) id TAA61152;
	Mon, 7 Dec 1998 19:22:47 -0600 (CST)
	(envelope-from alk)
From: Tony Kimball <alk@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Mon,  7 Dec 1998 19:22:46 -0600 (CST)
X-Face: \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.<li^!8ecK]}3L-
	6`ZQW3}kxy*5]B<KA"&iBl58"/$W-0PP`B7c%'XczR)8T0VN47L`rQlu8qBIX4TJ|v'D%:k7GO%v4A
	Os>Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO
	5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed
Reply-To: alk@pobox.com
To: net@FreeBSD.ORG
Subject: Re: resolver behaviour
References: <13929.39477.406338.806610@avalon.east>
	<199812052221.RAA10079@khavrinen.lcs.mit.edu>
	<13930.17883.922553.625725@avalon.east>
	<3.0.5.16.19981206214053.683794b8@pop.pbdhome.pinboard.com>
	<13931.34728.540828.941706@avalon.east>
	<366BF19F.6B8B267E@softweyr.com>
	<13932.10856.425298.58899@avalon.east>
	<366C42B6.F2F7FA0F@softweyr.com>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <13932.31680.79208.663049@avalon.east>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Quoth Wes Peters on Mon, 7 December:
: > It would be slightly silly for you to configure your system to
: > fallback to its original information source, but not completely -- it
: > would amount to adding a retry.
: 
: No, it would amount to keeping traffic off the slow link, and provide
: a backup in case the local caching server is off-line.  Redundant, yes,
: silly, no.

But why fall back to a source already known to provide defective information?

: I haven't missed your moving target, just decided, as apparently everyone
: else has, that it is too much a special case to bother with.

That may well be the case.  My experience is at best anecdotal and
quite possible unrepresentative.  

: Most of the time when nameservers have bad data, it has little to
: do with cache pollution and much to do with incompetent management.
: Such is the case with reverse lookups on my domain right now; the
: named.boot file has the wrong .IN-ADDR.ARPA domain for my reverse 
: file so it cannot possibly work.  Emails to my ISP have netted me
: zero results.  Is this what you're talking about?  ;^)

Yes, in part, although I the state of reverse lookup is so bad
that I'd prefer not to have to address the problem.

: I almost wrote in my last reply that such modifications may be of use to
: me, as I have a number of machines at my "day job" that are multi-homed
: and reside on disjoint networks, and have no way of providing DNS services
: on the internal networks without relying on DNS fallback rules.  We
: currently work around this by using NIS on the main net and placing all
: of the private hosts in the NIS hosts map, but this is an ugly solution
: at best.

Perhaps you missed the mail from Archie Cobbs about the forwarding
zone patch for bind 8 at ftp.whistle.com.  It addresses this problem
in a better way that would any proposal of mine, if you can run named.

: I'd prefer to see some way of giving the resolver a hint that the name
: you're searching for might be on the private network, rather than 
: shotgunning name servers, but don't see how you'd implement that.  Perhaps
: by using the searchlist and constraining domains to servers, i.e.
: 
: 	search	foo.com	foo.hack freebsd.org
: 	nameserver 202.202.202.202	# ns.foo.com
: 	nameserver 203.203.203.203	# ns.myisp.com
: 	domainserver foo.hack 192.168.204.204 # ns.foo.hack
: 
: where "foo.hack" is your internal network for software development?

This is a good idea too, better than any of my proposals at addressing
the bullet item #1 problem, and avoids running named.
How about just extending the nameserver entry, with an optional
domain field.  The fallback algorithm remains unchanged and
the change is both forward- and back-compatible:

nameserver 10.0.0.1 .intranet.com
nameserver 1.1.1.1 .com,.org,.gov,.edu,.int
nameserver 1.1.1.2 .mil
nameserver 1.1.1.3 !.intranet.com # fallback for everything but .intranet.com

I'm pretty sure this will pass Vixie.

But I still would like to address bullet item #2, and I don't think
I've got a solution yet that will pass Vixie.

Quoth Don Lewis on Mon, 7 December:
: What do you do when the first server returns NXDOMAIN and the second
: server doesn't answer?  Do you bounce the email because all the responses
: that you got were NXDOMAIN?

Yes, the net result is NXDOMAIN, and the effect is to bounce the mail.

: In the case of connecting to multiple disjoint networks that use split
: DNS, I don't believe your scheme is flexible enough.  If example.com
: lives in network A, and example.org lives on network B, an MX query for
: example.org sent to network A's internal servers may well return the
: external DNS information (instead of NXDOMAIN) for network B, when in
: fact you want the internal DNS information for network B.  Your
: proposal would accept the undesired DNS information and return it to the
: application.

I agree.  Wes Peter's suggestion appears to address this case well, however.

: Even if you hack FreeBSD so that it does this, what are you going to
: do when your boss tells you to make this work with the Windoze,
: MAC, or other closed-source machine on his desk?
:
: I think a better scheme would be to write an application that listens
: on port 53 and forwards queries to the appropriate server.  

Archie's BIND 8 forwarding zones patch does this, and although a
lighter-weight free cross-platform solution would be better, I don't
have any motivation to solve the problem for other platforms.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Mon Dec  7 18:35:28 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id SAA24277
          for freebsd-net-outgoing; Mon, 7 Dec 1998 18:35:28 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from set.scient.com (set.Scient.COM [208.29.209.254])
          by hub.freebsd.org (8.8.8/8.8.8) with SMTP id SAA24272
          for <net@FreeBSD.ORG>; Mon, 7 Dec 1998 18:35:25 -0800 (PST)
          (envelope-from enkhyl@scient.com)
Received: by set.scient.com; (5.65v4.0/1.3/10May95) id AA28242; Mon, 7 Dec 1998 18:35:05 -0800
Received: from somewhere by smtpxd
Date: Mon, 7 Dec 1998 18:35:00 -0800 (PST)
From: Christopher Nielsen <enkhyl@scient.com>
X-Sender: enkhyl@ender.sf.scient.com
Reply-To: Christopher Nielsen <cnielsen@pobox.com>
To: Tony Kimball <alk@pobox.com>
Cc: net@FreeBSD.ORG
Subject: Re: resolver behaviour
In-Reply-To: <13932.13268.182705.435207@avalon.east>
Message-Id: <Pine.BSF.4.05.9812071811360.428-100000@ender.sf.scient.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

On Mon, 7 Dec 1998, Tony Kimball wrote:

> : If you send a query to one of your local name servers
> : for broken-dns.com, and that name server tells you that broken-dns.com
> : doesn't exist, it does not good to send this query to the rest of
> : your local servers, since they'll just send a similar set of queries
> : out to the Internet, get similar responses, and finally tell you that
> : broken-dns.com doesn't exist.
> 
> This is the theory of dns, but in practice this is not the case.
> NXDOMAIN replies are issued in cases where a valid mapping exists, and
> can be obtained from another name server.  Repeating this fact is
> now wearisome.

I don't think there is a misunderstanding about what you want to do. I
think the issue is that the solution you're suggesting is a misplaced hack
to something that isn't broken.

As has been stated previously by many others, the solution to this problem
is NOT to hack the resolver (this is not the location of the problem), but
to have the domain administrator fix the problem with their broken DNS.

I agree with Jordan's response. Present these changes to Paul Vixie. If
you can convince him that this is desired and needed functionality (I'm
not convinced that it is), then it might be worth discussing. Something
tells me that there is a reason this has not been implemented before
(this doesn't seem to be a new idea).

-- 
Christopher Nielsen
Scient: The eBusiness Systems Innovator
<http://www.scient.com>
cnielsen@scient.com



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Mon Dec  7 19:01:23 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id TAA26832
          for freebsd-net-outgoing; Mon, 7 Dec 1998 19:01:23 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from poboxer.pobox.com (port95.prairietech.net [208.141.230.95] (may be forged))
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA26809
          for <net@FreeBSD.ORG>; Mon, 7 Dec 1998 19:01:12 -0800 (PST)
          (envelope-from alk@poboxer.pobox.com)
Received: (from alk@localhost)
	by poboxer.pobox.com (8.9.1/8.9.1) id UAA61616;
	Mon, 7 Dec 1998 20:59:39 -0600 (CST)
	(envelope-from alk)
From: Tony Kimball <alk@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Mon,  7 Dec 1998 20:59:38 -0600 (CST)
X-Face: \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.<li^!8ecK]}3L-
	6`ZQW3}kxy*5]B<KA"&iBl58"/$W-0PP`B7c%'XczR)8T0VN47L`rQlu8qBIX4TJ|v'D%:k7GO%v4A
	Os>Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO
	5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed
Reply-To: alk@pobox.com
To: net@FreeBSD.ORG
Subject: Re: resolver behaviour
References: <13932.13268.182705.435207@avalon.east>
	<Pine.BSF.4.05.9812071811360.428-100000@ender.sf.scient.com>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <13932.37544.359322.844613@avalon.east>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Quoth Christopher Nielsen on Mon, 7 December:
: As has been stated previously by many others, the solution to this problem
: is NOT to hack the resolver (this is not the location of the problem), but
: to have the domain administrator fix the problem with their broken DNS.

It's a non-solution, though.  A hack can actually ameliorate the
problem, and enhance end-user function, whereas idealism won't even do
that.

: I agree with Jordan's response. Present these changes to Paul Vixie. 

So far the discussion has suggested two new features:  domain-specific
nameservers in resolv.conf, and the algorithm of my immediately prior
mail.  IMO, the former is good, period, and should fly.  The latter is
probably not good enough to fly yet.  I'm still hopeful that someone
will make a suggestion that will result in a more acceptable solution, 
however.  Recent events are heartening!




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Mon Dec  7 19:29:31 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id TAA00775
          for freebsd-net-outgoing; Mon, 7 Dec 1998 19:29:31 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from poboxer.pobox.com (port95.prairietech.net [208.141.230.95] (may be forged))
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA00742
          for <net@freebsd.org>; Mon, 7 Dec 1998 19:29:23 -0800 (PST)
          (envelope-from alk@poboxer.pobox.com)
Received: (from alk@localhost)
	by poboxer.pobox.com (8.9.1/8.9.1) id VAA61763;
	Mon, 7 Dec 1998 21:27:51 -0600 (CST)
	(envelope-from alk)
From: Tony Kimball <alk@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Mon,  7 Dec 1998 21:27:50 -0600 (CST)
X-Face: \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.<li^!8ecK]}3L-
	6`ZQW3}kxy*5]B<KA"&iBl58"/$W-0PP`B7c%'XczR)8T0VN47L`rQlu8qBIX4TJ|v'D%:k7GO%v4A
	Os>Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO
	5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed
Reply-To: alk@pobox.com
To: net@FreeBSD.ORG
Subject: to change the subject...
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <13932.40073.465593.512234@avalon.east>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


How does one proxy/cache realaudio, realvideo?

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Mon Dec  7 19:34:25 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id TAA01472
          for freebsd-net-outgoing; Mon, 7 Dec 1998 19:34:25 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from gjp.erols.com (alex-va-n008c079.moon.jic.com [206.156.18.89])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA01464
          for <net@FreeBSD.ORG>; Mon, 7 Dec 1998 19:34:23 -0800 (PST)
          (envelope-from gjp@gjp.erols.com)
Received: from gjp.erols.com (localhost.erols.com [127.0.0.1])
	by gjp.erols.com (8.9.1/8.8.7) with ESMTP id WAA78207;
	Mon, 7 Dec 1998 22:33:57 -0500 (EST)
	(envelope-from gjp@gjp.erols.com)
X-Mailer: exmh version 2.0.1 12/23/97
To: alk@pobox.com
cc: net@FreeBSD.ORG
From: "Gary Palmer" <gpalmer@FreeBSD.ORG>
Subject: Re: to change the subject... 
In-reply-to: Your message of "Mon, 07 Dec 1998 21:27:50 CST."
             <13932.40073.465593.512234@avalon.east> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 07 Dec 1998 22:33:57 -0500
Message-ID: <78203.913088037@gjp.erols.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Tony Kimball wrote in message ID
<13932.40073.465593.512234@avalon.east>:
> 
> How does one proxy/cache realaudio, realvideo?

There is only one product which is claimed to cache realvideo ... Inktomi 
Traffic Server. I know of no other way to do that.

Gary
--
Gary Palmer                                          FreeBSD Core Team Member
FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Mon Dec  7 21:05:18 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id VAA09881
          for freebsd-net-outgoing; Mon, 7 Dec 1998 21:05:18 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from poboxer.pobox.com (port95.prairietech.net [208.141.230.95] (may be forged))
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA09870
          for <net@FreeBSD.ORG>; Mon, 7 Dec 1998 21:05:14 -0800 (PST)
          (envelope-from alk@poboxer.pobox.com)
Received: (from alk@localhost)
	by poboxer.pobox.com (8.9.1/8.9.1) id XAA62233;
	Mon, 7 Dec 1998 23:03:55 -0600 (CST)
	(envelope-from alk)
From: Tony Kimball <alk@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Mon,  7 Dec 1998 23:03:55 -0600 (CST)
X-Face: \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.<li^!8ecK]}3L-
	6`ZQW3}kxy*5]B<KA"&iBl58"/$W-0PP`B7c%'XczR)8T0VN47L`rQlu8qBIX4TJ|v'D%:k7GO%v4A
	Os>Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO
	5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed
Reply-To: alk@pobox.com
To: net@FreeBSD.ORG
Subject: Re: to change the subject... 
References: <13932.40073.465593.512234@avalon.east>
	<78203.913088037@gjp.erols.com>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <13932.41336.759027.878125@avalon.east>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Quoth Gary Palmer on Mon, 7 December:
: Tony Kimball wrote in message ID
: <13932.40073.465593.512234@avalon.east>:
: > 
: > How does one proxy/cache realaudio, realvideo?
: 
: There is only one product which is claimed to cache realvideo ... Inktomi 
: Traffic Server. I know of no other way to do that.

That's good information, but I was hoping for something more like
'read http://foo.bar.net/quux.html to learn how it works, and
go write a plugin for squid'.  Perhaps it is too much to hope for?






To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Mon Dec  7 21:48:45 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id VAA14583
          for freebsd-net-outgoing; Mon, 7 Dec 1998 21:48:45 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from mail.numachi.com (numachi.numachi.com [198.175.254.2])
          by hub.freebsd.org (8.8.8/8.8.8) with SMTP id VAA14573
          for <freebsd-net@FreeBSD.ORG>; Mon, 7 Dec 1998 21:48:42 -0800 (PST)
          (envelope-from reichert@numachi.com)
Received: (qmail 13045 invoked by uid 1001); 8 Dec 1998 05:48:30 -0000
Message-ID: <19981208004830.C12707@numachi.com>
Date: Tue, 8 Dec 1998 00:48:30 -0500
From: Brian Reichert <reichert@numachi.com>
To: freebsd-net@FreeBSD.ORG
Subject: Re: to change the subject...
References: <13932.40073.465593.512234@avalon.east>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91i
In-Reply-To: <13932.40073.465593.512234@avalon.east>; from Tony Kimball on Mon, Dec 07, 1998 at 09:27:50PM -0600
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

On Mon, Dec 07, 1998 at 09:27:50PM -0600, Tony Kimball wrote:
> 
> How does one proxy/cache realaudio, realvideo?

RealAudio hands out source for a RA proxy, build and runs just fine
under FreeBSD...

> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message

-- 
Brian 'you Bastard' Reichert		reichert@numachi.com
37 Crystal Ave. #303			Current daytime number: (603)-434-6842
Derry NH 03038-1713 USA			Intel architecture: the left-hand path

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Mon Dec  7 22:33:52 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id WAA18165
          for freebsd-net-outgoing; Mon, 7 Dec 1998 22:33:52 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from obie.softweyr.com ([204.68.178.33])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA18158
          for <net@FreeBSD.ORG>; Mon, 7 Dec 1998 22:33:48 -0800 (PST)
          (envelope-from wes@softweyr.com)
Received: from softweyr.com (zaphod.softweyr.com [204.68.178.35])
	by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id XAA03442;
	Mon, 7 Dec 1998 23:33:31 -0700 (MST)
	(envelope-from wes@softweyr.com)
Message-ID: <366CC83B.51597443@softweyr.com>
Date: Mon, 07 Dec 1998 23:33:31 -0700
From: Wes Peters <wes@softweyr.com>
Organization: Softweyr llc
X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: alk@pobox.com
CC: net@FreeBSD.ORG
Subject: Re: resolver behaviour
References: <13929.39477.406338.806610@avalon.east>
		<199812052221.RAA10079@khavrinen.lcs.mit.edu>
		<13930.17883.922553.625725@avalon.east>
		<3.0.5.16.19981206214053.683794b8@pop.pbdhome.pinboard.com>
		<13931.34728.540828.941706@avalon.east>
		<366BF19F.6B8B267E@softweyr.com>
		<13932.10856.425298.58899@avalon.east>
		<366C42B6.F2F7FA0F@softweyr.com> <13932.31680.79208.663049@avalon.east>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Tony Kimball wrote:
> 
> Quoth Wes Peters on Mon, 7 December:
> : > It would be slightly silly for you to configure your system to
> : > fallback to its original information source, but not completely -- it
> : > would amount to adding a retry.
> :
> : No, it would amount to keeping traffic off the slow link, and provide
> : a backup in case the local caching server is off-line.  Redundant, yes,
> : silly, no.
> 
> But why fall back to a source already known to provide defective information?

I don't know where the pollution came from, or where it currently lives.  It
may just be stale information in my local nameserver cache, while upstream
servers have flushed theirs and will return the correct information.

> : I haven't missed your moving target, just decided, as apparently everyone
> : else has, that it is too much a special case to bother with.
> 
> That may well be the case.  My experience is at best anecdotal and
> quite possible unrepresentative.

Mine configuration and experience are relatively common for small networks
using dialup links, but it would be hard to characterize anything as
"average" in FreeBSD.  ;^)

> : Most of the time when nameservers have bad data, it has little to
> : do with cache pollution and much to do with incompetent management.
> : Such is the case with reverse lookups on my domain right now; the
> : named.boot file has the wrong .IN-ADDR.ARPA domain for my reverse
> : file so it cannot possibly work.  Emails to my ISP have netted me
> : zero results.  Is this what you're talking about?  ;^)
> 
> Yes, in part, although I the state of reverse lookup is so bad
> that I'd prefer not to have to address the problem.

So you're not trying to download Netscape with strong encryption?

> : I almost wrote in my last reply that such modifications may be of use to
> : me, as I have a number of machines at my "day job" that are multi-homed
> : and reside on disjoint networks, and have no way of providing DNS services
> : on the internal networks without relying on DNS fallback rules.  We
> : currently work around this by using NIS on the main net and placing all
> : of the private hosts in the NIS hosts map, but this is an ugly solution
> : at best.
> 
> Perhaps you missed the mail from Archie Cobbs about the forwarding
> zone patch for bind 8 at ftp.whistle.com.  It addresses this problem
> in a better way that would any proposal of mine, if you can run named.

I've bookmarked the file he referred to.  It's pretty far down my list
right now, but I'll get to it someday.

> : I'd prefer to see some way of giving the resolver a hint that the name
> : you're searching for might be on the private network, rather than
> : shotgunning name servers, but don't see how you'd implement that.  Perhaps
> : by using the searchlist and constraining domains to servers, i.e.
> :
> :       search  foo.com foo.hack freebsd.org
> :       nameserver 202.202.202.202      # ns.foo.com
> :       nameserver 203.203.203.203      # ns.myisp.com
> :       domainserver foo.hack 192.168.204.204 # ns.foo.hack
> :
> : where "foo.hack" is your internal network for software development?
> 
> This is a good idea too, better than any of my proposals at addressing
> the bullet item #1 problem, and avoids running named.
> How about just extending the nameserver entry, with an optional
> domain field.  The fallback algorithm remains unchanged and
> the change is both forward- and back-compatible:
> 
> nameserver 10.0.0.1 .intranet.com
> nameserver 1.1.1.1 .com,.org,.gov,.edu,.int
> nameserver 1.1.1.2 .mil
> nameserver 1.1.1.3 !.intranet.com # fallback for everything but .intranet.com
> 
> I'm pretty sure this will pass Vixie.

Better.  The nomenclature is reasonable, and downward compatible with current
usage -- no domain name list implies "all domains."  I like this.  It also
COULD add the possibility of introducing "local top level domains" like .test
and .hack, which could be useful for keeping internal domain names short.  
Instead of test.boston.foocorp.com, you could simply create the internal 
domain .test at boston, and keep the test host names to two-part FQDNs.

> But I still would like to address bullet item #2, and I don't think
> I've got a solution yet that will pass Vixie.

Praise him, the keeper of DNS purity.  If he likes the idea, it's probably
generally useful.  ;^)

> : Even if you hack FreeBSD so that it does this, what are you going to
> : do when your boss tells you to make this work with the Windoze,
> : MAC, or other closed-source machine on his desk?
> :
> : I think a better scheme would be to write an application that listens
> : on port 53 and forwards queries to the appropriate server.
> 
> Archie's BIND 8 forwarding zones patch does this, and although a
> lighter-weight free cross-platform solution would be better, I don't
> have any motivation to solve the problem for other platforms.

Do the forwarding zones work from the client level, or as a part of the
BIND server.  If so, a FreeBSD machine configured with this patch may
provide "zoned" name services for a pile of machines, even ones as 
dumb as Win95.

And, as you point out, who cares?  People who use Win95 deserve what
they get.

-- 
       "Where am I, and what am I doing in this handbasket?"

Wes Peters                                                 Softweyr LLC
http://www.softweyr.com/~softweyr                      wes@softweyr.com

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Tue Dec  8 00:26:34 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id AAA28655
          for freebsd-net-outgoing; Tue, 8 Dec 1998 00:26:34 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from alive.znep.com (207-178-54-226.go2net.com [207.178.54.226])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA28650
          for <net@FreeBSD.ORG>; Tue, 8 Dec 1998 00:26:31 -0800 (PST)
          (envelope-from marcs@znep.com)
Received: from localhost (marcs@localhost)
	by alive.znep.com (8.9.1/8.9.1) with ESMTP id AAA02054;
	Tue, 8 Dec 1998 00:25:02 -0800 (PST)
	(envelope-from marcs@znep.com)
Date: Tue, 8 Dec 1998 00:25:02 -0800 (PST)
From: Marc Slemko <marcs@znep.com>
To: Tony Kimball <alk@pobox.com>
cc: net@FreeBSD.ORG
Subject: Re: resolver behaviour
In-Reply-To: <13932.37544.359322.844613@avalon.east>
Message-ID: <Pine.BSF.4.05.9812080012100.463-100000@alive.znep.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

On Mon, 7 Dec 1998, Tony Kimball wrote:

> Quoth Christopher Nielsen on Mon, 7 December:
> : As has been stated previously by many others, the solution to this problem
> : is NOT to hack the resolver (this is not the location of the problem), but
> : to have the domain administrator fix the problem with their broken DNS.
> 
> It's a non-solution, though.  A hack can actually ameliorate the
> problem, and enhance end-user function, whereas idealism won't even do
> that.

You can ameliorate whatever you want, but it is NOT a proper solution and
does not fix the problem while at the same time having a very high
overhead that simply isn't worth it.

If a server is listed as authoritative and returning bad responses, then
it is broken period.  You can add hacks here and there to try to work
around some of those cases, but the only solution is for it to be fixed.
Hiding the problem doesn't solve it and does not result in a workable long
term design.

What if NXDOMAIN is the correct answer and it is the server that is
returning something else which is broken or out of date?  

If some servers improperly return NXDOMAINs, it is quite likely they will
also return other bogus information.

Your suggestions would significantly increase nameserver traffic for
absolutely no good reason.  Take a look at traffic on a real network
someday; I think you will be suprised by the number of NXDOMAINs.  Your
proposal significantly reduces the ability to scale nameservers just by
adding another machine, since the total load will be increased simply by
having more listed.

There is a fundamental assumption in DNS that an authoritative nameserver
is either authoritative with correct information or not authoritative at
all.  It is a fundamental flaw in the design or implementation of DNS
services if a server is authoritative with incorrect information.  False
NXDOMAINs are only a very very small part of the problems that exist in
this situation.

In the real world, adding hacks upon hacks upon hacks designed to deal
with all sorts of special cases ends up breaking more than it fixes.  All
these little hacks may look like good ideas on the surface, but that
doesn't mean they are.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Tue Dec  8 13:28:57 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id NAA12434
          for freebsd-net-outgoing; Tue, 8 Dec 1998 13:28:57 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA12410
          for <freebsd-net@freebsd.org>; Tue, 8 Dec 1998 13:28:54 -0800 (PST)
          (envelope-from brett@lariat.org)
Received: (from brett@localhost)
	by lariat.lariat.org (8.8.8/8.8.6) id OAA02502;
	Tue, 8 Dec 1998 14:28:48 -0700 (MST)
Message-Id: <4.1.19981208142548.06cb83f0@mail.lariat.org>
X-Sender: brett@mail.lariat.org
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 08 Dec 1998 14:28:40 -0700
To: freebsd-net@FreeBSD.ORG
From: Brett Glass <brett@lariat.org>
Subject: Error message generated by pppd
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

I'm running a small system that uses pppd to field incoming calls and
connect callers to the Net. It's running routed, and IP forwarding is
enabled. However, whenever a caller connects, I see an error message in the
log: "ignoring RTM_ADD without gateway".

The system IS acting as a gateway, and callers can get through to the Net
just fine. What does the error message mean? How can it be avoided so that
it does not clutter up the logs? Is it indicative of a configuration
problem? Please respond to me as well as to the list, as I am not currently
subscribed.

--Brett Glass

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Tue Dec  8 13:34:50 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id NAA13165
          for freebsd-net-outgoing; Tue, 8 Dec 1998 13:34:50 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA13152
          for <freebsd-net@freebsd.org>; Tue, 8 Dec 1998 13:34:48 -0800 (PST)
          (envelope-from brett@lariat.org)
Received: (from brett@localhost)
	by lariat.lariat.org (8.8.8/8.8.6) id OAA02585;
	Tue, 8 Dec 1998 14:34:42 -0700 (MST)
Message-Id: <4.1.19981208143134.06cc0ea0@mail.lariat.org>
X-Sender: brett@mail.lariat.org
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 08 Dec 1998 14:34:37 -0700
To: freebsd-net@FreeBSD.ORG
From: Brett Glass <brett@lariat.org>
Subject: Error message generated by pppd
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

By the way, just thought I'd send a copy of the actual 
log messages I've described, in case it helps. The IP 
addresses have been changed to protect the guilty. Before
I upgraded the machine to FreeBSD 2.2.8, the error message
from routed said "punt RTM_ADD without gateway".

--Brett

Dec  8 13:09:34 forum pppd[554]: Connect: ppp0 <--> /dev/ttyd0
Dec  8 13:09:38 forum routed[106]: Send sendto(ppp0, w.x.y.z.520): Networ
k is down
Dec  8 13:09:38 forum routed[106]: ignore RTM_ADD without gateway
Dec  8 13:09:38 forum pppd[554]: local  IP address a.b.c.d
Dec  8 13:09:38 forum pppd[554]: remote IP address w.x.y.z
Dec  8 13:09:38 forum pppd[554]: Received bad configure-ack:  fe 02


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Wed Dec  9 12:24:44 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id MAA22796
          for freebsd-net-outgoing; Wed, 9 Dec 1998 12:24:44 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from mail2.adinet.com.uy (mail2.adinet.com.uy [206.99.44.33])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA22776;
          Wed, 9 Dec 1998 12:24:36 -0800 (PST)
          (envelope-from ang@adinet.com.uy)
Received: from adinet.com.uy (nro97.netgate.com.uy [206.99.53.97])
	by mail2.adinet.com.uy (8.9.0/8.9.0) with ESMTP id RAA11109;
	Wed, 9 Dec 1998 17:24:46 -0300 (GMT)
Message-ID: <366EDC77.3FB010EC@adinet.com.uy>
Date: Wed, 09 Dec 1998 17:24:23 -0300
From: Angelo Nardone <ang@adinet.com.uy>
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: "freebsd-net@FreeBSD.ORG" <freebsd-net@FreeBSD.ORG>,
        "freebsd-questions@FreeBSD.ORG" <freebsd-questions@FreeBSD.ORG>
Subject: Printer problem
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

I have a laser printer (HP 4MV Poscript) in the network.
I can print poscript files, but not text files.
Other problem is that i can't desactivate the page that print with
information of the ouner of the file
This is my configuration:

lasertxt|Ipresora laser texto:\
        :sh:\
        :hl:\
        :lp=:\
        :rm=laser:\
        :rp=text:\
        :lf=/var/spool/lpd/lasertxt.log:\
        :sd=/var/spool/lpd/lasertxt:

laserps|Ipresora laser poscript:\
        :sh:\
        :hl:\
        :lp=:\
        :rm=laser:\
        :rp=raw:\
        :lf=/var/spool/lpd/laserps.log:\

If anybody can helpme, i'll apreciate very much
Thanks
    Angelo


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Wed Dec  9 13:20:56 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id NAA28787
          for freebsd-net-outgoing; Wed, 9 Dec 1998 13:20:56 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from ns1.yes.no (ns1.yes.no [195.204.136.10])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA28782
          for <freebsd-net@FreeBSD.ORG>; Wed, 9 Dec 1998 13:20:54 -0800 (PST)
          (envelope-from eivind@bitbox.follo.net)
Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218])
	by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id WAA24343;
	Wed, 9 Dec 1998 22:20:43 +0100 (CET)
Received: (from eivind@localhost)
	by bitbox.follo.net (8.8.8/8.8.6) id WAA17837;
	Wed, 9 Dec 1998 22:20:42 +0100 (MET)
Message-ID: <19981209222041.N15330@follo.net>
Date: Wed, 9 Dec 1998 22:20:41 +0100
From: Eivind Eklund <eivind@yes.no>
To: Brett Glass <brett@lariat.org>, freebsd-net@FreeBSD.ORG
Subject: Re: Error message generated by pppd
References: <4.1.19981208142548.06cb83f0@mail.lariat.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.93.2i
In-Reply-To: <4.1.19981208142548.06cb83f0@mail.lariat.org>; from Brett Glass on Tue, Dec 08, 1998 at 02:28:40PM -0700
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

On Tue, Dec 08, 1998 at 02:28:40PM -0700, Brett Glass wrote:
> I'm running a small system that uses pppd to field incoming calls and
> connect callers to the Net. It's running routed, and IP forwarding is
                              ^^^^^^^^^^^^^^^^^^^

Is there any reason for this?  Unless you know a very explicit reason,
you shouldn't do that.  These messages are due to routed not being set
up for being a gateway, just a client, I think - but normally you
should just disable routed and everything should be fine.

Eivind.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Wed Dec  9 15:17:41 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id PAA10858
          for freebsd-net-outgoing; Wed, 9 Dec 1998 15:17:41 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA10853
          for <freebsd-net@FreeBSD.ORG>; Wed, 9 Dec 1998 15:17:39 -0800 (PST)
          (envelope-from brett@lariat.org)
Received: (from brett@localhost)
	by lariat.lariat.org (8.8.8/8.8.6) id QAA15265;
	Wed, 9 Dec 1998 16:17:29 -0700 (MST)
Message-Id: <4.1.19981209161541.067e3b50@mail.lariat.org>
X-Sender: brett@mail.lariat.org
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 09 Dec 1998 16:17:22 -0700
To: Eivind Eklund <eivind@yes.no>, freebsd-net@FreeBSD.ORG
From: Brett Glass <brett@lariat.org>
Subject: Re: Error message generated by pppd
In-Reply-To: <19981209222041.N15330@follo.net>
References: <4.1.19981208142548.06cb83f0@mail.lariat.org>
 <4.1.19981208142548.06cb83f0@mail.lariat.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Without routed, the system does not seem to route packets to or 
from the hosts that are attached via PPP. At least I can't
ping them. I'd actually LOVE to scuttle routed if I could,
but I need to know how to make things work without it.

--Brett

At 10:20 PM 12/9/98 +0100, Eivind Eklund wrote:
 
>On Tue, Dec 08, 1998 at 02:28:40PM -0700, Brett Glass wrote:
>> I'm running a small system that uses pppd to field incoming calls and
>> connect callers to the Net. It's running routed, and IP forwarding is
>                              ^^^^^^^^^^^^^^^^^^^
>
>Is there any reason for this?  Unless you know a very explicit reason,
>you shouldn't do that.  These messages are due to routed not being set
>up for being a gateway, just a client, I think - but normally you
>should just disable routed and everything should be fine.
>
>Eivind.
>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Wed Dec  9 23:54:39 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id XAA17021
          for freebsd-net-outgoing; Wed, 9 Dec 1998 23:54:39 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from achilles.noc.ntua.gr (achilles.noc.ntua.gr [147.102.222.210])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA17002;
          Wed, 9 Dec 1998 23:54:36 -0800 (PST)
          (envelope-from mantzios@softlab.ece.ntua.gr)
Received: from theseas.softlab.ece.ntua.gr (root@theseas.softlab.ece.ntua.gr [147.102.1.1])
	by achilles.noc.ntua.gr (8.8.8/8.8.8) with ESMTP id JAA10424;
	Thu, 10 Dec 1998 09:53:49 +0200 (EET)
Received: by softlab.ece.ntua.gr with ESMTP
	id JAA15715 ; Thu, 10 Dec 1998 09:53:49 +0200 (EET)
From: Achilleas Mantzios <mantzios@softlab.ece.ntua.gr>
Received: by softlab.ece.ntua.gr [client - phgasos]
	id JAA19755 at Thu, 10 Dec 1998 09:53:48 +0200 (EET)
Date: Thu, 10 Dec 1998 09:53:48 +0200 (EET)
Message-Id: <199812100753.JAA19755@softlab.ece.ntua.gr>
To: ang@adinet.com.uy, freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG
Subject: Re: Printer problem
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

You should use an :if filter for your printer, (apsfilter installation does
that automatically),
or you should pass your ascii file to a filter (a2ps) that produces postscript
and then lpr to the printer.

Cheers,

Achilleus.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Thu Dec 10 06:09:53 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id GAA25623
          for freebsd-net-outgoing; Thu, 10 Dec 1998 06:09:53 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5])
          by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA25551
          for <net@freebsd.org>; Thu, 10 Dec 1998 06:09:12 -0800 (PST)
          (envelope-from luigi@labinfo.iet.unipi.it)
Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id NAA21247; Thu, 10 Dec 1998 13:00:44 +0100
From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Message-Id: <199812101200.NAA21247@labinfo.iet.unipi.it>
Subject: Re: strange problems with ipfw and bridge
To: camposr@MATRIX.COM.BR (Rodrigo Campos)
Date: Thu, 10 Dec 1998 13:00:43 +0100 (MET)
Cc: net@FreeBSD.ORG
In-Reply-To: <Pine.BSF.4.02.9812101039400.20217-100000@speed.matrix.com.br> from "Rodrigo Campos" at Dec 10, 98 11:00:19 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

[crissposted to -net because it is relevant there]

> The bridge works just fine, but when I try to enable the packet filtering
> of bridged packets with 'sysctl -w net.link.ether.bridge_ipfw=1' the
> windows box cannot make any new connections. I'm using the following
> firewall rules:
> 
> 00100 allow ip from any to any via lo0
> 00200 deny ip from any to 127.0.0.0/8
> 01000 pipe 10 ip from any to 200.202.17.6
> 65000 allow ip from any to any
> 65535 deny ip from any to any
...
> There are some interesting details...
> 
> Once I make any network connection to a machine from the windows box
> (ping, ftp, telnet,etc...), the windows box can reconnect to this machine
> after enabling the bridge_ipfw, only new connections cannot be
> established, seems just like if the windows box couldn't find the 'way
> out' to new connections. In the inverse direction the problem is exactly

correct diagnosys. When the bridge passes a packet to the ipfw code and
the packet finds no matching rule, the default rule (65535) is used.
This is what happens e.g. for ARP and explains why you observe the
abvoe.

I should really implement support in IPFW for non-ip traffic matching.
In the meantime there is a hack in ip_fw.c:

                    /*
                     * temporary hack:
                     *   udp from 0.0.0.0 means this rule applies.
                     *   1 src port is match ether type
                     *   2 src ports (interval) is match ether type
                     *   3 src ports is match ether address
                     */

but the code only implements the first one and 
i don't think I have ever tested this...

You could try this and see if/how it works (or if it needs fixes etc.)

> p.s.: I'm having problems accessing your home page in the last few hours,
> anyway I'd like to know if you allow me to mirror it at Brazil so it would
> be faster for the freebsd community in south america to read all that
> documentation.

sure -- but actually the "bridge" and "dummynet" manpages
are supposes to contain everything you should need to know (and if
you or someone have suggestions for changes, integration, etc
please send me a patch).

	cheers
	luigi
-----------------------------+--------------------------------------
Luigi Rizzo                  |  Dip. di Ingegneria dell'Informazione
email: luigi@iet.unipi.it    |  Universita' di Pisa
tel: +39-50-568533           |  via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522           |  http://www.iet.unipi.it/~luigi/
_____________________________|______________________________________

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Thu Dec 10 12:33:20 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id MAA12032
          for freebsd-net-outgoing; Thu, 10 Dec 1998 12:33:20 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from abused.com (abused.com [204.216.142.63])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA12017
          for <freebsd-net@freebsd.org>; Thu, 10 Dec 1998 12:33:17 -0800 (PST)
          (envelope-from gvbmail@tns.net)
Received: from gvb (gvb.tns.net [204.216.245.137])
	by abused.com (8.9.1a/I feel abused.) with SMTP id MAA08104
	for <freebsd-net@freebsd.org>; Thu, 10 Dec 1998 12:33:41 -0800 (PST)
Message-Id: <4.1.19981210123311.00ae9560@abused.com>
X-Sender: gvbmail@mail.tns.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 10 Dec 1998 12:33:16 -0800
To: freebsd-net@FreeBSD.ORG
From: GVB <gvbmail@tns.net>
Subject: test
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

please ignore 

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Thu Dec 10 13:05:09 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id NAA16178
          for freebsd-net-outgoing; Thu, 10 Dec 1998 13:05:09 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from abused.com (abused.com [204.216.142.63])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA16172
          for <freebsd-net@freebsd.org>; Thu, 10 Dec 1998 13:05:07 -0800 (PST)
          (envelope-from gvbmail@tns.net)
Received: from gvb (gvb.tns.net [204.216.245.137])
	by abused.com (8.9.1a/I feel abused.) with SMTP id NAA08169
	for <freebsd-net@freebsd.org>; Thu, 10 Dec 1998 13:05:31 -0800 (PST)
Message-Id: <4.1.19981210125618.00ad17b0@abused.com>
X-Sender: gvbmail@mail.tns.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 10 Dec 1998 13:05:05 -0800
To: freebsd-net@FreeBSD.ORG
From: GVB <gvbmail@tns.net>
Subject: majordomo
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Might be a little offbase here, but I have been tasked to setup Majordomo
for one of our customers.. I know the basics of the beast, but would like
to know the basics of how it is supposed to work.  When someone sends email
to the list isnt it supposed to send it out to everyone right away? Or is a
a delay time? Or do you have to invoke something to send it?  I am getting
an error from majordomo when I try to force a digest to be sent out:

   ----- The following addresses had permanent fatal errors -----
camft-main-digest-outgoing
:include:/usr/local/majordomo/lists/camft-main-digest
    (expanded from: camft-main-digest-outgoing)

   ----- Transcript of session follows -----
550 :include:/usr/local/majordomo/lists/camft-main-digest... Cannot open
/usr/local/majordomo/lists/camft-main-digest: Group writable directory
Message delivered to mailing list camft-main-digest-outgoing
554 camft-main-digest-outgoing... aliasing/forwarding loop broken

It is weird because the same command issued to the test-l-digest doesnt
give me this error, but I still dont get the digest emailed to me
(i am subscribed to the test-l-digist list)

Any help?

Thanks
GVB


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Thu Dec 10 15:39:27 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id PAA08050
          for freebsd-net-outgoing; Thu, 10 Dec 1998 15:39:27 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from tasam.com (tasam.com [198.232.144.22])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA08040
          for <freebsd-net@FreeBSD.ORG>; Thu, 10 Dec 1998 15:39:15 -0800 (PST)
          (envelope-from security@tasam.com)
Received: from localhost (security@localhost)
	by tasam.com (8.9.1/8.9.1) with SMTP id RAA25763;
	Thu, 10 Dec 1998 17:23:12 -0500 (EST)
Date: Thu, 10 Dec 1998 17:23:11 -0500 (EST)
From: Tasam Security <security@tasam.com>
To: GVB <gvbmail@tns.net>
cc: freebsd-net@FreeBSD.ORG
Subject: Re: majordomo
In-Reply-To: <4.1.19981210125618.00ad17b0@abused.com>
Message-ID: <Pine.BSF.3.96.981210172039.20585A-100000@tasam.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

On Thu, 10 Dec 1998, GVB wrote:
>    ----- The following addresses had permanent fatal errors -----
> camft-main-digest-outgoing
> :include:/usr/local/majordomo/lists/camft-main-digest
>     (expanded from: camft-main-digest-outgoing)
> 
>    ----- Transcript of session follows -----
> 550 :include:/usr/local/majordomo/lists/camft-main-digest... Cannot open
> /usr/local/majordomo/lists/camft-main-digest: Group writable directory
> Message delivered to mailing list camft-main-digest-outgoing
> 554 camft-main-digest-outgoing... aliasing/forwarding loop broken

The joys or majordomo and sendmail are endless... apparently your lists/
directory is group writable.. chmod 750 is my recommendation, otherwise
nothing should work from that directory. Uhg.. I didn't notice you were
using a digest, I am not very clear on the workings of digests, but I'd
say change around the permissions first, then see if anything better
happens.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Thu Dec 10 18:56:21 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id SAA00844
          for freebsd-net-outgoing; Thu, 10 Dec 1998 18:56:21 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from magicnet.magicnet.net (magicnet.magicnet.net [204.96.116.9])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA00839
          for <freebsd-net@freebsd.org>; Thu, 10 Dec 1998 18:56:19 -0800 (PST)
          (envelope-from bill@bilver.magicnet.net)
Received: (from uucp@localhost)
	by magicnet.magicnet.net (8.8.6/8.8.8) with UUCP id VAA18246
	for freebsd-net@freebsd.org; Thu, 10 Dec 1998 21:55:39 -0500 (EST)
Received: (from bill@localhost)
	by bilver.magicnet.net (8.9.1/8.9.1) id VAA03249
	for freebsd-net@freebsd.org; Thu, 10 Dec 1998 21:58:44 -0500 (EST)
From: Bill Vermillion <bill@bilver.magicnet.net>
Message-Id: <199812110258.VAA03249@bilver.magicnet.net>
Subject: Re: majordomo
In-Reply-To: <4.1.19981210125618.00ad17b0@abused.com> from GVB at "Dec 10, 98 01:05:05 pm"
To: freebsd-net@FreeBSD.ORG
Date: Thu, 10 Dec 1998 21:58:44 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL38 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

GVB recently said:

> Might be a little offbase here, but I have been tasked to setup
> Majordomo for one of our customers.. I know the basics of the
> beast, but would like to know the basics of how it is supposed to
> work. When someone sends email to the list isnt it supposed to
> send it out to everyone right away? Or is a a delay time? Or do
> you have to invoke something to send it? I am getting an error
> from majordomo when I try to force a digest to be sent out:

>    ----- The following addresses had permanent fatal errors -----
> camft-main-digest-outgoing
> :include:/usr/local/majordomo/lists/camft-main-digest
>     (expanded from: camft-main-digest-outgoing)

>    ----- Transcript of session follows -----
> 550 :include:/usr/local/majordomo/lists/camft-main-digest... Cannot open
> /usr/local/majordomo/lists/camft-main-digest: Group writable directory
                                                ^^^^^^^^^^^^^^^^^^^^^^^^

There's your clue.  The latest sendmail doesn't like this.  After
all you don't want other changing your mailing list do you?


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Thu Dec 10 19:49:42 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id TAA06412
          for freebsd-net-outgoing; Thu, 10 Dec 1998 19:49:42 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from poboxer.pobox.com (port7.prairietech.net [208.141.230.84])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA06405
          for <freebsd-net@FreeBSD.ORG>; Thu, 10 Dec 1998 19:49:40 -0800 (PST)
          (envelope-from alk@poboxer.pobox.com)
Received: (from alk@localhost)
	by poboxer.pobox.com (8.9.1/8.9.1) id VAA08337;
	Thu, 10 Dec 1998 21:48:34 -0600 (CST)
	(envelope-from alk)
From: Tony Kimball <alk@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Thu, 10 Dec 1998 21:48:33 -0600 (CST)
X-Face: \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.<li^!8ecK]}3L-
	6`ZQW3}kxy*5]B<KA"&iBl58"/$W-0PP`B7c%'XczR)8T0VN47L`rQlu8qBIX4TJ|v'D%:k7GO%v4A
	Os>Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO
	5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed
Reply-To: alk@pobox.com
To: bill@bilver.magicnet.net
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: majordomo
References: <4.1.19981210125618.00ad17b0@abused.com>
	<199812110258.VAA03249@bilver.magicnet.net>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <13936.38339.37056.442305@avalon.east>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Quoth Bill Vermillion on Thu, 10 December:
: 
: >    ----- Transcript of session follows -----
: > 550 :include:/usr/local/majordomo/lists/camft-main-digest... Cannot open
: > /usr/local/majordomo/lists/camft-main-digest: Group writable directory
:                                                 ^^^^^^^^^^^^^^^^^^^^^^^^
: 
: There's your clue.  The latest sendmail doesn't like this.  After
: all you don't want other changing your mailing list do you?

Well, yes.  That's what group permissions are *for*, to allow
the members of a given group to administer those parts of the system
for which they are responsible.  Sendmail and ppp are painfully, 
woefully ignorant of the meaning and value of group bits.




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Thu Dec 10 22:13:39 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id WAA20715
          for freebsd-net-outgoing; Thu, 10 Dec 1998 22:13:39 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA20709
          for <freebsd-net@FreeBSD.ORG>; Thu, 10 Dec 1998 22:13:37 -0800 (PST)
          (envelope-from roberto@keltia.freenix.fr)
Received: (from uucp@localhost)
	by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id HAA04576
	for freebsd-net@FreeBSD.ORG; Fri, 11 Dec 1998 07:13:29 +0100 (CET)
	(envelope-from roberto@keltia.freenix.fr)
Received: by keltia.freenix.fr (Postfix, from userid 101)
	id BA763155B; Fri, 11 Dec 1998 07:02:02 +0100 (CET)
Date: Fri, 11 Dec 1998 07:02:02 +0100
From: Ollivier Robert <roberto@keltia.freenix.fr>
To: freebsd-net@FreeBSD.ORG
Subject: Re: majordomo
Message-ID: <19981211070202.A3479@keltia.freenix.fr>
Mail-Followup-To: freebsd-net@FreeBSD.ORG
References: <4.1.19981210125618.00ad17b0@abused.com> <199812110258.VAA03249@bilver.magicnet.net> <13936.38339.37056.442305@avalon.east>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.94.16i
In-Reply-To: <13936.38339.37056.442305@avalon.east>; from Tony Kimball on Thu, Dec 10, 1998 at 09:48:33PM -0600
X-Operating-System: FreeBSD 3.0-CURRENT/ELF ctm#4871 AMD-K6 MMX @ 200 MHz
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

According to Tony Kimball:
> Well, yes.  That's what group permissions are *for*, to allow
> the members of a given group to administer those parts of the system
> for which they are responsible.  Sendmail and ppp are painfully, 
> woefully ignorant of the meaning and value of group bits.

define(`confDONT_BLAME_SENDMAIL', `groupwritabledirpathsafe')dnl
-- 
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr
FreeBSD keltia.freenix.fr 3.0-CURRENT #2: Sun Nov  8 01:22:20 CET 1998


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Fri Dec 11 03:16:15 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id DAA20330
          for freebsd-net-outgoing; Fri, 11 Dec 1998 03:16:15 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from magicnet.magicnet.net (magicnet.magicnet.net [204.96.116.9])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA20325
          for <freebsd-net@freebsd.org>; Fri, 11 Dec 1998 03:16:13 -0800 (PST)
          (envelope-from bill@bilver.magicnet.net)
Received: (from uucp@localhost)
	by magicnet.magicnet.net (8.8.6/8.8.8) with UUCP id GAA14799
	for freebsd-net@freebsd.org; Fri, 11 Dec 1998 06:15:26 -0500 (EST)
Received: (from bill@localhost)
	by bilver.magicnet.net (8.9.1/8.9.1) id GAA09178
	for freebsd-net@freebsd.org; Fri, 11 Dec 1998 06:16:20 -0500 (EST)
From: Bill Vermillion <bill@bilver.magicnet.net>
Message-Id: <199812111116.GAA09178@bilver.magicnet.net>
Subject: Re: majordomo
In-Reply-To: <13936.38339.37056.442305@avalon.east> from Tony Kimball at "Dec 10, 98 09:48:33 pm"
To: freebsd-net@FreeBSD.ORG
Date: Fri, 11 Dec 1998 06:16:20 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL38 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Tony Kimball recently said:
> Quoth Bill Vermillion on Thu, 10 December:

> : >    ----- Transcript of session follows -----
> : > 550 :include:/usr/local/majordomo/lists/camft-main-digest... Cannot open
> : > /usr/local/majordomo/lists/camft-main-digest: Group writable directory
> :                                                 ^^^^^^^^^^^^^^^^^^^^^^^^
> : 
> : There's your clue.  The latest sendmail doesn't like this.  After
> : all you don't want other changing your mailing list do you?

> Well, yes.  That's what group permissions are *for*, to allow
> the members of a given group to administer those parts of the system
> for which they are responsible.  Sendmail and ppp are painfully, 
> woefully ignorant of the meaning and value of group bits.

Well this was touted as a feature in the latest sendmail.  Just
part of making everything more secure.  As another poster replied
there is a flag to change this.  I tend not to work in a group
adminstered arena so I had not considered this change to sendmail
to be a problem.  Opinions are shaped by your environment, so
thanks for pointing this out.

Does this list know that sendmail has gone commercial?
The freegoods are at www.sendmail.org, and the commericial
information is at www.sendmail.com

Support contracts, graphical interfaces, etc.

It is currenlty available ONLY on FreeBSD, Linux RedHat, and
Solaris on the Unix side.  There is also an NT version.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Fri Dec 11 03:46:57 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id DAA23153
          for freebsd-net-outgoing; Fri, 11 Dec 1998 03:46:57 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA23148
          for <freebsd-net@FreeBSD.ORG>; Fri, 11 Dec 1998 03:46:56 -0800 (PST)
          (envelope-from jkh@zippy.cdrom.com)
Received: from zippy.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1])
	by zippy.cdrom.com (8.9.1/8.9.1) with ESMTP id DAA04477;
	Fri, 11 Dec 1998 03:44:59 -0800 (PST)
To: Bill Vermillion <bill@bilver.magicnet.net>
cc: freebsd-net@FreeBSD.ORG
Subject: Re: majordomo 
In-reply-to: Your message of "Fri, 11 Dec 1998 06:16:20 EST."
             <199812111116.GAA09178@bilver.magicnet.net> 
Date: Fri, 11 Dec 1998 03:44:59 -0800
Message-ID: <4474.913376699@zippy.cdrom.com>
From: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

> Does this list know that sendmail has gone commercial?

Most people in both the northern and southern hemispheres have known
that for at least 6 months, Bill.  I heard they shot Kennedy too!  :-)

- Jordan

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Fri Dec 11 07:53:50 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id HAA20821
          for freebsd-net-outgoing; Fri, 11 Dec 1998 07:53:50 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from carp.gbr.epa.gov (carp.gbr.epa.gov [204.46.159.110])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA20813
          for <freebsd-net@freebsd.org>; Fri, 11 Dec 1998 07:53:47 -0800 (PST)
          (envelope-from mjenkins@carp.gbr.epa.gov)
Received: (from mjenkins@localhost)
	by carp.gbr.epa.gov (8.8.8/8.8.8) id JAA27969
	for freebsd-net@freebsd.org; Fri, 11 Dec 1998 09:53:23 -0600 (CST)
	(envelope-from mjenkins)
Date: Fri, 11 Dec 1998 09:53:23 -0600 (CST)
From: Mike Jenkins <mjenkins@carp.gbr.epa.gov>
Message-Id: <199812111553.JAA27969@carp.gbr.epa.gov>
To: freebsd-net@FreeBSD.ORG
Subject: Re: majordomo
In-Reply-To: <13936.38339.37056.442305@avalon.east>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

On Dec 10, Tony Kimball <alk@pobox.com> wrote:

> Well, yes.  That's what group permissions are *for*, to allow
> the members of a given group to administer those parts of the system
> for which they are responsible.  Sendmail and ppp are painfully, 
> woefully ignorant of the meaning and value of group bits.

It is a security thing.  Sendmail changes it uid/gid to those of
the mailing list file when delivering (for root owned mailing list
files it changes it uid/gid to option DefaultUser in sendmail.cf).

If the directory is group writeable anyone in the group can change
the mailing list files including ones they are not supposed to.  
They can add a program delivery like '| /tmp/create-suid-sh.sh'
which is a simple shell script to create a suid shell of the owner
of the mailing list file.  This is all spelled out in the Security
chapter of the Sendmail book (even the 1993 First Edition that I have).

I ran into this recently when I had a file delivery in a mailing
list file.  The file (/home/archives/somelist) had to be owned by
the owner of the mailing list file or in the same group as the
mailing list file and had to be writeable by the owner or group.

Mike

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Sat Dec 12 10:40:45 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id KAA15184
          for freebsd-net-outgoing; Sat, 12 Dec 1998 10:40:45 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from gjp.erols.com (alex-va-n008c079.moon.jic.com [206.156.18.89])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA15179
          for <freebsd-net@FreeBSD.ORG>; Sat, 12 Dec 1998 10:40:43 -0800 (PST)
          (envelope-from gjp@gjp.erols.com)
Received: from gjp.erols.com (localhost.erols.com [127.0.0.1])
	by gjp.erols.com (8.9.1/8.8.7) with ESMTP id NAA61705;
	Sat, 12 Dec 1998 13:39:54 -0500 (EST)
	(envelope-from gjp@gjp.erols.com)
X-Mailer: exmh version 2.0.1 12/23/97
To: Bill Vermillion <bill@bilver.magicnet.net>
cc: freebsd-net@FreeBSD.ORG
From: "Gary Palmer" <gpalmer@FreeBSD.ORG>
Subject: Re: majordomo 
In-reply-to: Your message of "Fri, 11 Dec 1998 06:16:20 EST."
             <199812111116.GAA09178@bilver.magicnet.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 12 Dec 1998 13:39:54 -0500
Message-ID: <61701.913487994@gjp.erols.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Bill Vermillion wrote in message ID
<199812111116.GAA09178@bilver.magicnet.net>:
> Does this list know that sendmail has gone commercial?
> The freegoods are at www.sendmail.org, and the commericial
> information is at www.sendmail.com

I think that very much depends on what you mean by ``gone commercial'' If 
you've ever been to one of Erics talks (say at ISPCon or USENIX or LISA) then 
you'll know that the commercial side sells support and features often needed 
in a commercial situation (i.e. point and click interfaces which make 
Pointy-Haired-Bosses happy), but the money is also used to fund future 
development of the *freeware* version. The free sendmail is not, and never 
will, go away as it is a fundamental part of Erics business model. Since 
sendmail is used by ~75 of the internet as its MTA, keeping it freeware gives 
him tremendous influence over the market, which can only help his commercial 
sales.

Gary
--
Gary Palmer                                          FreeBSD Core Team Member
FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Sat Dec 12 13:14:56 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id NAA27195
          for freebsd-net-outgoing; Sat, 12 Dec 1998 13:14:56 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from milkyway.org (lta-r-1.usit.net [205.241.194.17] (may be forged))
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA27190
          for <freebsd-net@FreeBSD.org>; Sat, 12 Dec 1998 13:14:52 -0800 (PST)
          (envelope-from toby@milkyway.org)
Received: from milkyway.org (rigel.milkyway.org [205.241.194.19]) by milkyway.org (8.8.5/8.8.3) with ESMTP id QAA27285 for <freebsd-net@FreeBSD.org>; Sat, 12 Dec 1998 16:19:24 -0500 (EST)
Message-ID: <3672DD2B.D45C5FD7@milkyway.org>
Date: Sat, 12 Dec 1998 16:16:27 -0500
From: Toby Swanson <toby@milkyway.org>
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: freebsd-net@FreeBSD.ORG
Subject: Re: majordomo
References: <4474.913376699@zippy.cdrom.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Which one did they get this time?  |;^)   GDR!

Toby ( I couldn't resist)

Jordan K. Hubbard wrote:

> > Does this list know that sendmail has gone commercial?
>
> Most people in both the northern and southern hemispheres have known
> that for at least 6 months, Bill.  I heard they shot Kennedy too!  :-)
>
> - Jordan
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message

From owner-freebsd-net  Sat Dec 12 17:09:50 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id RAA21385
          for freebsd-net-outgoing; Sat, 12 Dec 1998 17:09:50 -0800 (PST)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA21379;
          Sat, 12 Dec 1998 17:09:47 -0800 (PST)
          (envelope-from jkh@zippy.cdrom.com)
Received: from zippy.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1])
	by zippy.cdrom.com (8.9.1/8.9.1) with ESMTP id RAA33916;
	Sat, 12 Dec 1998 17:09:41 -0800 (PST)
To: "Gary Palmer" <gpalmer@FreeBSD.ORG>
cc: Bill Vermillion <bill@bilver.magicnet.net>, freebsd-net@FreeBSD.ORG
Subject: Re: majordomo 
In-reply-to: Your message of "Sat, 12 Dec 1998 13:39:54 EST."
             <61701.913487994@gjp.erols.com> 
Date: Sat, 12 Dec 1998 17:09:41 -0800
Message-ID: <33913.913511381@zippy.cdrom.com>
From: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

See http://www.salonmagazine.com/21st/ for more information on
this topic, guys...

- Jordan

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message