fallthrough: make clear this is a bad idea

Update the docs to reflect what's in the docs of
plugins/pkg/fallthrough.

Closes: #4545

Signed-off-by: Miek Gieben <miek@miek.nl>
This commit is contained in:
Miek Gieben
2021-06-16 22:06:45 +02:00
parent 6cbd6fdb1f
commit 57c3835e20

View File

@@ -125,12 +125,16 @@ In this example the *file* plugin is handling all names below (and including) `e
a query comes in that is not a subdomain (or equal to) `example.org` the next plugin is called. a query comes in that is not a subdomain (or equal to) `example.org` the next plugin is called.
Now, the world isn't perfect, and there are may be reasons to "fallthrough" to the next plugin, Now, the world isn't perfect, and there are may be reasons to "fallthrough" to the next plugin,
meaning a plugin is only responsible for a *subset* of names within the zone. meaning a plugin is only responsible for a *subset* of names within the zone. But this is a very
dangerous route to take, because the multiple sources can have very different ideas on what names
exist, this can confuse caches and resolvers.
The `fallthrough` directive should optionally accept a list of zones. Only queries for records The `fallthrough` directive should optionally accept a list of zones. Only queries for records
in one of those zones should be allowed to fallthrough. See `plugin/pkg/fallthrough` for the in one of those zones should be allowed to fallthrough. See `plugin/pkg/fallthrough` for the
implementation. implementation.
Use this directive should be a last resort and is almost never needed (nor a good idea).
## Mutating a Response ## Mutating a Response
Using a custom `ResponseWriter`, a plugin can mutate a response when another plugin further down the chain writes the response to the client. Using a custom `ResponseWriter`, a plugin can mutate a response when another plugin further down the chain writes the response to the client.