We only took two photos this time round. Again of the whiteboard. Comlaints were that the previous image was too small - so we took two this time: left and right, each about 200KB.

Routing

This gave us more crap in the end than we thought. Every time things got working, something new pitched up. Eventually we figured out that one of our subnets in the big network on the right wasn't part of out big network at all. Yea, 10.51.0.0/28 isn't part of 10.51.10.0/24 - believe it or not (no pun towards Ripley's intended). Whilst we could have gotten it to work we rather just fixed the network to be 10.51.10.0/28. This conforms the the classless addressing scheme towards which the internet is moving (or at least, that is what is claimed).

Please click here to get hold of a tgz file containing the routing tables for each and every router. Be gratefull - this took us the better part of the morning to get working.

We made the routes stick by stucking them into /etc/conf.d/local.start (this is exactly the same as rc.local on other systems, only difference afaik is that Gentoo also has a local.stop which no other distro afaik has - please feel free to correct me).

The correct way would have been to do it in /etc/conf.d/net as in:

routes_eth1 = (
		"-net 10.0.0.0/8 gw 192.168.10.2"
	)
routes_eth0 = (
		"-net 192.168.0.0/16 gw 192.168.10.1"
	)

For NL21 for example. NL23 would have looked like:

routes_eth0 = (
		"-net 192.168.2.0/24 gw 192.168.0.2"
		"-net 192.168.1.0/24 gw 192.168.0.1"
		"-net 192.168.0.0/26 reject"
	)
routes_eth1 = (
		"-net 10.0.0.0/8 gw 192.168.10.2"
	)

Which will mean that the routes will come up along with the device, instead of at the end of the boot proces when /etc/init.d/local start gets executed.

DNS

Right. After a few long hours of hacking DNS a few things came to the fore:

• Always remember to increment the serial number of any zone files that you alter.
• The DNS system is a lot more fragile than anyone can possibly tell you. You have to experience this for yourself. If and when you make a mistake in a zone file and don't fix it quickly enough and your AXFR transferes takes place then it can take up to a week (if not more) for the fix to propagate properly through the rest of the system.
• It's a conglomoration of IPs that is simply stuck together. We had to put the "hints" to the named_root in so many places it's not funny. Luckily most clients don't need to know these IPs - only DNS servers that performs the entire resolve process.
• GLUE records (Names + IPs of hosts that actually don't belong in the zone but is required to "make it work") are evil. They cause duplication of information that can theoretically be located elsewhere in the DNS system. They are however required. For example, say I would like to resolve www.kroon.co.za then the .co.za nameservers know the names of the kroon.co.za nameservers, but without their IP addresses this is pretty much useless as we would likely need these same nameservers in order to resolve the names.
• Make sure your network is correctly configured at an IP level before you start fiddling with DNS. Otherwise you will get very confused and wonder why names are not resolving when meanwhile you don't have a route to the namserver.
• The root and TLD nameservers themselves belong to domains. This can sound wierd, like using gcc 2.95.3 to compile gcc 4.0.0. If you don't believe that these nameservers are in domains, have a look in named.ca and you will that all 13 root servers are part of root-servers.net.

Right, so eventually we got the whole DNS system up and running. There was 5 of us - and 5 nameservers. So we each tackled one, and eventually everything worked. We got three top-level domains .eu, .af and .as, then we had a single secondary for all of them and a single root nameserver which knew something of these top-level nameservers. Each nameserver also got a name in the form of named_??.??. Then named_root ended up in .as and named_sec in .eu - for no particular reason.

We had no particular problems configuring these, we pretty much guessed our way through this. There are still a few problems. We couldn't figure out how to prevent recursive lookups on the nameserver. Further more, the primary top-level domain servers will serve as caching nameservers for the three big networks. We will need to allow recursive lookups only for those networks. Further more, AXFR transfers needs to be limited to named_sec.

And to quote Alan:
Even more interesting is
dig NS net.
dig NS com.
and see that these tld servers have NS records in their own domains...

And of course, the config files for each of our name servers:

Next week

We are not sure what we would like to get right next week, but we do know that we want some ntp. That shouldn't be too hard. From there I reckon we'll do some dhcp and dhrelay. That will probably take us well past lunch. Alan will probably have more ideas from there on.

So till next week...