NetDB and DNS at Stanford
NetDB developed in late 1980s
In 90s became java-based web application
Don't ask to make it fancier!
It is open source, but relies on Oracle, so not used by many other organizations
Source for DNS, source for DHCP, allows university to keep track of stuff
Access within NetDB is defined by Group and Record Type
Administrator field doesn't not grant any access to modify a record It is used by other systems (such as SSL certification group). But in NetDB it's just data field.
If you can't modify a record, mostly likely don't have correct Group or Record Type access
NetDB is source for all Stanford DNS info
.stanford.edu is appended by default
There are two special domains:
- ".nodomain" if you want to use a name that never gets into DNS
- ".sunet" if you want to use a name that exists only on campus, but not sent outside (like a printer)
DNS
DNS is updated every half hour from NetDB, and update takes 5-20 mins. Done at 5 and 35 past the hour
NetDB name field creates the A record in DNS
NetDB Alias field creates the CNAME ("canonical", which is less than "Authoritative")
MX field is used to redirect mail using the MX (Mail Alias)
netdb-dev.stanford.edu (past weekend's data)
- refreshed every week
"Advanced" node can have multiple Names
DHCP
Stanford uses two centrailized DHCP servers (Dusk & Dawn) to provide campus-wide DHCP
If roaming is clicked on "yes", then retrieves IP from a dynamic range
If you need one IP number to be handed out every time, enter that IP number
Data fields in NetDB
If department is not listed, or has changed names, submit a ticket. No automated update.
If location is not listed, or have changed names, please submit a ticket. There is "Cyberspace" or "Off Campus" locations.
Make and Model: don't use unknown when make doesn't exist. Submit a help ticket.
Operating System: you can have multiple OS, and users can create new ones, but check if there's one that already exists.
Data fields of NetDB that aren't just text
Node Type: most users can only make regular nodes, templates, or virtual nodes.
Administrator: this can be either one or more SUNet IDs, or preferbly, an Admin Team. NetDB treats this as plain text, but other departments and systems make use of the Administrator field. Remember doesn't grant access!
User: must be SUNet ID
Group Field
Group grants most power in NetDB
user has to share a Group with a record in order to be able to modify it. Every user is a member of the Group "Stanford".
State Field
Relatively new field. Anything other than "Good" may have a restriction.
"Dubious" is added by ISO for compliance.
"Unknown" is usually an incomplete self-reg record. It's best to just delete it and force the host to go through SNSR again.
"Stale" is used to clean up old nodes. Stale node will be deleted automatically after 90 days.
Stale gets triggered by (see documentation)
- networking.stanford.edu has documentation on Stale Nodes
- https://web.stanford.edu/group/networking/dist/sunet.reports/stale.txt
"Unknown", "Dubious", and "Vile" will not be listed in DHCP models.
Custom Fields
There are four custom fields in the form of Label:Value
You can use them any way you want
Command-Line NetDB & RMI
CLI version: netdb-cli.stanford.edu
Clone feature: with some preparation, you can create hundred of records in minutes.
If you need more capabilities, create your own CLI using the Java RMI! see netdb-rmi.stanford.edu
Mailing list for NetDB RMI:
netdb-rmi-users@lists.stanford.edu
(developers do review submissions)
StanfordWhat:
https://web.stanford.edu/group/networking/cgi-bin/stanford-what/lookup.cgi
