Re: RPZ zone response delay time ?
On 8/04/2023 4:27 am, Jason Vas Dias wrote: I have converted the excellent hosts file at https://someonewhocares.org/hosts/ to a Response Policy Zone (RPZ) file served by my local named that ends: *.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). Hi Jason. I'm doing something similar myself, although it looks like you've gone one step further with the inclusion of wildcards (i.e. "*") in the RPZ? The other notable difference in my case is that my RPZ results in NXDOMAIN (i.e. same as suggested by Evan Hunt) rather than returning a bogus IP address. FWIW I haven't experienced any issues with youtube, so I wonder whether one of these differences could be the cause of your CPU usage issue? 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: BIND operating in Parental Agent role (according to RFC 7344)?
On 12/04/2023 7:51 pm, Petr Špaček wrote: There is a philosophical question whether this is something a DNS server should do. You make a very good point. There are external tools which can automate zone scan, e.g. https://github.com/CZ-NIC/fred-cdnskey-scanner It hadn't occurred to me to look for a third-party solution. :-P I suppose that it should be possible to glue it to standard DNS UPDATE mechanism and thus make it work with any standard DNS server. I must admit I was hoping for a solution that didn't require me to convert my main zone into a dynamic zone - i.e. something that would work within the inline-signing framework. But perhaps I was being overly optimistic? I've decided I'll stick with manual KSK roll-overs for now... :-) Thanks again. 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: Delegation NS-records when zones share an authority server
> On 13 Apr 2023, at 06:44, Mark Andrews wrote: > > > >> On 13 Apr 2023, at 03:19, Fred Morris wrote: >> >> TLDR: NS records occur above and below zone cuts. >> >> On Wed, 12 Apr 2023, John Thurston wrote: >>> >>> We have authority over state.ak.us, which we publish as a public zone. We >>> also publish challenge.state.ak.us as a public zone. >>> >>> The public NS records for state.ak.us are: ns4.state.ak.us and >>> ns3.state.ak.us The NS records for challenge.state.ak.us are the same. >>> >>> I recently noticed there were no NS records _in the state.ak.us zone_ for >>> challenge.state.ak.us. >> >> So nothing above the zone cut == there is no zone cut. (IMO) >> >>> This had me scratching my head . . "how can this be working?", until I >>> remembered the same instances of BIND were serving out both zones. There >>> _were_ NS records in the challenge.state.ak.us zone, BIND had them, was >>> authoritative, so would answer with them; BIND didn't need to look in the >>> state.ak.us zone to find them. >> >> Yup. >> >>> Some experimentation shows that even if I insert NS records into >>> state.ak.us (for challenge.state.ak.us), BIND does not add them to its >>> answer when asked "dig NS challenge.state.ak.us". I interpret this to mean >>> that while this instance of BIND is authoritative for both zones, it >>> answers with information from the most specific zone it has, and ignores >>> values in the delegating zone. And that makes sense to me. >> >> Yup. >> >>> Now the question is, should I insert NS records into state.ak.us (for >>> challenge.state.ak.us) anyway? >>> [...] >>> >>> Unknown: >>> >>> * Does the answer change if we want to start signing either zone? >> >> I suspect you don't need the NS records in challenge.state.ak.us and if you >> remove them then the records in challenge.state.ak.us are simply part of the >> state.ak.us zone since they're served off of the same server. Glue records >> (above the cut) are essentially the same NS record(s) published on >> nameservers above the zone cut as within the zone on the nameservers for the >> zone proper (below the cut). >> >> On the other hand maybe whatever software you're using to manage / serve DNS >> does something with those records (or requires them since / if the two >> namespaces are loaded as separate zones). >> >> In terms of NXDOMAIN and SOA queries, both state.ak.us and >> challenge.state.ak.us seem to do the right thing in terms of pretending to >> be separate zones, e.g. in the first case returning the correct domain in >> the AUTHORITY and in the second case returning the relevant SOA records >> directly in the ANSWER. > > You need NS records in the parent domain to give correct answers to DS > queries (DATA or NODATA NOERROR vs NXDOMAIN) and to generate valid NSEC and > NSEC3 chains. Additionally if the parent zone is ever transferred to server > without the child zone clients will see a Schrödinger zone. Always add > delegating NS RRset and keep it consistent with the child zone. To demonstrate what I mean about DS. While named has code to handle this inconsistency other recursive servers may not as it is NOT a RFC requirement. % dig ds challenge.state.ak.us ;; BADCOOKIE, retrying. ; <<>> DiG 9.19.11-dev <<>> ds challenge.state.ak.us ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34581 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 13281432cf7c77c8010064371a0bdc1c24b7a7f4aaf4 (good) ;; QUESTION SECTION: ;challenge.state.ak.us. IN DS ;; AUTHORITY SECTION: state.ak.us. 3600 IN SOA ns3.state.ak.us. hostmaster.state.ak.us. 1681251385 3600 900 7776000 3600 ;; Query time: 1484 msec ;; SERVER: ::1#53(::1) (UDP) ;; WHEN: Thu Apr 13 06:52:27 AEST 2023 ;; MSG SIZE rcvd: 129 % dig soa challenge.state.ak.us ;; BADCOOKIE, retrying. ; <<>> DiG 9.19.11-dev <<>> soa challenge.state.ak.us ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9228 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 5babd4f25d912557010064371a19b455b75c97d45a2c (good) ;; QUESTION SECTION: ;challenge.state.ak.us. IN SOA ;; ANSWER SECTION: challenge.state.ak.us. 21600 IN SOA ns3.state.ak.us. hostmaster.state.ak.us. 2018034113 3600 300 86400 120 ;; Query time: 255 msec ;; SERVER: ::1#53(::1) (UDP) ;; WHEN: Thu Apr 13 06:52:41 AEST 2023 ;; MSG SIZE rcvd: 129 % >> -- >> >> Fred Morris, internet plumber >> >> >> -- >> 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/
Re: Delegation NS-records when zones share an authority server
On 13/04/2023 5:58 am, Havard Eidnes via bind-users wrote: I suspect you don't need the NS records in challenge.state.ak.us and if you remove them then the records in challenge.state.ak.us are simply part of the state.ak.us zone since they're served off of the same server. Unfortunately "not quite". While a publishing name server will respond with data from the most specific zone available to it when queried (e.g. for the NS records for challenge.state.ak.us), this "overriding" or "leakage" does not happen when you do a zone transfer of the parent zone (state.ak.us). So ... if you have a publishing name server which is a name server for state.ak.us and not for challenge.state.ak.us, it will *not* have the delegation NS RRset for challenge.state.ak.us, and if a recursor happens to query this particular publishing name server as part of the process of resolving a name in challenge.state.ak.us, it will get an apparently-spurious NXDOMAIN response. I think the suggestion was for the other way around - i.e. NS in parent zone only? But that is also not a good idea. I'll defer to RFC 1034 section 4.2.1 for the details: Though logically part of the authoritative data, the RRs that describe the top node of the zone are especially important to the zone's management. These RRs are of two types: name server RRs that list, one per RR, all of the servers for the zone, and a single SOA RR that describes zone management parameters. The RRs that describe cuts around the bottom of the zone are NS RRs that name the servers for the subzones. Since the cuts are between nodes, these RRs are NOT part of the authoritative data of the zone, and should be exactly the same as the corresponding RRs in the top node of the subzone. Since name servers are always associated with zone boundaries, NS RRs are only found at nodes which are the top node of some zone. In the data that makes up a zone, NS RRs are found at the top node of the zone (and are authoritative) and at cuts around the bottom of the zone (where they are not authoritative), but never in between. The terminology is a bit confusing, but it boils down to this: The NS records for the zone must be included in the zone itself, and also in the parent zone. 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: Delegation NS-records when zones share an authority server
> On 13 Apr 2023, at 03:19, Fred Morris wrote: > > TLDR: NS records occur above and below zone cuts. > > On Wed, 12 Apr 2023, John Thurston wrote: >> >> We have authority over state.ak.us, which we publish as a public zone. We >> also publish challenge.state.ak.us as a public zone. >> >> The public NS records for state.ak.us are: ns4.state.ak.us and >> ns3.state.ak.us The NS records for challenge.state.ak.us are the same. >> >> I recently noticed there were no NS records _in the state.ak.us zone_ for >> challenge.state.ak.us. > > So nothing above the zone cut == there is no zone cut. (IMO) > >> This had me scratching my head . . "how can this be working?", until I >> remembered the same instances of BIND were serving out both zones. There >> _were_ NS records in the challenge.state.ak.us zone, BIND had them, was >> authoritative, so would answer with them; BIND didn't need to look in the >> state.ak.us zone to find them. > > Yup. > >> Some experimentation shows that even if I insert NS records into state.ak.us >> (for challenge.state.ak.us), BIND does not add them to its answer when asked >> "dig NS challenge.state.ak.us". I interpret this to mean that while this >> instance of BIND is authoritative for both zones, it answers with >> information from the most specific zone it has, and ignores values in the >> delegating zone. And that makes sense to me. > > Yup. > >> Now the question is, should I insert NS records into state.ak.us (for >> challenge.state.ak.us) anyway? >> [...] >> >> Unknown: >> >> * Does the answer change if we want to start signing either zone? > > I suspect you don't need the NS records in challenge.state.ak.us and if you > remove them then the records in challenge.state.ak.us are simply part of the > state.ak.us zone since they're served off of the same server. Glue records > (above the cut) are essentially the same NS record(s) published on > nameservers above the zone cut as within the zone on the nameservers for the > zone proper (below the cut). > > On the other hand maybe whatever software you're using to manage / serve DNS > does something with those records (or requires them since / if the two > namespaces are loaded as separate zones). > > In terms of NXDOMAIN and SOA queries, both state.ak.us and > challenge.state.ak.us seem to do the right thing in terms of pretending to be > separate zones, e.g. in the first case returning the correct domain in the > AUTHORITY and in the second case returning the relevant SOA records directly > in the ANSWER. You need NS records in the parent domain to give correct answers to DS queries (DATA or NODATA NOERROR vs NXDOMAIN) and to generate valid NSEC and NSEC3 chains. Additionally if the parent zone is ever transferred to server without the child zone clients will see a Schrödinger zone. Always add delegating NS RRset and keep it consistent with the child zone. > -- > > Fred Morris, internet plumber > > > -- > 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: Delegation NS-records when zones share an authority server
> I suspect you don't need the NS records in challenge.state.ak.us and > if you remove them then the records in challenge.state.ak.us are > simply part of the state.ak.us zone since they're served off of the > same server. Unfortunately "not quite". While a publishing name server will respond with data from the most specific zone available to it when queried (e.g. for the NS records for challenge.state.ak.us), this "overriding" or "leakage" does not happen when you do a zone transfer of the parent zone (state.ak.us). So ... if you have a publishing name server which is a name server for state.ak.us and not for challenge.state.ak.us, it will *not* have the delegation NS RRset for challenge.state.ak.us, and if a recursor happens to query this particular publishing name server as part of the process of resolving a name in challenge.state.ak.us, it will get an apparently-spurious NXDOMAIN response. I understand this isn't the case right now, but this is a problem which might come and bite your behind if you later decide to change the NS RRsets so that they are no longer equal for the two zones. So the long and short of my advice: do the delegations properly by copying the NS RRset from the child to the parent, plus any required address glue records, and this particular problem will not become an issue. Best regards, - Håvard -- 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: Delegation NS-records when zones share an authority server
it'll matter when you decide to add DNSSEC to the zone, and it's also good hygiene in the absence of DNSSEC so that any future maintainer can be reminded that there is a subdomain at that name when looking at the parent. -- 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: Delegation NS-records when zones share an authority server
TLDR: NS records occur above and below zone cuts. On Wed, 12 Apr 2023, John Thurston wrote: We have authority over state.ak.us, which we publish as a public zone. We also publish challenge.state.ak.us as a public zone. The public NS records for state.ak.us are: ns4.state.ak.us and ns3.state.ak.us The NS records for challenge.state.ak.us are the same. I recently noticed there were no NS records _in the state.ak.us zone_ for challenge.state.ak.us. So nothing above the zone cut == there is no zone cut. (IMO) This had me scratching my head . . "how can this be working?", until I remembered the same instances of BIND were serving out both zones. There _were_ NS records in the challenge.state.ak.us zone, BIND had them, was authoritative, so would answer with them; BIND didn't need to look in the state.ak.us zone to find them. Yup. Some experimentation shows that even if I insert NS records into state.ak.us (for challenge.state.ak.us), BIND does not add them to its answer when asked "dig NS challenge.state.ak.us". I interpret this to mean that while this instance of BIND is authoritative for both zones, it answers with information from the most specific zone it has, and ignores values in the delegating zone. And that makes sense to me. Yup. Now the question is, should I insert NS records into state.ak.us (for challenge.state.ak.us) anyway? [...] Unknown: * Does the answer change if we want to start signing either zone? I suspect you don't need the NS records in challenge.state.ak.us and if you remove them then the records in challenge.state.ak.us are simply part of the state.ak.us zone since they're served off of the same server. Glue records (above the cut) are essentially the same NS record(s) published on nameservers above the zone cut as within the zone on the nameservers for the zone proper (below the cut). On the other hand maybe whatever software you're using to manage / serve DNS does something with those records (or requires them since / if the two namespaces are loaded as separate zones). In terms of NXDOMAIN and SOA queries, both state.ak.us and challenge.state.ak.us seem to do the right thing in terms of pretending to be separate zones, e.g. in the first case returning the correct domain in the AUTHORITY and in the second case returning the relevant SOA records directly in the ANSWER. -- Fred Morris, internet plumber -- 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 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
dnssec-validation?
Hello, again. Guys, sorry once again, but my dnssec implementation didn't work out. Using 9.16.23 (I have that problem of keys being regenerated every restart, but I'll learn to sign the zone later using the original key- Bug solved in version 9.16.30). After providing my DNSKEY record to parent domain, the test performed by dnssec-analyzer showed everything ok, nevertheless, all queries except those about my.domain were Rejected with SERVFAIL. dig @my.server or dig @localhost My secondary dns server hold everything while testing, and I noticed I had dnssec-validation auto; on it. 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. Regards David -- 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
Delegation NS-records when zones share an authority server
I uncovered an oddity in my zone definitions, which I'm trying to wrap my head around. We have authority over state.ak.us, which we publish as a public zone. We also publish challenge.state.ak.us as a public zone. The public NS records for state.ak.us are: ns4.state.ak.us and ns3.state.ak.us The NS records for challenge.state.ak.us are the same. I recently noticed there were no NS records _in the state.ak.us zone_ for challenge.state.ak.us. This had me scratching my head . . "how can this be working?", until I remembered the same instances of BIND were serving out both zones. There _were_ NS records in the challenge.state.ak.us zone, BIND had them, was authoritative, so would answer with them; BIND didn't need to look in the state.ak.us zone to find them. Some experimentation shows that even if I insert NS records into state.ak.us (for challenge.state.ak.us), BIND does not add them to its answer when asked "dig NS challenge.state.ak.us". I interpret this to mean that while this instance of BIND is authoritative for both zones, it answers with information from the most specific zone it has, and ignores values in the delegating zone. And that makes sense to me. Now the question is, should I insert NS records into state.ak.us (for challenge.state.ak.us) anyway? Arguments in favor: * Every other zone we delegate is handled by some other set of name serves, so we've come to accept (and expect) "every delegated zone will have NS records here". This outlier had me scratching my head, and will cause someone else confusion in the future. * The time may come when challenge.state.ak.us is not handled by the same instance of BIND as state.ak.us. Having benign delegation records present, will remind Future-Self to adjust the values to delegate to the new servers. * We parse the state.ak.us zone file to identify all delegated zones, and run periodic tests to confirm those delegates are delivering coherent answers. With no NS records for challenge.state.ak.us, we have not been performing these tests. Arguments against: * Maybe I misunderstand, and such NS records aren't actually benign Unknown: * Does the answer change if we want to start signing either zone? -- -- 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: BIND operating in Parental Agent role (according to RFC 7344)?
On 12. 04. 23 5:38, Nick Tait via bind-users wrote: I'm currently running a few DNSSEC zones in BIND using dnssec-policy option, albeit with an unlimited lifetime on the KSK, so that I can control KSK roll-overs (which is necessary because my Registrar doesn't support RFC 7344)... Anyway I know that BIND supports RFC 7344 via parental-agents option when BIND is operating in the 'Child' role; but my question is whether BIND currently supports (or if there are any plans for BIND to support) RFC 7344 with BIND operating in the 'Parental Agent' (and 'Parent') capacity. In other words, can BIND be configured to poll a child zone for CDS/CDNSKEY records, and automatically add corresponding DS records into a zone that it controls? If this isn't on the radar already, I'll be happy to submit an enhancement request? There is a philosophical question whether this is something a DNS server should do. There are external tools which can automate zone scan, e.g. https://github.com/CZ-NIC/fred-cdnskey-scanner I suppose that it should be possible to glue it to standard DNS UPDATE mechanism and thus make it work with any standard DNS server. -- Petr Špaček -- 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
