stackexchange / dnscontrol

Infrastructure as code for DNS!

DNSControl

DNSControl is a system for maintaining DNS zones. It has two parts: a domain specific language (DSL) for describing DNS zones plus software that processes the DSL and pushes the resulting zones to DNS providers such as Route53, Cloudflare, and Gandi. It can send the same DNS records to multiple providers. It even generates the most beautiful BIND zone files ever. It runs anywhere Go runs (Linux, macOS, Windows). The provider model is extensible, so more providers can be added.

Currently supported DNS providers:

• Akamai Edge DNS
• AutoDNS
• AWS Route 53
• AXFR+DDNS
• Azure DNS
• Azure Private DNS
• BIND
• Bunny DNS
• Cloudflare
• ClouDNS
• deSEC
• DigitalOcean
• DNS Made Easy
• DNSimple
• Domainnameshop (Domeneshop)
• Exoscale
• Gandi
• Gcore
• Google DNS
• Hetzner
• HEXONET
• hosting.de
• Huawei Cloud DNS
• Hurricane Electric DNS
• INWX
• Linode
• Loopia
• LuaDNS
• Microsoft Windows Server DNS Server
• Mythic Beasts
• Namecheap
• Name.com
• Netcup
• Netlify
• NS1
• Oracle Cloud
• OVH
• Packetframe
• Porkbun
• PowerDNS
• Realtime Register
• RWTH DNS-Admin
• SoftLayer
• TransIP
• Vultr

Currently supported Domain Registrars:

• AWS Route 53
• CSC Global
• DNSOVERHTTPS
• Dynadot
• easyname
• Gandi
• HEXONET
• hosting.de
• Internet.bs
• INWX
• Namecheap
• Name.com
• OpenSRS
• OVH
• Realtime Register

At Stack Overflow, we use this system to manage hundreds of domains and subdomains across multiple registrars and DNS providers.

You can think of it as a DNS compiler. The configuration files are written in a DSL that looks a lot like JavaScript. It is compiled to an intermediate representation (IR). Compiler back-ends use the IR to update your DNS zones on services such as Route53, Cloudflare, and Gandi, or systems such as BIND.

An Example

dnsconfig.js:

// define our registrar and providers
var REG_NAMECOM = NewRegistrar("name.com");
var r53 = NewDnsProvider("r53")

D("example.com", REG_NAMECOM, DnsProvider(r53),
  A("@", "1.2.3.4"),
  CNAME("www","@"),
  MX("@",5,"mail.myserver.com."),
  A("test", "5.6.7.8")
)

Running dnscontrol preview will talk to the providers (here name.com as registrar and route 53 as the dns host), and determine what changes need to be made.

Running dnscontrol push will make those changes with the provider and my dns records will be correctly updated.

The easiest way to run DNSControl is to use the Docker container:

docker run --rm -it -v "$(pwd):/dns"  ghcr.io/stackexchange/dnscontrol preview

See Getting Started page on documentation site to get started!

Benefits

• Less error-prone than editing a BIND zone file.
• More reproducible than clicking buttons on a web portal.
• Easily switch between DNS providers: The DNSControl language is vendor-agnostic. If you use it to maintain your DNS zone records, you can switch between DNS providers easily. In fact, DNSControl will upload your DNS records to multiple providers, which means you can test one while switching to another. We've switched providers 3 times in three years and we've never lost a DNS record.
• Adopt CI/CD principles to DNS! At StackOverflow we maintain our DNSControl configurations in Git and use our CI system to roll out changes. Keeping DNS information in a VCS means we have full history. Using CI enables us to include unit-tests and system-tests. Remember when you forgot to include a "." at the end of an MX record? We haven't had that problem since we included a test to make sure Tom doesn't make that mistake... again.
• Adopt PR-based updates. Allow developers to send updates as PRs, which you can review before you approve.
• Variables save time! Assign an IP address to a constant and use the variable name throughout the file. Need to change the IP address globally? Just change the variable and "recompile."
• Macros! Define your SPF records, MX records, or other repeated data once and re-use them for all domains.
• Control Cloudflare from a single source of truth. Enable/disable Cloudflare proxying (the "orange cloud" button) directly from your DNSControl files.
• Keep similar domains in sync with transforms and other features. If one domain is supposed to be a filtered version of another, this is easy to set up.
• It is extendable! All the DNS providers are written as plugins. Writing new plugins is very easy.

