Hello all/Jacques,
I think that I may have discovered a bug relating to udp and use of the
127.0.0.1/localhost address. The issue that I have is that udp packets
sent to the 127.0.0.1 address from within a virtual server appear to
actually go to the real 127.0.0.1 and not to IPROOT.
I have a virtual server (ns1) running bind version 8.3.3. Within the
server I can query IPROOT for DNS lookups without any problems. However if
I query localhost I get no response. I know that bind has bound to both
tcp and udp sockets:
ns1:/etc/bind/source# netstat -a | grep domain
tcp 0 0 ns1.cit.holcim.c:domain *:* LISTEN
udp 0 0 ns1.cit.holcim.c:domain *:*
However snooping the packets from within the root server I see the
following:
rhost01:/# ngrep -d lo .\* host 192.168.1.71 and port 53
interface: lo (127.0.0.0/255.0.0.0)
filter: ip and ( host 192.168.1.71 and port 53 )
match: .*
#
U 192.168.1.71:32898 -> 127.0.0.1:53
.............rblade18.cit.holcim.com.....
#
U 192.168.1.71:32898 -> 127.0.0.1:53
.............rblade18.cit.holcim.com.....
####
T 192.168.1.71:42824 -> 192.168.1.71:53 [AP]
.).............rblade18.cit.holcim.com.....
##
T 192.168.1.71:53 -> 192.168.1.71:42824 [AP]
.}.............rblade18.cit.holcim.com....................P.............ns1
...............ns2...E.............G.W.............H
As you can see the tcp request goes to the right place, however the udp
does not. By the way, I could only see these packets when I used the lo
device in the root server (which makes sense if this behaviour is what I
think it is).
In the vserver patch the following checks take place in route.h:
+ if (ipv4root != 0){
+ if (src == 0){
+ src = dst == 0x0100007f
+ ? 0x0100007f: ipv4root;
+ }else if (ipv4root != src){
+ return -EPERM;
+ }
+ if (dst == 0x0100007f && current->s_context != 0){
+ dst = ipv4root;
+ }
+ }
It seems to me that dst should properly be assigned to the ipv4root but it
doesn't feel like that to me at the moment. Can I ask if someone else can
duplicate this behaviour with bind? Also, I have an issue with running ntp
in a virtual server as a time server to other clients (but not as a normal
time client) which I think is also related to this issue.
Cheers,
Mark.
--
Mark Lawrence
Holcim Group Support Ltd
Corporate IT
Im Schachen
CH-5113 Holderbank
Phone +41 58 858 65 16
Fax +41 58 858 65 20
[EMAIL PROTECTED]
www.holcim.com
