DNS & DHCP

Quick Information
Authoritative Name Servers ns1.oregonstate.edu, ns2.oregonstate.edu
Caching Name Servers for OSU 128.193.15.12, 128.193.15.13
Policies Domain Name Policy
DNS/DHCP Registration System Maintain
DNS Information List of OSU Domains

What is DNS?

DNS stands for "domain name service". In essence, it is a directory of names that point to services on the local network or the Internet. Computers communicate with each other over the Internet via IP addresses (e.g. 128.193.4.20). DNS provides human-friendly names for these IP addresses. For example: the DNS name www.oregonstate.edu points to the IP address 128.193.4.112.

What is DHCP?

The Dynamic Host Configuration Protocol (DHCP) is an Internet protocol for automating the configuration of computers on a network. DHCP can be used to automatically assign IP addresses, to deliver TCP/IP stack configuration parameters such as the subnet mask and default router, and to provide other configuration information such as the addresses for DNS servers.

Registering Your Computer on the OSU Network

Most OSU network registration is done via Maintain, an open source application developed at OSU. For general help with Maintain, network registration, or activating your ONID account, please contact the OSU Computer Helpdesk.

  • Maintain Replacement Project
    Maintain, our existing network registration system is scheduled to be replaced with Cyder. See this page for additional details and updates on this project.
  • Departmental Computer Administrators (DCAs)
    DCAs have access to Maintain to register network devices for use on departmental networks. If you are a DCA and need access to Maintain, please contact Network Engineering (net@oregonstate.edu).
  • Employees
    Employees needing a device registered should contact their DCA. Employees may also register their own wireless devices by logging into Maintain with their ONID account.
  • Students Using Wireless
    You may register your own wireless devices by logging into Maintain with your ONID account. For help, see Helpdocs: Wireless Registration.
  • Students in the Residence Halls
    Directions for registering your computer on the Residence Hall Network (ResNet) are here: Helpdocs:ResNet.

Recursive Requests

As of August 3rd, 2013 Oregon State University's authoritative name servers ns1 and ns2 no longer answer recursive requests from outside of our network. This change was made to prevent our name servers from being used in DDoS attacks against other Internet hosts.

Cyder

Maintain Replacement

On March 7th, 2015, Information Services will replace Maintain with Cyder as our central IP address management (IPAM) solution. This new software will bring a revamped web interface, and more robust and extendable back-end design. This will allow us to deploy new functionality like IPv6 allocation/support, a RESTful API, DNS views, and more.

The process to migrate and verify data from Maintain will begin at 10am Saturday, 3/7. We anticipate this process taking a minimum of 4 hours, but possibly as long as 8 hours. During this time, the following services will be unavailable:

  • Access to Maintain or Cyder web interface to make DNS/DHCP changes.
  • Wireless mac address self-registration (wireless access and authentication will not be impacted)

If you need to make emergency DNS/DHCP changes during this time, please email us at ServerSupport@oregonstate.edu or call 7-4710.

How to Access

Production site (not yet available): cyder.oregonstate.edu

Test/development site: cyder.nws.oregonstate.edu

Wireless Registration Changes

Maintain currently provides a wireless self-registration facility for OSU_Access. This will be updated with a new site at selfreg.nws.oregonstate.edu in concert with the migration to Cyder. Users will be automatically directed to the appropriate self-registration page after deployment.

Documenation

API

For those with direct access to Maintain's MySQL database, you will need to transition your systems/applications/scripts to use Cyder's API. If you have not been notified about this previously, details are available at the links noted below. Access to Maintain's database will NOT be removed immediately after the 3/7 deployment. An additional notice will be sent when this database is finally removed and access revoked. Please note that the Maintain database will cease to be updated after Cyder is deployed.

For detailed information about the API, see:

Cyder User Guide

 

Introduction

Cyder is OSU's IP address and DNS management system. This provides a web interface and RESTful API for DCAs to manage their network allocations, assets, and names. Cyder also is the basis of network allocation and assignment documentation for our network engineers.

Transitioning from Maintain

Hosts in Maintain are now Systems in Cyder. A System can have one or more Interfaces. A System is where informational data resides, like department, other_id, etc. IP/DHCP information is tied to the Interface. Our data migration process from Maintain creates a System and a single corresponding Interface. If you have a device/system that has multiple network interfaces and subsequently had multiple host entries in Maintain, these can be combined into a single System with two Interfaces in Cyder. We do not have a merge function yet, but it is planned.

