Why use this plugin instead of the built in file plugin?

[chrisohaver]

Is it just the "inline" aspect of the configuration? Or are there other features (like the optional SOA?)

If file supported inline configuration, could we deprecate records?

[chrisohaver]

I'd like to consider making file a viable replacement for records.
Benefits:

• less code maintenance: one less coredns org plugin to maintain.
• file is built in to coredns. no need to custom compile with external plugin
• file is more fully featured (e.g. wildcards, dnssec ... and sans currently open PRs, cname/any)

[chrisohaver]

FYI @fuhry

[polarathene]

If file supported inline configuration, could we deprecate records?

Yes?

I originally requested the feature which was implemented as a plugin here, but switched to using file myself (records plugin had trouble with some TXT records IIRC): #1 (comment)

I think originally I just wasn't comfortable with the file format, as information / examples on it wasn't straight-forward (at least at the time?), and since I was supplying a Corefile, having the a few records defined inline seemed simpler? 🤷‍♂️

---

Or are there other features (like the optional SOA?)

IIRC I just wanted to configure CoreDNS to have MX and TXT records (possibly PTR) for a few containers to test mail features with in a local network. SOA, NS, etc was mostly noise via file and more to document.