D&C Lug - Home Page
Devon & Cornwall Linux Users' Group

[ Date Index ][ Thread Index ]
[ <= Previous by date / thread ] [ Next by date / thread => ]

Re: [LUG] NFS, /etc/resolv.conf rather odd connection.



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Neil Williams wrote:
>
> A default route is a gateway but it is possible to configure more than
one
> gateway (e.g. one per NIC), but there can only be one default route
(IIRC).
> (Our resident DNS expert seems to have been remarkably silent during this
> whole thread - have we got it right Simon?)

Routes are routing not DNS....

As I always say "DNS is an application", nothing to do wih networking at
all ;)

The "default route" is literally the route packets follow if they have
no other route specified. Usually these days the default route takes you
to the Internet, since if the IP address isn't yours it usually belongs
to someone on the Internet.

A gateway is usually the first "hop" on a route, it distinguishes things
that aren't "host" entries in the routing table.

You could presumably have two gateways that take your packets to the
Internet, which you might have some method of choosing between to ensure
your default route was "redundant".

Whilst a gateway is usually a host on your local network, I don't think
this is required, and you can specify that a route should go through a
gateway a long way away (as long as your machine knows how to route
packets to the gateway!), although this is pretty unusual.

Discussion of my "netstat -nr"

Destination     Gateway         Genmask         Flags   MSS Window  irtt
Iface

158.152.1.222   0.0.0.0         255.255.255.255 UH        0 0          0
ppp0

This is a host entry, get to 158.152.1.222 via ppp0 interface.

192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0
eth1

One local network (192.168.1) is via eth1

192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0
eth0

A second local network (192.168.0) is via eth0, this happens to be
wireless, but at this layer we don't care how packets are conveyed it
could be carrier pigeon for all the routing table cares.

Dedicated routers sometimes want to know properties of the lower layers,
so they can choose the most appropriate eans if more than one route exists.

Using 192.168 address space is a "poor show", I should allocate myself
random sunets from the 10/8 address space in case I need to merge my
network with another private network at some point in the future.
Fortunately my network is sufficiently small to renumber easily should
this happen.

172.16.0.0      -               255.255.0.0     !         - -          - -
10.0.0.0        -               255.0.0.0       !         - -          - -

These are null routes (!) they mean any packets for (172.16/16) or
(10/8) are to be discarded. These are RFC1918 address space and should
never be sent anywhere, especially not to your default route.

127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo

The (127/8) network is routed via the loopback adaptor. Whilst we
usually think of this as only 127.0.0.1, other addresses in 127.0.0/24
are sometimes used for local hardware devices like 'time sources'.

Those worried about IPv4 address allocations should not a whole class A
is wasted for 1 address (or one class C), some OSes use a class C for
127, others a class A, the RFC's are silent on this matter AFAIK.

224.0.0.0       -               224.0.0.0       !         - -          - -

The 224 prefix denotes multicast addresses (note the weird netmask), we
null route these as well as Simon hasn't been playing with multicast :(

Multicast, is mainly aimed at broadcast type situations, where the
routers co-operate to avoid duplicating traffic, this applied also to
multiuser conferencing. Most ISPs and most Internet exchanges are not
multicast enabled, something the transition to IPv6 may well fix, but
you can still play by tunneling into bits of the Internet that are
multicast enabled.


0.0.0.0         158.152.1.222   0.0.0.0         UG        0 0          0
ppp0

The default route, represented by the target 0.0.0.0, says here sends
everything still not matched to 158.152.1.222, which we know from the
above is go out via the ppp0 interface. Note the "G" this is my only
gateway.

I use slash notation "/n" to denote subnet masks "/8" means the subnet
is "255.0.0.0" (first 8 bits are network), "/16" is "255.255.0.0" (first
16 bits are network). Slash notation is used as it is much easier when
dealing with non-octet boundaries, i.e. what is the subnet for a /4 or a
/27 ? It is also much more succinct!

Here endeth the lesson on the output if the "netstat -rn" command.


The original problem looks like a TCP wrappers issues which is usually
'DNS' or less often 'ident'. "mountd" is tcpd wrapper aware on most
Linux systems I believe. Since it goes away with the contents of
resolv.conf let us assume DNS, the tcpd manual page gives a "fix" for
ident troubles).

I don't have much experience of NFS on Linux, but the manual suggests
that specific exports to hosts are fed straight to the kernel, where as
subnet exports are more complex to handle. Wonder if it is smart enough
to realise that a 255.255.255.255 subnet is a host? I'd try leaving out
the "/255.255.255.255" but I doubt that is the problem.

Andrew said....
>$ cat /etc/exports
/opt/ltsp/i386 10.0.0.0/255.255.255.0(ro,no_root_squash)
/home/netfs/ws20 10.0.0.20/255.255.255.255(rw,no_root_squash)
/home/netfs/nc21 10.0.0.21/255.255.255.255(rw,no_root_squash)
/home/mn        10.0.0.0/255.255.255.0(rw)

Otherwise try checking /etc/hosts.allow and /etc/hosts.deny, and check
how long it takes to look up "dig @ourdnsserver -x 10.0.0.1" for each
DNS server in /etc/resolv.conf.

Also posting contents of /etc/resolv.conf wouldn't hurt.

If your local DNS isn't configured to master 10.in-addr.arpa, the
Internet DNS servers should return "NXDOMAIN" for it (thank IANA for
this). But this could be quite slow as it requires going to an
offnetwork server (there are unicast routed DNS servers whose sole role
in life is to say the RFC1918 address space is empty - sad).

The Plymouth DNS admins could configure the domain rfc1918 domains (i.e.
10.in-addr.arpa) as empty domains to speed the process up and avoid
going "off network".

More local, and easier to try, I don't know if the getnamebyaddr call
used here (?) respects the nsswitch.conf settings, if it does making
sure you have a relevant /etc/hosts entry for the ws20 and nc21, and
files before DNS in nsswitch.conf might help.

 grep host /etc/nsswitch.conf
#hosts:     db files nisplus nis dns
hosts:      files dns

Worth a try....


-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/rkKGGFXfHI9FVgYRAmxNAKDF3JgJd4ISAKs2bYBELtaNKHz7dACbB8Ni
rpiA16MxvuxG6kebiLbhmJs=
=DLRI
-----END PGP SIGNATURE-----

--
The Mailing List for the Devon & Cornwall LUG
Mail majordomo@xxxxxxxxxxxx with "unsubscribe list" in the
message body to unsubscribe.


Lynx friendly