Maintain's method of delegating permissions to departments is accomplished with groupings called Zones. In Cyder, a Zone is now called a Container. As a part of the migration process, Containers will have the same name as their zone counterpart but without the 'zone.' prefix (Note: This change has not happened yet, but will before or on the deployment day). The permissions model, at least initially, will mimic that of Maintain with one exception: Any user can see all objects within Cyder (even those not in their Container), just not edit them. Select the global Container to see everything.

Introduction to Cyder's structure and naming conventions

This software provides a thin layer of abstraction between what is generated in a DHCP or DNS server configuration file. For DHCP, Cyder extracts information from objects called Systems and Interfaces. Systems are devices that exist on our network. The System object in Cyder retains inventory information and Interfaces. A System can have one or more Interfaces. The Interface of a System determine the IP address and name assigned to it. This allows a device such as a laptop to have both its wired and wireless interfaces tracked as a single entity, a System.

Interfaces drive DNS and DHCP configuration for Systems. There are two types of Interfaces: Static and Dynamic. As their names imply, a Static Interface defines a static IP reservation. Dynamic Interfaces allow a device to obtain an IP in the specified range. A System name is merely for reference, and the Interface label is what determines the hostname generated. We do not support Dynamic DNS, and as such, Cyder will only auto-generate A and PTR records for dynamic Ranges of the format 127-0-0-1.range.example.com and 1.0.0.127.in-addr.arpa respectively. The domain suffix used to auto-generate A records for dynamic Ranges is configured by network engineers.

Subnets are now referred to as Networks.  In addition to referring to a maskable range of IP space and a corresponding VLAN, Networks also have a Site and a VRF.  A VRF, in the simplest of terms, is a collection of related networks.  A Site refers to a building router, and not necessarily a physical location.  Because these are new concepts, all Networks migrated from Maintain will be a part of the 'Legacy' VRF and the 'Campus' Site.  Note: VRF is synonymous with the term Security Domain.

DHCP options sent to clients are derived from Workgroup and Network options. An Interface must belong to a Workgroup – if none is selected, the Workgroup named 'Default' will be used. Options can also be set at the Network level. Workgroup options override those of the Interface's Network. Network options override global options (not displayed within Cyder).

Most common DNS records can be created/managed with Cyder. A, AAAA, PTR, CNAME, SRV, TXT, MX, etc can all be created ad-hoc and not be tied to any specific System or Interface. If there is an RR type that is not available via the Cyder web interface, please submit a feature request and we will work to add it (requests for the DNAME RR type will be ignored, we will never support these).

DNS Views

Cyder supports two DNS views (also referred to as split-brain, split-horizon, and merely split-DNS). For most DNS objects, you will be given the option of exposing them to either the public or private view. If a service requires a different DNS query response depending on the network of the client making the request, make two objects – one with only the private view checked, and one with the public view checked. The views are defined as such:

Public: All queries from IP addreses not in the Private view will receive records that have this view checked.

Private: Queries from 128.193.0.0/16 and 10.0.0.0/8 will receive records checked as private.

When an object is set to both public and private views, the query response for that record will be the same from any client source IP address. When none are selected, the object is disabled and will not be included in any DNS zone files.

 

How to navigate the web interface

Table Filter

Cyder has many data tables on various pages. Each table can be filtered in-place using the Filter text box at the top of each table. This should not be confused with the Global Search text box at the upper-right of all pages. This filter can be a simple text filter or use RegEx as well.

To see additional details and related objects to an entry in a table, click on the magnifying glass with a lowercase 'i' inside it. This is located in the left-most column of all tables. Similarly, on the right-hand side of all tables will be an Actions column. If your account and/or Container have the necessary permissions to edit or delete an object, a clipboard and waste bin icon will appear here. An object can be deleted by clicking on the waste bin icon – you will be prompted to confirm your action.

Clicking the clipboard icon will expand an object edit form between the table name and the table itself. The page will not reload/redirect to a new page for editing. Your browser will automatically scroll to the top of the page to show the form. When editing any object, you must click on the Update button at the bottom of the form to commit changes. This will also make the edit form disappear.

Cyder Main page

The following image shows what you will see after logging in to Cyder.

Cyder Landing Page

1. Sidebar Menu: See Sidebar Menu section for details on menu structure

2. Home and log-out buttons, respectively

