Domain Name Service (DNS) provide access to a distributed database containing information about Internet hosts. Most commonly, DNS is used to translate between hostnames and IP addresses.
OIT provides several DNS servers for use by devices attached to the campus network.
OIT does not provide DNS service for devices attached to External Customer Networks. This document does not apply to such devices.
Most TCP/IP clients can use DHCP or BootP to learn the current list of appropriate DNS servers. We generally recommend that hosts that can be configured to learn this way be so configured. The DHCP and BootP services provided by OIT do include DNS servers in the information they provide.
Some TCP/IP clients cannot learn the current list of DNS servers via BootP or DHCP. In these cases, you must manually configure your TCP/IP client with a list of appropriate DNS servers. Here is a list of recommended DNS servers for everywhere on campus except ppnnet:
128.112.129.32
128.112.129.111
128.112.128.1
You may enter the list of servers in any order; this helps spread the load among the servers.
If you manually configure your device with this list of DNS servers, be sure to configure your device to use all three of the servers above, rather than just one or two.
If your client can be configured to "rotate" its DNS queries among the DNS servers, we recommend you configure it to do so. (Clients that learn their nameservers via DHCP or BootP typically do not provide a way to control this. Clients that are manually configured may provide a way to control this.) Rotating among all DNS servers provides better performance to your client (on average) when any one of the campus nameservers is unavailable.
There may be times when fewer than all three of these DNS servers are up. We periodically take down the servers (normally one at a time) for maintenance without any public announcement. We rely on the fact that every DNS client should be configured to use multiple DNS servers, and perform DNS caching.
Service from these DNS servers is limited to clients attached to Princeton University networks. (This includes clients of OIT Remote Access Services, Visitor IP Service, and Temporary Visitor Wireless Network Access (TVWNA).)
Because ppnnet is an isolated network, not attached to the rest of the campus network, clients attached to this network cannot communicate with the DNS servers that provide service to the rest of the campus network. Instead, these clients use another set of DNS servers attached to ppnnet.
Most TCP/IP clients can use DHCP or BootP to learn the current list of appropriate DNS servers. We generally recommend that hosts that can be configured to learn this way be so configured. The DHCP and BootP services provided by OIT do include DNS servers in the information they provide.
Some TCP/IP clients cannot learn the current list of DNS servers via BootP or DHCP. In these cases, you must manually configure your TCP/IP client with a list of appropriate DNS servers. Here is a list of recommended DNS servers for clients that are singly-homed on ppnnet:
128.112.97.36
128.112.97.37
128.112.97.38
You may enter the list of servers in any order; this helps spread the load among the servers.
If you manually configure your device with this list of DNS servers, be sure to configure your device to use all three of the servers above, rather than just one or two.
If your client can be configured to "rotate" its DNS queries among the DNS servers, we recommend you configure it to do so. (Clients that learn their nameservers via DHCP or BootP typically do not provide a way to control this. Clients that are manually configured may provide a way to control this.) Rotating among all DNS servers provides better performance to your client (on average) when any one of the campus nameservers is unavailable.
There may be times when fewer than all three of these DNS servers are up. We periodically take down the servers (normally one at a time) for maintenance without any public announcement. We rely on the fact that every DNS client should be configured to use multiple DNS servers, and perform DNS caching.
Service from these DNS servers is limited to clients attached to ppnnet.
In support of the isolated nature of ppnnet, the ppnnet DNS servers provide a limited view of DNS. In particular, when queried for IP addresses, these servers try to respond with only ppnnet IP addresses. When queried for hostnames corresponding to IP addresses, they try to respond only with hostnames corresponding to ppnnet IP addresses. When queried about other names or IP addresses, they try to respond that the name (or IP address) does not exist. This limited view is provided on a "best effort" basis; we do not guarantee that the servers will always limit their responses to ppnnet names and IP addresses; it is possible that the servers may respond to the client with other information as well.
If your device is multihomed on ppnnet and another campus subnet, you should not configure your device to use these DNS servers. Instead, configure your device to use the set of DNS servers recommended earlier "For Most of Campus." (And based upon that, if your client is multihomed on ppnnet and another campus subnet, you will need to configure your client's ppnnet interface manually rather than configuring that interface to use DHCP or BootP; either of the latter protocols could cause your client to use the ppnnet-specific DNS servers.)
Additionally, shufflenet IP addresses are not inserted into our DNS data. As a result, these IP addresses cannot be looked up in DNS.
The default DNS domain of many hosts is simply "Princeton.EDU". Hosts that are connected to the network as part of a Dormnet subscription (i.e. they normally reside in a student's room in an Eating Club or dormitory) have a default DNS domain of "student.Princeton.EDU". Some departments also have a different DNS domain name; e.g. "basketweaving.Princeton.EDU".
Most TCP/IP clients can use DHCP or BootP to learn your host's default DNS domain. The DHCP and BootP services provided by OIT do include a default DNS domain in the information they provide. If your TCP/IP client cannot learn a default DNS domain via DHCP or BootP, you may need to manually configure your host with its default DNS domain.
Modern operating systems cache the information they receive from DNS servers. This vastly reduces the volume of DNS queries they must send to DNS servers, and improves performance for both the client and the DNS server.
Most systems are configured to perform DNS caching by default. If your operating system is not configured to do this by default, you should configure it to do so.
Ideally, a client that performs DNS caching will cache DNS information using the DNS TTL (time-to-live) information provided by the DNS server. If your DNS caching client cannot make use of the DNS TTL information, but instead applies its own time-to-live to the DNS information it caches, we recommend setting the positive TTL to 3600 seconds (1 hour) and the negative TTL to 300 seconds (5 minutes). (The negative TTL is used to cache DNS responses that say "the information you requested does not exist in DNS.")
If your operating system does not perform DNS caching, it will experience degraded performance compared to those that perform DNS caching. It may also experience significant problems when any one of the campus nameservers is unavailable.
In some cases, failing to perform DNS caching may also allow your system to place excessive load on the campus DNS servers. As this can degrade DNS service to the rest of campus, it may result in OIT instructing you to fix or disconnect your device. In some extreme cases, it may result in OIT blocking your machine from using the campus DNS servers (or the campus network) until you fix the problem.
OIT does not accept DNS Dynamic Update requests from clients; that is, it will not modify the contents of Princeton's DNS data in response to requests from clients. The content of Princeton's DNS data comes from the Princeton University Host Database.
DNS clients should not send Dynamic Update requests to OIT DNS servers.
By default, many operating systems do not send DNS Dynamic Update requests. Additionally, some operating systems that might otherwise default to sending DNS Dynamic Update requests will not do so if they also happen to rely on OIT DHCP Service. That's because OIT DHCP Service sends an DHCP option to the DHCP client telling it to not send DNS Dynamic Update requests.
If your DNS client sends DNS Dynamic Update requests to OIT DNS servers (e.g. it does not fall into one of the cases above), OIT may ask you to reconfigure your client to stop sending these requests to OIT DNS servers.