Installation

DNSControl can be installed via packages for macOS, Linux and Windows, or from source code. See the official instructions.

Via GitHub Actions (GHA)

See dnscontrol-action or gacts/install-dnscontrol.

Deprecation warnings (updated 2024-03-25)

• REV() will switch from RFC2317 to RFC4183 in v5.0. This is a breaking change. Warnings are output if your configuration is affected. No date has been announced for v5.0. See https://docs.dnscontrol.org/language-reference/top-level-functions/revcompat
• MSDNS maintainer needed! Without a new volunteer, this DNS provider will lose support after April 2025. See #2878
• NAMEDOTCOM and SOFTLAYER need maintainers! These providers have no maintainer. Maintainers respond to PRs and fix bugs in a timely manner, and try to stay on top of protocol changes.
• get-certs/ACME support is frozen and will be removed without notice between now and July 2025. It has been unsupported since December 2022. If you don't use this feature, do not start. If you do use this feature, migrate ASAP. See discussion in issues/1400

More info at our website

The website: https://docs.dnscontrol.org/

The getting started guide: https://docs.dnscontrol.org/getting-started/getting-started

Stargazers over time

dnscontrol's Issues

conditional transforms

We need to support some additional logic for our import_transforms at stack.

CURRENT:

var TRANSFORM_DOUBLEINT = [
    {low: NYLO, high: NYLO+40, newBase: [NYINT,COINT] },  
    {low: NYHI, high: NYHI+40, newBase: [NYINT,COINT] },  
    {low: COLO, high: COLO+40, newBase: [NYINT,COINT] }, 
    {low: COHI, high: COHI+40, newBase: [NYINT,COINT] }, 
]

We need to conditionally only use one of the newBase entries for wildcard records.
Logic is essentially:

var TRANSFORM_DOUBLEINT = [
    {low: NYLO, high: NYLO+40, newBase: [NYINT(always),COINT(unless *)] },  
    {low: NYHI, high: NYHI+40, newBase: [NYINT(always),COINT(unless *)] },  
    {low: COLO, high: COLO+40, newBase: [NYINT(unless *),COINT(always)] }, 
    {low: COHI, high: COHI+40, newBase: [NYINT(unless *),COINT(always)] }, 
]

I can see a few different ways to implement this:

1. Hack it in

Just handle all * records as a special case and only emit the first newBase transform.

Quick and easy, but completely inflexible, and a bit "magical"

2. Add a field to each rule, double the rules

var TRANSFORM_DOUBLEINT = [
    {low: NYLO, high: NYLO+40, newBase: [NYINT,COINT], ignore:"*" },  
    {low: NYLO, high: NYLO+40, newBase: [NYINT] },
    {low: NYHI, high: NYHI+40, newBase: [NYINT,COINT] , ignore:"*"}, 
    {low: NYHI, high: NYHI+40, newBase: [NYINT] },  
    {low: COLO, high: COLO+40, newBase: [NYINT,COINT], ignore:"*" }, 
    {low: COLO, high: COLO+40, newBase: [COINT] }, 
    {low: COHI, high: COHI+40, newBase: [NYINT,COINT], ignore:"*" },
    {low: COHI, high: COHI+40, newBase: [COINT] }, 
]

Here each rule can have an ignore field to skip it. Since transforms stop looking at rules once we match one, this should behave as expected.

Cons: our home grown hacky transform format for transforms (~~ soup) is not making this easy. But it can be added in.

Also, is the field a regex? Or just do a contains on it? Regex for wildcard means putting in \* which feels kinda odd. Should it just match on the label, or on the fqdn?