3. User: The currently logged-in username (hopefully yours!).

4. Container permission level: The permission the currently logged in user account has on the selected container (5). Permission levels are defined in the Account Permissions section.

5. Current Container: The Container selected in this dropdown acts like a filter on most of the various data tables displayed within Cyder's interface. This selection does not affect some listings, like the global search results. To view objects outside of your assigned container(s), select 'global' from the list to have all objects appear in views/tables. Selecting a Container from the list automatically causes the current page to reload with data relevant to the newly selected Container.

6. Container detail (magnifying glass): Loads the currently selected Container's (5) detail view.

7. Click the "Set as default container?" text to set the currently selected container (5) as the container to be selected by default when you log in.

8. Global search: Search usage covered in greater detail in Search section.

 

Sidebar Menu Structure Details

The sidebar menu is the primary method for navigating through the various objects Cyder keeps track of. A brief description of each menu item is listed below, with links to additional details. Most users will only see three top-level menus on the sidebar: Core, DNS, and DHCP. Clicking on a top-level menu name will reveal the menu's objects/categories. An additional Admin menu is available to users with the cyder- and superadmin account levels.

Core

- Container: Provides a list of all Containers. This list is not affected by the Container selected in the dropdown of the main page.

- Interface: Also referred to as the 'Combined Interface View,' this will provide a list of all interfaces static and dynamic in the currently selected container. This listing is not available when the global pseudo-container is selected.

- System: Provides a list of all Systems within the currently selected Container.

DNS

- DNS Statistics: A list of DNS record counts for the current Container.

- Address Record, CNAME, NS, MX, PTR, SOA, SSHFP, TXT, SRV: Provides a list of the named record type in the currently selected Container.

- Domain: A list of all domains, forward and reverse, allowed to be used within the context of the currently selected Container.

DHCP

- Dynamic, Static Interface: Provides a list of all dynamic or static Interfaces within currently selected Container.

- Network: A list of Networks (subnet in ISC-DHCPd parlance) allowed to be used within the context of the currently selected Container. Networks are further broken down in to Ranges and the entirety of a Network may not actually be allocated to your Container for use.

- Range: A list of IP Ranges (pools) that that can be used by Interfaces within the context of the currently selected Container.

- Sites: A list of logical locations, referring to typically to different campuses/physical locations, but not always. All objects migrated from Maintain will have the site 'Campus.'

- VLAN: A list of all VLANs used by Networks in the currently selected Container.

- VRF: A list of VRFs (Security Domains) available.

- Workgroups: A list of Workgroups (groups) available for use in the currently selected Container.

 

Common Operations

Registering a device on the OSU network

Assigning a device an IP address and name on the OSU network requires at a minimum, a System and an Interface. When a System is created, you must create at least one Interface at the same time. Creating a new System will automatically provide you with the form to create the first Interface. To begin, make sure the Container selected at the top of the page is one you wish to assign this System/Interface to. Do not use 'global.'

Expand the Core sidebar menu, and then select System. This will load a list of Systems that exist in the currently selected Container. At the top of the table, click on the Create System button. When presented with a Create a System form, enter in a descriptive name for this device. This name is not used outside of Cyder for DNS. Then select the Interface type (static or dynamic) and the appropriate Interface creation form will expand below.

For static Interfaces:

The most important, and required fields are the hostname, MAC address, Domain, and IP address. The hostname and Domain are used to create an A-record for this Interface. A corresponding PTR record will be created given the IP address specified. The MAC address does not need to be supplied if DHCP will not be used to configure this Interface on the device (i.e. hard-coding the address on the device).

To ease selection of an IP address, you may use the VRF, Site, and Range filters selections. Selecting a VRF will then limit the amount of Sites selectable to those wish are assigned this VRF. Select a Site to reduce the available Ranges to choose from. Initially only the Legacy and Campus VRF/Site combination will be available, and automatically selected. Now select the Range from which the IP address should be assigned. Check the 'Select available IP' box to have the next free IP address auto-filled in to the IP address field.

The automatically generated A and PTR records for this Interface can be disabled by un-checking the Enable DNS box. The DNS view for these records can also be changed from this form as well. Un-checking both the public and private views will have the same effect as un-checking Enable DNS.

For dynamic Interfaces:

Dynamic Interfaces are very simple: Only a MAC address and range are required. Just like the static Interface form, the VRF and Site fields are only to help filter the Range selections available. Unlike the static Interface form, the Range is required.

