HP3000-L Archives

June 1997, Week 3

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:
John Skelton <[log in to unmask]>
Reply To:
Date:
Sat, 14 Jun 1997 23:16:58 +0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (76 lines)
Hi Mark,

Wow!!, if I knew only 'alf of wot yer discussing I'd be impressed,
thank god your on our side, I just 'ope you can iron out the problem
so we can all be seriously smooooooth :-)

John "Nothing goes with THESE pants!,hehehe :-)" Skelton

> 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)
>
John "Danger" Skelton

ATOM RSS1 RSS2