Standardize IPv6 Format

If I make a AAAA record: AAAA("@","2001:0db8:85a3:0000:0000:8a2e:0370:7334"), I can create it in gcloud no problem.

I do always get a modification though: MODIFY AAAA example5555qwerty.com: (2001:db8:85a3::8a2e:370:7334 300) -> (2001:0db8:85a3:0000:0000:8a2e:0370:7334 300)

Because gcloud stores and returns it in the minified format. I propose as part of the validation/normalization phase, we minimize all ipv6 addresses. That will become our "standard" format. If any provider has issue with that, we will handle it in the provider itself.

Support PTR records

Hello,

It'd be nice to be able to use this tool to also create reverse zones. Reverse zones use PTR records which are basically CNAME records. Can we set this up so that PTR records are like CNAME?

Examples are like:

2               IN      PTR     blah1.domain.com.
3               IN      PTR     blah2.domain.com.
4               IN      PTR     blah3.domain.com.
5               IN      PTR     blah4.domain.com.
6               IN      PTR     blah5.domain.com.

Currently it generates this error: ReferenceError: 'PTR' is not defined

Thanks!

Multiple strings in RR value (from convertzone) cause parse failure

Many RR-types which take strings, take N strings, for N >= 1. Eg, the TXT RR-type.

convertzone took a zonefile which had such RR values and made dnsconfig directives which had two sequential strings with no operator between them, which led to a JS parse failure.

In this case, the cause is DKIM keys in TXT records. The below is actual data for the spodhuis.org zone.

I read all the docs I could find before trying the tool and saw nothing describing how to manual multiple strings as part of one RR value. The output from convertzone is not accepted as input into dnscontrol.

% dnscontrol
2017/04/17 20:55:23 main.go:56: Error executing javasscript in (dnsconfig.js): (anonymous): Line 42:280 Unexpected string (and 3 more errors)

% sed -n 42p < dnsconfig.js
	TXT('d201611._domainkey', "v=DKIM1; k=rsa; p=MIG7MA0GCSqGSIb3DQEBAQUAA4GpADCBpQKBnQDJZk8JRPxvefSR/6CWRqgiGQvvtGuFmvIaUuOyVys2TYE61h/8rC6se00NKzN1hU+gJwfw8FKk8l+JhJ/znd9KdIJreu41KzIFIxeWsdYpcbwvTGYzfdbWifqNrgFa4l/D6Nicreh2/hT5aI121167qoZ6fgBRWFZ5vKXJoRHtGoqOX8qCLBBGUDz7ZaujVfI" "KQ1oU26fnLa2etlkCAwEAAQ==", TTL(7200)),

Determine corrections in parallel

dnscontrol is slow when there are many domains because they are processed sequentially. It should be possible to gather all the information related to what corrections are needed in parallel. (Updates should be done serially, at least initially.)

Support Route53 as a registrar

Error creating registrars: Registrar type ROUTE53 not declared.
Self explanatory?
We just recently moved to r53, so this would be nice.

Since I have been wanted to learn Go, this may be a good chance for me, but Im not sure when I would be able to start this, in case someone else is capable of doing this faster/before I can start learning

Should we support ALIAS records?

Some providers support an ALIAS or ANAME record type that acts like a CNAME, but converts it dynamically to an A or AAAA record at dns request time.

The primary use case I believe is allowing a CNAME type record at the zone apex where it is not usually allowed.

R53, DME, and DNSimple, and CF support them natively, while others do not at the moment.

Proposal:

1. Add an ALIAS( name, aliasDomain) record type.

2. Add some mechanism for a provider to indicate it supports these records (perhaps by implementing interface { SupportsAlias() bool }).

3. At validation time, check if you use ALIAS records with a non-supporting provider, and error if so.

4. Potentially add some "override" metadata, to resolve the name at "compile time" and use that A and/or AAAA records instead for non-supporting providers. This would be a one-time lookup, but could still "work" in a way. Perhaps you run dnsconrtol on a cron job to keep it updated it or something. I would want to use something like ALIAS("@", "otherdomain.com", { lookup_on_build: true}) to make sure you are really ok with that behaviour. (name negotiable).

