DOCS: Fix many minor typos (#3752)

Co-authored-by: Tom Limoncelli <6293917+tlimoncelli@users.noreply.github.com>

.gitattributes

@@ -2,7 +2,7 @@
 
 # Git itself
 .gitattributes eol=lf
-.gitigore eol=lf
+.gitignore eol=lf
 OWNERS eol=lf
 
 # dnscontrol files are unix line-endings:

commands/types/dnscontrol.d.ts

@@ -2081,7 +2081,7 @@ declare function MX(name: string, priority: number, target: string, ...modifiers
  * control `.com`.  If the domain was `gmeet.io`, the registrar does
  * the right thing to talk to the people that control `.io`.
  *
- * (A better name might have been `PARENTNAMESERVER()` but we didn"t
+ * (A better name might have been `PARENTNAMESERVER()` but we didn't
  * think of that at the time.)
  *
  * Each registrar handles delegations differently.  Most use

docs/index.md

@@ -54,7 +54,7 @@ title: DNSControl
 <hr class="feature">
 
 <div class="row">
-    {% include feature.html text="Maintain your DNS data as a high-level DS, with macros, and variables for easier updates." img="biology.svg" %}
+    {% include feature.html text="Maintain your DNS data in a high-level DSL, with macros and variables for easier updates." img="biology.svg" %}
     {% include feature.html text="Super extensible! Plug-in architecture makes adding new DNS providers and Registrars easy!" img="light-bulb.svg" %}
     {% include feature.html text="Eliminate vendor lock-in. Switch DNS providers easily, any time, with full fidelity." img="group.svg" %}
     {% include feature.html text="Reduce points of failure: Easily maintain dual DNS providers and easily drop one that is down." img="layers.svg" %}

documentation/advanced-features/byo-secrets.md

@@ -162,7 +162,7 @@ Some rules:
 
 * The account/credentials should only access the test domain. Don't send your company's actual credentials and trust us to only touch the test domain. (this hasn't happened yet, thankfully!)
 * Renew the domain in a timely manner. This may be monitoring an email inbox you don't normally monitor.
-* Don't do anything that will get you in trouble with your employer, like charging it to your employer without permission. (this hasn't happend yet either, thankfully!)
+* Don't do anything that will get you in trouble with your employer, like charging it to your employer without permission. (this hasn't happened yet either, thankfully!)
 {% endhint %}
 
 Now that we've covered all that...

documentation/advanced-features/json-reports.md

@@ -2,7 +2,7 @@
 
 DNSControl can generate a machine-parseable report of changes.
 
-The report is JSON formated and contains the zonename, the provider or
+The report is JSON formatted and contains the zonename, the provider or
 registrar name, and the number of changes.
 
 To generate the report, add the `--report <filename>` option to a preview or

documentation/advanced-features/nameservers.md

@@ -94,7 +94,7 @@ D("example.com", REG_THIRDPARTY,
 ## Zone is elsewhere
 
 Purpose:
-This is a "Registar only" configuration.  Use it when you control the registar but want to delegate the zone to someone else.
+This is a "Registrar only" configuration.  Use it when you control the registrar but want to delegate the zone to someone else.
 
 Why?
 We are delegating the domain to someone else. In this example we're
@@ -243,7 +243,7 @@ D("example.com", REG_NAMECOM,
 Purpose:
 You don't control the registrar but want to detect if the delegation changes.
 You can specify the existing nameservers in `dnsconfig.js` and you will get
-a notified if the delegation diverges.
+a notification if the delegation diverges.
 
 Why?
 Sometimes you just want to know if something changes!

documentation/advanced-features/styleguide-code.md

@@ -83,9 +83,9 @@ Therefore, if your code looks like, "add dot, but not if one exists" or "remove
 
 ### But isn't future-proofing good? What if the API changes?
 
-The protocol won't change.  That would break all their other users that didn't future-proof their code. Why would they make a random change like that?  A breaking change like that would (by semvar rules) require a new protocol version, which would trigger code changes in DNSControl.
+The protocol won't change.  That would break all their other users that didn't future-proof their code. Why would they make a random change like that?  A breaking change like that would (by semver rules) require a new protocol version, which would trigger code changes in DNSControl.
 
-### But what if it changes anway?
+### But what if it changes anyway?
 
 If the protocol does change, how do you know your future-proofed code is doing the right thing?
 

documentation/advanced-features/writing-providers.md

@@ -117,7 +117,7 @@ The main driver should be called `providers/name/nameProvider.go`.
 The API abstraction is usually in a separate file (often called
 `api.go`).
 
-Directory names should be consitent.  It should be all lowercase and match the ALLCAPS provider name. Avoid `_`s.
+Directory names should be consistent.  It should be all lowercase and match the ALLCAPS provider name. Avoid `_`s.
 
 ## Step 4: Activate the driver
 
@@ -276,7 +276,7 @@ Please use `go vet` from the [newest release of Go](https://golang.org/doc/devel
 
 golint is deprecated and frozen but it is still useful as it does a few checks that haven't been
 re-implemented in staticcheck.
-However golink fails on any file that uses generics, so
+However golint fails on any file that uses generics, so
 be prepared to ignore errors about `expected '(', found '[' (and 1 more errors)`
 
 How to install and run [golint](https://github.com/golang/lint):

documentation/commands/check-creds.md

@@ -2,7 +2,7 @@
 
 This is a stand-alone utility to help verify entries in `creds.json`.
 
-The command does a trivia operation to verify credentials.  If
+The command does a trivial operation to verify credentials.  If
 successful, a list of zones will be output (which may be an empty list). If the credentials or other problems prevent this operation from executing, the exit code will be non-zero and hopefully verbose error messages will be output.
 
 ```text

documentation/index.md

@@ -11,7 +11,7 @@ Want to jump right in? Follow our [quick start tutorial](getting-started/getting
 Take advantage of the advanced features. Use macros and variables for easier updates. Upload your zones to [multiple DNS providers](provider/index.md).
 
 {% hint style="success" %}
-* Maintain your DNS data as a high-level DS, with macros, and variables for easier updates.
+* Maintain your DNS data in a high-level DSL, with macros and variables for easier updates.
 * Super extensible! Plug-in architecture makes adding new DNS providers and Registrars easy!
 * Eliminate vendor lock-in. Switch DNS providers easily, any time, with full fidelity.
 * Reduce points of failure: Easily maintain dual DNS providers and easily drop one that is down.

documentation/language-reference/domain-modifiers/NAMESERVER.md

@@ -57,7 +57,7 @@ the registrar who does the hard work of talking to the people that
 control `.com`.  If the domain was `gmeet.io`, the registrar does
 the right thing to talk to the people that control `.io`.
 
-(A better name might have been `PARENTNAMESERVER()` but we didn"t
+(A better name might have been `PARENTNAMESERVER()` but we didn't
 think of that at the time.)
 
 Each registrar handles delegations differently.  Most use

documentation/language-reference/top-level-functions/require.md

@@ -104,7 +104,7 @@ for (var domain in domains) {
 ```javascript
 {
     "example.com": "1.1.1.1",
-    "other-example.com``": "5.5.5.5"
+    "other-example.com": "5.5.5.5"
 }
 ```
 {% endcode %}

documentation/language-reference/why-the-dot.md

@@ -45,7 +45,7 @@ ambiguous and are therefore are considered errors.
 How are they ambiguous?
 
   * Should $DOMAIN be added to "bar.com"?  Well, obviously not, because it already ends with ".com" and we all know that "bar.com.bar.com" is probably not what they want. No, it isn't that obvious!  Why?  (see the next bullet point)
-  * Should $DOMAIN be added to "meta.xyz"?  Everyone knows that ".xyz" isn't a TLD. Obviously, yes, $DOMAIN should be appended. However, wait...  ".xyz" became a TLD in June 2014.  We don't want to be surprised by changes like that.  Also, users should not be required to memorize all the TLDs. (In the old days it was reasonable to expect people to memorize the 7 TLDS (gov/edu/com/mil/org/net) but since 2000 that's all changed. By the way, we forgot to include "int" in the original and you didn't notice.)
+  * Should $DOMAIN be added to "meta.xyz"?  Everyone knows that ".xyz" isn't a TLD. Obviously, yes, $DOMAIN should be appended. However, wait...  ".xyz" became a TLD in June 2014.  We don't want to be surprised by changes like that.  Also, users should not be required to memorize all the TLDs. (In the old days it was reasonable to expect people to memorize the 7 TLDs (gov/edu/com/mil/org/net) but since 2000 that's all changed. By the way, we forgot to include "int" in the original and you didn't notice.)
   * What if the CNAME target is "www.bar.com" and the domain is "bar.com"?  Then It is reasonable to infer the user's intent, right?  `www.bar.com.bar.com.` would be silly, right?  Maybe. What if we are copying 100 lines of `dnsconfig.js` from one `D()` to another. Buried in the middle is this one CNAME that means something entirely different when in a new $DOMAIN. That would be bad.  We've seen this in production and want to prevent this kind of error.
 
 Yes, we could layer rule upon rule upon rule.  Eventually we'd get

documentation/provider/bind.md

@@ -130,7 +130,7 @@ any files named `*.zone` and assumes they are zone files.
 dnscontrol get-zones --format=nameonly - BIND all
 ```
 
-If `filenameformat` is defined, `dnscontrol` makes an guess at which
+If `filenameformat` is defined, `dnscontrol` makes a guess at which
 filenames are zones but doesn't try to hard to get it right, which is
 mathematically impossible in some cases.  Feel free to file an issue if
 your format string doesn't work. I love a challenge!

documentation/provider/bunny_dns.md

@@ -64,7 +64,7 @@ If a domain does not exist in your Bunny account, DNSControl will automatically
 ## Custom record types
 
 Any custom record types like Script, Flatten or Pull Zone are currently not supported by this provider, except
-those explicitely listed below. Such records will be completely ignored by DNSControl and left as-is.
+those explicitly listed below. Such records will be completely ignored by DNSControl and left as-is.
 
 ### Redirect
 

documentation/provider/gcloud.md

@@ -73,7 +73,7 @@ D("example.com", REG_NAMECOM, DnsProvider(DSP_GCLOUD),
 ## Activation
 1. Go to your app-engine console and select the appropriate project.
 2. Go to "API Manager > Credentials", and create a new "Service Account Key"
-   ![Create new Service Accoun](../assets/gcloud/create-credentials-service-account-key.png)
+   ![Create new Service Account](../assets/gcloud/create-credentials-service-account-key.png)
 3. Choose an existing user, or create a new one. The user requires the "DNS Administrator" role.
 4. Download the JSON key and copy it into your `creds.json` under the name of your gcloud provider.
 
@@ -113,7 +113,7 @@ D("example.tld", REG_NAMECOM, DnsProvider(DSP_GCLOUD),
 ```
 {% endcode %}
 
-> `visiblity` and `networks` only applies on `create-domains` at the moment. Neither setting is enforced by the provider after a zone is created.  Additional work is required to support modifications to `networks` visibility during `push`, however the API will not permit `visibility` to be modified on an existing zone.
+> `visibility` and `networks` only applies on `create-domains` at the moment. Neither setting is enforced by the provider after a zone is created.  Additional work is required to support modifications to `networks` visibility during `push`, however the API will not permit `visibility` to be modified on an existing zone.
 
 > `networks` may be specified using the network name if the VPC network exists in `project_id`
 

documentation/provider/hedns.md

@@ -82,7 +82,7 @@ This option is disabled by default when this key is not present,
 
 **Security Warning**:
 * Anyone with access to this `.hedns-session` file will be able to use the existing session (until it expires) and have
-  *full* access to your Hurrican Electric account and will be able to modify and delete your DNS entries.
+  *full* access to your Hurricane Electric account and will be able to modify and delete your DNS entries.
 * It should be stored in a location only trusted users can access.
 
 {% code title="creds.json" %}