[bind10-dev] ACL Syntax proposal

[JINMEI Tatuya / 神明達哉]

At Fri, 3 Jun 2011 11:14:58 +0200,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:
> 
> Well, as I said. We start matching from outside, the dict contains name-value
> pairs. The name says what kind of check it should be and the value completely
> belongs to the check, it is free to have it structured in any way. Some rules
> can extract bit of it and say that these are smaller expressions, so they are
> matched from their outside again. But the high-level syntax doesn't say where
> the subexpressions should be placed inside the type-dependant structure.
> 
> Then each type defines its syntax. The NOT contains the subexpression directly,
> OR and AND contain list of them and the FIRST-MATCH contain kind of sequential
> program, each command being a condition and what result should the whole
> FIRST-MATCH return when the condition is met.

The problem is that, without a more formal definition, and with having
"constant" functions with side effects (accept/deny), it's not clear
whether (e.g.) this is a valid representation:

{
  "DENY-IF": {
	"OR": [
		{ "ip": "192.168.0.0/16" },
		{ "ACCEPT-IF": {"ip": "::/0"}},
		{ "ip": "10.0.0.0/8" },
		{ "ip": "172.16.0.0/12" }
	]
  }
}

and, if it is, what should happen if it's an IPv6 address.

Specific examples instead of formal (boring) definitions are rather
helpful when we try to understand the concept, but once this phase is
done and when we want to know how exactly we should implement it,
(IMO) we need more precise, formal definition.  Otherwise, we can
always come up with deviant examples like the above one and wonder
whether it's okay or not forever.

> > - Maybe related to the first point, we'll often want to specify a rule
> >   like "accept something from this source address".  How would such a
> >   rule look like in this proposed scheme?
> 
> I'm not sure what you ask. Like a rule that accepts packets from
> only single IP address? It would be:
> 
> {"ip": "1.2.3.4"}
> 
> (Returning true for this one and false for anything else).
> 

Basically (one form of) what I meant is how some common BIND 9 ACL
definitions would specifically be represented in the proposed format,
just so that we can have a clearer image of what we will be expected
to do in the implementation phase.

In BIND 9, we write:
options {
...
	allow-query { 127.0.0.1; ::1; localnets; };
};

What specifically would we have in b10-config.db for this?

How about this?

zone "example.com" {
 ...
 allow-transfer { key "key.example.com"; 2001:db8:1::/48; };
};

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.