Concerns:

1. Inconsistent experience if using some supporting providers and some non-supporting. Dual host setups could end up with divergent zones.

2. Is this feature even needed? I do think CNAME apex records could be valuable, but don't want to do it if nobody will use it.

3. Is "compile time" lookup a horrible idea in general?

Gandi MX priority not diffed properly.

ALIAS record doesn't work with cloudflare_proxy

D("fir.sh", REG_NONE, DnsProvider(CFLARE),
  ALIAS('@', 'fir.sh.s3-website-us-east-1.amazonaws.com.', {"cloudflare_proxy": "ON"}),
...

throws:

$ dnscontrol preview
...
******************** Domain: fir.sh
----- Getting nameservers from: cloudflare.com
----- DNS Provider: cloudflare.com... ERROR
Error getting corrections: cloudflare_proxy set on ALIAS record: "@" cloudflare_proxy="ON"
...

Gandi does not allow setting apex NS records

Need to remove ns records from desired config like we do for nam.com/cloudflare.

Show warning if they are for non-gandi.

DSL does not properly validate function arguments.

I'm a little fuzzy on why this would be happening, but it seems like a possible bug in the route53 provider.

I have a MX record for a subdomain subdomain, i.e. [email protected] that should point to A record of mail4.example.com.

Using either:

MX('department', 'mail4', TTL(600))

or...

MX('department', 'mail4.example.com.', TTL(600))

... it ends up in Route 53 with a recordset value of:

0 example.com.

If I manually change the record in Route 53 to mail4 or mail4.example.com., dnscontrol picks up the change difference and changes it back to example.com., so it seems like an issue in the dnscontrol Route 53 provider.

Implement AD record deletion

Multiple TXT records in apex causes panic

Having two apex TXT records causes a panic. e.g. the following config:

TXT('@','google-site-verification=abcd1234'),
TXT('@','google-site-verification=wxyz9876'),

causes panic:

panic: interface conversion: interface {} is nil, not *models.RecordConfig

goroutine 1 [running]:
panic(0xa0e120, 0xc0422be1c0)
        /usr/local/go/src/runtime/panic.go:500 +0x1af
github.com/StackExchange/dnscontrol/providers/namedotcom.(*nameDotCom).GetDomainCorrections(0xc0424d1420, 0xc04226c3f0, 0xc0426f17b0, 0xf, 0xc042380658, 0x1, 0x0)
        /go/src/github.com/StackExchange/dnscontrol/providers/namedotcom/records.go:44 +0x98c
main.main()
        /go/src/github.com/StackExchange/dnscontrol/main.go:184 +0x1051

Bind driver returning 0 for all TTLs

Any zone that uses the Active Directory driver is returning a 0 for the TTL when reading the zone for diffing. This results in all the AD records being replaced every time dnscontrol is run.

E.g: [Step 1/1] MODIFY A example.com: (10.7.3.28 0) -> (10.7.3.28 300)

Support Gandi as a registrar

It is claimed to be supported, but doesn't seem to actually be implemented. See also #85.

PURGE and NO_PURGE should be respected by all providers

a required parameter to the central diff routine should do pretty good at ensuring each provider respects the flag.

Document a checklist for new providers

Document a checklist of things that make a new provider "complete". I can think of a few things.

1. Write the provider itself (either Registrar, DnsProvider, or bot)
2. Add the provider to https://stackexchange.github.io/dnscontrol/provider-list
3. Add the provider to the bullet list on https://github.com/StackExchange/dnscontrol

Set name servers and NS records dynamically to handle multiple providers better

Case 0: Don't talk to the Registrar

No NAMESERVER() or NAMESERVERS_FROM() directives exist in the zone.

NS() directives may be part of the zone and generate NS records, but these are not communicated to the Registrar.

Case 1: Set static name servers at the Registrar.

NAMESERVER() directives will generate NS records into the zone, and those named servers will be communicated to the Registrar to be the "registered name servers".

NS() directives may be part of the zone and generate NS records, but these are not communicated to the Registrar.

NOTE: Currently NAMESERVER() does not inject NS records into the zone. This is new functionality.

Case 2: Set dynamic name servers at the Registrar.

NAMESERVERS_FROM(DSP_foo) directives will query DSP_foo for the names of the name servers to be used for this zone. For each server, an NS record will be injected into the zone, and it will be be communicated to the Registrar as a "registered name servers".

NS() directives may be part of the zone and generate NS records, but these are not communicated to the Registrar.

NOTE: This requires a new pass done prior to the current processing: Loop through each domain looking for NAMESERVER_FROM() directives. For each, ask the DSP for a list of name servers to be used for this zone. For each server, an NS record will be injected into the zone, and it will be be communicated to the Registrar as a "registered name servers".
(In other words, a NAMESERVER_FROM() is equivalent to performing the query and generating a NAMESERVER() directive for each answer in the query.)

NOTE: The "BIND" DSP can not be queried via an API. Instead, the list of name servers should be taken from the meta data.

Case 3: Mixture of static and dynamic name servers are set at the Registrar.

NAMESERVER() and NAMESERVERS_FROM() directives are included. Each does its thing, adding to the name servers set at the Registrar. There should be no conflict.

NS() directives may be part of the zone and generate NS records, but these are not communicated to the Registrar.

Easier Getting Started guide

It dawned on me that boostrapping with dnscontrol would be a lot easier if we provided a walk-through that first only used the BIND provider (making the creds.json file much easier to create). Then it would walk through adding an API-based provider.

Along the way it should include ways to check your json file. Suggestion: jq or run the built-in checked in Python:

echo '{"json":"obj", }' | python -m json.tool

Powershell should check if elevated

getzones_windows.go:16 should be preceeded by a command that checks to see if PowerShell is being run with elevated privileges (administrator) and should warn the user accordingly.

activedirectory: Add-DnsServerResourceRecord should include the -TimeToLive flag

Creating DNS records via the ActiveDirectory driver should set the TTL:

Add-DnsServerResourceRecordA -ComputerName "ny-dc01" -ZoneName "internal" -Name "pingdomcheck.stackoverflow.com" -IPv4Address "10.10.10.10" -TimeToLive 123

It should only be included if the TTL value is non-zero and not 300 (or the default TTL for this zone).

Support the DS record type

Issues I see up front:

1. not all DNS providers support all record types.

2. The object model (e.g. RecordConfig) doesn't have fields for the extra data; it only understands Priority (for MX and SRV records). I'm not convinced you can treat the entire record as opaque data; some DNS providers want text strings instead of protocol numbers for the 'algorithm' and 'digest type' fields of a DS record, for example.

Dyn

Dyn is pretty big and would be nice to have support. <3

If nobody is inclined, I may dig deeper into the code and see if I can implement this myself.

Are IMPORT_TRANSFORM cnames wrong

Currently if I do:

D("old.com",...
  CNAME("c", "google.com.")
)
D("new.com",...,IMPORT_TRANSFORM("foo.com"))

I will end up with:

CNAME c.old.com.new.com. -> google.com.new.com.

But nowhere else is that record defined in an A record or anything because it is outside the zone.

I'm wondering if the behaviour for CNAMES should first check if the cname is a FQDN outside the old zone, and if so, do nothing to it at all.

That would give us instead:

CNAME c.old.com.new.com. -> google.com.

Better validation of CNAME record mutual exclusion

Writing this down so I don't forget about it. Low priority.

Per all the rfcs, CNAME records should be the ONLY record for any given label. No other records of any type should be created with the same name as a CNAME.

We have had confusion with various providers accepting them inconsistently, or giving unhelpful errors if you try.

We may want to do a pre-pass to make sure CNAMES are the only records for their names and give a clear warning (or fail hard) if you try to.

Apex CNAMES are technically valid, but require extra care as well. Technically you should not have any other records at all if you use one. Perhaps we should not allow them at all? Or require some extra validation to make one? With Gcloud, for example, we would need to remove ALL records (including the NS records) for google to even accept an apex CNAME. This kinda requires special code just for this case. Is it one we even care to support, or should we explicitly disallow it?

Allow import from providers

It would be nice to be able to create a dnsconfig.js (or maybe a separate file) from the providers. This would allow people to jumpstart their configuration instead of having to manually convert zone files or configurations from their providers.

Stumbling when attempting to follow the documentation

This project seems like an AMAZING solution for a common problem and one that is definitely affecting me @ work. I'm not the best programmer and have no experience with Go, though, and having some trouble following the documentation.

From the provided examples, when attempting to do a basic update to a Route53 zone:

[root@dflgnvweby0 a]# cat dnscontrol.js 
var registrar = NewRegistrar("name.com", "NAMEDOTCOM");
var route53 = NewDnsProvider("route53", "ROUTE53");


D("aws.thig.com", registrar, DnsProvider(route53),
    A("image101", "10.9.1.101"),
    A("image102", "10.9.1.102")
);

[root@dflgnvweby0 a]# cat providers.js
{
  "route53":{
    "KeyId": ";sdklfja;sdfjasdlfjasldfj",
    "SecretKey": "not_anything_real"
  }
}
{
  "name.com":{
    "apikey": "yourApiKeyFromName.com-klasjdkljasdlk235235235235",
    "apiuser": "yourUsername"
  }
}
[root@dflgnvweby0 a]# ./dnscontrol-Linux -js dnscontrol.js -creds providers.js preview
2017/03/17 08:52:56 main.go:117: Error creating registrars: Registrar name.com not listed in -providers file.
[root@dflgnvweby0 a]# 
[root@dflgnvweby0 a]# ./dnscontrol-Linux -js dnscontrol.js -providers providers.js preview
2017/03/17 08:54:56 main.go:113: error loading provider configurations: While reading provider credentials file creds.json: open creds.json: no such file or directory

Some other questions:

D
What is the default location for dnsconfig.js and providers.json (I've tried same folder, GOPATH, some other various folders, it only seems to work when I provide the arguments -js and -creds??)
What is creds.json? is that the same as providers.json? What would be in one as opposed to the other?

Would it be possible to have some more working real world examples?

Thanks again in advance, I'm really looking forward to using this tool...

gcloud: Use service account for API access

Rather than setting up OAuth the odd way we're doing it now, it would be better to use Google's Service Accounts to authenticate: https://support.google.com/googleapi/answer/6158849?hl=en#serviceaccounts

• You receive a private key which is stored in JSON (which would need to be stored in creds.json)
• The following GoLang code will give you a HTTPClient that can be used for the rest of the API work:

	rawConfig, err := ioutil.ReadFile("./jsoncreds.json")
	if err != nil {
		panic(err)
	}
	config, err := google.JWTConfigFromJSON(rawConfig, "https://www.googleapis.com/auth/ndev.clouddns.readwrite")
	if err != nil {
		panic(err)
	}
	ctx := context.Background()
	hc := config.Client(ctx)

• No more setup with refresh keys or manual authorisation against a google account

Allow IMPORT_TRANSFORM records to override ttl

Add a third parameter to IMPORT_TRANSFORM in helpers.js for ttl. If set, set ttl on the import transform record.

When applying import transforms, respect that ttl and override any ttl on the source records.

Support passing the intermediate JSON as a command line parameter?

So I already have my own internal project that generates DNS zones using a DSL in Ruby. It outputs bind files currently, but I heard about DnsControl and thought I might be able to reuse it's providers support.

Support SRV records

The title basically says it - dnscontrol should support SRV records

Add support for NS1

Just wanted to add this to the Dyn requst, as another common T2 provider.

• https://ns1.com/pricing#managed has a free tier
• https://ns1.com/integrations lots of integrations
• Full api support and https://github.com/ns1 own libraries

ActiveDirectory: NS records always cause corrections.

Active directory driver skips NS record creations, but still generates corrections for them. We should make sure to catch them earlier. Our build is currently stuck giving "4 corrections" because of this issue.

Purely cosmetic, but should be fixed.

convertzone build fails

On current master, go build for convertzone fails with:

$ go build
# _/home/erik/src/dnscontrol/misc/convertzone
./main.go:73: cannot use l (type []"github.com/miekg/dns".RR) as type []"github.com/StackExchange/dnscontrol/vendor/github.com/miekg/dns".RR in argument to bind.WriteZoneFile

I do have https://github.com/miekg/dns and https://github.com/pkg/errors installed as required, but I'm afraid I don't grok golang enough to further troubleshoot this.

Thanks for any insight you can provide!

DNSSEC Discussion

Just started thinking about this and wanted to write down notes for the future.

One thing I think would be interesting for DNSControl to manage would be DNSSEC records. This really has two parts:

1. DNS Provider needs to implement it. This involves managing keys, generating RRSIG records and so forth.
2. Registrar needs to register the DS record(s) with the tld nameservers.

I would love for dnscontrol to be able to activate DNSSEC for a domain with minimal effort required.

A few issues I foresee:

• Provider support is fairly limited.

  Of the registrars we support, gandi has an api. name.com has functionality in the web ui, but no api. route53 as a registrar supports dnssec, but not as a dns provider.

  As far as DNS providers go, gcloud has alpha support, gandi appears to support it, cloudflare has some sort of support, and all others seem to not. We could certainly do it for the bind provider with some work.

• Multiple providers

DNSSEC would definitely not work unless all providers for a zone support it. If they do, I believe they can all use a separate key, and we can add multiple DS records via the registrar.

Most cloud providers provide only a "just turn it on" model where they maintain all the keys and just give you the DS info to give the registrar.

• Key management

Bind may or may not be worth implementing anything for. Maybe the keys live on the actual server, and part of the process of deploying zonefiles is using dnssec-signzone or something.

Provider request: Azure DNS

The docs are at https://docs.microsoft.com/en-us/azure/dns/ and there's a GO SDK which looks to have DNS support at Azure/azure-sdk-for-go

I don't have the time right now to try adding this in, but if someone else does I can help test it out.

Support NS TTL customization?

This project is awesome, thanks for making it public.

I'm not seeing a way to set a TTL for a nameserver record. Not a on delegated zone, but the NS records for the domain in D(). The hard-coded default of 300 is all I can get.

This is what I think is the case, but I hope there is a way that I'm not seeing:

NAMESERVER('blah.', TTL(86400)), // TTL ignored
DEFAULTS(DefaultTTL(86400)); // doesn't apply to NS records set by NAMESERVER()
D(DefaultTTL(86400)); // ditto

Am I doing it wrong?

Thanks! Eli

Allow ttl to be specified as duration string.

Currently we expect DefaultTTL(3000) or TTL(100) with only numbers.

Would be cool if you could do DefaultTTL("4h") instead and defer to go's ParseDuration.

Route53 should not require explicit key ID/access key, as there are other credential sources

The AWS SDK can find credentials from local profiles (AWS_PROFILE env var), instance profiles, and/or environment variables. Right now it seems the R53 provider code deliberately requires passing in the credentials, which makes it impossible to use any other credential source.

AFAIK the recommended way to deal with credentials is to pass them if they are explicitly defined, but not care at all otherwise and let the SDK handle things. If no valid credentials actually exist API calls will simply fail with lack of authorization.

BIND provider: Using DefaultTTL() adds a TTL to each record instead of changing $TTL

Using the BIND provider, if we set DEFAULTS( DefaultTTL(60000) ); or adding DefaultTTL(60000), to the D( I would expect the $TTL to change in the resulting .zone file, instead a TTL is added to each record. This seems like incorrect behavior. $TTL is always 300 (which I believe is being pulled from https://github.com/StackExchange/dnscontrol/blob/master/models/dns.go#L18 )

Allow splitting of config into multiple files

From twitter:

@Nick_Craver with dnscontrol is there a recommended approach for a global.js (providers/vars) + a single .js file for each domain?

— Brandon Potter (@BrandonPotter) March 20, 2017

I agree this might be a useful feature. Currently the javascript is processed by the following process, using https://github.com/robertkrimen/otto as its javascript interpreter:

1. Load and run the built in code from helpers.js.
2. Load and run your user code from dnsconfig.js.
3. Run a small script to jsonify and dump your config object to be read in go.

It may be possible to have some kind of built in mechanism for combining / importing other js files if your config is large and complicated.

Possibly require("otherfile.js") or import("otherfile.js"). It would simply act as string replacement, replacing the import statement with the contents of the specified file before running.

This is not a commitment to implement this, only a place for discussion. Please state cases for or against such a scheme.

Gandi provider should validate TTL max 2592000

Gandi does not permit TTLs larger than 30 days. We should detect this problem on validation, not during "push":

FAILURE! error: "Error on object : OBJECT_DNS_RECORD (CAUSE_BADPARAMETER) [2629800 is greater than maximum value 2592000]" code: 581137

panic: runtime error: invalid memory address or nil pointer dereference

TEST JS.

var registrar = NewRegistrar("none","NONE");
var r53 = NewDnsProvider("r53", "ROUTE53");

D("test.net", registrar, DnsProvider(r53),
A("test","10.160.40.22")
);

Running:

dnscontrol -providers all -js ../config/test_com.js -creds ../config/creds.js -bindtree ../zones

RESULTS

Initialized 1 registrars and 1 dns service providers.
******************** Domain: test.net
----- Getting nameservers from: r53
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x15aef1b]

goroutine 1 [running]:
github.com/StackExchange/dnscontrol/providers/route53.(*route53Provider).GetNameservers(0xc420295160, 0xc420294b60, 0x10, 0x3, 0xc42017bca8, 0x1, 0x0, 0x0)
/gocode/src/github.com/StackExchange/dnscontrol/providers/route53/route53Provider.go:102 +0x13b
github.com/StackExchange/dnscontrol/nameservers.DetermineNameservers(0xc42001e310, 0x0, 0xc42036f7a0, 0x1, 0x1, 0x2e, 0x0, 0x0)
gocode/src/github.com/StackExchange/dnscontrol/nameservers/nameservers.go:29 +0x239
main.main()
gocode/src/github.com/StackExchange/dnscontrol/main.go:161 +0x91c

Validate CNAME targets (check for "/")

The target of a CNAME, MX, and NS record should be validated to make sure there are no slashes in it. For some reason, this cut-and-paste error seems to happen a lot:

CNAME('support', 'elb21.freshdesk.com/.'),

NOTE: There should be no "/" in that target.

This should be detected at the "preview" stage, not "push" stage.

CC: @captncraig @GABeech

Namecheap registrar provider making changes during preview?

When strictly running my config with dnscontrol preview, I get an alert from Namecheap that my nameservers have been updated. Is this expected?

Actually log powershell output

Provider request: ClouDNS

Another provider i seem to have setup is one called ClouDNS. they have an API which seems to do all the stuff required... Might take a stab at doing this myself, but just adding it here is case anyone else knows anything about it...

createdomains does not work for cloudflare

if you run dnscontrol on a domain that you want hosted on cloudflare, but is not actually there, create-domains will not create it.

Test issue plz ignore

Testing gitter

Default creds file name (docs mismatch)

In dnscontrol-Linux version: dnscontrol 0.1.0 (c52ff67386750e96138fe78f0631d757f928f452) built 14 Mar 17 00:32 UTC (current latest compiled release)

Everything in the utility (help text etc) defaults to creds.json, documentation indicates providers.json is default. https://github.com/StackExchange/dnscontrol/blob/master/docs/getting-started.md