How do I resolve names in the NX VPN?

or: How do I setup DNS ?

• Configure your clients to direct their queries directly to a NX DNS. This is very easy, but DNS queries will be quite slow (they have to cross the VPN). Furthermore, if the name server fails, you will have to reconfigure your clients.
• Configure your name server to forward every DNS traffic to a NX DNS. This is a bit better, as your local server will cache replies, but if the remote server fails, you won't be able to resolve host names anymore.
• Configure your name server to forward DNS traffic only for NX domain queries. With BIND, add the following lines to named.conf :

zone "nx" { type forward; forwarders { NX-NAME-SERVER-IP; }; };

zone "168.192.in-addr.arpa" { type forward; forwarders { NX-NAME-SERVER-IP; }; };

zone "10.in-addr.arpa" { type forward; forwarders { NX-NAME-SERVER-IP; }; };

• Alternatively, you can setup your name server to cache the nx and reverse zones totally, but it's not very useful, because this will only cache NS and SOA records for SLD. For instance, when resolving platyn.orion.nx, your will skip the NS query for orion.nx but not the A query. This kind of setup is achieved with the following statements :

zone "nx" { type slave; file "db.nx"; masters { NX-NAME-SERVER-IP; }; };

zone "168.192.in-addr.arpa" { type slave; file "db.192.168"; masters { NX-NAME-SERVER-IP; }; };

zone "10.in-addr.arpa" { type slave; file "db.10"; masters { NX-NAME-SERVER-IP; }; };

• If you want to host your own SLD (for instance, foobar.nx), two steps are involved in the process :
• setup your name server : this needs configuration directives similar to the following :

zone "foobar.nx" { type master; file "/etc/bind/db.foobar.nx"; };

zone "69.168.192.in-addr.arpa" { type master; file "/etc/bind/db.192.168.69"; };

• request the DNS maintener to add stub zones for your SLD. You should inform him about your name servers IP addresses, and of course, the name of your SLD. Also, specify your reverse zone name servers.
• If you want to delegate zones, for instance, suppose you manage foobar.nx, and want another name server to host quux.foobar.nx subdomain, you will need to declare stub zones ; a stub zone is similar to a slave zone, but only NS and SOA records are fetched. Also, your name server should not have global forwarders directives. Sample stub zone :

zone "quux.foobar.nx" { type stub ; masters { IP-OF-MASTER-SERVER-FOR-QUUX-ZONE; }; };

Okay, I decided to host my own SLD (Second Level Domain), say foobar.nx ; what do I have to do?

$TTL 604800
@       IN      SOA     bigserv.foobar.nx jrandom.yahoo.com (
                        2000090403      ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         302400 )       ; Negative Cache TTL
                NS      bigserv
		NS	littleserv
		MX 20	mailserv
		MX 10	mailhub.quux.nx.
                A       192.168.69.4
bigserv         A       192.168.0.69
firewall	A       192.168.69.1
bigserv		A       192.168.69.2
littleserv      A       192.168.69.3
mailserv        A       192.168.69.4
;available      A       192.168.69.5
;available      A       192.168.69.6
;available      A       192.168.69.7
gamemachine     A       192.168.69.8
www             CNAME   mailserv
ftp             CNAME   bigserv
irc             CNAME   bigserv
dollywoops      CNAME   dollywoops.quux.nx.
www.panda       CNAME   www
$TTL 3600
dynamix         A       192.168.42.69
                A       192.168.42.80
dhcp            NS      dynamix

• TTL is the default Time-To-Live for zone records, in seconds. That means that when a remote DNS will fetch, say, bigserv.foobar.nx from your server, it will be allowed to keep it valid for 604800 seconds before having to ask again.
• The following block is the SOA record (Start Of Authority) ; it explains that bigserv.foobar.nx will be the primary master server for this zone, and that the zone is administratively managed by jrandom@yahoo.com (yes, you have to put a dot in the SOA record, and I don't know how you are supposed to enter a dotted mail address). Following numbers are :
  • Zone serial number. Traditionnally, YYYYMMDDSS, where YYYY is year (2000), MM month (01 thru 12), DD day (01 thru 31), and SS subserial number (if you make more than one change a day). You should keep consistent with this numbering, as it helps to remember when you did last changes for instance, and you MUST increment this number if you want your changes to propagate to slaves DNS (they compare their serial number to yours to check whether they should initiate a zone transfer or not).
  • Refresh delay, in seconds : how often should a slave name server automatically check for new versions of the zone? It's not necessary to set this too low, because anyway, when your master server reloads a modified zone, it sends NOTIFY messages to slave servers and they reload automatically.
  • Retry delay, in seconds : when a refresh fails, how long should a slave wait before asking the master again ?
  • Expire delay, in seconds : if a slave could not contact the master after this time, it considers that the zone is dead, and doesn't forward queries anymore. You can set it quite big.
• You must then specify one ore more NS records, specifying which name servers will host your zone.
• You can optionnally list one ore more MX records. These are Mail eXchangers. When someone wants to send mail to anybody@foobar.nx, it will look for an MX record under foobar.nx. You can specify priorities, in order to declare backup mail servers (in case of server downtime or network outage, you won't lose mail).
• Then come the famous A records, establishing the well-known mapping between host names an IP addresses.
• Notice that you can have more than one A record for the same name : this allow load balancing over multiple servers, and is almost required for multiple homed hosts - or more simply, hosts with more than one network interface.
• A peculiar record type is CNAME, which allow to define aliases. It is very useful to "map" hosts outside your zone ; for instance, suppose you access frequently dollywoops.quux.nx ; with a CNAME, you can map it inside your zone, and keep consistent even if its IP address changes (well, it works as long as dollywoops' maintener keeps her zone files up to date).
• You can specify sub-zones by writing a NS record pointing to their name server. You may also want to specify stub zone, but that's another story.

gator CNAME ali.gotham.nx

Last word : when a line doesn't start with a name, BIND considers you want to repeat the preceding name. If you want to refer to the zone itself, use the special name @.