search

StackExchange / dnscontrol

Infrastructure as code for DNS!
https://dnscontrol.org/
MIT License
3.16k stars 400 forks source link

FEATURE: M365_BUILDER add support for alternative MX hosts #3191

Open ajh0912 opened 2 weeks ago

ajh0912 commented 2 weeks ago

Closes #3185

Could you review and advise if this approach is the right way?

I've added a new example for M365_BUILDER, with all services enabled and using the new mxHost parameter to point to an example DNSSEC enabled MX host.

tlimoncelli commented 2 weeks ago

CC @juliusrickert @nikolamilekic for feedback

nikolamilekic commented 2 weeks ago

@tlimoncelli I wish I could give constructive feedback on this, but I'm not sure I can.

I understand the challenges of supporting complex macros, but at the same time, I highly value the ability to glance at a DNSControl file and quickly get the idea of what is configured and what isn't (and correctly). For complex configurations such as that of M365 (or MTA-STS), I believe it is especially important to have a macro because I only need to read a single line of code and know what it pertains to instead of 20.

I think it will be of enormous help for the adoption of various complex DNS conventions and standards (such as MTA-STS) if there were an easy way to configure them. With the DMARC and SPF builders, DNSControl is already well on the way of becoming just such a tool. Wouldn't it be great if we went all the way? If the cost is community-supported maintenance of complex builders, would that be so bad? I'd much rather place trust on a community of experts to maintain a set of macros, than risk copy/paste mistakes from documentation.

tlimoncelli commented 2 weeks ago

@nikolamilekic

Thank you for taking the time to write up your thoughts.

"Builders" are perhaps one of DNSControl's most unique and powerful features. They are complex to maintain, and I'd like to improve that.

One idea I had was to remove them from the system, so that people can maintain them independently. However I think that just takes a big problem and moves it elsewhere.

I'd rather make them easier to manage:

  1. Testable: Unit tests so we don't break existing use-cases.
  2. Isolated: Isolate the code to 1 place for easier management
  3. Versioned: Either semver or a policy of "no breaking changes until major releases"

I don't know how to do those things in JavaScript, but I do know how to do them all in Go. I have an idea for a way to make it possible to write these in Go, with proper testing, isolation, and versioning.

That's long term. As far as M365_BUILDER, I defer to @juliusrickert and would prefer documentation (rather than major changes) at this time.