Re: DNSSEC Private OIDs RR
Gabriel Gbs wrote: > In case that this is not possible out of the box, where should I start in > source code doing some modifications or workarounds? Have a look in lib/dns/dst_* and lib/dns/openssl_* Tony. -- f.anthony.n.finchhttp://dotat.at/ a world in which all people share the same basic rights ___ 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
DNSSEC Private OIDs RR
Hello, I would like to get some hints on how can I do to set up bind9 in order to implement a new signing algorithm. rfc4034 states that a private OID (254 alg type) type has to be used. I would have an OpenSSL engine that implements this said algorithm, which registers this new algorithm. It is not a business case, but for academic and learning purposes. In case that this is not possible out of the box, where should I start in source code doing some modifications or workarounds? Thanks in advance. ___ 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: Localhost view is not working for me
Try without the "match-destinations". Only use match-clients to determine
the view. (Or try only match-destinations as a separate test.)
(I have never used match-destinations.)
Turn on query logging and see what source and destination your queries are
using. Make fake queries to unique names just to be sure which queries you
are looking at.
That's the best that I can suggest.
--
Bob Harold
On Mon, Mar 30, 2020 at 1:07 PM Marc Chamberlin via bind-users <
bind-users@lists.isc.org> wrote:
> Hello - I am running the Bind server
>
> > named -v
> BIND 9.11.2
>
> under OpenSuSE Leap 15.0. In order to support other servers running on the
> same system that my Bind server is running on I am trying to set up 3
> views, one for the localhost, one for my internal network to use, and one
> for the external Internet. (yes this is also a gateway system with 2 NIC
> cards.) What I am having troubles with is getting the localhost view to
> work properly. I have tried a number of ways to get this to work and will
> show the apropos segment of my named.conf file below. Commented out
> sections show things I have tried already but rejected because the results
> I get from queries, from other servers on this gateway/localhost system,
> that are not what I want. For example if I use the definition in with
> localhost is defined, rather than 127.0.0.1, I will get results that are
> defined by my internal view which is not acceptable. If I use 127.0.0.1
> instead, lookup query results from/for the other servers running on my
> gateway/localhost fail completely with no results returned. I don't
> understand why 127.0.0.1 fails, it seems like this should be the proper way
> to limit the scope of localhost queries so that they are answered by
> definitions defined in my "localhost_resolver" view. What am I missing?
> How to I set up the "localhost_resolver" view so that it will answer
> queries from localhost without falling through to my "internal" view?
> (The keys are also necessary to restrict certain types of queries but I
> tried not using them and got the same inadequate responses to queries from
> the localhost.)
>
> I have also used dig to show exactly what view was answering queries from
> localhost and it verified that the queries were indeed being answered by my
> internal view when I used localhost in the match-clients and
> match-destinations statements. If necessary I can post other files, such
> as the local_zones.conf or some of the domain definition files themselves
> but will have to edit them to remove actual URLs and other sensitive
> information. I checked the log files also, after setting the debug level
> to 10, and the Bind server reports no errors or warnings when it is started
> up. Thanks for any help offered, and below is what I think is the relevant
> part of my named.conf file.
>
> Marc
>
> view "localhost_resolver"
> {
> //match-clients { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; localhost; };
> //match-destinations { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; localhost; };
>
> match-clients { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; 127.0.0.1; };
> match-destinations { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; 127.0.0.1; };
>
> // match-clients { 127.0.0.1; };
> // match-destinations { 127.0.0.1; };
>
> recursion yes;
> zone "." in {
> type hint;
> file "root.hint";
> };
> zone "localhost" in {
> type master;
> file "localhost.zone";
> allow-update { none; };
> };
> zone "0.0.127.in-addr.arpa" in {
> type master;
> file "127.0.0.zone";
> allow-update { none; };
> };
> zone
> "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" in
> {
> type master;
> file "127.0.0.zone";
> };
> include "/etc/named.d/local/local_zones.conf";
> };
>
> view "internal" { // What the home network will see
> // match-clients { ! key letsencrypt.; ! key rndc-key.; ! key
> letsencrypt_amcrest.; localnets; localhost; };
> // match-destinations { ! key letsencrypt.; ! key rndc-key.; ! key
> letsencrypt_amcrest.; localnets; localhost; };
>
> // match-clients { ! key letsencrypt.; ! key rndc-key.; ! key
> letsencrypt_amcrest.; 192.168.10.0/24; 127.0.0.1; };
> // match-destinations { ! key letsencrypt.; ! key rndc-key.; ! key
> letsencrypt_amcrest.; 192.168.10.0/24; 127.0.0.1; };
>
> match-clients { ! key letsencrypt.; ! key rndc-key.; ! key
> letsencrypt_amcrest.; 192.168.10.0/24; };
> match-destinations { ! key letsencrypt.; ! key rndc-key.; ! key
> letsencrypt_amcrest.; 192.168.10.0/24; };
>
> // match-clients { 192.168.10.0/24; };
> // match-destinations { 192.168.10.0/24; };
Re: BIND 9.16.1: unable to set effective uid to 0: Operation not permitted
Yup, I got this error on 9.14.7 running on CentOS 7.7 > On Mar 30, 2020, at 1:31 PM, Mike Lewinski > wrote: > > This error (unable to set effective uid to 0: Operation not permitted) was > reported a year ago where it affected BIND 9.14.0: > https://lists.isc.org/mailman/htdig/bind-users/2019-March/101582.html > > I can confirm this error still exists in the most recent isc/bind copr > version 9.16.1 installed on CentOS 7 using the reference caching-only > resolver configuration from the Bv9ARM. > > The process is running with this command line: > /opt/isc/isc-bind/root/usr/sbin/named -u named > > It is started from the unmodified copr installation of > /usr/lib/systemd/system/isc-bind-named.service > > [Unit] > After=network.target > Wants=nss-lookup.target > Before=nss-lookup.target > > [Service] > Type=forking > EnvironmentFile=-/etc/opt/isc/isc-bind/sysconfig/named > PIDFile=/var/opt/isc/isc-bind/run/named/named.pid > ExecStart=/opt/isc/isc-bind/root/usr/sbin/named -u named $OPTIONS > ExecReload=/bin/kill -HUP $MAINPID > ExecStop=/bin/kill -TERM $MAINPID > PrivateTmp=true > > [Install] > WantedBy=multi-user.target > > I've been trying to track down a (probably) unrelated dnssec issue resolving > theoptimalfinancialgroup.com and this error has distracted me from my > investigation. > > Mike > > > > ___ > 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 ___ 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
BIND 9.16.1: unable to set effective uid to 0: Operation not permitted
This error (unable to set effective uid to 0: Operation not permitted) was reported a year ago where it affected BIND 9.14.0: https://lists.isc.org/mailman/htdig/bind-users/2019-March/101582.html I can confirm this error still exists in the most recent isc/bind copr version 9.16.1 installed on CentOS 7 using the reference caching-only resolver configuration from the Bv9ARM. The process is running with this command line: /opt/isc/isc-bind/root/usr/sbin/named -u named It is started from the unmodified copr installation of /usr/lib/systemd/system/isc-bind-named.service [Unit] After=network.target Wants=nss-lookup.target Before=nss-lookup.target [Service] Type=forking EnvironmentFile=-/etc/opt/isc/isc-bind/sysconfig/named PIDFile=/var/opt/isc/isc-bind/run/named/named.pid ExecStart=/opt/isc/isc-bind/root/usr/sbin/named -u named $OPTIONS ExecReload=/bin/kill -HUP $MAINPID ExecStop=/bin/kill -TERM $MAINPID PrivateTmp=true [Install] WantedBy=multi-user.target I've been trying to track down a (probably) unrelated dnssec issue resolving theoptimalfinancialgroup.com and this error has distracted me from my investigation. Mike ___ 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
Localhost view is not working for me
Hello - I am running the Bind server
> named -v
BIND 9.11.2
under OpenSuSE Leap 15.0. In order to support other servers running on
the same system that my Bind server is running on I am trying to set up
3 views, one for the localhost, one for my internal network to use, and
one for the external Internet. (yes this is also a gateway system with
2 NIC cards.) What I am having troubles with is getting the localhost
view to work properly. I have tried a number of ways to get this to work
and will show the apropos segment of my named.conf file below.
Commented out sections show things I have tried already but rejected
because the results I get from queries, from other servers on this
gateway/localhost system, that are not what I want. For example if I
use the definition in with localhost is defined, rather than 127.0.0.1,
I will get results that are defined by my internal view which is not
acceptable. If I use 127.0.0.1 instead, lookup query results from/for
the other servers running on my gateway/localhost fail completely with
no results returned. I don't understand why 127.0.0.1 fails, it seems
like this should be the proper way to limit the scope of localhost
queries so that they are answered by definitions defined in my
"localhost_resolver" view. What am I missing? How to I set up the
"localhost_resolver" view so that it will answer queries from localhost
without falling through to my "internal" view? (The keys are also
necessary to restrict certain types of queries but I tried not using
them and got the same inadequate responses to queries from the localhost.)
I have also used dig to show exactly what view was answering queries
from localhost and it verified that the queries were indeed being
answered by my internal view when I used localhost in the match-clients
and match-destinations statements. If necessary I can post other files,
such as the local_zones.conf or some of the domain definition files
themselves but will have to edit them to remove actual URLs and other
sensitive information. I checked the log files also, after setting the
debug level to 10, and the Bind server reports no errors or warnings
when it is started up. Thanks for any help offered, and below is what I
think is the relevant part of my named.conf file.
Marc
> view "localhost_resolver"
> {
> // match-clients { ! key letsencrypt.; ! key
> rndc-key.; ! key letsencrypt_amcrest.; localhost; };
> // match-destinations { ! key letsencrypt.; ! key
> rndc-key.; ! key letsencrypt_amcrest.; localhost; };
>
> match-clients { ! key letsencrypt.; ! key rndc-key.;
> ! key letsencrypt_amcrest.; 127.0.0.1; };
> match-destinations { ! key letsencrypt.; ! key rndc-key.;
> ! key letsencrypt_amcrest.; 127.0.0.1; };
>
> // match-clients { 127.0.0.1; };
> // match-destinations { 127.0.0.1; };
>
> recursion yes;
> zone "." in {
> type hint;
> file "root.hint";
> };
> zone "localhost" in {
> type master;
> file "localhost.zone";
> allow-update { none; };
> };
> zone "0.0.127.in-addr.arpa" in {
> type master;
> file "127.0.0.zone";
> allow-update { none; };
> };
> zone
> "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa"
> in {
> type master;
> file "127.0.0.zone";
> };
> include "/etc/named.d/local/local_zones.conf";
> };
>
> view "internal" { // What the home network will see
> // match-clients { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; localnets; localhost; };
> // match-destinations { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; localnets; localhost; };
>
> // match-clients { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; 192.168.10.0/24; 127.0.0.1; };
> // match-destinations { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; 192.168.10.0/24; 127.0.0.1; };
>
> match-clients { ! key letsencrypt.; ! key rndc-key.; ! key
> letsencrypt_amcrest.; 192.168.10.0/24; };
> match-destinations { ! key letsencrypt.; ! key rndc-key.; ! key
> letsencrypt_amcrest.; 192.168.10.0/24; };
>
> // match-clients { 192.168.10.0/24; };
> // match-destinations { 192.168.10.0/24; };
>
> recursion yes;
> zone "." in {
> type hint;
> file "root.hint";
> };
> include "/etc/named.d/internal/internal_zones.conf";
> };
> view "external" { // What the Internet will see
> match-clients { any; };
> match-destinations { any; };
> recursion no;
> include "/etc/named.d/external/external_zones.conf";
> };
--
--... ...-- .. ...-.. ..-- .- --... .--. -..- .-- --
.- .-. -.-.
*Computers: the final frontier. These are the voyages of the user Marc.
His mission: to explore strange new
