file plugin does not answer "ANY" requests

[jpicht]

Version: CoreDNS-1.6.4 (b139ba3-dirty) via docker.io/coredns/coredns:latest with Corefile

When I set up the file plugin (or the auto plugin) queries for "ANY" records are answered by SOA only. I have no idea if this is by design. When I use the same zone files with bind9, I get the result I would expect: all records matching the name.

I put together a small testcase (using docker) in a git repo.

I dug into the sources and found this line in the lookup code, that explains the behavior: only records matching the "ANY" type would be returned. This does not seem very intentional.

Maybe it could be fixed by changing the lookup like this

diff --git a/plugin/file/lookup.go b/plugin/file/lookup.go
index 3d8d899d..319ca556 100644
--- a/plugin/file/lookup.go
+++ b/plugin/file/lookup.go
@@ -153,11 +153,16 @@ func (z *Zone) Lookup(ctx context.Context, state request.Request, qname string)
        // Found entire name.
        if found && shot {
 
-               if rrs := elem.Type(dns.TypeCNAME); len(rrs) > 0 && qtype != dns.TypeCNAME {
+               if rrs := elem.Type(dns.TypeCNAME); len(rrs) > 0 && qtype != dns.TypeCNAME && qtype != dns.TypeANY {
                        return z.externalLookup(ctx, state, elem, rrs)
                }
 
-               rrs := elem.Type(qtype)
+               var rrs []dns.RR
+               if qtype == dns.TypeANY {
+                       rrs = elem.All()
+               } else {
+                       rrs = elem.Type(qtype)
+               }
 
                // NODATA
                if len(rrs) == 0 {

testcase

diff --git a/plugin/file/lookup_test.go b/plugin/file/lookup_test.go
index 71004397..8dba6bbf 100644
--- a/plugin/file/lookup_test.go
+++ b/plugin/file/lookup_test.go
@@ -12,6 +12,13 @@ import (
 )
 
 var dnsTestCases = []test.Case{
+       {
+               Qname: "www.miek.nl.", Qtype: dns.TypeANY,
+               Answer: []dns.RR{
+                       test.CNAME("www.miek.nl.        1800    IN      CNAME   a.miek.nl."),
+               },
+               Ns: miekAuth,
+       },
        {
                Qname: "www.miek.nl.", Qtype: dns.TypeA,
                Answer: []dns.RR{

I only looked at the straight forward code path, not at wildcards or anything, so there is probably a bit more to do, if the desired behavior is to return the same data bind9 does.

[miekg]

[ Quoting <notifications@github.com> in "[coredns/coredns] file plugin does ..." ]

Version: CoreDNS-1.6.4 (b139ba3-dirty) via docker.io/coredns/coredns:latest with [Corefile](https://github.com/jpicht/coredns-file-not-returning-any/blob/master/config/Corefile) When I set up the file plugin (or the auto plugin) queries for "ANY" records are answered by SOA only. I have no idea if this is by design. When I use the same zone files with bind9, I get the result I would expect: all records matching the name.

No this was not intentional, but, in fact, goes not against any standard. Also in light of https://tools.ietf.org/html/rfc8482 this actually doesn't seem too bad either. /label: plugin/file /label: dns

[jpicht]

First: I personally agree.

But I have a problem with this behavior: the VMWare SDDC installer verifies that the DNS is set up "correctly" by querying forward and reverse. It uses ANY requests for both 😲

I consider that to be a bug on their end, but they seem to be content with "it works fine with windows" 😫

I was hoping to just enable ANY requests on our CoreDNS server and be done with it, but now I ran into this behavior. I think it should either be documented, that ANY is not implemented in file/auto/hosts/maybe more, or be implemented. The presence of the "any" filter plugin suggests to me that it is implemented in the other plugins.

[miekg]

[ Quoting <notifications@github.com> in "Re: [coredns/coredns] file plugin d..." ]

First: I personally agree. But I have a problem with this behavior: the VMWare SDDC installer verifies that the DNS is set up "correctly" by querying forward and reverse. It uses ANY requests for both 😲 I consider that to be a bug on their end, but they seem to be contend with "it works fine with windows" 😫 I was hoping to just enable ANY requests on our CoreDNS server and be done with it, but now I ran into this behavior. I think it should either be documented, that ANY is not implemented in file/auto/hosts/maybe more, or be implemented. The presence of the "any" filter plugin suggests to me that it is implemented in the other plugins.

I think, in the end, it would be good to fix this, but *exactly* what ANY should return is not completely defined. With the *any* plugin we already have a way to block and minimize ANY responses so would should be fine from a amplication attack. You had some code already that fixes this? Might be worth turning that into a proper PR. *Obviously* VMWare doesn't understand DNS at all :/ /Miek

…

-- Miek Gieben

[johnbelamaric]

If all they look for is a reply that is not NXDOMAIN, if you enable the any plugin, don't we automatically respond with HINFO or TXT or something for every ANY query? Or you could rewrite any queries.

…

On Tue, Oct 29, 2019 at 12:38 AM Miek Gieben ***@***.***> wrote: [ Quoting ***@***.***> in "Re: [coredns/coredns] file plugin d..." ] >First: I personally agree. > >But I have a problem with this behavior: the VMWare SDDC installer verifies that the DNS is set up "correctly" by querying forward and reverse. It uses ANY requests for both 😲 > >I consider that to be a bug on their end, but they seem to be contend with "it works fine with windows" 😫 > >I was hoping to just enable ANY requests on our CoreDNS server and be done with it, but now I ran into this behavior. I think it should either be documented, that ANY is not implemented in file/auto/hosts/maybe more, or be implemented. The presence of the "any" filter plugin suggests to me that it is implemented in the other plugins. I think, in the end, it would be good to fix this, but *exactly* what ANY should return is not completely defined. With the *any* plugin we already have a way to block and minimize ANY responses so would should be fine from a amplication attack. You had some code already that fixes this? Might be worth turning that into a proper PR. *Obviously* VMWare doesn't understand DNS at all :/ /Miek -- Miek Gieben — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3405?email_source=notifications&email_token=ACIHRM3PFITV7XIB2Y2BBY3QQ7R5TA5CNFSM4JFTGRB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECPQYMI#issuecomment-547294257>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACIHRM7MOQUOHRLUXUXE3RDQQ7R5TANCNFSM4JFTGRBQ> .

[chrisohaver]

... or if the response needs to be something more specific, the template plugin might work.

[chrisohaver]

Nevermind - apparently the template plugin uses the word "ANY" to be a wildcard - so you cannot create a template for type == ANY ...

[miekg]

@jpicht can you propose your fix as a PR (with a test) ?. Thanks!

[jpicht]

@jpicht can you propose your fix as a PR (with a test) ?. Thanks!

Will do, but may take a few more days still. I'm really busy at the moment.

[jpicht]

I've implemented it, including a test case. While testing it, I became aware that this change introduces a 10% performance hit on simple lookups.

While investigating what caused this regression, I found that a few simple changes to https://github.com/miekg/dns could shave nearly 50% off the lookup process, so making it 10% slower doesn't seem like a big deal?

Should I try to improve the performance in-place or just create two pull requests, one for this change and one for the dns library?

[jpicht]

Afterthought: I could add a compile-time switch to restore the previous behavior, thus creating a possibility to gain back those 10% if necessary.

[miekg]

[ Quoting <notifications@github.com> in "Re: [coredns/coredns] file plugin d..." ]

I've [implemented it](https://github.com/jpicht/coredns/tree/issue-3405), including a test case. While testing it, I became aware that this change introduces a 10% performance hit on simple lookups. While investigating what caused this regression, I found that [a few simple changes](https://github.com/jpicht/dns/tree/label-speedup) to https://github.com/miekg/dns could shave nearly 50% off the lookup process, so making it 10% slower doesn't seem like a big deal? Should I try to improve the performance in-place or just create two pull requests, one for this change and one for the dns library?

please split it up and send to PR to miekg/dns as well. thanks!

[jpicht]

I've opened miekg/dns#1039 for the DNS library.

I had the idea, that this ANY implementation could be separate from the actual backend-plugin and created this proof of concept plugin code: https://github.com/jpicht/coredns/tree/anyplex/plugin/anyplex

It just rewrites ANY-queries to configurable other query types and then merges the results. The code does need more work, tests, documentation etc. also the name is questionable, but this approach would only introduce query latency for people who actually need that feature.

[miekg]

[ Quoting <notifications@github.com> in "Re: [coredns/coredns] file plugin d..." ]

I've opened miekg/dns#1039 for the DNS library. I had the idea, that this ANY implementation could be separate from the actual backend-plugin and created this proof of concept plugin code: https://github.com/jpicht/coredns/tree/anyplex/plugin/anyplex It just rewrites ANY-queries to configurable other query types and then merges the results. The code does need more work, tests, documentation etc. also the name is questionable, but this approach would only introduce query latency for people who actually need that feature.

I considered that as well, but just doing it in the *any* plugin: #3445 Just using HINFO and asking the backend sounds like an excellent idea.

[miekg]

/duplicate #3445