Problem with ACL in named.conf

[GS Bryan]

I tried to use the acl statement in my named.conf file, but I have a
hard time making it work. In my named.conf file, I've put these acl
statements in these formats (made up IP addresses mind you):-

----------
// Individual ACL list

acl addr1 {
11.22.33.44;
12.23.34.45;
};

acl addr2 {
22.33.44.55;
5.4.3.2;
99.0.0.0;
};

acl addr3 {
111.3.4.5;
2001:3000::1;
122.3.4.5;
2001:3000::2;
};


// Nested ACLs list

acl alladdr {
addr1;
addr2;
addr3;
};

------------

Then when I put the 'alladdr' thing in my 'allow-transfer' and
'also-notify' arguments, as shown below, BIND will fail to start:-

-----------

zone "example.net" {
type master;
file "examplenet.conf";
allow-transfer { "alladdr"; };
also-notify { "alladdr"; };
key-directory "keys/examplenet/";
inline-signing yes;
auto-dnssec maintain;
};

-------

Here is the log:-

------
----------------------------------------------------
BIND 9 is maintained by Internet Systems Consortium,
Inc. (ISC), a non-profit 501(c)(3) public-benefit
corporation. Support and training for BIND 9 are
available at https://www.isc.org/support
----------------------------------------------------
adjusted limit on open files from 1024 to 1048576
found 1 CPU, using 1 worker thread
using 1 UDP listener per interface
using up to 4096 sockets
loading configuration from '/etc/named.conf'
reading built-in trusted keys from file '/etc/named.iscdlv.key'
using default UDP/IPv4 port range: [1024, 65535]
using default UDP/IPv6 port range: [1024, 65535]
listening on IPv4 interface lo, 127.0.0.1#53
listening on IPv4 interface venet0:0, <redacted>#53
listening on IPv6 interface lo, ::1#53
listening on IPv6 interface venet0, <redacted>#53
generating session key for dynamic DNS
sizing zone task pool based on 10 zones
/etc/named.conf:111: masters "alladdr" not found
loading configuration: not found
exiting (due to fatal error)
-----

>From examples I read from the Internet, I don;t think I have done
anything wrong. If I put all the IP addresses from addr1, addr2 and
addr3 into the allow-transfer and also-notify statements, BIND will
start normally without problems.

Thanks for reading.
--
Bryan S.G.

[Doug Barton]

On 08/29/2012 03:25 PM, GS Bryan wrote:
> Then when I put the 'alladdr' thing in my 'allow-transfer' and
> 'also-notify' arguments,

also-notify does not take an acl. The ARM will give you more information
on the grammar.

That said, this is a very annoying problem that I wish there was a
better solution for. I used to build my conf files with m4 to work
around this, but that was a big hammer for a very large installation.
You might be able to do something simpler by putting notes in the conf
to remind people who update 1 area to also update the other.

Doug

[Jeremy C. Reed]

On Thu, 30 Aug 2012, GS Bryan wrote:

> also-notify { "alladdr"; };

This uses an ip_addr instead of an address_match_list. Some versions of
named-checkconf will tell you "expected IP address".

> /etc/named.conf:111: masters "alladdr" not found

