transfer to must include * destination

[Isolus]

I want to restrict zone transfers (with the file middleware) to specific secondary servers. At the moment I can only allow all servers (* is present in the list) or none (* is not present). The function TransferAllowed in zone.go seems to be incomplete.

I think rewriting it shouldn't be that hard but the TransferTo slice of Zone includes only strings so I have to parse them again. That seems unnecessary. So wouldn't it be better to have a slice of structs with IP, IPNet (to support CIDR notation) and Port?

[miekg]

Yes, we need this. The reason this was not done is that it needs a language that allows you to specify various aspects of networks and/or TSIG keys. It also needs to be similar enough to the (non-specified) language of the rewrite middleware (and maybe other middlewares).

@johnbelamaric do you have an idea for a language here?

[johnbelamaric]

Ok, this may be overkill, but as I see it this ties into the policy work we (Infoblox) are doing. This is just another example of policy. We want to be able to create policies that control who can request what. Those policies need to be external from the code for sure, but also possibly from the Corefile itself, allowing them to change at runtime without restarting CoreDNS.

Currently the policy work is internal, but we will either be open sourcing it or joining https://openpolicyagent.org and bringing it there. Planning to make that decision ASAP.

Some example policy questions could be:

• Who can access a given server (i.e., ACLs)?
• Who can transfer what zones?
• Can a client from Kubernetes namespace X lookup a record in namespace Y (i.e., multi-tenancy)?
• Similarly, if a client in K8s namespace X does a wildcard query (*.*.svc.cluster.local), what records should be returned? Only X or others too?
• Can a query with some specific EDNS0 option lookup some specific record?
• Should a given query be resolved normally or should the resolved IP be changed (i.e., redirection)?
• Which of several possible IPs should be returned for a given query?

This provides the functionality of RPZ plus way, way more. I currently have an integration here: https://github.com/johnbelamaric/coredns/tree/policy-middleware that integrates with this internal (to-be-open-sourced) prototype policy engine we have. It lets you externalize the policies into YAML files. Right now it is a middleware that allows you to enable checks on a per query basis. In theory it could support all use cases above, though for ACLs we may want something more specialized.

This current implementation is a completely external system accessed via gRPC. But we could also embed some of this to allow putting policy definitions into the Corefile and applying them locally without making external calls.

Now, that said...we could also consider having a simple policy language internally that can be used across different middleware, while still offering something like this for the more complex use cases.

[miekg]

Thanks for that update @johnbelamaric. OPA looks nice, but the language (from what I saw) is quite verbose (and powerful). Slight hesitation from my side to include such a framework by default (as opposed to a middleware) as the acl language of CoreDNS.

I'll double check what nsd, bind and powerdns use.

[johnbelamaric]

Yes, it's probably best as a middleware. We may want a simple built-in policy middleware that just does basic stuff; then these other things would be used for complex stuff.

[miekg]

Yes! (Only now I see the light). The lightweight policy stuff also needs to be a middleware, which bascially means the transfer to * and friends need to be removed from here and live in their own contained middleware. Ohhh. Nice! :-)

[miekg]

Well, we still need specify where and how (tsig or not) to transfer to and from. But the acl business can be moved elsewhere.

[miekg]

NSD:

key:
   name: "sec_key"
   algorithm: hmac-md5
   secret: "6KM6qiKfwfEpamEq72HQdA=="

zone:
    name: home.lan
    zonefile: home.lan.forward
  # notify: 10.0.0.222@53 sec_key
  # provide-xfr: 10.0.0.222 sec_key

(Glanced at some bind stuff as well). The minimum need here is the possibility to specify a key and use that on tranfer-to|from. We don't need any CIDR notation because that's ACL stuff that will live in the acl middleware, only bare IPs with (optional) port numbers are needed (I think).

The main thing to think about is, is it OK to repeat the key's definition or do we need/want it to be named.

Corefile:

miek.nl {
    transfer-to 10.10.1.2 hmac-md5:<base64>
    transfer-to 10.10.1.1 hmac-sha1:<base64>
}

Or

miek.nl {
    key x1 hmac-md5 base64
    key x2 hmac-sha1 base64
    transfer-to 10.10.1.2 x1
    transfer-to 10.10.1.1 x2
}
`transfer-from` *is* btw an ACL thing in my opinion.

[miekg]

See #57, #178, and #179 for stuff that might benefit from this magical DSL as well. I'll try to write down a proposal.

[miekg]

I like this: https://caddyserver.com/docs/ipfilter

[stp-ip]

Any update on ACL like stuff for zone transfers?

[miekg]

No, other than the framework @johnbelamaric mentioned, we didn't make any progress on a small, easy to use DSL for these usecases.

[Centzilius]

Well at least it is no longer required to put * in the list since 9fb266a which is kind of enough for me but might not be enough for others

[stp-ip]

But only for secondary. It's still necessary fir "file" and "auto" middlewares afaik.

[Centzilius]

It does work for "file" due to the change in middleware/file/zone.go 9fb266a#diff-e15ee1accd50ebebcb6df120c7a07b0b

[stp-ip]

Seems like this could be done for auto too right?

[miekg]

Yes that code is all shared.

…

On Aug 31, 2017 21:28, "Michael Grosser" ***@***.***> wrote: Seems like this could be done for auto too right? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#469 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAVkWw6EsvOCCvmM2WiGmcEDBZuKwO9Rks5sdwl5gaJpZM4LaqTy> .

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.