HP3000-L Archives

June 1997, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Mark Bixby <[log in to unmask]>
Reply To:
Date:
Fri, 13 Jun 1997 19:21:57 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (66 lines)
I have just confirmed a serious POSIX smoothing issue that prevents proper
operation of BIND/iX.  :-(

The scenario:

1) Create a SOCK_DGRAM socket.
2) sendto() "someplace".
3) recvfrom() a reply along with the sockaddr_in structure showing where it came
from.

Under HPUX, and probably all other Unixes (I assume), if "someplace" is a
non-127.0.0.1 address for the host you're running this test program on, the
recvfrom() sockaddr_in structure will contain the non-127.0.0.1 address as
expected.

HOWEVER, under MPE 5.5, recvfrom() returns 127.0.0.1 in sockaddr_in, instead of
the non-loopback address.  Thus on my loaner machine, sendto(159.115.2.222)
results in recvfrom(127.0.0.1).  Unfortunately BIND is expecting to see
recvfrom(159.115.2.222).

Note that under both HPUX and MPE if you sendto() 127.0.0.1, recvfrom() will
return 127.0.0.1, which is OK.

Why is this a problem for BIND/iX?

BIND/iX generates a list of nameservers to query to resolve the hostname in
question.  It goes down the list, trying to query each nameserver.  For
security reasons, it compares the address from the recvfrom() with the
sendto() (i.e. to make sure the answer came back from the expected nameserver).
If there is a mismatch, BIND throws away the data and tries the next server.

For BIND/iX, the result is to ignore answers from the local BIND/iX server,
forcing the resolver routines to query external nameservers.  If you have your
zones slaved to external servers, you just suffer a performance penalty.  But
if BIND/iX is the master and there are *no* external slaves, you're screwed,
because BIND/iX ignores your local data due to the address mismatch problem.

This may or may not be related to an early porting issue I discovered, where
under MPE you are forbidden to bind() to a non-zero address.  By default,
BIND wants to bind() explicitly to 127.0.0.1 plus all other interface
addresses.  My porting hack was to zero out the address before calling bind(),
and in the BIND/iX named.conf file, only specify a single non-loopback
listen-on address.

Summary:

Serious POSIX smoothing issue: recvfrom() always returns 127.0.0.1 when you
are receiving from the local host, instead of the same address that you called
sendto() with.

May be related to another smoothing issue of being unable to bind() to explicit
non-zero addresses.

BIND/iX should function properly when querying external nameservers.

BIND/iX will ignore itself when trying to query or update data.  There is an
#ifdef to ignore the address mis-match check, but that's a major security
hole that shouldn't be opened.  I think this problem is going to require a
fix from HP......
--
Mark Bixby                      E-mail: [log in to unmask]
Coast Community College Dist.   Web: http://www.cccd.edu/~markb/
District Information Services   1370 Adams Ave, Costa Mesa, CA, USA 92626-5429
Technical Support               +1 714 438-4647
"You can tune a file system, but you can't tune a fish." - tunefs(1M)

ATOM RSS1 RSS2