LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)
-   -   SuSE 9.2 XDM turn "off" authoritative DNS queries (https://www.linuxquestions.org/questions/linux-software-2/suse-9-2-xdm-turn-off-authoritative-dns-queries-347447/)

confused-but-committ 07-27-2005 07:00 PM

SuSE 9.2 XDM turn "off" authoritative DNS queries
 
Q: Is there a way to turn "OFF" forced authoritative reverse DNS lookups in XDM on SuSE 9.2? RedHat works fine and accpets non-authoritative reverse DNS lookup replies. Apparently SuSE is much more security conscious, to our chagrin. It seems to ALWAYS want to contact the "authoritative" server for a domain to get reverse lookups satisfied. Internal lab hosts on private networks suffer as a result since they are not in DNS when queried from hosts external to the lab.. Details below.

We have external corporate network hosts on subnet A ( example: 123.143.92.x) which are unknown in DNS to lab networks, (ex: 10.100.4.x) on subnet B. Each have their own domain for which they are authoritative and company policy will not allow any lab interaction of any sort with lab networks. Proxies and switch VLANs allow the handling of traffic between the 2 networks. A proxy using NAT and a caching nameserver handles outbound DNS queries as if they were being answered by the proxy, hence lab get the proper DNS query responses, even though they are on an unknown network.

When RedHat ES4 hosts running XDM are queried by an external corporate host on 123.143.92.x, they reference the appropriate internal nameserver which forwards to the proxy, yielding an non-authoritative response for reverse record lookups. RedHat is quite happy the name given by the reverse lookup and hence allows XDM displays to open up.

SuSe EL9.2 however is not so forgiving. Traced code show that the queries coming back from the non-authoritative name server are followed by a request from SuSE XDM for an "authoritative" answer for that name. It gets the right name, but wants MORE. The internal lab DNS servers responds with the name of the authoritative server, and SuSE XDM tries to go directly to that host to obtain the authoritative reverse lookup. This circumvents the /etc/resolv.conf file and the DNS proxy host and forces the queried XDM host to send for a response to the corporate DNS server. The corporate DNS server of course doesn't recognized the lab host query IP since it is unknown to it. So, the "computed display" from XDM debug info comes back as 0.0.0.0 due to the inability to get an authoritative answer.

Is there a way to circumvent this default setting either within the X11 settings, startup config, or by using some other architecture changes to make the SuSe 9.2 reverse lookups succeed so that our users can get X displays to lab hosts from the corporate network desktops? (corp Windows XP client using Cygwin "x -query host.IP", ala "x -query 10.100.1.41") (Similar to Xwin32 and Xdeep)

Example:

Basic problem XDM debug on lab host:

ProcessRequestSocket^M
header: 1 10 23^M
Manage 23^M
FindProtoDisplay^M
Manage Session ID 331888001, pdpy 0x8071ae0^M
Computed display name: 0.0.0.0:0^M
ConvertAddr returning 0 for family 10^M
Starting display 0.0.0.0:0,MIT-unspecified^M
StartDisplay 0.0.0.0:0^

Basic details of query failure:

open("/etc/resolv.conf", O_RDONLY) = 6^M
fstat64(6, {st_mode=S_IFREG|0644, st_size=104, ...}) = 0^M
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4032b000^M
read(6, "nameserver 10.100.4.50\nnameserve"..., 4096) = 104^M
read(6, "", 4096) = 0^M
close(6) = 0^M
munmap(0x4032b000, 4096) = 0^M
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 6^M
connect(6, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.100.4.50")}, 28) = 0^M
send(6, "\326\300\1\0\0\1\0\0\0\0\0\0\0010\0010\0010\0010\7in-a"..., 38, 0) = 38^M
gettimeofday({1121901491, 530464}, NULL) = 0^M
poll([{fd=6, events=POLLIN, revents=POLLIN}], 1, 5000) = 1^M
ioctl(6, FIONREAD, [118]) = 0^M
recvfrom(6, "\326\300\205\203\0\1\0\0\0\1\0\0\0010\0010\0010\0010\7"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.100.4.50")}, [16]) = 118^M
close(6) = 0^M
write(1, "Computed display name: 0.0.0.0:0"..., 33) = 33^M



Using proxy host 123.143.92.29 yields the same

recvfrom(6, "v\315\201\203\0\1\0\0\0\1\0\0\0010\0010\0010\0010\7in-"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("123.143.92.29")}, [16]) = 104^M
close(6) = 0^M
write(1, "Computed display name: 0.0.0.0:0"..., 33) = 33


Details of failure:

stat64("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=104, ...}) = 0^M
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 6^M
connect(6, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.100.4.50")}, 28) = 0^M
send(6, "u8\1\0\0\1\0\0\0\0\0\0\0010\0010\0010\0010\7in-addr\4arpa\0\0\f\0\1", 38, 0) = 38^M (reverse lookup)
gettimeofday({1121995111, 595750}, NULL) = 0^M
poll([{fd=6, events=POLLIN, revents=POLLIN}], 1, 5000) = 1^M
ioctl(6, FIONREAD, [118]) = 0^M
recvfrom(6, "u8\205\203\0\1\0\0\0\1\0\0\0010\0010\0010\0010\7in-addr\4arpa\0\0\f\0\1\0010\7in-addr\4arpa\0\0\6\0\1\0\0\16\20\0006\7dnsrvr1\3flt\3lab\3com\0\nhostmaster\300H\0\0\0\1\0\0\3\204\0\0 \2X\0\1Q\200\0\0\16\20", 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.100.1.50")}, [16]) = 118^M
close(6) = 0^M
(request for authoritative answer, which gives only the local lab domain as authoritative, not for corporate net)


Actual DNS logs on servers (request for authoritative host for looked up host name, d1100757.corp.com)

lab dnsrvr1: PACKET UDP Rcv 10.100.1.51 09f8 Q [0001 D NOERROR] (3)146(2)92(3)143(3)123(7)in-addr(4)arpa(0)

lab dnsrvr1: PACKET UDP Snd 10.100.1.51 09f8 R Q [8081 DR NOERROR] (3)146(2)92(3)143(3)123(7)in-addr(4)arpa(0),
DATA (9)d11007157(4)corp(3)com(0)

lab dnsrvr1: PACKET UDP Rcv 10.100.1.51 09f9 Q [0001 D NOERROR] (9)d11007157(4)corp(3)com(0),
Name "[C016](4)corp(3)com(0)
DATA
PrimaryServer: (11)corpdnsrv[C016](3)corp(3)com(0)
Administrator: (6)bobby(3)sox)
SerialNo = 1184023
Refresh = 900
Retry = 600
Expire = 604800
MinimumTTL = 900

confused-but-committ 07-29-2005 04:32 PM

XDM+KDM not supported - use GDM
 
XDM, KDM are NOT SUPPORTED by SuSE ..... They work fine on RedHat, not so on SuSE

See: http://www.novell.com/support/produc..._supported.pdf

Only GDM is supported by SuSE

GDM is a total re-write per below:

GDM is a replacement for XDM, the X Display Manager.
Unlike its competitors (X3DM, KDM, WDM) GDM was written
from scratch and does not contain any original XDM / X
Consortium code. GDM runs and manages the X servers for
both local and remote logins (using XDMCP). See
http://www.jirka.org/gdm.html for more details.


So, after hacking through /etc/opt/gnome/gdm/gdm.conf and /etc/sysconfig/displaymanager, I finally got an Xserver to come up from a Cygwin/XWin32
request from a coporate host.

I will be putting the tweaks to the other swdev servers so that hosts will be accessible and have extensive logging enabled via Gnome. Note that
the default desktop you will get is still KDE.... It's just the "Display Manager" that must be GNOME. None of the /etc/X11/xdm/xdm-config files will
be used and there is no "authoritative" DNS requests to the corporate server for reverse lookup names on IP addresses.

Note that to startup up GDM, you still have to use /etc/init.d/xdm restart and it uses the selection of GDM from /etc/sysconfig/displaymanager
(set by hand as the required display manager)


All times are GMT -5. The time now is 03:34 PM.