DNS cannot be disabled for dynamic Interfaces, but DHCP can. Generally DHCP should only be disabled if the MAC address is not yet known but a reservation in the Range is needed.

 

Creating an Address record (A and AAAA)

Address records are one of the most common and basic types of DNS records. They map a name to an IP address. To create one in Cyder, ensure the correct Container is selected at the top of the page and expand the DNS sidebar menu. Then select Address Record. This will bring you to a page that lists all Address records (A and AAAA) in the currently selected Container. From this page, click on the “Create address record” button at the top right – the creation form will appear above the table of Address records.

Label, Domain, and IP address are the most important, and required fields on this form. For details on all fields, see the the Address Record section of “Edit Form fields, defined” later in this document.

The Label field will be added to the selected Domain to create the full name used in the Address record. For example, if you enter

db-secondary

as a Label and then select

tss.oregonstate.edu

as the Domain, the resulting name used for this Address record is

db-secondary.tss.oregonstate.edu

An IP is required to complete the form, enter one into the IP address field. This can either be an IPv4 or IPv6 address – but make sure the IP address type is selected properly (it defaults to IPv4). The VRF, Site, and Range fields are available to help you select a free IP if needed. If you're creating an Address record for a computer that doesn't already have a System and Interface, it is recommended that you create a System and associated Static Interface rather than a bare Address record. Creating a Static Interface makes an Address record and PTR record pair, and makes management and tracking of related records easier.

Address records have some restrictions:

- Cannot have the exact same in two different Containers (round-robins cannot span multiple Containers)

 

Creating a CNAME record

CNAME records are used to alias another existing name. CNAMEs are especially useful if you're trying to provide your own name to a system that already has one – and you do not control the IP address of the target host. A common use for CNAMEs is for ease of management: If you host many websites from a single web server, it is possible to create multiple CNAMEs that all have the same target – an Address record for the web server. If the IP of that web server ever needs to change, only the server's Address record would need to be updated, not every CNAME that points to it. This is in contrast to using multiple different Address records that all point to the same IP.

To create one in Cyder, ensure the correct Container is selected at the top of the page and expand the DNS sidebar menu. Then select CNAME. This will bring you to a page that lists all CNAME records in the currently selected Container. From this page, click on the “Create CNAME” button at the top right – the creation form will appear above the table of CNAME records.

Label, Domain, and Target are the most important, and required fields on this form. For details on all fields, see the the CNAME section of “Edit Forms explained” later in this document.

The Label field will be added to the selected Domain to create the full name used in the CNAME. For example, if you enter www as a Label and then select geo.oregonstate.edu as the Domain, the resulting name used for this CNAME is www.geo.oregonstate.edu.

CNAME records have some significant restrictions:

