| Status | (Proposed / Accepted / Implemented / Obsolete) |
|---|---|
| RFC # | NNN (update when you have RFC PR #) |
| Author(s) | My Name (@my-github-id), Another Name (@your-github-id) |
| Sponsor | A CoreDNS Maintainer (@github-id), Another Maintainer (@github-id) |
| Updated | YYYY-MM-DD |
| Obsoletes | Replaced by RFC NNN, or not being worked on |
What are we doing and why? What problem will this solve? What are the goals and non-goals? This is your executive summary; keep it short, elaborate below.
Why this is a valuable problem to solve? Why is it related to CoreDNS? Can this be done outside the scope of CoreDNS?
Which place will this proposal live in? A default plugin in CoreDNS repo, a separate repo in CoreDNS org, or a external repo maintained outside of CoreDNS org? Note exteranl repo maintained outside of CoreDNS org does not need a RFC.
This is the meat of the document, where you explain your proposal. If you have multiple alternatives, be sure to use sub-sections for better separation of the idea, and list pros/cons to each approach. If there are alternatives that you have eliminated, you should also list those here, and explain why you believe your chosen approach is superior.
Make sure you’ve thought through and addressed the following sections. If a section is not relevant to your specific proposal, please explain why, e.g. your RFC addresses a convention or process, not an API.
- Make sure to discuss the relative merits of alternatives to your proposal.
Seed this with open questions you require feedback on from the RFC process.