mir/vinyldns
2
0
Fork 0
mirror of https://github.com/VinylDNS/vinyldns synced 2025-08-21 17:37:15 +00:00
Code Issues Releases Wiki Activity

Update docs

Browse Source
This commit is contained in:
Ryan Emerle 2021-12-15 12:24:29 -05:00
parent c9b5a87074
commit 9e8c1003d4
No known key found for this signature in database
GPG Key ID: C0D34C592AED41CE
8 changed files with 466 additions and 503 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
CONTRIBUTING.md
View File

@ -139,7 +139,7 @@ information on how to run and edit the documentation page.
#### Style Guides
* For Scala code we use [Scalastyle](https://www.scalastyle.org/). The configs are `scalastyle-config.xml` and
* For Scala code we use [Scalastyle](http://www.scalastyle.org/). The configs are `scalastyle-config.xml` and
`scalastyle-test-config.xml` for source code and test code respectively
* We have it set to fail builds if the styling rules are not followed. For example, one of our rules is that all
lines must be <= 120 characters, and a build will fail if that is violated.
@ -210,4 +210,4 @@ A pull request must satisfy our [pull request requirements](#pull-request-requir
Afterwards, if a Pull Request is approved, a maintainer of the project will merge it. If you are a maintainer, you can
merge your Pull Request once you have the approval of at least 2 other maintainers.
> Note: The first time you make a Pull Request, add yourself to the authors list [here](AUTHORS.md) as part of the Pull Request
> Note: The first time you make a Pull Request, add yourself to the authors list [here](https://github.com/vinyldns/vinyldns/blob/master/AUTHORS.md) as part of the Pull Request

20
modules/docs/src/main/mdoc/api/zone-model.md
View File

@ -241,12 +241,12 @@ Note that if both a backend ID and specific connection keys are included on a zo
Zone Connection specifies the connection information to the backend DNS server.
field | type | description |
------------ | :---------- | :---------- |
primaryServer | string | The IP address or host that is connected to. This can take a port as well `127.0.0.1:5300`. If no port is specified, 53 will be assumed. |
keyName | string | The name of the DNS key that has access to the DNS server and zone. **Note:** For the transfer connection, the key must be given *allow-transfer* access to the zone. For the primary connection, the key must be given *allow-update* access to the zone. |
name | string | A user identifier for the connection.
key | string | The TSIG secret key used to sign requests when communicating with the primary server. **Note:** After creating the zone, the key value itself is hashed and obfuscated, so it will be unusable from a client perspective. |
| field | type | description |
|---------------|:-------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| primaryServer | string | The IP address or host that is connected to. This can take a port as well `127.0.0.1:5300`. If no port is specified, 53 will be assumed. |
| keyName | string | The name of the DNS key that has access to the DNS server and zone. **Note:** For the transfer connection, the key must be given *allow-transfer* access to the zone. For the primary connection, the key must be given *allow-update* access to the zone. |
| name | string | A user identifier for the connection. |
| key | string | The TSIG secret key used to sign requests when communicating with the primary server. **Note:** After creating the zone, the key value itself is hashed and obfuscated, so it will be unusable from a client perspective. |
#### ZONE CONNECTION EXAMPLE <a id="zone-conn-example"></a>
@ -261,4 +261,10 @@ key | string | The TSIG secret key used to sign requests when com
### SHARED ZONES <a id="shared-zones"></a>
Shared zones allow for a more open management of records in VinylDNS. Zone administrators can assign ownership of records to groups. Any user in VinylDNS can claim existing unowned records in shared zones, as well as create records in those zones. Once a record is owned, only users in the record owner group, the zone administrators and those with relevant ACL rules can modify or delete the record. The [batch change API endpoint](create-batchchange.html) and [batch change area of the portal](../portal/batch-changes.html) are where users can create new records in shared zones, modify records they own, or claim unowned records. If a zone's shared state changes to false the record ownership access is no longer applicable.
Shared zones allow for a more open management of records in VinylDNS. Zone administrators can assign ownership of
records to groups. Any user in VinylDNS can claim existing unowned records in shared zones, as well as create records in
those zones. Once a record is owned, only users in the record owner group, the zone administrators and those with
relevant ACL rules can modify or delete the record. The [batch change API endpoint](create-batchchange.html)
and [DNS change area of the portal](../portal/dns-changes.html) are where users can create new records in shared zones,
modify records they own, or claim unowned records. If a zone's shared state changes to false the record ownership access
is no longer applicable.

14
modules/docs/src/main/mdoc/index.md
View File

@ -1,6 +1,5 @@
---
layout: home
title: "Home"
layout: home title: "Home"
section: "home"
position: 1
---
@ -9,18 +8,21 @@ position: 1
![VinylDNS logo](../img/vinyldns-fulllogoDARK-300.png)
VinylDNS is a vendor agnostic front-end for enabling self-service DNS and streamlining DNS operations. It is designed to integrate with your existing DNS infrastructure, and provides extensibility to fit your installation.
VinylDNS manages millions of DNS records supporting thousands of engineers in production at [Comcast](http://www.comcast.com).
The platform provides fine-grained access controls, auditing of changes, a self-service user interface,
secure RESTful API, and integration with infrastructure automation tools like Ansible and Terraform.
VinylDNS is a vendor agnostic front-end for enabling self-service DNS and streamlining DNS operations. It is designed to
integrate with your existing DNS infrastructure, and provides extensibility to fit your installation. VinylDNS manages
millions of DNS records supporting thousands of engineers in production at [Comcast](https://comcast.github.io/). The
platform provides fine-grained access controls, auditing of changes, a self-service user interface, secure RESTful API,
and integration with infrastructure automation tools like Ansible and Terraform.
VinylDNS helps secure DNS management via:
* AWS Sig4 signing of all messages to ensure that the message that was sent was not altered in transit
* Throttling of DNS updates to rate limit concurrent updates against your DNS systems
* Encrypting user secrets and TSIG keys at rest and in-transit
* Recording every change made to DNS records and zones
Integration is simple with first-class language support including:
* Java
* JavaScript
* Python

148
modules/docs/src/main/mdoc/operator/config-api.md
View File

@ -1,6 +1,5 @@
---
layout: docs
title: "API Configuration Guide"
layout: docs title: "API Configuration Guide"
section: "operator_menu"
---
@ -9,6 +8,7 @@ section: "operator_menu"
**Note: ALL configuration assumes a `vinyldns` namespace. For example, sqs settings would be under `vinyldns.sqs`.**
## Configuration
- [Configuration Overview](#configuration-overview)
- [Configuration API Server](#configuring-api-server)
- [Queue Configuration](#queue-configuration)
@ -17,35 +17,40 @@ section: "operator_menu"
- [Additional Configuration Settings](#additional-configuration-settings)
- [Full Example Config](#full-example-config)
There are a lot of configuration settings in VinylDNS. So much so that it may seem overwhelming to configure
vinyldns to your environment. This document describes the configuration settings, highlighting the settings
you are _most likely to change_. All of the configuration settings are captured at the end.
There are a lot of configuration settings in VinylDNS. So much so that it may seem overwhelming to configure vinyldns to
your environment. This document describes the configuration settings, highlighting the settings you are _most likely to
change_. All of the configuration settings are captured at the end.
It is important to note that the `api` and `portal` have _different_ configuration. We will review the configuration
for each separately.
It is important to note that the `api` and `portal` have _different_ configuration. We will review the configuration for
each separately.
## Configuration Overview
### How do we config?
All configuration is done using [Typesafe Config](https://github.com/lightbend/config). It provides a means to
specifying default configurations, and overriding the configured values in a number of ways:
1. The _default_ configuration provides "safe" default values for all configuration. This makes it possible for you
to only change the configuration values that you _need_ to, and assume the _default_ for the rest. This can
typically be found in a file named `reference.conf`. The Typesafe Config library manages populating unspecified values
for you automatically.
1. The _default_ configuration provides "safe" default values for all configuration. This makes it possible for you to
only change the configuration values that you _need_ to, and assume the _default_ for the rest. This can typically be
found in a file named `reference.conf`. The Typesafe Config library manages populating unspecified values for you
automatically.
1. You can override the `reference.conf` file by providing your own `application.conf` file when the system starts up.
We will review how to do that in the sections that follow.
1. You can override _individual_ configuration properties when the application starts up using standard jvm arguments.
For example, you can specify `-Dmy.config.value=42`, and that will override _both_ application.conf _and_ reference.conf (defaults)
For example, you can specify `-Dmy.config.value=42`, and that will override _both_ application.conf _and_
reference.conf (defaults)
1. You can further override configuration properties with _environment variables_. The Typesafe Config provides special
syntax that allows you to use environment variables. You can make the environment variable optional (meaning use it if it is there)
or required (fail to start up without the environment variable). We will illustrate use of environment variables in this guide.
syntax that allows you to use environment variables. You can make the environment variable optional (meaning use it
if it is there)
or required (fail to start up without the environment variable). We will illustrate use of environment variables in
this guide.
### Using Environment Variables
We _strongly_ recommend that you use environment variables in particular for secrets. Laying down environment variables
in a flat file is a security vulnerability for your installation. To demonstrate environment variable usage, here is a following
snippet...
in a flat file is a security vulnerability for your installation. To demonstrate environment variable usage, here is a
following snippet...
```yaml
queue.settings {
@ -60,24 +65,27 @@ snippet...
In the example, if any of the values in `${xxx}` are not found in the environment, the application will not start up!
## Configuring API Server
The API configuration has a lot of values, the important ones reviewed here. There are several configuration
settings that are specific to _your_ environment.
The API configuration has a lot of values, the important ones reviewed here. There are several configuration settings
that are specific to _your_ environment.
The most important configuration is around your system dependencies. Presently, these are your settings for:
* `AWS SQS`
* `AWS DynamoDB`
* `MySQL`
**We are actively working on supporting different message queues and data stores. Look for those to become available shortly**
## Queue Configuration
VinylDNS supports both SQS and MySQL queue implementations.
There are a couple of implementation-dependent settings that need to be specified:
* `messages-per-poll`: Number of messages retrieved in a single queue receive request. Valid values are 1 through 10 (default).
* `messages-per-poll`: Number of messages retrieved in a single queue receive request. Valid values are 1 through 10 (
default).
* `polling-interval`: Interval to delay between each poll for messages.
If using SQS, be sure to follow the [AWS SQS Setup Guide](setup-sqs.html) first to get the values you need to configure here.
If using SQS, be sure to follow the [AWS SQS Setup Guide](setup-sqs.html) first to get the values you need to configure
here.
If using MySQL, follow the [MySQL Setup Guide](setup-mysql.html) first to get the values you need to configure here.
@ -147,12 +155,12 @@ queue {
```
## Database Configuration
VinylDNS supports a MySQL database. You can enable all repos in a single backend, or have a mix of the two.
For each backend, you need to configure the table(s) that should be loaded.
VinylDNS supports a MySQL database. You can enable all repos in a single backend, or have a mix of the two. For each
backend, you need to configure the table(s) that should be loaded.
If using MySQL, follow the [MySQL Setup Guide](setup-mysql.html) first to get the values you need to configure here.
```yaml
vinyldns {
@ -233,17 +241,19 @@ vinyldns {
```
## Cryptography Settings
VinylDNS uses symmetric cryptography in order to encrypt/decrypt sensitive information in the system. This includes
TSIG keys and user secrets. Cryptography is used in _both_ the portal as well as the api.
VinylDNS uses symmetric cryptography in order to encrypt/decrypt sensitive information in the system. This includes TSIG
keys and user secrets. Cryptography is used in _both_ the portal as well as the api.
Cryptography is _pluggable_, meaning you can bring your own crypto with you. All that is required is to provide an
implementation of [CryptoAlgebra](https://github.com/vinyldns/vinyldns/blob/master/modules/core/src/main/scala/vinyldns/core/crypto/CryptoAlgebra.scala)
using a crypto library of choice. The default implementation is `NoOpCrypto`, which does not do any encryption (not recommended for production).
VinylDNS provides a cryptography implementation called `JavaCrypto` that you can use for production. The example that follows illustrates
using the provided `JavaCrypto`.
implementation
of [CryptoAlgebra](https://github.com/vinyldns/vinyldns/blob/master/modules/core/src/main/scala/vinyldns/core/crypto/CryptoAlgebra.scala)
using a crypto library of choice. The default implementation is `NoOpCrypto`, which does not do any encryption (not
recommended for production). VinylDNS provides a cryptography implementation called `JavaCrypto` that you can use for
production. The example that follows illustrates using the provided `JavaCrypto`.
If you create your own implementation, you have to build your jar and make it (and all dependencies) available to the VinylDNS API
and the VinylDNS portal.
If you create your own implementation, you have to build your jar and make it (and all dependencies) available to the
VinylDNS API and the VinylDNS portal.
The following are the configuration settings for crypto. Notice here the _only_ thing we see is the `type`. The `type`
is the fully qualified class name for the `CryptoAlgebra` you will be using. If your crypto implementation requires
@ -259,20 +269,24 @@ vinyldns {
```
## Default Zone Connections
VinylDNS has three ways of indicating zone connections:
1. Global default connection applies to all zones unless overridden by one of the following connections. This configuration is required.
2. Backends allows you to specify zone connection information for an individual zone by choosing a pre-configured zone connection. This configuration is optional.
3. Zone level override allows you to specify zone update and transfer connection information _for each zone_. More information is in the [Zone Model](../api/zone-model.html).
1. Global default connection applies to all zones unless overridden by one of the following connections. This
configuration is required.
2. Backends allows you to specify zone connection information for an individual zone by choosing a pre-configured zone
connection. This configuration is optional.
3. Zone level override allows you to specify zone update and transfer connection information _for each zone_. More
information is in the [Zone Model](../api/zone-model.html).
VinylDNS has **2** connections for each zone:
1. The DDNS connection - used for making DDNS updates to the zone
1. The Transfer connection - used for making AXFR requests for zone syncing with the DNS backend
VinylDNS also ties in testing network connectivity to the default zone connection's primary server into its API health checks. A value
for the health check connection timeout in milliseconds can be specified using `health-check-timeout`; a default value of 10000 will
be used if not provided.
VinylDNS also ties in testing network connectivity to the default zone connection's primary server into its API health
checks. A value for the health check connection timeout in milliseconds can be specified using `health-check-timeout`; a
default value of 10000 will be used if not provided.
```yaml
vinyldns {
@ -333,8 +347,9 @@ backends = [
## Additional Configuration Settings
### Approved Name Servers
When running a large DNS installation, allowing users the ability to self-manage zone delegations can lead to a lot
of problems when not done properly. Also, allowing delegation to untrusted DNS servers can be a security risk.
When running a large DNS installation, allowing users the ability to self-manage zone delegations can lead to a lot of
problems when not done properly. Also, allowing delegation to untrusted DNS servers can be a security risk.
To "lock down" zone delegation, you can configure name servers that you trust, so zone delegation is controlled.
@ -349,24 +364,29 @@ approved-name-servers = [
```
### Processing Disabled
The processing disabled flag can be used if doing a blue/green deployment. When processing is disabled, the
VinylDNS engine will _not_ be actively polling the message queue for messages.
The processing disabled flag can be used if doing a blue/green deployment. When processing is disabled, the VinylDNS
engine will _not_ be actively polling the message queue for messages.
`processing-disabled = false | true`
### Color
For blue-green deployments, you can configure the color of the current node. Not applicable to every environment.
`color = "green"`
### Version
Version of the application that is deployed. Currently, this is a configuration value.
`version = "0.8.0"`
**Note: You can get installation information including color, version, default key name, and processing-disabled by hitting the _status_ endpoint GET /status**
**Note: You can get installation information including color, version, default key name, and processing-disabled by
hitting the _status_ endpoint GET /status**
### HTTP Host and Port
To specify what host and port to bind to when starting up the API server, default is 9000.
```yaml
@ -377,6 +397,7 @@ rest {
```
### Sync Delay
VinylDNS uses a "sync-delay" setting that prevents users from syncing their zones too frequently. The settings is
inspected _per zone_, and is the number of milliseconds since the _last_ sync to wait before allowing another sync for
_that_ zone.
@ -386,6 +407,7 @@ sync-delay = 10000
```
### Notifiers
VinylDNS provides the ability to send notifications via configured notifiers when a batch change is either implemented
or rejected. Notifiers in VinylDNS are designed to be pluggable (ie. bring-your-own-implementation), granting users the
flexibility to implement their own which can smoothly integrate into their instance.
@ -398,6 +420,7 @@ notifiers = ["email", "sns"]
```
#### E-mail notifier
Configuration for the e-mail notifier appears like the following:
```yaml
@ -414,16 +437,18 @@ email = {
host = "example.host"
}
}
}
```
Note that `settings.from` and `settings.smtp` are both required, though the `smtp` values requirements depend on the specific
exchange service that you are interfacing with.
Note that `settings.from` and `settings.smtp` are both required, though the `smtp` values requirements depend on the
specific exchange service that you are interfacing with.
Below is an example e-mail notification:
![Sample E-mail Notification](../img/sample-email-nofitication.png)
#### AWD Simple Notification Service (SNS) notifier
Configuration for the AWS SNS notifier appears like the following:
```yaml
@ -449,20 +474,23 @@ sns {
```
### Batch Manual Review Enabled <a id="manual-review" />
[manual-review]: #manual-review
Configuration setting that determines whether batch changes with non-fatal errors can be reviewed rather than failing immediately.
When enabling manual review, the expectation is that a DNS technician is actively querying and addressing batch change
requests that are in a manual review state. If your process flow does not accommodate this expectation, we advise disabling
manual review.
Configuration setting that determines whether batch changes with non-fatal errors can be reviewed rather than failing
immediately. When enabling manual review, the expectation is that a DNS technician is actively querying and addressing
batch change requests that are in a manual review state. If your process flow does not accommodate this expectation, we
advise disabling manual review.
```yaml
manual-batch-review-enabled = true
```
### Manual Review Domains
Configuration setting that determines what Batch Change/DNS Change input names require manual review if `manual-batch-review-enabled` is set to `true`.
If `manual-batch-review-enabled` is set to `false` any input names that match entries in the configured list will be treated as fatal errors.
Configuration setting that determines what Batch Change/DNS Change input names require manual review
if `manual-batch-review-enabled` is set to `true`. If `manual-batch-review-enabled` is set to `false` any input names
that match entries in the configured list will be treated as fatal errors.
```yaml
manual-review-domains = {
@ -482,16 +510,19 @@ manual-review-domains = {
```
### Scheduled Batch Changes Enabled
Configuration setting that determines if users are able to make Batch Changes with a scheduled time. `manual-batch-review-enabled` must be enabled as well.
If enabled, a VinylDNS administrator cannot approve the Batch Change until after the scheduled time. An administrator could also reject the Batch Change.
Configuration setting that determines if users are able to make Batch Changes with a scheduled
time. `manual-batch-review-enabled` must be enabled as well. If enabled, a VinylDNS administrator cannot approve the
Batch Change until after the scheduled time. An administrator could also reject the Batch Change.
```yaml
scheduled-changes-enabled = true
```
### IPv6 Zone Discovery Boundaries
Configuration setting that determines the range that will be searched for in reverse IPv6 Zone Discovery. This allows you
to limit the search for what is appropriate for your organization. For example, min = 2, max = 3 will only search in
Configuration setting that determines the range that will be searched for in reverse IPv6 Zone Discovery. This allows
you to limit the search for what is appropriate for your organization. For example, min = 2, max = 3 will only search in
zones in the form `X.X.ip6.arpa.` and `X.X.X.ip6.arpa.`. Note the following constraints: 0 < min <= max <= 32. If your
organization only makes zone cuts at one point, you may set min == max.
@ -506,6 +537,7 @@ v6-discovery-nibble-boundaries {
```
### Full Example Config
```yaml
# The default application.conf is not intended to be used in production. It assumes a docker-compose
# setup for all of the services. Provide your own application.conf on the docker mount with your
@ -678,6 +710,7 @@ vinyldns {
high-value-domains = {
regex-list = [
"high-value-domain.*"
]
ip-list = [
"192.0.2.252",
"192.0.2.253",
@ -749,4 +782,5 @@ akka.http {
illegal-header-warnings = on
}
}
}
```

41
modules/docs/src/main/mdoc/operator/pre.md
View File

@ -1,6 +1,5 @@
---
layout: docs
title: "Pre-requisites"
layout: docs title: "Pre-requisites"
section: "operator_menu"
---
@ -41,44 +40,6 @@ Connections (DDNS and Transfer) can be setup
can [configure default zone connections](config-api.html#default-zone-connections). When no zone connection is
specified on a zone, the global defaults will be used.
## Database
[database]: #database
The VinylDNS database has a `NoSQL` / non-relational design to it. Instead of having a heavily normalized set of SQL
tables that surface in the system, VinylDNS relies on `Repositories` where each `Repository` is independent of each one
another. This allows implementers to best map each `Repository` into the data-store of choice.
As `Repositories` are independent, there are no "transactions" that span repositories. Each `Repository` implementation
can choose to use transactions if it maps to multiple tables within itself.
There are **links** across repositories, for example the `RecordSet.id` would be referenced in
a `RecordSetChangeRepository`.
The following are the repositories presently used by VinylDNS:
* `RecordSetRepository` - Instead of individual DNS records, VinylDNS works at the `RRSet`. The unique key for RecordSet
is the `record name` + `record type`
* `RecordChangeRepository` - The history of all changes to all records in VinylDNS. In general, some kind of pruning
strategy should be implemented otherwise this could get quite large
* `ZoneRepository` - DNS Zones and managing access to zones
* `ZoneChangeRepository` - The history of all changes made to _zones_ in VinylDNS. Zone changes can including syncs,
updating ACL rules, changing zone ownership, etc.
* `GroupRepository` - VinylDNS Groups
* `UserRepository` - VinylDNS Users. These users are typically created the first time the user logs into the portal. The
user information will be pulled from LDAP, and inserted into the VinylDNS UserRepository
* `MembershipRepository` - Holds a link from users to groups
* `GroupChangeRepository` - Holds changes to groups and membership
* `BatchChangeRepository` - VinylDNS allows users to submit multiple record changes _across_ DNS zones at the same time
within a `Batch`
The `BatchChangeRepository` holds the batch itself and all individual changes that executed in the batch.
* `UserChangeRepository` - Holds changes to users. Currently only used in the portal.
## Database Types
### MySQL
Review the [Setup MySQL Guide](setup-mysql.html) for more information.
## Message Queues

54
modules/docs/src/main/mdoc/portal/batch-changes.md
View File

@ -1,54 +0,0 @@
---
layout: docs
title: "Batch Changes"
section: "portal_menu"
---
## Batch Changes
Batch Changes is an alternative to submitting individual RecordSet changes and provides the following:
* The ability to include records of multiple record types across multiple zones.
* Input names are entered as fully-qualified domain names (or IP addresses for `PTR` records), so users don't have to think in record/zone context.
#### Access
* Access permissions will follow existing rules (admin group or ACL access). Note that an update (delete and add of the same record name, zone and record type combination) requires **Write** or **Delete** access.
* <span class="important">**NEW**</span> **Records in shared zones.** All users are permitted to create new records or update unowned records in shared zones.
#### Supported record types
* Current supported record types for Batch Change are: `A`, `AAAA`, `CNAME`, `PTR`, `TXT`, and `MX`.
* Additionally, there are `A+PTR` and `AAAA+PTR` types that will be processed as separate `A` (or `AAAA`) and `PTR` changes in the VinylDNS backend. Deletes for `A+PTR` and `AAAA+PTR` require Input Name and Record Data.
* Supported record types for records in shared zones may vary.
Contact your VinylDNS administrators to find the allowed record types.
This does not apply to zone administrators or users with specific ACL access rules.
#### Requirements
* DNS change requests must contain at least one change.
* The maximum number of single changes within a Batch change varies by instance of VinylDNS. Contact your VinylDNS administrators to find the Batch change limit for your instance.
* To update an existing record, you must delete the record first and add all expected records within the same request; a delete and add of the same record set within a Batch change request will be processed as an update.
* When creating a new record in a shared zone, or updating an existing unowned record, a record owner group is required. Once the owner group is assigned only users in that group, zone admins, and users with ACL permissions can modify the record.
---
### Create a Batch Change
1. Go to the Batch Changes section of the site.
1. Select the *New Batch Change* button.
1. Add a description.
1. Add record changes in one of two ways:
- Select the *Add a Change* button to add additional rows for data entry as needed.
- Select the *Import CSV* button to choose and upload a CSV file of the record changes. See [Batch Change CSV Import](#dns-change-csv-import) for more information.
1. Select the submit button. Confirm your submission.
- If your submission was successful you'll redirect to the Batch Change summary page where you will see the status of the Batch Change request overall and of the individual records in the Batch Change.
- If there are errors in the Batch Change you will remain on the form with prompts to correct errors before you attempt to submit again.
[![Batch Changes main page screenshot](../img/portal/dns-change-main-annotated.png){: .screenshot}](../img/portal/dns-change-main-annotated.png)
[![New Batch Change form screenshot](../img/portal/dns-change-new-annotated.png){: .screenshot}](../img/portal/dns-change-new-annotated.png)
[![Submitted Batch Change screenshot](../img/portal/dns-change-summary.png){: .screenshot}](../img/portal/dns-change-summary.png)
#### Batch Change CSV Import
[Download a sample CSV here](../static/dns-changes-csv-sample.csv)
* The header row is required. The order of the columns is `Change Type, Record Type, Input Name, TTL, Record Data`.
* The TTL field is optional for each record, but the column is still required. If TTL is empty VinylDNS will use the existing TTL value for record updates or the default TTL value for new records.
### Review a Batch Change
You can review your submitted Batch Change requests by selecting the linked Batch ID or View button for the Batch Change on the main page of the Batch Change section in the portal.
[![List of Batch Change requests screenshot](../img/portal/dns-change-list-annotated.png){: .screenshot}](../img/portal/dns-change-annotated.png)

4
modules/docs/src/main/mdoc/portal/dns-changes.md
View File

@ -14,7 +14,7 @@ DNS Changes is an alternative to submitting individual RecordSet changes and pro
#### Access
* Access permissions will follow existing rules (admin group or ACL access). Note that an update (delete and add of the same record name *or* delete of single entry of multi-record DNS record set, zone and record type combination) requires **Write** or **Delete** access.
* <span class="important">**NEW**</span> **Records in shared zones.** All users are permitted to create new records or update unowned records in shared zones.
* **Records in shared zones.** All users are permitted to create new records or update unowned records in shared zones.
#### Supported record types
* Current supported record types for DNS change are: `A`, `AAAA`, `CNAME`, `PTR`, `TXT`, and `MX`.
@ -53,4 +53,4 @@ This does not apply to zone administrators or users with specific ACL access rul
### Review a DNS Change
You can review your submitted DNS Change requests by selecting the linked DNS Change ID or View button for the DNS Change on the main page of the DNS Changes section in the portal.
[![List of DNS Change requests screenshot](../img/portal/dns-change-list-annotated.png){: .screenshot}](../img/portal/dns-change-annotated.png)
[![List of DNS Change requests screenshot](../img/portal/dns-change-list-annotated.png){: .screenshot}](../img/portal/dns-change-list-annotated.png)

24
modules/docs/src/main/mdoc/portal/manage-access.md
View File

@ -3,13 +3,21 @@ layout: docs
title: "Manage Access"
section: "portal_menu"
---
## Manage Access to Zones and Records <a id="access"></a>
### Full Access
Members of a zone admin group have *full* access to all records and permissions in the zone. Each zone is limited to one admin group. Typically, this should be a limited set of
users. If you wish to add other users to a group you can do so in the [Groups](manage-membership.html) section of the portal.
Members of a zone admin group have *full* access to all records and permissions in the zone. Each zone is limited to one
admin group. Typically, this should be a limited set of users. If you wish to add other users to a group you can do so
in the [Groups](manage-membership.html) section of the portal.
### Limited Access
If you don't want a user to have full access to a zone you can use ACL rules to give them more granular access. With ACL rules, the zone admins can grant individual users or groups read, write or delete access to all records in the zone, or a subset of record names and/or types.
If you don't want a user to have full access to a zone you can use ACL rules to give them more granular access. With ACL
rules, the zone admins can grant individual users or groups read, write or delete access to all records in the zone, or
a subset of record names and/or types.
1. Go to the desired zone
1. Select the Manage Zone tab
1. Select the Create ACL rule button
@ -18,5 +26,11 @@ If you don't want a user to have full access to a zone you can use ACL rules to
[![ACL rule form screenshot](../img/portal/create-acl-rule.png){:.screenshot}](../img/portal/create-acl-rule.png)
### <span class="important">**NEW**</span> Shared Zones
The shared zone feature is designed to allow more granular record ownership and management in a flexible way. Super users can mark zones as 'shared' which then allow any users to create new records or claim existing unowned records in zones. Zone administrators can assign records in a shared zone to specific groups by designating a group when creating the record set or when updating existing records in the portal. Users who are not zone administrators can create new records in shared zones, or claim and modify unowned records in shared zones, through the [DNS Changes](dns-changes.html) interface.
### Shared Zones
The shared zone feature is designed to allow more granular record ownership and management in a flexible way. Super
users can mark zones as 'shared' which then allow any users to create new records or claim existing unowned records in
zones. Zone administrators can assign records in a shared zone to specific groups by designating a group when creating
the record set or when updating existing records in the portal. Users who are not zone administrators can create new
records in shared zones, or claim and modify unowned records in shared zones, through
the [DNS Changes](dns-changes.html) interface.