diff options
author | 2017-06-13 00:58:13 +0100 | |
---|---|---|
committer | 2017-06-13 00:58:13 +0100 | |
commit | b1efd3736e6e68ab01baf54f83071c62690899b2 (patch) | |
tree | a0337dbfc2721ed450455d2c49853ad76d3b99a4 | |
parent | f32dcf2817a7e0a300ac5d99be001302fb044951 (diff) | |
download | coredns-b1efd3736e6e68ab01baf54f83071c62690899b2.tar.gz coredns-b1efd3736e6e68ab01baf54f83071c62690899b2.tar.zst coredns-b1efd3736e6e68ab01baf54f83071c62690899b2.zip |
Doc updates (#708)
A somewhat longer living PR to group documentation updates
-rw-r--r-- | middleware.md | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/middleware.md b/middleware.md index 5da1357fd..ee4181c2b 100644 --- a/middleware.md +++ b/middleware.md @@ -140,6 +140,7 @@ repos work just as well. So when do we consider the inclusion of a new middlewar * First, the middleware should be useful for other people. "Useful" is a subjective term. We will probably need to further refine this. +* It should be sufficiently different from other middleware to warrant inclusion. * Current internet standards need be supported: IPv4 and IPv6, so A and AAAA records should be handled (if your middleware is in the business of dealing with address records that is). * It must have tests. |