Re: How to *require* TSIG for NOTIFY
It’s `also-notify ;` and `notify explicit;`
The online documentation is here:
https://bind9.readthedocs.io/en/v9_16_34/reference.html
Ondrej
--
Ondřej Surý — ISC (He/Him)
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
> On 15. 11. 2022, at 3:44, Jesus Cea wrote:
>
> On 15/11/22 3:30, Mark Andrews wrote:
>
>> NOTIFY is a hint for the secondary to perform a SOA refresh query sooner
>> than the SOA query triggered by REFRESH and RETRY. Those queries are rate
>> limited. Additionally multiple notify messages often coalesce
>> into one action as the server is waiting to send or is waiting for responses
>> when they arrive.
>
> I understand. I interpret your words as "even if you are getting fake
> notifies, the cost is quite small". That is nice.I am being possibly too
> paranoid.
>
>> While I don’t see the need, adding an 'allow-notify-explicit ;’ could
>> be added to ignore the primaries
>> list and only use the allow-notify acl.
>
> Could you possibly send me an URL documenting 'allow-notify-explicit'
> clause?. I am not able to find anything relevant online. I don't ever see
> anything related in 9.16.34 source code:
>
> """
> jcea@jcea:/tmp/ram/bind-9.16.34$ find . -name "*.c" -exec grep -i
> "allow-notify-" {} \; -print
> """
>
> Thanks!
>
> --
> Jesús Cea Avión _/_/ _/_/_/_/_/_/
> j...@jcea.es - https://www.jcea.es/_/_/_/_/ _/_/_/_/ _/_/
> Twitter: @jcea_/_/_/_/ _/_/_/_/_/
> jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/
> "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/
> "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/
> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
> this list
>
> ISC funds the development of this software with paid support subscriptions.
> Contact us at https://www.isc.org/contact/ for more information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: How to *require* TSIG for NOTIFY
On 15/11/22 3:30, Mark Andrews wrote:
NOTIFY is a hint for the secondary to perform a SOA refresh query sooner than
the SOA query triggered by REFRESH and RETRY. Those queries are rate limited.
Additionally multiple notify messages often coalesce
into one action as the server is waiting to send or is waiting for responses
when they arrive.
I understand. I interpret your words as "even if you are getting fake
notifies, the cost is quite small". That is nice.I am being possibly too
paranoid.
While I don’t see the need, adding an 'allow-notify-explicit ;’ could be
added to ignore the primaries
list and only use the allow-notify acl.
Could you possibly send me an URL documenting 'allow-notify-explicit'
clause?. I am not able to find anything relevant online. I don't ever
see anything related in 9.16.34 source code:
"""
jcea@jcea:/tmp/ram/bind-9.16.34$ find . -name "*.c" -exec grep -i
"allow-notify-" {} \; -print
"""
Thanks!
--
Jesús Cea Avión _/_/ _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/ _/_/_/_/ _/_/
Twitter: @jcea_/_/_/_/ _/_/_/_/_/
jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/
"My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: How to *require* TSIG for NOTIFY
> On 15 Nov 2022, at 12:41, Jesus Cea wrote:
>
> Hi everybody,
>
> I can configure my bind master to send TSIG in the NOTIFY messages, but I am
> not able to configure secondaries to *ONLY* allow NOTIFY with a valid TSIG.
>
> In the slave zone config I have something like:
>
> """
> zone "XXX" {
> type slave;
> ...
> allow-notify { key "KEY_TSIG"; };
> masters {
>IP;
> };
> };
> """
>
> The slave accepts the NOTIFY coming from "IP" (the master IP address), in
> both cases, with TSIG and with no TSIG. That is, it seems like ips listed in
> "masters" are not required to TSIG at all.
>
> The log shows this fact:
>
> Master configured with TSIG:
>
> """
> 15-Nov-2022 01:48:50.961 notify: info: client @268b268 IP#57901/key_tsig:
> received notify for zone 'XXX.local': TSIG 'key_tsig'
> """
>
> Master configured with no TSIG:
>
> """
> 15-Nov-2022 02:15:30.701 notify: info: client @4074268 IP#32138: received
> notify for zone 'XXX.local'
> """
>
> So, I can control whenever the master send notifies with and without TSIG,
> but slaves just don't care to verify it (if the notify comes from a "masters"
> source).
>
> Checking documentation around, I read this:
>
> """
> allow-notify applies to slave zones only and defines a match list, for
> example, IP address(es) that are allowed to NOTIFY this server and implicitly
> update the zone in addition to those hosts defined in the masters option for
> the zone. The default behaviour is to allow zone updates only from the
> masters IP(s). This statement may be used in a zone, view or global options
> clause.
> """
>
> It seems that whatever I specify in "allow-notify", "masters" are always
> allowed to notify without TSIG.
>
> Given that NOTIFY is UDP and source spoofing is so easy, I would like to be
> able to *REQUIRE* TSIG even for "masters".
>
> Is this something I can configure in bind? Is this something unrealistic/too
> paranoid for my own good?
NOTIFY is a hint for the secondary to perform a SOA refresh query sooner than
the SOA query triggered by REFRESH and RETRY. Those queries are rate limited.
Additionally multiple notify messages often coalesce
into one action as the server is waiting to send or is waiting for responses
when they arrive.
While I don’t see the need, adding an 'allow-notify-explicit ;’ could be
added to ignore the primaries
list and only use the allow-notify acl.
Mark
> Thanks.
>
> --
> Jesús Cea Avión _/_/ _/_/_/_/_/_/
> j...@jcea.es - https://www.jcea.es/_/_/_/_/ _/_/_/_/ _/_/
> Twitter: @jcea_/_/_/_/ _/_/_/_/_/
> jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/
> "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/
> "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/
> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
> this list
>
> ISC funds the development of this software with paid support subscriptions.
> Contact us at https://www.isc.org/contact/ for more information.
>
>
> 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
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
How to *require* TSIG for NOTIFY
Hi everybody,
I can configure my bind master to send TSIG in the NOTIFY messages, but
I am not able to configure secondaries to *ONLY* allow NOTIFY with a
valid TSIG.
In the slave zone config I have something like:
"""
zone "XXX" {
type slave;
...
allow-notify { key "KEY_TSIG"; };
masters {
IP;
};
};
"""
The slave accepts the NOTIFY coming from "IP" (the master IP address),
in both cases, with TSIG and with no TSIG. That is, it seems like ips
listed in "masters" are not required to TSIG at all.
The log shows this fact:
Master configured with TSIG:
"""
15-Nov-2022 01:48:50.961 notify: info: client @268b268
IP#57901/key_tsig: received notify for zone 'XXX.local': TSIG 'key_tsig'
"""
Master configured with no TSIG:
"""
15-Nov-2022 02:15:30.701 notify: info: client @4074268 IP#32138:
received notify for zone 'XXX.local'
"""
So, I can control whenever the master send notifies with and without
TSIG, but slaves just don't care to verify it (if the notify comes from
a "masters" source).
Checking documentation around, I read this:
"""
allow-notify applies to slave zones only and defines a match list, for
example, IP address(es) that are allowed to NOTIFY this server and
implicitly update the zone in addition to those hosts defined in the
masters option for the zone. The default behaviour is to allow zone
updates only from the masters IP(s). This statement may be used in a
zone, view or global options clause.
"""
It seems that whatever I specify in "allow-notify", "masters" are always
allowed to notify without TSIG.
Given that NOTIFY is UDP and source spoofing is so easy, I would like to
be able to *REQUIRE* TSIG even for "masters".
Is this something I can configure in bind? Is this something
unrealistic/too paranoid for my own good?
Thanks.
--
Jesús Cea Avión _/_/ _/_/_/_/_/_/
j...@jcea.es - https://www.jcea.es/_/_/_/_/ _/_/_/_/ _/_/
Twitter: @jcea_/_/_/_/ _/_/_/_/_/
jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/
"My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: CH/TXT/VERSION.SERVER queries
Hi Anand, correct me if I am wrong, but the VERSION.SERVER doesn't seem to be anywhere documented[1], and you are the first one to request it[2]. 1. RFC 4892 only talks about ID.SERVER 2. Please create a GitLab issue for tracking Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 14. 11. 2022, at 17:33, Anand Buddhdev wrote: > > Hi folks (especially BIND developers), > > Apologies if this has been discussed and answered before. I just noticed that > BIND doesn't respond to CH/TXT/VERSION.SERVER queries. It only responds to > ID.SERVER. > > Other name servers, such as Knot DNS, NSD, Verisign's ATLAS name server, > Quad9's and Cloudflare's public resolvers, respond to VERSION.SERVER queries. > > So what's the reason for BIND not responding to VERSION.SERVER queries? It > seems like an anomaly or oversight. > > Regards, > Anand > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
CH/TXT/VERSION.SERVER queries
Hi folks (especially BIND developers), Apologies if this has been discussed and answered before. I just noticed that BIND doesn't respond to CH/TXT/VERSION.SERVER queries. It only responds to ID.SERVER. Other name servers, such as Knot DNS, NSD, Verisign's ATLAS name server, Quad9's and Cloudflare's public resolvers, respond to VERSION.SERVER queries. So what's the reason for BIND not responding to VERSION.SERVER queries? It seems like an anomaly or oversight. Regards, Anand -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Deprecating auto-dnssec and inline-signing in 9.18+
FYI: We are going forward with deprecating 'auto-dnssec' in 9.18+.
We might deprecate 'inline-signing' too in 9.18, but only if we have
implemented the replacement code to configure it inside 'dnssec-policy'
in time.
After last year's discussion on this mailing list I initially wanted to
make creating keys inside the HSM work with dnssec-policy. But the
OpenSSL pkcs#11 engine has no capability to do so. Now we are
transitioning to OpenSSL 3.0 and the engine API is being replaced with
the provider API, this task has become even more challenging.
But since there is functional parity between 'dnssec-policy' and
'auto-dnssec', we decided that it is acceptable to deprecate the legacy
style of DNSSEC maintenance.
You can configure dnssec-policy to do no key rollover (and do key
maintenance/rotation in a different way) as follows:
dnssec-policy "no-auto-rotate" {
keys {
ksk lifetime unlimited algorithm 13;
zsk lifetime unlimited algorithm 13;
};
};
Best regards,
Matthijs
On 10-08-2021 10:02, Matthijs Mekking wrote:
Hi users,
We are planning to deprecate the options 'auto-dnssec' and
'inline-signing' in BIND 9.18. The reason for this is because
'dnssec-policy' is the preferred way of maintaining your DNSSEC zone.
Deprecating means that you can still use the options in 9.18, but a
warning will be logged and it is very likely that the options will be
removed in BIND 9.20.
We would like to encourage you to change your configurations to
'dnssec-policy'. See this KB article for migration help:
https://kb.isc.org/docs/dnssec-key-and-signing-policy
Do you have reasons for keeping 'inline-signing' or 'auto-dnssec'
configurations? Is there a use case that is not (yet) covered by
'dnssec-policy'? Any other concerns? Please let us know.
Best regards,
Matthijs
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
ISC funds the development of this software with paid support
subscriptions. Contact us at https://www.isc.org/contact/ for more
information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
