As I mentioned in the last entry, we have an internal subnet for laptops and other generic user machines. For various reasons, we require machines on this subnet to be registered so that we can identify who is (theoretically) responsible for them. One of the ways that people can do this is with a 'plug in and go' registration portal; you plug in, try to go somewhere, and you wind up on a simple registration web page instead.

Behind the scenes, it works like this:

• our DHCP server gives unregistered machines IP addresses from a special subnet. Our internal firewall doesn't allow these IP addresses access to the outside world.

• as part of the DHCP information, the unregistered machines are pointed at a special DNS server that is essentially a fake DNS server. The DNS server simply has a zone file for ., the root zone, with only two entries; one entry for our registration portal's public name that points to one internal IP, and a wildcard ('*') A record that claims everything else has another internal IP address.

  (In the terms of the last entry, these IP addresses are Inside-2 and Inside-1 respectively.)

• the two IP addresses that the DNS server tells people about run some web servers, including the registration CGI.

• the registration CGI gets and validates the user's credentials, picks the Ethernet address of their machine out of the web server's ARP cache, and pokes the DHCP server to get the new machine registered (using a method beyond the scope of this entry).

  (In practice, not having to ask users for their machine's Ethernet address is a big win for all parties.)

• once registered, users have to renew their DHCP lease (which will cause their machine to get an IP address that can talk to the network, along with a gateway and our proper DNS servers) and flush any cached DNS information they picked up from our fake DNS server. We tell users that the easiest way to do this is to reboot their machine.

In terms of servers, the special fake DNS server and all of the web stuff run on one machine, while the DHCP stuff runs on another (and the firewall is a third machine). This is mostly a historical accident, in that we already had the DHCP server running in production before we started building this registration portal system.

Redirecting people's connections with DNS instead of with firewall magic is much simpler but has some side effects, especially since the machine that responds to the wildcard A record's IP address does have an ssh server. We should probably do some work to make the wildcard record's IP address block access to at least the ssh server.