A network database gives particular meaning to the following attributes: .TF dnsdomainxx
auth name or address of authentication server
bootf name of the file to send to a device on request when booting
dns name or address of DNS resolver (see also the ns attribute below)
dnsdomain domain in which the local host lives (used to qualify unqualified names)
dom Internet domain name (host or DNS zone)
ether Ethernet address in the form accepted by ether (2)
fs name or address of file server
il IL service name
infernosite empty-valued attribute that labels default site parameters
ip Internet address
ipgw name or address of Internet gateway
ipmask Internet network mask
ipnet network or subnetwork name
ipv4proto IPv4 protocol number (see also protocol )
mx mail exchanger
ns name of a DNS name server for an associated dom
port port number for a service
protocol protocol name
soa start of area (value is empty if locally authoritative, or ` delegated ' if another server is authoritative)
sys system name (short local name for a host)
tcp TCP service name
udp UDP service name
Internet addresses and masks can be written in any form accepted by Ip (2). Network applications might use other attributes of their own, which they document on their own pages.
Cs (8) interprets a host name of the form $ server as referring to the set of names and addresses that are values of the attribute server in the network data base. Attributes in general use include some of those above, and the following: .TF FILESERVER
FILESERVER older name for file server fs file server
pop3 mail reading service using the POP3 protocol
PROXY firewall proxy for ftpfs (4)
SIGNER Inferno authentication server running logind (8) and/or signer (8)
smtp mail delivery gateway using the SMTP protocol
Other such symbolic server names are mentioned in the manual pages for associated applications.
Dns (8) interprets dns and dnsdomain values in any infernosite entry, and dom , ip , and ns values more generally. When resolving a domain name, dns looks first in this data base to see if there is a dom entry for the name, and if so, whether there is either an associated ns attribute giving a name server to ask, or an ip attribute giving the name's IP address. Failing that, it works up the name hierarchy looking for name servers to ask. Failing that, it looks for a dnsdomain entry with dns attributes listing other resolvers to ask. Bootstrap data is commonly stored in /lib/ndb/dns ; by default it defines the root name servers:
.EX dom= # root ns=a.root-servers.net ns=b.root-servers.net \f1... dom=a.root-servers.net ip=198.41.0.4 dom=b.root-servers.net ip=128.9.0.107 \f1...