Re: dnssec-keygen not available in Bind9.16-utils package?
Hello David, I have Oracle Linux 8 instance running bind 9.11.x as well bind 9.16.x and confirm that there’s no dnssec-* utilities in the bind9.16-utils. Although the 9.11 and 9.16 version cannot coexist, you can insead installing the bind9.16-utils install bind-utils. It works still perfect on the instance I ran bind9.16. Currently on this instance I have both version of bind-libs and version 9.11.x of bind-utils working together with bind9.16. Regards, Jiaming Zhang Yixi Meta Email: j.zh...@yiximeta.com Website: yiximeta.com Van: bind-users namens David Carvalho via bind-users Verzonden: Friday, March 24, 2023 10:22:45 AM Aan: 'Petr Menšík' ; bind-users@lists.isc.org Onderwerp: RE: dnssec-keygen not available in Bind9.16-utils package? Thank you so much for your help. Unfortunately it seems bind-utils 9.11 and 9.16 can not co-exist (at least in Oracle Linux 8). I had problems with dependencies and didn’t force anything until having more information. Thanks once again! Regards David Carvalho From: bind-users On Behalf Of Petr Menšík Sent: 24 March 2023 01:09 To: bind-users@lists.isc.org Subject: Re: dnssec-keygen not available in Bind9.16-utils package? Oh, correction. Those were published, but in wrong repository. If you enable CodeReady Builder (CRB) repository, you should be able to install it even with current version. Not sure what is official name on Oracle Linux, use "dnf repolist --all" command to find the name. They are called powertools on CentOS Stream 8. On RHEL 8 enable it by command: subscription-manager repos --enable codeready-builder-for-rhel-8-x86_64-rpms On 3/24/23 01:43, Petr Menšík wrote: dnssec utilities are in bind9.16-dnssec-utils, which by mistake stayed internal only package. We have built them, but not published them. It would be moved into public repository once RHEL 8.8.0 is released, tracked under bug #2115322 [1]. It should be already available in CentOS Stream 8. I am sorry for the inconvenience, this issue were missed during our testing. It should be possible to install bind-utils from bind 9.11 together with bind9.16 server until that is fixed. Unless you depend on more recent features in bind9.16-utils, it might help in the mean time. Regards, Petr 1. https://bugzilla.redhat.com/show_bug.cgi?id=2115322 On 3/20/23 13:31, David Carvalho via bind-users wrote: Hello, good morning. I’m trying to setup DNNSEC and I’ve been using Bind9.16 packages available in Oracle Linux 8. Somehow there are also “Bind” packages, which default to 9.11 version. Being a new installation I went for 9.16. The problem now is that dnssec-keygen seems to be only available in version 9.11, and if I try to install I get problems with dependencies . Does anyone have some experience with this? Kind regards David -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- 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
Best practice MultiView
Dear community,
I was wondering if notifying and updating zones in different view (say
"internal" and "external") between bind servers via different key is a good
practice. I got a sample zone/config like below:
```
view "internal" {
zone "example.com" IN {
# some other config, master zone
allow-transfer { key key1; };
notify yes;
};
# some more zone
}
view "external" {
zone "example.com" IN {
# some other config, master zone
allow-transfer { key key2; };
notify yes;
};
}
```
where both zones have the same name server (e.g. `ns1.example.com` and
`ns2.example.com`). What I'm trying to archive is that and update on zones in
"internal" view does not contaminate zones in "external" view, or vice versa. I
was wondering if using different key to limit update is a good practice, since
I'm expecting "external" view on slave server will also receive notify upon
update on "internal" zone at master, but just unable to query update due to
incorrect key.
Kind Regards,
Jiaming Zhang
Yixi Meta
Tel: +31 (6) 12 98 08 07
Email: j.zh...@yiximeta.com
Website: yiximeta.com
De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. Aan
dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u deze
e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de
afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail
of informatie uit deze e-mail is alleen toegestaan met voorafgaande
schriftelijke toestemming van de afzender. Het Yixi Meta staat geregistreerd
bij de Kamer van Koophandel in het handelsregister onder nummer 85744115.
The content of this message is intended solely for the addressee. No rights can
be derived from this message or its attachments. If you are not the intended
recipient, we kindly request you to delete the message and inform the sender.
It is strictly prohibited to disclose, copy or distribute this email or the
information inside it, without a written consent from the sender. Yixi Meta is
registered with the Dutch Chamber of Commerce trade register with number
85744115.
--
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: Best practice MultiView
Dear Nick,
Thanks for the reply. What was already set that I didn't include in my first
mail was that both views on both servers have match-clients set (for internal
set to "localhost" and "localnets", and for external set to "any"), so I'll add
the keys also to the match-clients.
However, I got a question on the syntax of also-notify, what I can see from
bind9's user manual, the target of also-notify can be |
[ port ] | [ port ], does
this means that I can use domain names of the server instead of IP? Both name
server has IPv4 (single or multiple) and IPv6 glued with the domain name, and I
was wondering if by setting domain name instead of IP, bind will intelligently
find if it would need to communicate with which IP (like it currently do with
notify yes). I asked because if by any chance for whatever reason sending
notify was failed to a certain IP, it may look up any other available IP that
is defined with the related domain name (at least from my observation).
I was also confused what you exactly referred to with '"primaries" (or
"masters" in old terminology) statement that includes the correct key name', I
assume you mean I need to point which is the master and the keys to communicate
with this specific master on the slave server. For the reference, I attached
the related config on slave below.
```
zone "example.com" IN {
type slave;
masters { ; };
file "/path/to/file";
allow-query { any; };
notify yes; # will become "explicit"
};
```
Kind regards,
Jiaming Zhang
Yixi Meta
Tel: +31 (6) 12 98 08 07
Email: j.zh...@yiximeta.com
Website: yiximeta.com
De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. Aan
dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u deze
e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de
afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail
of informatie uit deze e-mail is alleen toegestaan met voorafgaande
schriftelijke toestemming van de afzender. Het Yixi Meta staat geregistreerd
bij de Kamer van Koophandel in het handelsregister onder nummer 85744115.
The content of this message is intended solely for the addressee. No rights can
be derived from this message or its attachments. If you are not the intended
recipient, we kindly request you to delete the message and inform the sender.
It is strictly prohibited to disclose, copy or distribute this email or the
information inside it, without a written consent from the sender. Yixi Meta is
registered with the Dutch Chamber of Commerce trade register with number
85744115.
Van: bind-users namens Nick Tait via
bind-users
Verzonden: maandag, april 17, 2023 1:03 PM
Aan: bind-users@lists.isc.org
Onderwerp: Re: Best practice MultiView
Hi Jiaming.
You'll also need "match-clients" in the first view (at least), so that the
correct view handles the zone transfer request. As well as specifying 'the
right key' in match-clients, you'll probably also want to specify 'not the
wrong key', otherwise you won't be able to query the view from any clients
(e.g. on your internal network) that don't present any key in their request...
I've taken your example, and changed the key names to "internal.example.com"
and "external.example.com" (for clarity), and added the match-clients to it as
follows:
view "internal" {
match-clients { key "internal.example.com"; !key "external.example.com";
internal-networks; };
zone "example.com" IN {
# some other config, master zone
allow-transfer { key "internal.example.com"; };
notify yes;
};
# some more zone
};
view "external" {
match-clients { key "external.example.com"; !key "internal.example.com"; any;
};
zone "example.com" IN {
# some other config, master zone
allow-transfer { key "external.example.com"; };
notify yes;
};
};
Note that I've included "internal-networks" in the internal view. This is
simply to illustrate that you might also want the view to answer DNS requests
from clients within your network.
There is one further improvement on the above, which is what Mark referred to
below, which is where each view can include the respective key in NOTIFY
messages. To do that, change "notify yes" to "notify explicit" and then use
"also-notify" to specify the secondary servers along with the key to use.
Applying this to the above you get something like:
view "internal" {
match-clients { key "internal.example.com"; !key "external.example.com";
internal-networks; };
zone "example.com" IN {
# some other config, master zone
allow-transfer { key "internal.example.com";
Re: Best practice MultiView
Hi Greg, Thanks for the example given. I was trying to digest your answer, it seems it would be better to have intermediate subdomain for the purpose. So it will be site1.internal.example.com, site2.internal.example.com, etc. and thus only NS records of internal.example.com can be visible and not the actual internally operating site. Now it just a matter of migration from site_n.example.com to site_n.internal.example.com. (which I suppose is also better for DNSSEC) Kind regards, Jiaming Zhang Yixi Meta Tel: +31 (6) 12 98 08 07 Email: j.zh...@yiximeta.com Website: yiximeta.com De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. Aan dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u deze e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail of informatie uit deze e-mail is alleen toegestaan met voorafgaande schriftelijke toestemming van de afzender. Het Yixi Meta staat geregistreerd bij de Kamer van Koophandel in het handelsregister onder nummer 85744115. The content of this message is intended solely for the addressee. No rights can be derived from this message or its attachments. If you are not the intended recipient, we kindly request you to delete the message and inform the sender. It is strictly prohibited to disclose, copy or distribute this email or the information inside it, without a written consent from the sender. Yixi Meta is registered with the Dutch Chamber of Commerce trade register with number 85744115. Van: Greg Choules Verzonden: Wednesday, April 19, 2023 11:01:00 PM Aan: Jiaming Zhang CC: bind-users@lists.isc.org Onderwerp: Re: Best practice MultiView Hi Jiaming. Here's what I would do. I am assuming one nameserver for the public zone and one (different) nameserver for the internal zones. You would use more in practice but I'm keeping it simple, for illustration. The external NS is reachable from anywhere in the Internet. If you host it in your own network, ideally do it on a public DMZ. It hosts one zone; example.com<http://example.com>. The NS name is externalns.example.com<http://externalns.example.com>. The internal NS is *not* reachable from anywhere in the Internet, only to internal hosts and probably on a private address (depends on your internal addressing scheme). It hosts three zones; internal1.example.com<http://internal1.example.com>, internal2.example.com<http://internal2.example.com>, internal3.example.com<http://internal3.example.com>. The name of the NS itself is internalns.internal1.example.com<http://internalns.internal1.example.com> EXTERNAL NS zone: example.com<http://example.com> @ SOA @ NS externalns internal1 NS internalns.internal1 internal2 NS internalns.internal1 internal2 NS internalns.internal1 other records... INTERNAL NS zone internal1.example.com<http://internal1.example.com> @ SOA @ NS internalns internalns A 192.168.1.1 other records zone internal2.example.com<http://internal2.example.com> @ SOA @ NS internalns.internal1.example.com<http://internalns.internal1.example.com>. other records zone internal3.example.com<http://internal3.example.com> @ SOA @ NS internalns.internal1.example.com<http://internalns.internal1.example.com>. other records From an Internet source, the only NS that can be reached is externalns.example.com<http://externalns.example.com>. Queries could be made to it to learn that delegations exist for the internal zones and the name of the NS for those zones. However, they cannot resolve the IP address of internalns. Not that it would help anyway if it's 192.168.something and/or your firewalls block incoming DNS. It is not essential to have the delegations in externalns because internal clients do not use them anyway. However, it is recommend to have them because a) it is technically correct and b) it will be necessary for DNSSEC validation to work internally. Hope that helps. Greg On Wed, 19 Apr 2023 at 18:20, Jiaming Zhang mailto:j.zh...@yiximeta.com>> wrote: Dear Greg, That’s what I thought, of each individual zone must have NS record point to it. But my point is not hiding NS record (or which server handles it) from internal client but hiding which internal domain are we running from the external malicious client. Kind regards, Jiaming Zhang Yixi Meta Tel: +31 (6) 12 98 08 07 Email: j.zh...@yiximeta.com<mailto:j.zh...@yiximeta.com> Website: yiximeta.com<http://yiximeta.com> De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. Aan dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u deze e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail of in
Re: Best practice MultiView
Dear Greg, That’s what I thought, of each individual zone must have NS record point to it. But my point is not hiding NS record (or which server handles it) from internal client but hiding which internal domain are we running from the external malicious client. Kind regards, Jiaming Zhang Yixi Meta Tel: +31 (6) 12 98 08 07 Email: j.zh...@yiximeta.com Website: yiximeta.com De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. Aan dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u deze e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail of informatie uit deze e-mail is alleen toegestaan met voorafgaande schriftelijke toestemming van de afzender. Het Yixi Meta staat geregistreerd bij de Kamer van Koophandel in het handelsregister onder nummer 85744115. The content of this message is intended solely for the addressee. No rights can be derived from this message or its attachments. If you are not the intended recipient, we kindly request you to delete the message and inform the sender. It is strictly prohibited to disclose, copy or distribute this email or the information inside it, without a written consent from the sender. Yixi Meta is registered with the Dutch Chamber of Commerce trade register with number 85744115. Van: Greg Choules Verzonden: Tuesday, April 18, 2023 2:51:05 PM Aan: Jiaming Zhang CC: bind-users@lists.isc.org Onderwerp: Re: Best practice MultiView Hi Jiaming. Every zone *must* have one SOA record and at least one NS record. This is a requirement of the protocol. Internal clients will (probably) be making recursive queries to the internal DNS server for A, , MX, SRV records (maybe some more types as well). It is unlikely they will be making queries for NS records normally. But what if they do? Why does it matter if clients find out the NS names for the internal zones? Cheers, Greg On Tue, 18 Apr 2023 at 13:27, Jiaming Zhang mailto:j.zh...@yiximeta.com>> wrote: Dear Greg, I agree using child zones is a better idea, and I'm actually using this, what I want to hide is the NS records of the internal-only subdomains. OR is the NS record totally unnecessary if the DNS resolver has these individual zones (which I don't think so based on how DNS query works). Kind regards, Jiaming Zhang Yixi Meta Tel: +31 (6) 12 98 08 07 Email: j.zh...@yiximeta.com<mailto:j.zh...@yiximeta.com> Website: yiximeta.com<http://yiximeta.com> De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. Aan dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u deze e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail of informatie uit deze e-mail is alleen toegestaan met voorafgaande schriftelijke toestemming van de afzender. Het Yixi Meta staat geregistreerd bij de Kamer van Koophandel in het handelsregister onder nummer 85744115. The content of this message is intended solely for the addressee. No rights can be derived from this message or its attachments. If you are not the intended recipient, we kindly request you to delete the message and inform the sender. It is strictly prohibited to disclose, copy or distribute this email or the information inside it, without a written consent from the sender. Yixi Meta is registered with the Dutch Chamber of Commerce trade register with number 85744115. Van: Greg Choules mailto:gregchoules%2bbindus...@googlemail.com>> Verzonden: Tuesday, April 18, 2023 2:10:49 PM Aan: Jiaming Zhang mailto:j.zh...@yiximeta.com>> CC: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org> mailto:bind-users@lists.isc.org>> Onderwerp: Re: Best practice MultiView Hi Jiaming. I had a similar requirement. Since there were not many (a few tens or at most a hundred) names that needed to be resolved differently locally my approach was to create a zone for each of them and to not have the parent zone at all. Each specific zone would contain a single A record (or maybe others) with the owner name being @ or tha name of the zone. e.g.: EXTERNAL zone example.com<http://example.com> INTERNAL zones insite.example.com<http://insite.example.com> @ A 10.1.1.1 another.example.com<http://another.example.com> @ A 10.1.1.2 etc... This way, the default is for all resolution to go externally, except the names you want to resolve internally with different answers. Cheers, Greg On Tue, 18 Apr 2023 at 12:59, Jiaming Zhang mailto:j.zh...@yiximeta.com>> wrote: Dear Greg, The initiative was that we have certain records that wish to be view only internally and may resolve to private address (e.g. insite A 10.1.1.1). Kind Regards, Jiaming Zhang Yixi Met
Re: Best practice MultiView
Dear Greg,
The initiative was that we have certain records that wish to be view only
internally and may resolve to private address (e.g. insite A 10.1.1.1).
Kind Regards,
Jiaming Zhang
Yixi Meta
Tel: +31 (6) 12 98 08 07
Email: j.zh...@yiximeta.com
Website: yiximeta.com
De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. Aan
dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u deze
e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de
afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail
of informatie uit deze e-mail is alleen toegestaan met voorafgaande
schriftelijke toestemming van de afzender. Het Yixi Meta staat geregistreerd
bij de Kamer van Koophandel in het handelsregister onder nummer 85744115.
The content of this message is intended solely for the addressee. No rights can
be derived from this message or its attachments. If you are not the intended
recipient, we kindly request you to delete the message and inform the sender.
It is strictly prohibited to disclose, copy or distribute this email or the
information inside it, without a written consent from the sender. Yixi Meta is
registered with the Dutch Chamber of Commerce trade register with number
85744115.
Van: Greg Choules
Verzonden: Monday, April 17, 2023 4:43:58 PM
Aan: Jiaming Zhang
CC: bind-users@lists.isc.org
Onderwerp: Re: Best practice MultiView
Hi Jiaming.
The arguments to "also-notify {...};" are explicit IP addresses.
Why do you need it? Do you have some secondaries that are not listed as NS in
zones?
Regarding views. Why would you have the same zone in an internal and external
view? A few years ago, having to maintain multiple zones of the same name but
different contents caused me problems daily. I would recommend having internal
zones be proper delegations from external zones. e.g.:
external "example.com<http://example.com>"
internal "internal.example.com<http://internal.example.com>"
Cheers, Greg
On Mon, 17 Apr 2023 at 14:41, Jiaming Zhang
mailto:j.zh...@yiximeta.com>> wrote:
Dear Nick,
Thanks for the reply. What was already set that I didn't include in my first
mail was that both views on both servers have match-clients set (for internal
set to "localhost" and "localnets", and for external set to "any"), so I'll add
the keys also to the match-clients.
However, I got a question on the syntax of also-notify, what I can see from
bind9's user manual, the target of also-notify can be |
[ port ] | [ port ], does
this means that I can use domain names of the server instead of IP? Both name
server has IPv4 (single or multiple) and IPv6 glued with the domain name, and I
was wondering if by setting domain name instead of IP, bind will intelligently
find if it would need to communicate with which IP (like it currently do with
notify yes). I asked because if by any chance for whatever reason sending
notify was failed to a certain IP, it may look up any other available IP that
is defined with the related domain name (at least from my observation).
I was also confused what you exactly referred to with '"primaries" (or
"masters" in old terminology) statement that includes the correct key name', I
assume you mean I need to point which is the master and the keys to communicate
with this specific master on the slave server. For the reference, I attached
the related config on slave below.
```
zone "example.com<http://example.com>" IN {
type slave;
masters { ; };
file "/path/to/file";
allow-query { any; };
notify yes; # will become "explicit"
};
```
Kind regards,
Jiaming Zhang
Yixi Meta
Tel: +31 (6) 12 98 08 07
Email: j.zh...@yiximeta.com<mailto:j.zh...@yiximeta.com>
Website: yiximeta.com<http://yiximeta.com>
De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. Aan
dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u deze
e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de
afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail
of informatie uit deze e-mail is alleen toegestaan met voorafgaande
schriftelijke toestemming van de afzender. Het Yixi Meta staat geregistreerd
bij de Kamer van Koophandel in het handelsregister onder nummer 85744115.
The content of this message is intended solely for the addressee. No rights can
be derived from this message or its attachments. If you are not the intended
recipient, we kindly request you to delete the message and inform the sender.
It is strictly prohibited to disclose, copy or distribute this email or the
information inside it, without a written consent from the sender. Yixi Meta is
registered with the Dutch Chamber of Commerce trade register with number
85744115.
___
Re: Best practice MultiView
Dear Greg,
I agree using child zones is a better idea, and I'm actually using this, what I
want to hide is the NS records of the internal-only subdomains. OR is the NS
record totally unnecessary if the DNS resolver has these individual zones
(which I don't think so based on how DNS query works).
Kind regards,
Jiaming Zhang
Yixi Meta
Tel: +31 (6) 12 98 08 07
Email: j.zh...@yiximeta.com
Website: yiximeta.com
De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. Aan
dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u deze
e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de
afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail
of informatie uit deze e-mail is alleen toegestaan met voorafgaande
schriftelijke toestemming van de afzender. Het Yixi Meta staat geregistreerd
bij de Kamer van Koophandel in het handelsregister onder nummer 85744115.
The content of this message is intended solely for the addressee. No rights can
be derived from this message or its attachments. If you are not the intended
recipient, we kindly request you to delete the message and inform the sender.
It is strictly prohibited to disclose, copy or distribute this email or the
information inside it, without a written consent from the sender. Yixi Meta is
registered with the Dutch Chamber of Commerce trade register with number
85744115.
Van: Greg Choules
Verzonden: Tuesday, April 18, 2023 2:10:49 PM
Aan: Jiaming Zhang
CC: bind-users@lists.isc.org
Onderwerp: Re: Best practice MultiView
Hi Jiaming.
I had a similar requirement. Since there were not many (a few tens or at most a
hundred) names that needed to be resolved differently locally my approach was
to create a zone for each of them and to not have the parent zone at all. Each
specific zone would contain a single A record (or maybe others) with the owner
name being @ or tha name of the zone.
e.g.:
EXTERNAL zone
example.com<http://example.com>
INTERNAL zones
insite.example.com<http://insite.example.com>
@ A 10.1.1.1
another.example.com<http://another.example.com>
@ A 10.1.1.2
etc...
This way, the default is for all resolution to go externally, except the names
you want to resolve internally with different answers.
Cheers, Greg
On Tue, 18 Apr 2023 at 12:59, Jiaming Zhang
mailto:j.zh...@yiximeta.com>> wrote:
Dear Greg,
The initiative was that we have certain records that wish to be view only
internally and may resolve to private address (e.g. insite A 10.1.1.1).
Kind Regards,
Jiaming Zhang
Yixi Meta
Tel: +31 (6) 12 98 08 07
Email: j.zh...@yiximeta.com<mailto:j.zh...@yiximeta.com>
Website: yiximeta.com<http://yiximeta.com>
De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. Aan
dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u deze
e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de
afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail
of informatie uit deze e-mail is alleen toegestaan met voorafgaande
schriftelijke toestemming van de afzender. Het Yixi Meta staat geregistreerd
bij de Kamer van Koophandel in het handelsregister onder nummer 85744115.
The content of this message is intended solely for the addressee. No rights can
be derived from this message or its attachments. If you are not the intended
recipient, we kindly request you to delete the message and inform the sender.
It is strictly prohibited to disclose, copy or distribute this email or the
information inside it, without a written consent from the sender. Yixi Meta is
registered with the Dutch Chamber of Commerce trade register with number
85744115.
Van: Greg Choules
mailto:gregchoules%2bbindus...@googlemail.com>>
Verzonden: Monday, April 17, 2023 4:43:58 PM
Aan: Jiaming Zhang mailto:j.zh...@yiximeta.com>>
CC: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
mailto:bind-users@lists.isc.org>>
Onderwerp: Re: Best practice MultiView
Hi Jiaming.
The arguments to "also-notify {...};" are explicit IP addresses.
Why do you need it? Do you have some secondaries that are not listed as NS in
zones?
Regarding views. Why would you have the same zone in an internal and external
view? A few years ago, having to maintain multiple zones of the same name but
different contents caused me problems daily. I would recommend having internal
zones be proper delegations from external zones. e.g.:
external "example.com<http://example.com>"
internal "internal.example.com<http://internal.example.com>"
Cheers, Greg
On Mon, 17 Apr 2023 at 14:41, Jiaming Zhang
mailto:j.zh...@yiximeta.com>> wrote:
Dear Nick,
Thanks for the reply. What was already set that I didn't include in my first
mail was that both views on both servers have m
Re: Best practice MultiView
Dear Nick,
The slave config was amended from the master, I don’t need the slave to notify
any other server. I’ll check if any other zones have similar residue left.
Thanks for pointing out.
Kind regards,
Jiaming Zhang
Yixi Meta
Tel: +31 (6) 12 98 08 07
Email: j.zh...@yiximeta.com
Website: yiximeta.com
De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. Aan
dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u deze
e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de
afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail
of informatie uit deze e-mail is alleen toegestaan met voorafgaande
schriftelijke toestemming van de afzender. Het Yixi Meta staat geregistreerd
bij de Kamer van Koophandel in het handelsregister onder nummer 85744115.
The content of this message is intended solely for the addressee. No rights can
be derived from this message or its attachments. If you are not the intended
recipient, we kindly request you to delete the message and inform the sender.
It is strictly prohibited to disclose, copy or distribute this email or the
information inside it, without a written consent from the sender. Yixi Meta is
registered with the Dutch Chamber of Commerce trade register with number
85744115.
Van: bind-users namens Nick Tait via
bind-users
Verzonden: Monday, April 17, 2023 10:58:22 PM
Aan: bind-users@lists.isc.org
Onderwerp: Re: Best practice MultiView
On 18/04/2023 1:40 am, Jiaming Zhang wrote:
However, I got a question on the syntax of also-notify, what I can see from
bind9's user manual, the target of also-notify can be |
[ port ] | [ port ], does
this means that I can use domain names of the server instead of IP? Both name
server has IPv4 (single or multiple) and IPv6 glued with the domain name, and I
was wondering if by setting domain name instead of IP, bind will intelligently
find if it would need to communicate with which IP (like it currently do with
notify yes). I asked because if by any chance for whatever reason sending
notify was failed to a certain IP, it may look up any other available IP that
is defined with the related domain name (at least from my observation).
As Greg said, it needs to be IP addresses, not host names. The documentation
defines "" as follows:
A named list of one or more ip_addresses with optional tls_id, server_key,
and/or port. A remote-servers list may include other remote-servers lists. See
primaries block.
I was also confused what you exactly referred to with '"primaries" (or
"masters" in old terminology) statement that includes the correct key name', I
assume you mean I need to point which is the master and the keys to communicate
with this specific master on the slave server. For the reference, I attached
the related config on slave below.
```
zone "example.com" IN {
type slave;
masters { ; };
file "/path/to/file";
allow-query { any; };
notify yes; # will become "explicit"
};
```
What I was trying to say was the primaries/masters block above needs to include
the key name. Also you may not even need your secondaries (slaves) to send
notifies - unless you have a hierarchical structure where your secondaries need
to notify downstream secondaries? e.g. In the simplest case you might have your
secondaries using:
zone "example.com" IN {
type slave;
masters { 192.0.2.2 key "internal.example.com"; };
file "/path/to/file";
allow-query { any; };
notify no;
};
NB: In all my examples "192.0.2.2" is the primary (master) and "192.0.2.1" is
the secondary (slave).
Nick.
--
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: Potential bug in Bind 9.16.23
Thanks I’ll try download from the official site, it seems oracle’s repo is really slow in catching up new updates. Met vriendelijke groet / Best regards, Jiaming Zhang Van: Ondřej Surý Verzonden: Friday, July 28, 2023 10:09:08 AM Aan: Jiaming Zhang CC: bind-users@lists.isc.org Onderwerp: Re: Potential bug in Bind 9.16.23 The latest BIND 9.16 release is 9.16.42. You either need to upgrade to the latest release, preferably directly to 9.18.17. Alternatively, you should contact the supplier who provided you the outdated version. Ondřej -- 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 28. 7. 2023, at 10:04, Jiaming Zhang wrote: Hi Community, I recently upgraded bind to 9.16.23, and a wired error occurs: the named could not start after the configuration is loaded (and any zone mentioned in the config). However, if loaded with the example config, and after the service is successfully started, I can replace the sample config with the previous config (`mv old.conf sample.conf`), and reconfig with rndc. In which case the Bind behaves totally normal and can also answer every zone it has loaded. I thought in the beginning that there's incompatibility in the conf file between versions, but named-checkconf returns 0 as exit code. bind version info: ``` $ named -V BIND 9.16.23-RH (Extended Support Version) running on Linux aarch64 5.4.17-2136.321.4.el8uek.aarch64 #2 SMP Wed Jun 28 17:52:50 PDT 2023 built by make with '--build=aarch64-redhat-linux-gnu' '--host=aarch64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-python=/usr/libexec/platform-python' '--with-libtool' '--localstatedir=/var' '--with-pic' '--disable-static' '--includedir=/usr/include/bind9' '--with-tuning=large' '--with-libidn2' '--with-maxminddb' '--with-dlopen=yes' '--with-gssapi=yes' '--with-lmdb=yes' '--without-libjson' '--with-json-c' '--enable-dnstap' '--enable-fixed-rrset' '--enable-full-report' 'build_alias=aarch64-redhat-linux-gnu' 'host_alias=aarch64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fasynchronous-unwind-tables -fstack-clash-protection' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig' compiled by GCC 8.5.0 20210514 (Red Hat 8.5.0-18.0.2) compiled with OpenSSL version: OpenSSL 1.1.1k FIPS 25 Mar 2021 linked to OpenSSL version: OpenSSL 1.1.1k FIPS 25 Mar 2021 compiled with libuv version: 1.41.1 linked to libuv version: 1.41.1 compiled with libxml2 version: 2.9.7 linked to libxml2 version: 20907 compiled with json-c version: 0.13.1 linked to json-c version: 0.13.1 compiled with zlib version: 1.2.11 linked to zlib version: 1.2.11 linked to maxminddb version: 1.2.0 compiled with protobuf-c version: 1.3.0 linked to protobuf-c version: 1.3.0 threads support is enabled default paths: named configuration: /etc/named.conf rndc configuration: /etc/rndc.conf DNSSEC root key: /etc/bind.keys nsupdate session key: /var/run/named/session.key named PID file: /var/run/named/named.pid named lock file: /var/run/named/named.lock geoip-directory: /usr/share/GeoIP ` Met vriendelijke groet / Best regards, Jiaming Zhang -- 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
Potential bug in Bind 9.16.23
Hi Community, I recently upgraded bind to 9.16.23, and a wired error occurs: the named could not start after the configuration is loaded (and any zone mentioned in the config). However, if loaded with the example config, and after the service is successfully started, I can replace the sample config with the previous config (`mv old.conf sample.conf`), and reconfig with rndc. In which case the Bind behaves totally normal and can also answer every zone it has loaded. I thought in the beginning that there's incompatibility in the conf file between versions, but named-checkconf returns 0 as exit code. bind version info: ``` $ named -V BIND 9.16.23-RH (Extended Support Version) running on Linux aarch64 5.4.17-2136.321.4.el8uek.aarch64 #2 SMP Wed Jun 28 17:52:50 PDT 2023 built by make with '--build=aarch64-redhat-linux-gnu' '--host=aarch64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-python=/usr/libexec/platform-python' '--with-libtool' '--localstatedir=/var' '--with-pic' '--disable-static' '--includedir=/usr/include/bind9' '--with-tuning=large' '--with-libidn2' '--with-maxminddb' '--with-dlopen=yes' '--with-gssapi=yes' '--with-lmdb=yes' '--without-libjson' '--with-json-c' '--enable-dnstap' '--enable-fixed-rrset' '--enable-full-report' 'build_alias=aarch64-redhat-linux-gnu' 'host_alias=aarch64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fasynchronous-unwind-tables -fstack-clash-protection' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig' compiled by GCC 8.5.0 20210514 (Red Hat 8.5.0-18.0.2) compiled with OpenSSL version: OpenSSL 1.1.1k FIPS 25 Mar 2021 linked to OpenSSL version: OpenSSL 1.1.1k FIPS 25 Mar 2021 compiled with libuv version: 1.41.1 linked to libuv version: 1.41.1 compiled with libxml2 version: 2.9.7 linked to libxml2 version: 20907 compiled with json-c version: 0.13.1 linked to json-c version: 0.13.1 compiled with zlib version: 1.2.11 linked to zlib version: 1.2.11 linked to maxminddb version: 1.2.0 compiled with protobuf-c version: 1.3.0 linked to protobuf-c version: 1.3.0 threads support is enabled default paths: named configuration: /etc/named.conf rndc configuration: /etc/rndc.conf DNSSEC root key: /etc/bind.keys nsupdate session key: /var/run/named/session.key named PID file: /var/run/named/named.pid named lock file: /var/run/named/named.lock geoip-directory: /usr/share/GeoIP ` Met vriendelijke groet / Best regards, Jiaming Zhang -- 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: DNSSEC doubt
Hi Daniel,
As far as from my experience, you’ll need to create a KSK and a ZSK first. But
you can also use script to generate these key pairs. However, it is (at least
with the few registrars I have experience) mandatory to enter your first DS
record manually, and then you could use CDS (if they support querying CDS) for
new keys.
A quick shell syntax for creating key pairs might be:
```bash
# domain=example.com
# root_keydir=/var/named/keys # use whatever you want as long as named has
proper permission to access
# create key directory
mkdir -p "${root_keydir}/${domain}" && cd "${root_keydir}/${domain}"
# KSK
dnssec-keygen -a -b -f KSK $domain
dnssec-keygen-a -b $domain
# what I usually do also (to correct ownership), don't use this kind of
wildcard if you keep everything in one dir:
crown named:named ./K*
# if not already done add config to your config file, with key-directory
specified
# you can also store the DS record to file or send them via API but to retrieve
them
dnssec-dsfromkey
```
Met vriendelijke groet / Best regards,
Jiaming Zhang
Yixi Meta
Email: j.zh...@yiximeta.com
Website: yiximeta.com
De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. Aan
dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u deze
e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de
afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail
of informatie uit deze e-mail is alleen toegestaan met voorafgaande
schriftelijke toestemming van de afzender. Het Yixi Meta staat geregistreerd
bij de Kamer van Koophandel in het handelsregister onder nummer 85744115.
The content of this message is intended solely for the addressee. No rights can
be derived from this message or its attachments. If you are not the intended
recipient, we kindly request you to delete the message and inform the sender.
It is strictly prohibited to disclose, copy or distribute this email or the
information inside it, without a written consent from the sender. Yixi Meta is
registered with the Dutch Chamber of Commerce trade register with number
85744115.
Van: bind-users namens Daniel A. Rodriguez
via bind-users
Verzonden: Thursday, June 22, 2023 7:47:55 PM
Aan: bind-users@lists.isc.org
Onderwerp: DNSSEC doubt
I wonder if it's mandatory make a manual deployment prior to an automated setup.
--
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: Update to 9.18 failed due to libuv
Then I should download the source, there's no devel package for this one in the repo. Met vriendelijke groet / Best regards, Jiaming Zhang Yixi Meta Tel: +31 (0)85 800 99 88 / +31 (0)6 12 98 08 07 Email: j.zh...@yiximeta.com Website: yiximeta.com De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. Aan dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u deze e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail of informatie uit deze e-mail is alleen toegestaan met voorafgaande schriftelijke toestemming van de afzender. Het Yixi Meta staat geregistreerd bij de Kamer van Koophandel in het handelsregister onder nummer 85744115. The content of this message is intended solely for the addressee. No rights can be derived from this message or its attachments. If you are not the intended recipient, we kindly request you to delete the message and inform the sender. It is strictly prohibited to disclose, copy or distribute this email or the information inside it, without a written consent from the sender. Yixi Meta is registered with the Dutch Chamber of Commerce trade register with number 85744115. Van: Anand Buddhdev Verzonden: Monday, March 4, 2024 2:04:35 PM Aan: Jiaming Zhang ; bind-users@lists.isc.org Onderwerp: Re: Update to 9.18 failed due to libuv On 04/03/2024 13:56, Jiaming Zhang wrote: Hi Jiaming, > Recently I was trying to upgrade bind from 9.16 to 9.18. However, running > `./configure` return an error stating the `libuv` was not found. I have this > library installed (version 1.41.1) via dnf, and can can find it using `rpm > -ql` which shows the library is under `/usr/lib64`. I'm using Oracle Linux 8 > (RHEL 8 compatible). When compiling BIND, you need the development header files for libuv, so you have to install the "libuv-devel" package. 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
Update to 9.18 failed due to libuv
Dear community, Recently I was trying to upgrade bind from 9.16 to 9.18. However, running `./configure` return an error stating the `libuv` was not found. I have this library installed (version 1.41.1) via dnf, and can can find it using `rpm -ql` which shows the library is under `/usr/lib64`. I'm using Oracle Linux 8 (RHEL 8 compatible). My questions are: 1) is there a way to specify the location of the respective library file during the configuration; and 2) if not, is there a walk around? (download the source maybe, but is there another way?) Thanks in advance. ps. I tried using the isc/bind repo, but it seems they offer only x86-64 binary, no src, no arm. Regards, Jimmy -- 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
