Browse NETS topics: A B C D E F G H I J K L M N O P Q R S T U V W X Y Z	Search NETS:

DNS and Network Naming Procedures

• Network Names
• DNS Names
• Examples
• DNS zones (domains)

The sheer number of different roles which 'networks' play will invariably lead to situations where these rules cannot be applied or lead to silly conclusions. Engineers should use their best judgement in applying them. The rules incorporate the terms 'must' and 'should' in a similar manner to the definitions found in RFC 2119.

Network Names

• It may be used as a VLAN name, so it must be 32 characters or less.
• It may be used in a DNS name, so it should be all lower case.
• It should consist only of the characters a-z0-9 and dash '-'
• Point to point networks should consist of the two locations or entities which are being connected.

DNS Names

• Every IP address must have a unique DNS name with matching forward and reverse entries.
• The 'short' name used for CLI access must resolve to only a single address.
• The 'short' name used for CLI access and such should be a CNAME entry which points to the appropriate interface. In most cases, the loopback is the appropriate interface.
• The unique names for each interface should incorporate the short name of the device and the network name the interface is on separated by an underscore.
• Historical names which incorporate the third octet of the IP address may remain. mlr-n64.ucar.edu for example.
• The unique name may shorten the device or network name if doing so would reduce duplication.

Examples

The DNS entry for the loopback interface on mlra. One 'mlra' is dropped from the DNS entry because it would be redundant.

IP Address	DNS Name	Network Name
128.117.243.49	mlra_lo0	mlra-lo0

A point to point link between ML and CG.

IP Address	DNS Name	Network Name
128.117.243.225	mlra_ml-cg-net	ml-cg-net
128.117.243.226	cgra_ml-cg-net	ml-cg-net

The DNS entry for a standard client subnet

IP Address	DNS Name	Network Name
128.117.8.253	mlra_scdnet	scdnet

The historical DNS entry for a client subnet.

IP Address	DNS Name	Network Name
128.117.64.253	mlra-n64	ucarnet

Entries for the FRGP Level3 Router

IP Address	DNS Name	Network Name
192.43.217.81	l3-gw-1_nlra	nlra
192.43.217.113	l3-gw-1_nlrb	nlrb
192.43.217.134	l3-gw-1_frgp-level3-net	frgp-level3-net
192.43.217.137	l3-gw-1_level3-nlr-net	level3-nlr-net
192.43.217.141	l3-gw-1_lo0	l3-gw-1-lo0
192.43.217.145	l3-gw-1_level3-ucb-net	level3-ucb-net
192.43.217.150	l3-gw-1_level3-ucdhsc-net	level3-ucdhsc-net
192.43.217.153	l3-gw-1_level3-csm-net	level3-csm-net
192.43.217.158	l3-gw-1_level3-utah-net	level3-utah-net

DNS zones

Subject: Re: ATD DNS
From: Greg Woods <woods@ucar.edu>
To: Pete Siemsen
Cc: brandon@ucar.edu
Date: Tue, 26 Sep 2006 12:45:53 -0600

Only the administrators of the name server(s) that have authoritative data for a zone can make changes to that zone. What confuses the issue is that the forward and reverse zones are completely different. In most cases, we try to delegate the forward and reverse zones to the same servers, so we don't have this confusion. But there are a few cases such as the 81 subnet, the fully exposed subnets at each campus, the guest networks, etc. where the zone is shared by multiple groups. In those situations, it's not possible to avoid the case where the forward and reverse zone are managed by different people.

All I want is a working name for 128.117.81.240. Do you handle forward resolutions for some 81 addresses as "ucar.edu", and does ATD handle the others as "atd.ucar.edu"?

As an additional aside: the assignment of IP addresses is the responsibility of those who manage the reverse zone (SCD in the case of the 81 subnet and most other shared subnets (fully exposed, guest, etc.), but the forward entries must still be made by whoever administers the zone containing that name (atd.ucar.edu -> ATD/EOL).

To determine who manages a zone, issue an NS query like "host -t ns zone-name" (reverse zones have the horrible in-addr.arpa syntax). If you get a list of delegated name servers, then you know who you have to talk to for records in that zone. If you get something like "there is no NS record", or a blank response, then that subzone is not delegated and is managed by the parent zone.

Examples:

$ host -t ns 81.117.in-addr.arpa.
81.117.128.in-addr.arpa has no NS record

$ host -t ns 117.128.in-addr.arpa.
117.128.in-addr.arpa name server dns2.itd.umich.edu.
117.128.in-addr.arpa name server dns.ucar.edu.

$ host -t soa 117.128.in-addr.arpa.
117.128.in-addr.arpa SOA dns.ucar.edu. postmaster.ucar.edu. 20060926428800 14400 110 10

On the other hand:

$ host -t ns atd.ucar.edu.
atd.ucar.edu name server chandon.eol.ucar.edu.
atd.ucar.edu name server merlot.eol.ucar.edu.

$ host -t soa atd.ucar.edu.
atd.ucar.edu has SOA record chandon.eol.ucar.edu. newbery.ucar.edu. 200613155 10800 3600 604800 600

Sorry to go on at such length about this, but it is always confusing and there is clearly some confusion in this case. The bottom line is that the missing A record is within the atd.ucar.edu zone, so EOL staff must add it, I cannot.

--Greg