- No other type of record can share the same name as a CNAME. As such, CNAMEs cannot exist in the root of a DNS zone (e.g. oregonstate.edu cannot be a CNAME as this does not allow the creation of necessary SOA and NS records in the root. The same applies if you have a department sub-domain like nws.oregonstate.edu that is used for a web site and also used for e-mail (have an MX record for nws.oregonstate.edu). nws.oregonstate.edu can be an Address record, but not a CNAME, as the CNAME and MX cannot co-exist.

- Cannot have the exact same in two different Containers (round-robins cannot span multiple Containers)

 

Other DNS Tasks

Creating an MX record

MX records, or “Mail eXchanger” records are used to help other mail servers determine who to forward mail on to. For example: When a mail server wishes to determine where to forward on mail for a message sent to Some.User@oregonstate.edu, the server's mail software will look up the MX record for oregonstate.edu. The same goes for sub-domains like science.oregonstate.edu, engr.oregonstate.edu, etc. The oregonstate.edu MX record does not supersede an existing MX record on a sub-domain of oregonstate.edu.

When creating an MX record, the domain, server and priority are the most important, and required fields to be filled. For details on all fields, see the the MX Record section of “Edit Forms explained” later in this document.

The label field is not required and typically will not be used – as most MX records are for an existing domain, and not an individual System. Make sure to select the appropriate domain, then enter the server address in the server field. The last piece of information needed is the priority. This is only used if there will be multiple MX records for a particular name. This allows the creation of a backup mail server or servers. Priority is used by clients to determine which MX record to use first. If only one MX record is going to be created, the priority of 0,1, 5, 10, etc can be used and is mostly irrelevant.

MX record restrictions:

- Multiple MX records can be created for the same name/domain, but they must have different priorities and server fields entered.

- Cannot span across multiple Containers. All MX records for a particular name/domain must reside in the same Container.

- Cannot co-exist with a CNAME of the same name (server address, however, can be a CNAME).

 

Creating a PTR record

PTR records, also known as 'pointers' or 'reverse pointers,' are used to create a DNS entry that allows others to determine a hostname given an IP address. While Cyder will ask for an IP address, internally it will convert this to the appropriate entry in the reverse zone (in-addr.arpa or ip6.arpa). Most users will NOT need to make PTRs for any reason. In most cases PTRs are used by our network engineers to easily map the many interfaces of routers/switches and their IP addresses back to a single name. If you don't know what this is, don't use it!

As with other forms throughout Cyder, the VRF/Site/Range selection is available. This isn't terribly useful for PTR creation, but is available if selection of a free IP in a certain Range is needed.

Multiple PTRs for the same IP address cannot be created. Keep in mind the creation of an Interface generates the appropriate PTR.

Round-Robin DNS

A Round-Robin is a simplistic way of doing load balancing or providing redundancy. In DNS terms, a Round-Robin is a set of records with the same name, but different targets. Each time a client requests the name of the Round-Robin, a list of targets are returned. The order of the targets returned is changed per request from the client. Since most clients will attempt to reach out to the first target in the list, this provides some level of connection distribution across all targets returned.

Round-Robins are made with sets of A-records or CNAMEs that share the same label and domain. Here is a real-world example of this at OSU. All incoming mail for oregonstate.edu is sent to relay.oregonstate.edu. Relay.oregonstate.edu is not a single server, nor is it a single A-record. To distribute incoming mail load and allow easy addition/removal of mail servers during maintenance OSU generally has three A-records for relay.oregonstate.edu – each having a different target IP address. To see this in action, use a DNS lookup tool of your choice (nslookup, host, dig, etc.) and query for relay.oregonstate.edu. If queried multiple times, the order of the results changes with each query.

All records used to make the Round-Robin must be kept together in the same container. PTRs and certain other records are not allowed to be in a Round-Robin. In general, only A-records and CNAMEs are used.

 

Edit Form fields, defined

System

- Name: A short name for the system. Does not affect DNS. DNS records are generated based off the Hostname set on the Interface or the range an Interface is in.

Static Interface

- Description: A brief description of the interface (e.g. 'Management Interface')

- Hostname: The DNS name used for this Interface's A Record.

- Domain: The DNS name suffix used for this Interface's A Record.

- MAC Address: The hardware ethernet address of this Interface. Can be blank or invalid if DHCP is disabled for this Interface (see below). Can include colons or dashes, but they will be stripped upon saving. The following fields are used to select an appropriate IP address and are not actually values stored with a Static Interface object. Begin in order from VRF to Range to locate an IP. These selections are to ease the location of a free IP address, and are not required.

- VRF: Filter Ranges by VRF.

- Site: Filter Ranges by Site.

- Range: Ranges available for use in this Container, optionally filtered by the previous two selections.

- IP Address Type: Identifies this as a IPv4 or IPv6 Interface. If a System requires both IPv4 and IPv6, two interfaces must be created for each type.

- Select free IPv4 IP?: Allow Cyder to automatically select the next free available IP in the selected range. IP Address field will be automatically updated with the selected IP before you save changes.

- IP Address: The IP address for this Interface. Can be an IPv4 or IPv6 address, depending on type selected earlier.

- Time to Live: The TTL value for the automatically generated DNS records for this host (A, PTR)

- Workgroup: The DHCP options that should be sent from the DHCP server to this interface. Typically this should be Default unless you have a special device like an IP-Phone or thin client.

- Expire: The expiration date for this interface (interface will be deleted on this date). Format is MM/DD/YYYY. If the System this interface is tied to only has one interface, the System will also be deleted on the expiration date. Leave field blank to never expire interface.

- Views: This allows you to configure how DNS records automatically generated for this Interface are queriable from. If Public is checked, the A and PTR records will be available from outside of OSU's IP space. If Private is checked, they will be queriable internally. The private view is for 128.193.0.0/16 and 10.0.0.0/8, public is for the rest of the Internet. Default: public, private both checked

- Enable DHCP?: Enable/Disable DHCP for this entry. If disabled, this IP is reserved and can still be used, but a lease for this address will not be given out. Default: Enabled

- Enable DNS?: If disabled, Cyder will not auto-generate an A Record or PTR for this Interface's address. Equivalent to unchecking both the public and private view. Default: Enabled

Dynamic Interface

- MAC Address: The hardware ethernet address of this Interface. Can accept colons or dashes, but they will be stripped upon saving. Field can be blank if DHCP is not enabled.

The VRF and Site selections are only for filtering down the Range selection. They are not actually fields stored with the Dynamic Interface object.

- Range: The IP range in which this Interface should be assigned an address. Use 10.255.255.255/32 dynamic Range to register an interface to bypass the captive portal on OSU_Access.

- Workgroup: The DHCP options that should be sent from the DHCP server to this interface. Typically this should be Default unless you have a special device like an IP-Phone or thin client.

- Expire: The expiration date for this interface (interface will be deleted on this date). Format is MM/DD/YYYY. If the System this interface is tied to only has one interface, the System will also be deleted on the expiration date. leave field blank to never expire interface.

- Enable DHCP?: Enable/Disable DHCP for this entry. If disabled, this IP is reserved and can still be used, but a lease for this address will not be given out. Default: Enabled

A Record

-Label: The non-fully-qualified name (no domain suffix!)

-Domain: The domain suffix for this record.

The following fields (VRF, Site, Range) are used to aide in finding/selecting an appropriate IP. Use is not necessary, especially if the IP address is not within OSU's IP space.

-VRF: Filter Ranges by VRF.

-Site: Filter Ranges by Site.

-Range: Ranges available for use in this Container, optionally filtered by the previous two selections.

-IP Address Type: Selects whether this is an A record or AAAA.

-Select free IPv4 IP?: Allow Cyder to automatically select the next free available IP in the selected range. The IP Address field will be automatically updated with the selected IP before you save changes. Again, this is not necessary if you are not using the VRF/Site/Range filters above.

-IP Address: The IP address this A record points to. Can be an IPv4 or IPv6 address, depending on type selected earlier.

-Views: This allows you to set where this record is queriable from. If Public is checked, the A and PTR records will be available from outside of OSU's IP space. If Private is checked, they will be queriable internally. The private view is for 128.193.0.0/16 and 10.0.0.0/8, public is for the rest of the Internet. Default: public, private both checked

-Time to Live: The TTL value for this record, in seconds. Default: 3600 seconds (one hour)

-Description: A description/note for this record (only shown within Cyder).

CNAME

-Label: The non-fully-qualified name (no domain suffix!)

-Domain: The domain suffix for this record.

-Target: The name that this CNAME points to. Do not enter an IP address here!

-Views: This allows you to set where this record is queriable from. If Public is checked, the A and PTR records will be available from outside of OSU's IP space. If Private is checked, they will be queriable internally. The private view is for 128.193.0.0/16 and 10.0.0.0/8, public is for the rest of the Internet. Default: public, private both checked

-Time to Live: The TTL value for this record, in seconds. Default: 3600 seconds (one hour)

-Description: A description/note for this record (only shown within Cyder).

 

Account Permissions

Account permissions are set per-Container. Containers are merely a group of objects within Cyder that are related e.g. a department or related equipment.

There are five different account levels in Cyder, ordered least to most privileged: guest, user, admin, cyder-admin, and super-admin. The guest level is generally considered superfluous because all accounts have access to view all objects managed by Cyder. The guest level is only useful if an admin account (or above) wishes to give another account read-only access only, and that account has not been given any permissions to any Containers.

The user and admin permission levels are very similar. Most accounts should be at the user permission level for any given container. The admin permission level is the typical Container permission level given to DCAs or IT staff managers. The admin level allows an account to add, remove, and change permissions of other users within a given Container.

Cyder-admin and super-admin permission levels are reserved for NOC staff and administrators of Cyder itself. A detailed break-down of permissions are listed in the table below.

 

Object User Admin Cyder Admin
       
Container R R RW
Container Users R RW RW
Container Objects R R RW
       
VRF, Network, Range, Workgroup, VLAN, Site R R RW
System, Interface RW RW RW
       
SOA, NS, Domain R R RW
A, CNAME, MX, PTR, etc RW RW RW
       
Subnet Options R R RW
Workgroup Options R RW RW

R = read-only, RW = read/write access.