Re: RPZ zone response delay time ?
On Fri, 2023-04-07 at 17:27 +0100, Jason Vas Dias wrote: > > *.google-analytics.com A 0.0.0.0 > *.clarity.ms A 0.0.0.0 > *.adtelligent.com A 0.0.0.0 > > (there are over 15,000 entries in it). > > This serves to speed up my internet accesses about 10 times, > normally, and acts great as an ad+spyware site blocker, > like a do-it-yourself RBL list. > > I create a static route at boot-up : > > blackhole 0.0.0.0/8 A /8 blackhole route will not win from the 0.0.0.0/32 "route" (it is implicit, but you can see it with `ip route get` on Linux) that goes to your local system. 0.0.0.0 is not the right DNS response here, or almost anywhere. NXDOMAIN likely fits better. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ -- 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-validation?
Hello and thank you for the reply. My domain is "di.ubi.pt". The parent domain "ubi.pt" recently configured DNSSEC (BIND 9.11) so it was time again for me to try to set it up for my domain. A few months ago I updated both dns servers to Oracle Linux 8, running BIND 9.16.23 to prepare for this. They seem to be working fine as previously, running as both recursive and authoritative for di.ubi.pt. DNS2 has still "dnssec-validation auto;" on its /etc/named.conf. I've found out that if I wanted my primary server to start answering my internal requests for outside "di.ubi.pt" I had to change dnssec-validation to "no". I still don't understand why, to be honest. Yesterday I set dnssec-validation to auto on my primary server, but as I wrote before, although outside tools showed everything was fine, my server kept answering "SERVFAIL" to my client queries. I don't think I tested dnssec-validation to no when dnssec was enabled, nor if this makes much sense, but I can try. Kind regards David On Wed, Apr 12, 2023 at 05:41:33PM +0100, David Carvalho via bind-users wrote: > After reverting my primary dns configuration, and asking my provider > to remove the DNSKEY, I had to include dnssec-validation no; otherwise > it would keep answering with SERVFAIL > > I noticed the server was constantly trying to reach top domain dns servers. > > Is this dnssec-validation mandatory? Any help appreciated. dnssec-validation can be set three ways: - "no" (validation is never performed) - "yes" (validation *may* be performed, but only if you have also configured a trust anchor in named.conf) - "auto" (validation will be performed using the standard root zone trust anchor, which is built in to BIND and doesn't need to be configured by hand). The default is "auto". When it's set to that, your server will query the root name servers in order to confirm that the automatically-configured trust anchor is correct. You said it was "trying to" reach the root, which suggests it wasn't succeeding? If so, that would explain why everything that wasn't locally authoritative would return SERVFAIL. Note that this is related to *recursive* queries, that is, queries for zones that are not served by your secondary server. It should have nothing to do with whether your own domain is signed, or whether there's a DS record for it in the parent zone. My guess is, you had the authoritative configuration working fine (otherwise presumably dnssec-analyzer would've complained), but recursive isn't working. Unfortunately, since you haven't provided any configuration info or even the name of the domain you were trying to set up, I can't make any more educated guesses than that. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- 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: Fully automated DNSSEC with BIND 9.16
1. Everytime I restart the service, it seems all these files are recreated. How did you observe this? Just by file timestamps or actual content? And just to be sure to ask the obvious: you are not manually removing these files are you? :) -JP -- 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-validation?
Hello again. Problem number 1: Dnssec seems to be running on "di.ubi.pt", but dnssec-validation still needs to be set to no; Will this cause troubles? Dns2 is set to auto and runs fine. Problem number 2: How can I avoid the key regeneration (using version 9.16.23) every named restart? Kind regards, David Carvalho -Original Message- From: Evan Hunt Sent: 12 April 2023 18:08 To: David Carvalho Cc: bind-users@lists.isc.org Subject: Re: dnssec-validation? On Wed, Apr 12, 2023 at 05:41:33PM +0100, David Carvalho via bind-users wrote: > After reverting my primary dns configuration, and asking my provider > to remove the DNSKEY, I had to include dnssec-validation no; otherwise > it would keep answering with SERVFAIL > > I noticed the server was constantly trying to reach top domain dns servers. > > Is this dnssec-validation mandatory? Any help appreciated. dnssec-validation can be set three ways: - "no" (validation is never performed) - "yes" (validation *may* be performed, but only if you have also configured a trust anchor in named.conf) - "auto" (validation will be performed using the standard root zone trust anchor, which is built in to BIND and doesn't need to be configured by hand). The default is "auto". When it's set to that, your server will query the root name servers in order to confirm that the automatically-configured trust anchor is correct. You said it was "trying to" reach the root, which suggests it wasn't succeeding? If so, that would explain why everything that wasn't locally authoritative would return SERVFAIL. Note that this is related to *recursive* queries, that is, queries for zones that are not served by your secondary server. It should have nothing to do with whether your own domain is signed, or whether there's a DS record for it in the parent zone. My guess is, you had the authoritative configuration working fine (otherwise presumably dnssec-analyzer would've complained), but recursive isn't working. Unfortunately, since you haven't provided any configuration info or even the name of the domain you were trying to set up, I can't make any more educated guesses than that. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- 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: Fully automated DNSSEC with BIND 9.16
Hello. Both content and timestamps. I've been told previously here that there is a bug prior to version 9.16.30. I'm using 9.16.23, no update available yet. No, not removing 😉 Regards David -Original Message- From: bind-users On Behalf Of Jan-Piet Mens Sent: 13 April 2023 11:12 To: bind-users@lists.isc.org Subject: Re: Fully automated DNSSEC with BIND 9.16 >1. Everytime I restart the service, it seems all these files are recreated. How did you observe this? Just by file timestamps or actual content? And just to be sure to ask the obvious: you are not manually removing these files are you? :) -JP -- 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: Fully automated DNSSEC with BIND 9.16
> On 13. 4. 2023, at 15:25, David Carvalho via bind-users > wrote: > > I'm using 9.16.23 Just don't. ISC provides packages for major linux distributions (https://www.isc.org/download/), so there's really no reason to shoot yourself into foot to use a random BIND 9 snapshot provided by your distro. And while you are at it - upgrade straight to latest 9.18, your experience will be much smoother. 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. -- 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: Fully automated DNSSEC with BIND 9.16
Hello and thanks for the reply. I enabled this repo in Oracle Linux 8 with: dnf copr enable isc/bind Then I tried to install (dnf install isc-bind) but I got: Error: Problem: package isc-bind-1:2-3.el8.x86_64 requires isc-bind-bind, but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libbind9-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libdns-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libisc-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libisccc-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libisccfg-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libns-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires isc-bind-bind-libs = 9.18.13, but none of the providers can be installed - conflicting requests - nothing provides libjemalloc.so.2()(64bit) needed by isc-bind-bind-libs-9.18.13-1.1.el8.x86_64 (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) This is the main reason I usually stick with provided packages. Kind regards David -Original Message- From: Ondřej Surý Sent: 13 April 2023 14:40 To: David Carvalho Cc: Bind Users Mailing List Subject: Re: Fully automated DNSSEC with BIND 9.16 > On 13. 4. 2023, at 15:25, David Carvalho via bind-users > wrote: > > I'm using 9.16.23 Just don't. ISC provides packages for major linux distributions (https://www.isc.org/download/), so there's really no reason to shoot yourself into foot to use a random BIND 9 snapshot provided by your distro. And while you are at it - upgrade straight to latest 9.18, your experience will be much smoother. 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. -- 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: Fully automated DNSSEC with BIND 9.16
On 13/04/2023 17:17, David Carvalho via bind-users wrote: Hi David, Hello and thanks for the reply. I enabled this repo in Oracle Linux 8 with: dnf copr enable isc/bind Then I tried to install (dnf install isc-bind) but I got: Error: Problem: package isc-bind-1:2-3.el8.x86_64 requires isc-bind-bind, but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libbind9-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libdns-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libisc-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libisccc-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libisccfg-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires libns-9.18.13.so()(64bit), but none of the providers can be installed - package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires isc-bind-bind-libs = 9.18.13, but none of the providers can be installed - conflicting requests - nothing provides libjemalloc.so.2()(64bit) needed by isc-bind-bind-libs-9.18.13-1.1.el8.x86_64 (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) BIND 9.18 and newer require jemalloc, but this package isn't part of Redhat base. You also need to enable the EPEL repository for this. With Oracle Linux, there are 2 different EPELs available. Oracle's own rebuild of EPEL packages, and the Fedora EPEL. My personal preference is the Fedora EPEL repo, which you can install with: dnf -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm Then you should be able to install the ISC BIND packages. 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: Fully automated DNSSEC with BIND 9.16
Hello and thank you for the reply. I can confirm my current dns servers have already EPEL repo enabled and jemalloc package is available. I'll setup my test machine accordingly to be able to install BIND 9.18. Will it also provide named-chroot (is it really necessary?) Thanks! David -Original Message- From: Anand Buddhdev Sent: 13 April 2023 16:48 To: David Carvalho Cc: 'Bind Users Mailing List' Subject: Re: Fully automated DNSSEC with BIND 9.16 On 13/04/2023 17:17, David Carvalho via bind-users wrote: Hi David, > Hello and thanks for the reply. > I enabled this repo in Oracle Linux 8 with: dnf copr enable isc/bind > > Then I tried to install (dnf install isc-bind) but I got: > Error: > Problem: package isc-bind-1:2-3.el8.x86_64 requires isc-bind-bind, but none > of the providers can be installed >- package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires > libbind9-9.18.13.so()(64bit), but none of the providers can be installed >- package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires > libdns-9.18.13.so()(64bit), but none of the providers can be installed >- package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires > libisc-9.18.13.so()(64bit), but none of the providers can be installed >- package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires > libisccc-9.18.13.so()(64bit), but none of the providers can be installed >- package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires > libisccfg-9.18.13.so()(64bit), but none of the providers can be installed >- package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires > libns-9.18.13.so()(64bit), but none of the providers can be installed >- package isc-bind-bind-9.18.13-1.1.el8.x86_64 requires isc-bind-bind-libs > = 9.18.13, but none of the providers can be installed >- conflicting requests >- nothing provides libjemalloc.so.2()(64bit) needed by > isc-bind-bind-libs-9.18.13-1.1.el8.x86_64 > (try to add '--skip-broken' to skip uninstallable packages or > '--nobest' to use not only best candidate packages) BIND 9.18 and newer require jemalloc, but this package isn't part of Redhat base. You also need to enable the EPEL repository for this. With Oracle Linux, there are 2 different EPELs available. Oracle's own rebuild of EPEL packages, and the Fedora EPEL. My personal preference is the Fedora EPEL repo, which you can install with: dnf -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm Then you should be able to install the ISC BIND packages. 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: dnssec-validation?
On Thu, Apr 13, 2023 at 11:38:15AM +0100, David Carvalho wrote: > Problem number 1: Dnssec seems to be running on "di.ubi.pt", but > dnssec-validation still needs to be set to no; Will this cause troubles? > Dns2 is set to auto and runs fine. >From here, di.ubt.pt appears to be properly signed and everything's working from here. Turning off validation won't have any affect on that. Your only problem is with local recursive service. > Problem number 2: How can I avoid the key regeneration (using version > 9.16.23) every named restart? I'm not certain what you mean by key regeneration. Taking a stab in the dark: Check that the working directory for named is writable. If named can't write files, then it can't save trust anchor status across restarts and it has to reinitialize each time. If that doesn't turn out to be the problem, then can show me the relevant lines from your log file so I can see what you're referring to by "key regeneration"? -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- 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-validation?
Hello and thank you for the reply. Problem 1 - I'll have to investigate further. As for problem 2 ... it's weird. I was working on another thing and now I was checking permissions by your suggestion, when I noticed the files have new timestamp from a while ago. I compared the contents of the updated files with a previous backup and they seem the same. Tests such as https://dnssec-analyzer.verisignlabs.com/di.ubi.pt also seem to be still fine. So, my conclusion is: Named changes the Kdi.ubi.pt** timestamps according to some criteria. If I do a systemctl restart named-chroot or rdnc reload, the contents also change (and according to a response I got earlier this is a bug solved in version 9.16.30) I've been told to upgrade to version 9.18 and I'm setting a test server to do this. In the meantime, if there is a way to avoid the keys to be rewritten every time I reconfigure and reload, I would stick with this version. Regards David -Original Message- From: Evan Hunt Sent: 13 April 2023 18:08 To: David Carvalho Cc: bind-users@lists.isc.org Subject: Re: dnssec-validation? On Thu, Apr 13, 2023 at 11:38:15AM +0100, David Carvalho wrote: > Problem number 1: Dnssec seems to be running on "di.ubi.pt", but > dnssec-validation still needs to be set to no; Will this cause troubles? > Dns2 is set to auto and runs fine. >From here, di.ubt.pt appears to be properly signed and everything's >working from here. Turning off validation won't have any affect on that. Your only problem is with local recursive service. > Problem number 2: How can I avoid the key regeneration (using version > 9.16.23) every named restart? I'm not certain what you mean by key regeneration. Taking a stab in the dark: Check that the working directory for named is writable. If named can't write files, then it can't save trust anchor status across restarts and it has to reinitialize each time. If that doesn't turn out to be the problem, then can show me the relevant lines from your log file so I can see what you're referring to by "key regeneration"? -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- 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
Reverse Policy Zone to make MS Azure stuff work?
Due to a requirement to use something Microsoft crafted, we are being asked to assert (internally) authority over 3rd-level names under appserviceenvironment.net I've pushed back on this, because I don't think it's nice to publish "authoritative" answers in domains we have not been delegated. But I'm told it's all ok, because Microsoft says its ok* Having accepted that the ship has sailed, it's now a question of how to deliver such answers. One obvious way is to define a zone for each 3rd level under appserviceenvironment.net, and publish them in a way our resolvers can find them. In the absence of catalog-zones, this could be a lot of additional work (for me). Then I wondered if adding these 'hijacked' names to our RPZ would meet the need. I first thought, "Yeah. It'll work.", but then I re-read the statement from MS saying each 3rd level was going to need to have a 4th level zone defined. A zone definition requires at least an SOA and NS record . . and last time I checked, an RPZ would not deliver an NS record. So it seems that idea may be squashed. Who else has need to publish locally-defined appserviceenvironment.net names? Were you able to do it with your RPZ? * https://learn.microsoft.com/en-us/azure/app-service/environment/create-ilb-ase -- -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska -- 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: Reverse Policy Zone to make MS Azure stuff work?
On Friday, 14 April 2023 00:28:24 CEST John Thurston wrote:
> Due to a requirement to use something Microsoft crafted, we are being
> asked to assert (internally) authority over 3rd-level names under
> appserviceenvironment.net
>
> I've pushed back on this, because I don't think it's nice to publish
> "authoritative" answers in domains we have not been delegated. But I'm
> told it's all ok, because Microsoft says its ok* Having accepted that
> the ship has sailed, it's now a question of how to deliver such answers.
>
> One obvious way is to define a zone for each 3rd level under
> appserviceenvironment.net, and publish them in a way our resolvers can
> find them. In the absence of catalog-zones, this could be a lot of
> additional work (for me).
>
> Then I wondered if adding these 'hijacked' names to our RPZ would meet
> the need. I first thought, "Yeah. It'll work.", but then I re-read the
> statement from MS saying each 3rd level was going to need to have a 4th
> level zone defined. A zone definition requires at least an SOA and NS
> record . . and last time I checked, an RPZ would not deliver an NS
> record. So it seems that idea may be squashed.
>
> Who else has need to publish locally-defined appserviceenvironment.net
> names? Were you able to do it with your RPZ?
>
> *
> https://learn.microsoft.com/en-us/azure/app-service/environment/create-ilb-a
> se
Hello John,
For what it's worth, I've been working on Microsoft related domains in an RPZ
recently as
well. The way I've done this is by defining a zone "rpz.local" in my
named.conf, as shown
below.
// Response Policy Zone
zone "rpz.local" {
type master;
file "/etc/bind/zones/rpz.local.db";
allow-update { none; };
allow-transfer { internal; };
allow-query { localhost; };
};
Then I define in this rpz.local.db file, entries like the ones below.
$TTL 300
@ IN SOA localhost. need.to.know.only. (
202303131 ; Serial number
60 ; Refresh every minute
60 ; Retry every minute
43200 ; Expire in 5 days
60 ); Negative cache TTL 1 minute
IN NS LOCALHOST.
; Examples
block.example.com IN CNAME .
passthrough.example.com IN CNAME rpz-passthru.
redirect.example.comIN CNAME example.com.
Pay special attention to the lack of a final dot in the records themselves,
this is important.
As far as I understand, this makes them relative to your rpz.local zone, not
the actual
domain on the internet. The only major issue I've been facing with this so far,
is that AXFR
to secondary and tertiary name servers has some issues, and at least Windows 10
Home
will query those when the primary name server does not give a satisfactory
answer.
--
Met vriendelijke groet / Best regards,
Michael De Roover
--
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: Reverse Policy Zone to make MS Azure stuff work?
Create a catalog zone and use that to distribute the zone configuration to all your recursive servers. As for using a zone that is not delegated to you. Microsoft own appserviceenvironment.net and are telling you to use it this way. This is no different to the IETF saying you can have your own 10.in-addra.arpa for RFC 1918 addresses. Mark > On 14 Apr 2023, at 08:28, John Thurston wrote: > > Due to a requirement to use something Microsoft crafted, we are being asked > to assert (internally) authority over 3rd-level names under ç > I've pushed back on this, because I don't think it's nice to publish > "authoritative" answers in domains we have not been delegated. But I'm told > it's all ok, because Microsoft says its ok* Having accepted that the ship has > sailed, it's now a question of how to deliver such answers. > One obvious way is to define a zone for each 3rd level under > appserviceenvironment.net, and publish them in a way our resolvers can find > them. In the absence of catalog-zones, this could be a lot of additional work > (for me). > Then I wondered if adding these 'hijacked' names to our RPZ would meet the > need. I first thought, "Yeah. It'll work.", but then I re-read the statement > from MS saying each 3rd level was going to need to have a 4th level zone > defined. A zone definition requires at least an SOA and NS record . . and > last time I checked, an RPZ would not deliver an NS record. So it seems that > idea may be squashed. > Who else has need to publish locally-defined appserviceenvironment.net names? > Were you able to do it with your RPZ? > * > https://learn.microsoft.com/en-us/azure/app-service/environment/create-ilb-ase > > -- > -- > Do things because you should, not just because you can. > > John Thurston 907-465-8591 > john.thurs...@alaska.gov > Department of Administration > State of Alaska > -- > 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
Re: Reverse Policy Zone to make MS Azure stuff work?
Another thing I forgot to mention, is the need to express these parameters in
the options clause in named.conf:
options {
// RPZ zone
// Source: https://deteque.com/m3aawg-bind-training/named.conf
response-policy {
zone "rpz.local";
};
};
My apologies for not double-checking earlier, but I think this should be
everything.
--
Met vriendelijke groet / Best regards,
Michael De Roover
signature.asc
Description: This is a digitally signed message part.
--
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-validation?
> On 13 Apr 2023, at 19:23, David Carvalho via bind-users > wrote: > > Hello and thank you for the reply. > My domain is "di.ubi.pt". The parent domain "ubi.pt" recently configured > DNSSEC (BIND 9.11) so it was time again for me to try to set it up for my > domain. > > A few months ago I updated both dns servers to Oracle Linux 8, running BIND > 9.16.23 to prepare for this. > They seem to be working fine as previously, running as both recursive and > authoritative for di.ubi.pt. > > DNS2 has still "dnssec-validation auto;" on its /etc/named.conf. > I've found out that if I wanted my primary server to start answering my > internal requests for outside "di.ubi.pt" I had to change dnssec-validation > to "no". > I still don't understand why, to be honest. Look at your logs. If named is having problems it will be logging error messages. What does "rndc managed-keys status” report? % rndc managed-keys status view: secure next scheduled event: Fri, 14 Apr 2023 02:04:19 GMT name: . keyid: 20326 algorithm: RSASHA256 flags: SEP next refresh: Sat, 15 Apr 2023 00:53:04 GMT trusted since: Fri, 11 Aug 2017 01:07:03 GMT view: forward next scheduled event: Fri, 14 Apr 2023 02:04:19 GMT name: . keyid: 20326 algorithm: RSASHA256 flags: SEP next refresh: Sat, 15 Apr 2023 00:53:04 GMT trusted since: Tue, 10 May 2022 05:09:01 GMT view: external next scheduled event: Fri, 14 Apr 2023 03:04:19 GMT name: . keyid: 20326 algorithm: RSASHA256 flags: SEP next refresh: Fri, 14 Apr 2023 03:04:19 GMT trusted since: Thu, 10 Aug 2017 13:01:30 GMT % Are you using a forwarder? Does the forwarder support DNSSEC? Do you have an overly restrictive firewall? What does “dig +cd +dnssec +multi . DNSKEY” return? % dig +cd +dnssec +multi . DNSKEY ;; BADCOOKIE, retrying. ; <<>> DiG 9.19.11-dev <<>> +cd +dnssec +multi . DNSKEY ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10255 ;; flags: qr rd ra ad cd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; COOKIE: 9c2f2034f253efff01006438ad22999ed76ba1835477 (good) ;; QUESTION SECTION: ;. IN DNSKEY ;; ANSWER SECTION: . 88321 IN DNSKEY 257 3 8 ( AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTO iW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN 7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5 LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8 efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7 pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLY A4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws 9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ) ; KSK; alg = RSASHA256 ; key id = 20326 . 88321 IN DNSKEY 256 3 8 ( AwEAAbF1LAxEQPtClEQno48k6u7JjCOfVfwdENOxQUrX 0JbpN5DnKGMAKIfdiWa5oDeKQ3OoQ58yCC8vjtaaGFDg pJxoLwqzhBYHPGFgins5HIERcCQPGAJKWu/ku4XLh+Fu 7UyBubDCelxKTbnj26EwbochltRqGIE8hbwSXEzRNo4g +NXkaRMq2FFbaBtEE82yTmZUgFRYAFUvfGTPWblyZGtk epVuHyNb0w/u24dpsz+uyCZZR04cHfRrWOKvqD3lDOwC 4+sqd6f7F841R0N2tqSh/WDUZzWdvPBaBOz0FWFLb9po rIeZ3Jm08tAMHa+3SGRXfK4RAmxVCmIQQypGabE= ) ; ZSK; alg = RSASHA256 ; key id = 60955 . 88321 IN RRSIG DNSKEY 8 0 172800 ( 2023050200 2023041100 20326 . ID/zjsZ8MPaJMm4Ilw9PESU92a/MvPFKlKkE8d2qAbDV fMGYQikmls8z0fIorVfoGECgiEey42+Y4Bk99qTEFxPr Cml12/xyJcmzQICQcr28djuMMA+yY7w57GuRLkE+LTnl 5IdlucNf52gS/eKSBIjKH3hNYElH6BwIbTHKV5Jh1ZJg FTo+FRtrniR4HlhhHaydDVLc2A8FG3Whl1kyATDlqcLr F6yqbjAhNR0+Ak26gd5BkY9kwOYCMZ2KQ1RBKRmG3Dbk tohYVHbH2j6B6kfIjooRwY5hWyNQnBZP6LOHQLyfYrUT R3EK438G9VW0tXvNqL3ssDhuxhbFy7x3hw== ) ;; Query time: 0 msec ;; SERVER: ::1#53(::1) (UDP) ;; WHEN: Fri Apr 14 11:32:18 AEST 2023 ;; MSG SIZE rcvd: 892 % > Yesterday I set dnssec-validation to auto on my primary server, but as I > wrote before, although outside tools showed everything was fine, my server > kept answering "SERVFAIL" to my client queries. I don't think I tested > dnssec-validation to no when dnssec was enabled, nor if this makes much > sense, but I can try. > > Kind regards > David > > > > > > > On Wed, Apr 12, 2023 at 05:41:33PM +0100, David Carvalho via bind-users > wrote: >> After reverting my primary dns configuration, and asking my provider >> to remove the DNSKEY, I had to include dnssec-validation no; otherwise >> it would keep answering with SERVFAIL >> >> I noticed the server was constantly trying to reach top domain dns > servers. >> >> Is this dnssec-validation mandatory? Any help appreciated. > > dnssec-validation can be set three ways: > - "no" (validation is never performed) > - "yes" (validation *may* be performed, but only if you have also > configured a trust anchor in named.conf) > - "auto" (validation will be performed using the standard root zone > trust anchor, which is built in to BIND and doesn't need to be > configured by hand). > > The default is "auto". When it's set to that, your server will query the > root name servers in order to confirm that the automatically-configured > trust anchor is correct. You said it was "trying to" reach the root, whi