I can't reproduce your problem. What version of BIND are you running?
(I am surprised it didn't log the version.) Also please consider using
named-checkconf in your testing.

[Mark Andrews]

In message <CAOJ-cLgi-Z1DyEnKq1PbK4+jzGG3ew8ZHfv10B751sEbb9V-=Q...@mail.gmail.com>

, GS Bryan writes:
> I tried to use the acl statement in my named.conf file, but I have a
> hard time making it work. In my named.conf file, I've put these acl
> statements in these formats (made up IP addresses mind you):-
>
> ----------
> // Individual ACL list
>
> acl addr1 {
> 11.22.33.44;
> 12.23.34.45;
> };
>
> acl addr2 {
> 22.33.44.55;
> 5.4.3.2;
> 99.0.0.0;
> };
>
> acl addr3 {
> 111.3.4.5;
> 2001:3000::1;
> 122.3.4.5;
> 2001:3000::2;
> };
>
>
> // Nested ACLs list
>
> acl alladdr {
> addr1;
> addr2;
> addr3;
> };
>
> ------------
>

> Then when I put the 'alladdr' thing in my 'allow-transfer' and

> 'also-notify' arguments, as shown below, BIND will fail to start:-

also-notify does not take a ACL (it is not a access control).
It will take a named "masters" list.

> /etc/named.conf:111: masters "alladdr" not found

> loading configuration: not found
> exiting (due to fatal error)
> -----
>
> >From examples I read from the Internet, I don;t think I have done
> anything wrong. If I put all the IP addresses from addr1, addr2 and
> addr3 into the allow-transfer and also-notify statements, BIND will
> start normally without problems.

A plain address in a acl is shorthand for address/32 or address/128
depending apon the address type. While they are visually similar
the two list are functionally very different.

The acl addr3 you have above is short hand for:

acl addr3 {
111.3.4.5/32;
2001:3000::1/128;
122.3.4.5/32;
2001:3000::2/128;
};

You could define master lists as use those.

e.g.
master addr3 {

111.3.4.5;
2001:3000::1;
122.3.4.5;
2001:3000::2;
};

you can even tell named to use specify keys and ports when talking
to the server.

master addr3 {
111.3.4.5 port 333 key xxxx;

2001:3000::1;
122.3.4.5;
2001:3000::2;
};

Mark

> Thanks for reading.
> --
> Bryan S.G.

> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

[Doug Barton]

On 08/29/2012 04:02 PM, Mark Andrews wrote:
> A plain address in a acl is shorthand for address/32 or address/128
> depending apon the address type. While they are visually similar
> the two list are functionally very different.

Mark,

I understand the "behind the scenes" reasons why the 2 things are
handled differently. But I still think it would be awesome to have a new
kind of list that accepts bare IP addresses, and can be used inside both
allow-transfer and also-notify. It's a really common issue to need to
configure the same list for both, and having to do it twice in the first
place, and then keep it updated twice down the road, really screams out
for a programmatic solution.

Doug

[GS Bryan]

hmm... that explains it.

Damn, DNSMadeEasy needs to have notify notices sent to a different IP
set than their nameserver service. This means that I have to hardcode
this myself.

Another question then, if zone 'example.net' has the NS records of
'ns1.example.net' (its IP address is 101.1.1.1) and 'ns2.example.net'
(its IP address is 101.1.2.1), then if I put the 'also-notify {
22.22.22.222; 22.22.22.223; 22.22.22.224; };' in the zone clause, when
the zone file is modified, notify messages will be sen to 101.1.1.1,
101.1.2.1, 2.22.22.222, 22.22.22.223, and 22.22.22.224 right?
--
Bryan S.G.

On Thu, Aug 30, 2012 at 9:42 AM, Doug Barton <do...@dougbarton.us> wrote:
> On 08/29/2012 03:25 PM, GS Bryan wrote:

>> Then when I put the 'alladdr' thing in my 'allow-transfer' and
>> 'also-notify' arguments,
>

[GS Bryan]

My BIND version, as shown by 'named -v' is BIND 9.9.1-P1-RedHat-9.9.1-2.P1.el6.

'named-checkconf /etc/named.conf' doesn't throw any error messages whatsoever.
--
Bryan S.G.

On Thu, Aug 30, 2012 at 9:59 AM, Jeremy C. Reed <jr...@isc.org> wrote:
> On Thu, 30 Aug 2012, GS Bryan wrote:
>
>> also-notify { "alladdr"; };
>
> This uses an ip_addr instead of an address_match_list. Some versions of
> named-checkconf will tell you "expected IP address".
>

>> /etc/named.conf:111: masters "alladdr" not found
>

[Cathy Almond]

On 30/08/12 03:19, GS Bryan wrote:
> My BIND version, as shown by 'named -v' is BIND 9.9.1-P1-RedHat-9.9.1-2.P1.el6.
>
> 'named-checkconf /etc/named.conf' doesn't throw any error messages whatsoever.
> --
> Bryan S.G.
>

You're correct - named-checkconf doesn't see the problem, but named
errors during start-up. I'm opening a bug ticket for you.

Cathy

[Cathy Almond]

On 30/08/12 03:17, GS Bryan wrote:
> hmm... that explains it.
>
> Damn, DNSMadeEasy needs to have notify notices sent to a different IP
> set than their nameserver service. This means that I have to hardcode
> this myself.
>
> Another question then, if zone 'example.net' has the NS records of
> 'ns1.example.net' (its IP address is 101.1.1.1) and 'ns2.example.net'
> (its IP address is 101.1.2.1), then if I put the 'also-notify {
> 22.22.22.222; 22.22.22.223; 22.22.22.224; };' in the zone clause, when
> the zone file is modified, notify messages will be sen to 101.1.1.1,
> 101.1.2.1, 2.22.22.222, 22.22.22.223, and 22.22.22.224 right?

Yes (except for the master listed in the SOA record), and unless you
have 'notify explicit;' set.