DNS: Difference between revisions
Jump to navigation
Jump to search
m (clarification) |
(→CSC DNS: gone) |
||
| Line 8: | Line 8: | ||
== CSC DNS == |
== CSC DNS == |
||
DNS service was terminated because it didn't work well (some problem with additional work needing to be done for some nameservers to accept delegating authority to us), nobody used it and it caused a potential security problem (which could have been fixed, but removing it was easier for the preceding reasons). |
|||
[http://www.isc.org/software/bind BIND9] is running on [[Machine_List#caffeine|caffeine]] (master) and [[Machine_List#taurine|taurine]] (slave). We do not currently have ns1.csclub.uwaterloo.ca or similar hostnames, so refer to them by either these names or their IP addresses (129.97.134.17 and 129.97.134.34, respectively). |
|||
See an old revision of this article for more detail. |
|||
At present, we do not host any subzones of uwaterloo.ca (IST's nameservers continue to be used for csclub.uwaterloo.ca etc.). If we wanted to do this, we would have to ask IST. |
|||
As with Apache vhosts, zone changes must be made by [[Systems Committee|syscom]]. The following instructions assume that caffeine will be the primary (master) DNS server. If this is not the case, adjust the configuration directives as appropriate. |
|||
To create a new zone, an entry should be added in <tt>/etc/bind/named.conf.local</tt> on caffeine: |
|||
// Calum's site (ctdalek) |
|||
zone "ctdalek.net" { |
|||
type master; |
|||
file "/etc/bind/zones/ctdalek.net"; |
|||
}; |
|||
A brief comment including the username of the member to whom the zone belongs would be appreciated. Additional configuration directives could be added, but sensible defaults are used. If the settings for zone transfers are changed, taurine must be among the allowed hosts so that it can mirror caffeine correctly. Create a corresponding entry in taurine's <tt>named.conf.local</tt> file. |
|||
// Calum's site (ctdalek) |
|||
zone "ctdalek.net" { |
|||
type slave; |
|||
file "/etc/bind/zones/ctdalek.net"; |
|||
masters { 129.97.134.17; }; |
|||
}; |
|||
Make sure that caffeine's IP is specified as the master. Finally, create the actual zone on caffeine (e.g. <tt>/etc/bind/zones/ctdalek.net</tt>). For example: |
|||
$TTL 1h |
|||
@ IN SOA caffeine.csclub.uwaterloo.ca. ctdalek.csclub.uwaterloo.ca. ( |
|||
1 ; Serial |
|||
24h ; Refresh |
|||
30m ; Retry |
|||
30d ; Expire |
|||
1h ; Minimum |
|||
) |
|||
@ IN NS caffeine.csclub.uwaterloo.ca. |
|||
@ IN NS taurine.csclub.uwaterloo.ca. |
|||
@ IN A 129.97.134.17 |
|||
@ IN MX 10 aspmx.l.google.com. |
|||
mail IN CNAME ghs.google.com. |
|||
A few things to note here. caffeine should be specified as the primary nameserver in the SOA record, and the member's csclub email address (with @ replaced by .) should be used as the contact. The serial can be any unsigned 32-bit integer, but it must increase when the zone is updated. The two most common conventions are to simply count upwards, or to use the current date (in yyyymmdd format). We can have a long refresh time because caffeine will notify taurine when the zone has changed (long before the refresh timeout). Finally, the nameservers should include caffeine and taurine at a minimum. |
|||
To have BIND9 reload all configuration, run <tt>sudo rndc reload</tt> on caffeine (and on taurine, if you've modified configuration there). '''You should do this after adding a new zone on any nameserver (including slaves).''' |
|||
If you've modified a zone, run <tt>sudo rndc reload ctdalek.net</tt> (or whatever the zone is). This does not shutdown the DNS server, so this helps minimize service interruptions. Finally, reloading the zone on caffeine causes it to automatically notify taurine to initiate a zone transfer. As a result, modifying a zone on caffeine does not require any action to be taken on taurine. |
|||
== Miscellaneous == |
== Miscellaneous == |
||
Revision as of 13:22, 4 May 2011
IST DNS
The University of Waterloo's DNS is managed through Maintain.
People who have access to Maintain:
- mspang
CSC DNS
DNS service was terminated because it didn't work well (some problem with additional work needing to be done for some nameservers to accept delegating authority to us), nobody used it and it caused a potential security problem (which could have been fixed, but removing it was easier for the preceding reasons).
See an old revision of this article for more detail.
Miscellaneous
LOC Records
If we really cared, we might add a LOC record for csclub.uwaterloo.ca.
SSHFP
We could look into SSHFP records. Apparently OpenSSH supports these. (Discussion moved to Talk:DNS.)