Re: update-policy wildcard grant
> On 2 Apr 2020, at 11:59, Jim Popovitch via bind-users
> wrote:
>
> On Thu, 2020-04-02 at 09:27 +1100, Mark Andrews wrote:
>>> On 2 Apr 2020, at 06:53, Jim Popovitch via bind-users <
>>> bind-users@lists.isc.org> wrote:
>>>
>>> Hello!
>>>
>>> I started on #bind, moved on to the ARM, and now I am here.
>>>
>>> Here is what I want:
>>>
>>> update-policy {grant webserver-tsig-key wildcard _acme-challenge.*
>>> TXT;};
>>>
>>> This is what I get:
>>>
>>> ~$ named-checkconf
>>> /etc/bind/named.conf:73: '_acme-challenge.*' is not a wildcard
>>>
>>> What am I doing wrong?
>>
>> Presumably the webserver is locked done enough that you can just let
>> the TSIG update TXT anywhere.
>
> Do you mean like kb.isc.org ? :-)
>
> Honestly, no webserver, worth it's salt in 2020, is ever locked down
> well enough, imho.
The tool updating the acme challenges and certificates can definitely
be locked down enough.
You could use SIG(0) rather than TSIG to authenticate the updates and store KEY
records in the DNS for each site. That is much easier to manage than TSIG’s for
each site and doesn’t require updating named.conf once it is setup with TSIG
only
being used to add the KEY records as each site is establised.
grant * self . TXT;
>> If you really need to apply tighter rules then use ‘external’ and
>> implement the check outside of named.
>
> Thanks for that, it looks exactly like what I need/want.
>
> -Jim P.
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-users@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
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: update-policy wildcard grant
On Thu, 2020-04-02 at 09:27 +1100, Mark Andrews wrote:
> > On 2 Apr 2020, at 06:53, Jim Popovitch via bind-users <
> > bind-users@lists.isc.org> wrote:
> >
> > Hello!
> >
> > I started on #bind, moved on to the ARM, and now I am here.
> >
> > Here is what I want:
> >
> > update-policy {grant webserver-tsig-key wildcard _acme-challenge.*
> > TXT;};
> >
> > This is what I get:
> >
> > ~$ named-checkconf
> > /etc/bind/named.conf:73: '_acme-challenge.*' is not a wildcard
> >
> > What am I doing wrong?
>
> Presumably the webserver is locked done enough that you can just let
> the TSIG update TXT anywhere.
Do you mean like kb.isc.org ? :-)
Honestly, no webserver, worth it's salt in 2020, is ever locked down
well enough, imho.
> If you really need to apply tighter rules then use ‘external’ and
> implement the check outside of named.
Thanks for that, it looks exactly like what I need/want.
-Jim P.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: update-policy wildcard grant
> On 2 Apr 2020, at 06:53, Jim Popovitch via bind-users
> wrote:
>
> Hello!
>
> I started on #bind, moved on to the ARM, and now I am here.
>
> Here is what I want:
>
> update-policy {grant webserver-tsig-key wildcard _acme-challenge.* TXT;};
>
> This is what I get:
>
> ~$ named-checkconf
> /etc/bind/named.conf:73: '_acme-challenge.*' is not a wildcard
>
> What am I doing wrong?
Presumably the webserver is locked done enough that you can just let the TSIG
update TXT anywhere.
If you really need to apply tighter rules then use ‘external’ and implement the
check outside of named.
This is documented in the BIND 9 Administrators Reference Manual.
external
This rule allows named to defer the decision of whether to allow a given update
to an external daemon.
The method of communicating with the daemon is specified in the identity field,
the format of which is "local:path", where path is the location of a
UNIX-domain socket. (Currently, "local" is the only supported mechanism.)
Requests to the external daemon are sent over the UNIX-domain socket as
datagrams with the following format:
Protocol version number (4 bytes, network byte order, currently 1)
Request length (4 bytes, network byte order)
Signer (null-terminated string)
Name (null-terminated string)
TCP source address (null-terminated string)
Rdata type (null-terminated string)
Key (null-terminated string)
TKEY token length (4 bytes, network byte order )
TKEY token (remainder of packet)
The daemon replies with a four-byte value in network byte order, containing
either 0 or 1; 0 indicates that the specified update is not permitted, and 1
indicates that it is.
Mark
> tia!
>
> -Jim P.
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-users@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
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: update-policy wildcard grant
Jim Popovitch via bind-users wrote:
>
>update-policy {grant webserver-tsig-key wildcard _acme-challenge.* TXT;};
Sadly in the DNS a wildcard * can only occur as the leftmost label in a name.
RFC 4592 has more than you ever wanted to know about DNS wildcards. It's
not pretty.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
The Minch: Northwesterly 6 to gale 8, occasionally severe gale 9 at first in
north, decreasing 4 to 6 later. Slight or moderate, occasionally rough in
north. Squally wintry showers. Good, occasionally poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
