Re: How to introduce automatic signing for existing signed zones?
Niall, Thanks for reporting back. This is an omission in our KB article that I will fix. - Matthijs On 07-11-2022 18:24, Niall O'Reilly wrote: On 7 Nov 2022, at 11:40, Niall O'Reilly wrote: Preparation: - Set up minimal stand-alone instance of BIND9 named, configured with a **dnssec-policy** for each algorithm, matching properties of existing DNSSEC keys, and with `lifetime unlimited`; - Deliver current key files and recently-signed copy of zone files to this instance. I needed an additional stage of preparation, before delivering the key files; specifically, I needed to edit the .private files to 'Private-key-format: v1.3' and add missing lifecycle metadata. After doing this, named behaved exactly as expected. Thanks, Matthijs, for steering me in the right direction, and for being ready to give me additional help. /Niall -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How to introduce automatic signing for existing signed zones?
On 7 Nov 2022, at 11:40, Niall O'Reilly wrote: > Preparation: > > - Set up minimal stand-alone instance of BIND9 named, > configured with a **dnssec-policy** for each algorithm, > matching properties of existing DNSSEC keys, and with > `lifetime unlimited`; > - Deliver current key files and recently-signed copy of > zone files to this instance. I needed an additional stage of preparation, before delivering the key files; specifically, I needed to edit the .private files to 'Private-key-format: v1.3' and add missing lifecycle metadata. After doing this, named behaved exactly as expected. Thanks, Matthijs, for steering me in the right direction, and for being ready to give me additional help. /Niall -- 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: automatic reverse and forwarding zones
"Garbage" records... On Mon, 7 Nov 2022, Matus UHLAR - fantomas wrote: On 07.11.22 15:42, Petr Špaček wrote: That's part of normal resolver operation: Garbage in - garbage out - garbage eventually cleaned out from cache. There is nothing special about PTR records in that regard. sooner or later, but filling up cache with garbage could result in other non-garbage records being flushed out. Are there any mechanisms that would wipe this garbage before other records, used more often even if not very recently? The only reason you get records in cache is because you requested them. From my vantage most PTR records are demonstrably garbage. Caching exists because if you requested it once you might request it again. Who knows, maybe you didn't believe it the first time. In any case, that's why the aphorism "garbage in garbage out" is a thing. -- Fred Morris -- 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 lookups not working when Internet connection failed.
On 11/7/22 9:45 AM, Fred Morris wrote: The PUBLIC DNS is not secure against eavesdropping or parallel construction and never will be. Even if the information is out there, I believe there is an exposure risk for ISPs if they do something that makes it /easy/ to correlate customer / client resources. An ISP's lawyer won't care if the customer advertises their own IP space on their website as long as the ISP is not the one to expose such information. That being said -- I assume -- we are all adults here and we can make our own informed decisions. :-) -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- 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: automatic reverse and forwarding zones
On 11/7/22 9:08 AM, Matus UHLAR - fantomas wrote: I'm afraid that this problem can become really huge when someone creates huge amount of generated records, e.g. using proposed module. Even if BIND's cache is simply FIFO -- which I'm fairly certain that it's smarter than that -- and flushes a less garbage record in favor of a more garbage record, then BIND will do what it's designed to do the next time someone queries for the less garbage record, namely it will go fetch it and cache it. It will effectively be the same as if it never had the less garbage record in cache like if it is from a cold start. It will be a small delay. But it won't negatively impact the stability or operation of BIND. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- 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 lookups not working when Internet connection failed.
"Problems"... On Sun, 6 Nov 2022, Grant Taylor via bind-users wrote: On 11/6/22 6:39 AM, Matus UHLAR - fantomas wrote: alternatively they can choose to 0/28.66.136.193.in-addr.arpa. or 0-15.66.136.193.in-addr.arpa. instead of 0-28.66.136.193.in-addr.arpa. N.B. I've had some problems with the forward slash character "/" in domain names multiple times in the past. I'd stick with the hyphen "-" for compatibility. I've had problems with web browsers with "non-hostname" characters. I don't consider web browsers or their ilk the likely use case for resources under in-addr.arpa. There are some things I would avoid as a courtesy to others if I was so inclined: escape, completion and wildcard characters in shells and SQL implementations... -- Fred Morris -- 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 lookups not working when Internet connection failed.
Don't kid yourself. This is wishing for a security outcome which will never reach fruition because of asymmetric interests and capabilities. On Sun, 6 Nov 2022, Grant Taylor via bind-users wrote: [...] I find that $CLIENTNAME or some other stand in for the client is a potential for information lek. The PUBLIC DNS is not secure against eavesdropping or parallel construction and never will be. Just like the destruction of whois (never was a good tool) doesn't prevent reconstruction of people's networks. People like me get paid a lot of money to see that this is so, and at least in some cases I remain convinced it's a good enough idea I don't care what people think about it. I even offer software to accomplish this for free on the internet; I even leverage features of e.g. BIND to do this. I can make arguments for being generic, or provider centric, or customer centric; I can also make arguments for outright lying. Hey, choose your own adventure; other people will judge you accordingly. -- 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: Reverse lookups not working when Internet connection failed.
On 07.11.22 15:57, David Carvalho via bind-users wrote: Finally had the opportunity to get back to this. Having internet connection restored, everything seems to be working as supposed to. One simple query from my client and one response from my server. Output from wireshark: 1 0.0010.0.0.199 193.136.66.1DNS 85 Standard query 0x000b PTR 8.66.136.193.in-addr.arpa 2 0.016660193.136.66.110.0.0.199 DNS 204 Standard query response 0x000b PTR 8.66.136.193.in-addr.arpa CNAME 8.0-28.66.136.193.in-addr.arpa PTR meteo.di.ubi.pt NS dns.di.ubi.pt NS dns2.di.ubi.pt A 193.136.66.1 A 193.136.66.2 Just 2 packets. great, it works. But on the command line I get the following, and I'm confused why the "non-authoritive answer": Non-authoritative answer: ---here!??? 8.66.136.193.in-addr.arpa canonical name = 8.0-28.66.136.193.in-addr.arpa this happens your server is not authoritative for the 66.136.193.in-addr.arpa domain. I guess your servers don't fetch 66.136.193.in-addr.arpa from your ISP. I also wasn't able to reach your servers: 8.66.136.193.in-addr.arpa. 86400 IN CNAME 8.0-28.66.136.193.in-addr.arpa. 0-28.66.136.193.in-addr.arpa. 86400 IN NS dns2.di.ubi.pt. 0-28.66.136.193.in-addr.arpa. 86400 IN NS dns.di.ubi.pt. ;; Received 121 bytes from 193.136.2.228#53(ns02.fccn.pt) in 56 ms % dig -x 193.136.66.8 @dns.di.ubi.pt. dig: couldn't get address for 'dns.di.ubi.pt.': failure % dig -x 193.136.66.8 @dns2.di.ubi.pt. dig: couldn't get address for 'dns2.di.ubi.pt.': failure so there's another problem to solve. IN NS dns.di.ubi.pt. IN NS dns2.di.ubi.pt. looks like your servers dns.di.ubi.pt (193.136.66.1) and dns2.di.ubi.pt (193.136.66.2) aren't reachable from internet. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Linux IS user friendly, it's just selective who its friends are... -- 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: automatic reverse and forwarding zones
On 7. 11. 2022, at 16:19, Matus UHLAR - fantomas wrote: while it's doable, and with using BIND plugin at generating server it won't need much of memory, any server that will be repeatedly asked to resolve IPs from that range will fill its cache with generated records. On 07.11.22 16:28, Ondřej Surý wrote: That's not any different than wildcard record in a forward zone. The resolvers already have to deal with garbage in the cache and cache eviction algorithms. I'm afraid that this problem can become really huge when someone creates huge amount of generated records, e.g. using proposed module. The DNS server doesn't live among rainbows and unicorns, so we prepare for the worst to come from network, not the best. Let's hope such problem won't appear. I was only curious if it may happen, if there's need to consider it. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. How does cat play with mouse? cat /dev/mouse -- 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 lookups not working when Internet connection failed.
Hello again. Finally had the opportunity to get back to this. Having internet connection restored, everything seems to be working as supposed to. One simple query from my client and one response from my server. Output from wireshark: 1 0.0010.0.0.199 193.136.66.1DNS 85 Standard query 0x000b PTR 8.66.136.193.in-addr.arpa 2 0.016660193.136.66.110.0.0.199 DNS 204 Standard query response 0x000b PTR 8.66.136.193.in-addr.arpa CNAME 8.0-28.66.136.193.in-addr.arpa PTR meteo.di.ubi.pt NS dns.di.ubi.pt NS dns2.di.ubi.pt A 193.136.66.1 A 193.136.66.2 Just 2 packets. But on the command line I get the following, and I'm confused why the "non-authoritive answer": Nslookup Set stype=ptr > 193.136.66.8 Server: dns.di.ubi.pt Address: 193.136.66.1 Aliases: 1.66.136.193.in-addr.arpa Non-authoritative answer: ---here!??? 8.66.136.193.in-addr.arpa canonical name = 8.0-28.66.136.193.in-addr.arpa 8.0-28.66.136.193.in-addr.arpa name = meteo.di.ubi.pt 0-28.66.136.193.in-addr.arpanameserver = dns.di.ubi.pt 0-28.66.136.193.in-addr.arpanameserver = dns2.di.ubi.pt dns.di.ubi.pt internet address = 193.136.66.1 dns2.di.ubi.pt internet address = 193.136.66.2 I believe my records are properly created, so I need to understand this before considering the steps bellow. Thanks and best regards David My reverse file again: $TTL 86400 @ IN SOA di.ubi.pt. postmaster.di.ubi.pt ( 2020040401 ; serial 28800 ; refresh 3h 7200; retry 1h 604800 ; expire 1w 86400 ) ; ttl 1d ; Servidores de nomes IN NS dns.di.ubi.pt. IN NS dns2.di.ubi.pt. 0.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.0 1.0-28.66.136.193.in-addr.arpa. IN A 193.136.66.1 ... 14.0-28.66.136.193.in-addr.arpa.IN A 193.136.66.14 ; reverse mapping 1 IN PTR dns.di.ubi.pt. 2 IN PTR dns2.di.ubi.pt. ... 14 IN PTR gw.di.ubi.pt. -Original Message- From: bind-users On Behalf Of Matus UHLAR - fantomas Sent: 06 November 2022 13:39 To: bind-users@lists.isc.org Subject: Re: Reverse lookups not working when Internet connection failed. On 05.11.22 09:58, David Alexandre M. de Carvalho via bind-users wrote: >Thank you all for the replies. >For what I understand after reading your replies (I might be wrong :) >), reverse lookups fail when I have no outgoing connection because some >caching or or transfer is needed from 66.136.193.in-addr.arpa. , wich I don't >control. This is divided in several networks, 2 of them under my control. correct. Admin of that zone is supposed to: 1. create proper CNAME records: 0.66.136.193.in-addr.arpa. CNAME 0.0-28.66.136.193.in-addr.arpa. ... 15.66.136.193.in-addr.arpa. CNAME 15.0-28.66.136.193.in-addr.arpa. 2. delegate 0-28.66.136.193.in-addr.arpa. to your servers, make their servers secondary for this zone (optional) 3. allow your servers to to fetch 66.136.193.in-addr.arpa. step 1. creates proper aliases step 2. creates working delegation step 3. allows you to see reverse records when your connection is down. alternatively they can choose to 0/28.66.136.193.in-addr.arpa. or 0-15.66.136.193.in-addr.arpa. instead of 0-28.66.136.193.in-addr.arpa. >I'll have to read more carefully your suggestions to see if I find an >alternative way to achieve this only by modifying my zone files, >without messing up my current setup. I'll let you know how it goes. >> On 11/4/22 2:07 PM, Mark Andrews wrote: >>> Any ISP that offers these delegations should be allowing their >>> customers to transfer the zone that contains the CNAMEs for the >>> customer address space by default. >> >> I've had enough trouble getting ISPs to support 2317 delegation period. >> I think that asking them to allow me to do a zone transfer would have >> been a hard no. >> >> I certainly don't think this would be allowed /by/ /default/. >> >> I just checked and § 5.1 of RFC 2317 mentioned having the parent do a >> secondary zone transfer of the child zone. But I don't see any >> mention of the child doing a secondary zone transfer of the parent zone. >> >> I think that would be a good idea. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Emacs is a complicated operating system without good text editor. -- 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
Re: automatic reverse and forwarding zones
> On 7. 11. 2022, at 16:19, Matus UHLAR - fantomas wrote: > > while it's doable, and with using BIND plugin at generating server it won't > need much of memory, any server that will be repeatedly asked to resolve IPs > from that range will fill its cache with generated records. That's not any different than wildcard record in a forward zone. The resolvers already have to deal with garbage in the cache and cache eviction algorithms. The DNS server doesn't live among rainbows and unicorns, so we prepare for the worst to come from network, not the best. 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: automatic reverse and forwarding zones
On 7. 11. 2022, at 15:50, Matus UHLAR - fantomas wrote: sooner or later, but filling up cache with garbage could result in other non-garbage records being flushed out. Are there any mechanisms that would wipe this garbage before other records, used more often even if not very recently? On 07.11.22 16:07, Ondřej Surý wrote: How do you know it's a garbage? One woman's trash is another woman's treasure... That is the point. If anyone generates generic DNS records for /64 (16Ei addresses) as the OP asked for: https://lists.isc.org/pipermail/bind-users/2022-October/106846.html ...it will most probably be just garbage. while it's doable, and with using BIND plugin at generating server it won't need much of memory, any server that will be repeatedly asked to resolve IPs from that range will fill its cache with generated records. Won't this cause troubles on any server? I don't know - it might. if it does, do we have anything against it? Won't this cause even more problem on server generating those records? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Windows 2000: 640 MB ought to be enough for anybody -- 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: automatic reverse and forwarding zones
> On 7. 11. 2022, at 15:50, Matus UHLAR - fantomas wrote: > > > sooner or later, but filling up cache with garbage could result in other > non-garbage records being flushed out. > Are there any mechanisms that would wipe this garbage before other records, > used more often even if not very recently? How do you know it's a garbage? One woman's trash is another woman's treasure... 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: How to introduce automatic signing for existing signed zones?
Thank you for your speedy response, Matthijs. On 7 Nov 2022, at 13:10, Matthijs Mekking wrote: Ignore that, I saw too late there were attachments. Perhaps I ought to have mentioned them explicitly. Are you able to share the public key and key state files with me so I can investigate why BIND thinks the existing keys cannot be used? Off list, and PGP-protected, yes. This will mean I'll end up having to change the parent DS RRs later on. That seems a reasonable cost for getting to the root of the problem. I have no key state files, except after starting named, and then only for the RSA/SHA-256 and **newly-generated** ECDSA keys. My current signing process uses ldns-signzone, which seems not to use such files. Also, the log file looks like an excerpt. No; that's everything named, as configured, writes. A full debug (level 3) log would be useful too. I'll set up for that, and follow up off list. Thanks and best regards, Niall -- 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: automatic reverse and forwarding zones
On 28.10.22 08:26, Ondřej Surý wrote: BIND 9 have support for writing plugins, and we would accept a well written plugin that would allow generating the forward/reverse plugins on the fly. There’s already a feature request for it here: https://gitlab.isc.org/isc-projects/bind9/-/issues/1586 On 28. 10. 22 9:29, Matus UHLAR - fantomas wrote: this request for ipv4 too. I really don't think making generic named for ipv6 addresses within range bigger then e.g. /112 (64Ki addresses) makes any sense. prehaps it may for small subsets of IP addresses /64 is 18446744073709551616 addresses, that can't be scanned in meaningful time and this number of DNS records would just mess up any DNS servers' memory. making BIND resilient against overflowing memory this way would make more sense than creating generic addresses. On 07.11.22 15:06, Petr Špaček wrote: Yes, that's exactly why plugin is needed. The plugin can generate answers on the fly without having all of them in memory. On 07. 11. 22 15:23, Matus UHLAR - fantomas wrote: what about BIND receiving those records? I don't want my resolving DNS server to fill out cache by reverse records of any remote ipv6 range/ranges. We'd need to clean those too. On 07.11.22 15:42, Petr Špaček wrote: That's part of normal resolver operation: Garbage in - garbage out - garbage eventually cleaned out from cache. There is nothing special about PTR records in that regard. sooner or later, but filling up cache with garbage could result in other non-garbage records being flushed out. Are there any mechanisms that would wipe this garbage before other records, used more often even if not very recently? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Linux IS user friendly, it's just selective who its friends are... -- 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: automatic reverse and forwarding zones
On 07. 11. 22 15:23, Matus UHLAR - fantomas wrote: On 28.10.22 08:26, Ondřej Surý wrote: BIND 9 have support for writing plugins, and we would accept a well written plugin that would allow generating the forward/reverse plugins on the fly. There’s already a feature request for it here: https://gitlab.isc.org/isc-projects/bind9/-/issues/1586 On 28. 10. 22 9:29, Matus UHLAR - fantomas wrote: this request for ipv4 too. I really don't think making generic named for ipv6 addresses within range bigger then e.g. /112 (64Ki addresses) makes any sense. prehaps it may for small subsets of IP addresses /64 is 18446744073709551616 addresses, that can't be scanned in meaningful time and this number of DNS records would just mess up any DNS servers' memory. making BIND resilient against overflowing memory this way would make more sense than creating generic addresses. On 07.11.22 15:06, Petr Špaček wrote: Yes, that's exactly why plugin is needed. The plugin can generate answers on the fly without having all of them in memory. what about BIND receiving those records? I don't want my resolving DNS server to fill out cache by reverse records of any remote ipv6 range/ranges. We'd need to clean those too. That's part of normal resolver operation: Garbage in - garbage out - garbage eventually cleaned out from cache. There is nothing special about PTR records in that regard. -- 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
Re: automatic reverse and forwarding zones
On 28.10.22 08:26, Ondřej Surý wrote: BIND 9 have support for writing plugins, and we would accept a well written plugin that would allow generating the forward/reverse plugins on the fly. There’s already a feature request for it here: https://gitlab.isc.org/isc-projects/bind9/-/issues/1586 On 28. 10. 22 9:29, Matus UHLAR - fantomas wrote: this request for ipv4 too. I really don't think making generic named for ipv6 addresses within range bigger then e.g. /112 (64Ki addresses) makes any sense. prehaps it may for small subsets of IP addresses /64 is 18446744073709551616 addresses, that can't be scanned in meaningful time and this number of DNS records would just mess up any DNS servers' memory. making BIND resilient against overflowing memory this way would make more sense than creating generic addresses. On 07.11.22 15:06, Petr Špaček wrote: Yes, that's exactly why plugin is needed. The plugin can generate answers on the fly without having all of them in memory. what about BIND receiving those records? I don't want my resolving DNS server to fill out cache by reverse records of any remote ipv6 range/ranges. We'd need to clean those too. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Spam = (S)tupid (P)eople's (A)dvertising (M)ethod -- 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: automatic reverse and forwarding zones
On 28. 10. 22 9:29, Matus UHLAR - fantomas wrote: On 28.10.22 08:26, Ondřej Surý wrote: BIND 9 have support for writing plugins, and we would accept a well written plugin that would allow generating the forward/reverse plugins on the fly. There’s already a feature request for it here: https://gitlab.isc.org/isc-projects/bind9/-/issues/1586 this request for ipv4 too. I really don't think making generic named for ipv6 addresses within range bigger then e.g. /112 (64Ki addresses) makes any sense. prehaps it may for small subsets of IP addresses /64 is 18446744073709551616 addresses, that can't be scanned in meaningful time and this number of DNS records would just mess up any DNS servers' memory. making BIND resilient against overflowing memory this way would make more sense than creating generic addresses. Yes, that's exactly why plugin is needed. The plugin can generate answers on the fly without having all of them in memory. -- 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
Re: How to introduce automatic signing for existing signed zones?
On 07-11-2022 14:04, Matthijs Mekking wrote: Hi Niall, You need to share the dnssec-policy for no8.be in order to investigate why it doesn't show the expected behavior, but I suspect that the policy did not match the properties for the existing DNSSEC keys completely. Ignore that, I saw too late there were attachments. Are you able to share the public key and key state files with me so I can investigate why BIND thinks the existing keys cannot be used? Also, the log file looks like an excerpt. A full debug (level 3) log would be useful too. Best regards, Matthijs Best regards, Matthijs On 07-11-2022 12:40, Niall O'Reilly wrote: I have a couple of zones which I want to migrate from CLI-driven signing to BIND9 automatic signing, while avoiding any change to the respective parent-zone DS RR. Status quo ante: - https://dnsviz.net/d/no8.be/dnssec/ separate KSK, ZSK; both using alg 13 - https://dnsviz.net/d/jamm.ie/dnssec/ 2048-bit KSK, 2x 1024-bit ZSKs (live and spare); all using alg 8 Preparation: - Set up minimal stand-alone instance of BIND9 named, configured with a **dnssec-policy** for each algorithm, matching properties of existing DNSSEC keys, and with `lifetime unlimited`; - Deliver current key files and recently-signed copy of zone files to this instance. Expected behaviour on starting named: - Zones are loaded; - Spare ZSK for jamm.ie is retired; - Other keys for each zone are accepted and retained; - A CDS RR is generated for each zone, matching the current DS RR. Observed behaviour: - `named -v` shows `BIND 9.18.8 (Stable Release) `; - Zones are loaded; - Spare ZSK for jamm.ie is retired; - Other RSA/SHA-256 keys (for jamm.ie) are accepted and retained; - A CDS RR is published for jamm.ie, matching the current DS RR; - ECDSAP256SHA256 keys (for no8.be) are not accepted; - New ECDSAP256SHA256 keys are created for no8.be; - No CDS RR is generated for no8.be. Unless I'm missing something, there seems to be a discrepancy according to key type between the handling of RSA/SHA-256 and ECDSAP256SHA256 keys respectively. /Niall -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How to introduce automatic signing for existing signed zones?
Hi Niall, You need to share the dnssec-policy for no8.be in order to investigate why it doesn't show the expected behavior, but I suspect that the policy did not match the properties for the existing DNSSEC keys completely. Best regards, Matthijs On 07-11-2022 12:40, Niall O'Reilly wrote: I have a couple of zones which I want to migrate from CLI-driven signing to BIND9 automatic signing, while avoiding any change to the respective parent-zone DS RR. Status quo ante: - https://dnsviz.net/d/no8.be/dnssec/ separate KSK, ZSK; both using alg 13 - https://dnsviz.net/d/jamm.ie/dnssec/ 2048-bit KSK, 2x 1024-bit ZSKs (live and spare); all using alg 8 Preparation: - Set up minimal stand-alone instance of BIND9 named, configured with a **dnssec-policy** for each algorithm, matching properties of existing DNSSEC keys, and with `lifetime unlimited`; - Deliver current key files and recently-signed copy of zone files to this instance. Expected behaviour on starting named: - Zones are loaded; - Spare ZSK for jamm.ie is retired; - Other keys for each zone are accepted and retained; - A CDS RR is generated for each zone, matching the current DS RR. Observed behaviour: - `named -v` shows `BIND 9.18.8 (Stable Release) `; - Zones are loaded; - Spare ZSK for jamm.ie is retired; - Other RSA/SHA-256 keys (for jamm.ie) are accepted and retained; - A CDS RR is published for jamm.ie, matching the current DS RR; - ECDSAP256SHA256 keys (for no8.be) are not accepted; - New ECDSAP256SHA256 keys are created for no8.be; - No CDS RR is generated for no8.be. Unless I'm missing something, there seems to be a discrepancy according to key type between the handling of RSA/SHA-256 and ECDSAP256SHA256 keys respectively. /Niall -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
How to introduce automatic signing for existing signed zones?
I have a couple of zones which I want to migrate from CLI-driven
signing to BIND9 automatic signing, while avoiding any change to
the respective parent-zone DS RR.
Status quo ante:
- https://dnsviz.net/d/no8.be/dnssec/
separate KSK, ZSK; both using alg 13
- https://dnsviz.net/d/jamm.ie/dnssec/
2048-bit KSK, 2x 1024-bit ZSKs (live and spare); all using alg 8
Preparation:
- Set up minimal stand-alone instance of BIND9 named,
configured with a **dnssec-policy** for each algorithm,
matching properties of existing DNSSEC keys, and with
`lifetime unlimited`;
- Deliver current key files and recently-signed copy of
zone files to this instance.
Expected behaviour on starting named:
- Zones are loaded;
- Spare ZSK for jamm.ie is retired;
- Other keys for each zone are accepted and retained;
- A CDS RR is generated for each zone, matching the current DS RR.
Observed behaviour:
- `named -v` shows `BIND 9.18.8 (Stable Release) `;
- Zones are loaded;
- Spare ZSK for jamm.ie is retired;
- Other RSA/SHA-256 keys (for jamm.ie) are accepted and retained;
- A CDS RR is published for jamm.ie, matching the current DS RR;
- ECDSAP256SHA256 keys (for no8.be) are not accepted;
- New ECDSAP256SHA256 keys are created for no8.be;
- No CDS RR is generated for no8.be.
Unless I'm missing something, there seems to be a discrepancy
according to key type between the handling of RSA/SHA-256 and
ECDSAP256SHA256 keys respectively.
/Niall
// Based on
https://bind9.readthedocs.io/en/latest/chapter3.html#primary-authoritative-name-server
// authoritative primary named.conf file
// options clause defining the server-wide properties
options {
// all relative paths use this directory as a base
directory "/usr/local/var/named";
listen-on { 127.0.0.1; };
listen-on-v6 { ::1; };
allow-query { 127.0.0.1; ::1; };
allow-query-cache { none; };
recursion no;
};
// logging clause
// log to /var/log/named/example.log all events from info UP in severity (no
debug)
// uses 3 files in rotation swaps files when size reaches 250K
// failure messages that occur before logging is established are
// in syslog (/var/log/messages)
//
logging {
channel example_log {
// uses a relative path name and the directory statement to
// expand to /var/log/named/example.log
file "example.log" versions 3 size 250k;
// only log info and up messages - all others discarded
severity info;
};
category default {
example_log;
};
};
acl local-requesters {
localhost;
};
dnssec-policy "persistent-rsasha256" {
keys {
ksk lifetime unlimited algorithm rsasha256;
zsk lifetime unlimited algorithm rsasha256 1024;
};
};
dnssec-policy "persistent-ecdsa256" {
keys {
ksk lifetime unlimited algorithm 13;
zsk lifetime unlimited algorithm 13;
};
};
// We are a standalone test server for jamm.ie
zone "jamm.ie" {
type primary;
update-policy local;
file "jamm.ie/db.jamm.ie";
key-directory "jamm.ie/";
masterfile-format text;
dnssec-policy persistent-rsasha256;
notify explicit;
allow-transfer {
local-requesters;
};
};
// We are a standalone test server for no8.be
zone "no8.be" {
type primary;
update-policy local;
file "no8.be/db.no8.be";
key-directory "no8.be/";
masterfile-format text;
dnssec-policy persistent-ecdsa256;
notify explicit;
allow-transfer {
local-requesters;
};
};
managed-keys-zone: loaded serial 0
zone no8.be/IN: loaded serial 2022110700 (DNSSEC signed)
zone jamm.ie/IN: loaded serial 2022110700 (DNSSEC signed)
zone no8.be/IN: reconfiguring zone keys
keymgr: DNSKEY no8.be/ECDSAP256SHA256/42593 (KSK) created for policy
persistent-ecdsa256
keymgr: DNSKEY no8.be/ECDSAP256SHA256/5030 (ZSK) created for policy
persistent-ecdsa256
Fetching no8.be/ECDSAP256SHA256/42593 (KSK) from key repository.
DNSKEY no8.be/ECDSAP256SHA256/42593 (KSK) is now published
DNSKEY no8.be/ECDSAP256SHA256/42593 (KSK) is now active
Fetching no8.be/ECDSAP256SHA256/5030 (ZSK) from key repository.
DNSKEY no8.be/ECDSAP256SHA256/5030 (ZSK) is now published
DNSKEY no8.be/ECDSAP256SHA256/5030 (ZSK) is now active
zone no8.be/IN: next key event: 07-Nov-2022 12:17:13.995
zone jamm.ie/IN: reconfiguring zone keys
keymgr: retire DNSKEY jamm.ie/RSASHA256/3078 (ZSK)
DNSKEY jamm.ie/RSASHA256/17103 (ZSK) is now active
Removing expired key 3078/RSASHA256 from DNSKEY RRset.
DNSKEY jamm.ie/RSASHA256/3078 (ZSK) is now deleted
CDS for key jamm.ie/RSASHA256/47680 is now published
CDNSKEY for key jamm.ie/RSASHA256/47680 is now published
zone jamm.ie/IN: next key event: 07-Nov-2022 10:17:14.023
all zones loaded
running
managed-keys-zone: Initializing automatic trust anchor management for zone '.';
DNSKEY ID 20326 is now trusted, waiving the normal 30-day waiting period.
resolver priming query complete: success
zone jamm.ie/IN: reconfiguring zone keys
zone jamm.ie/IN: next key event: 07-Nov-2022 11:17:14.026
zone jamm.ie/IN:
Re: Reverse lookups not working when Internet connection failed.
On 11/6/22 11:12 AM, Carl Byington via bind-users wrote: or use $clientname.66.136.193.in-addr.arpa. as the intermediate zone which has a slight advantage when the same client has multiple disjoint parts of the same /24. On 06.11.22 20:08, Grant Taylor via bind-users wrote: I find that $CLIENTNAME or some other stand in for the client is a potential for information lek. I agree, the client may want to stay private. There is nothing inherent in the CNAME to non-identifying RNAMEs that leaks any client identifying information. Conversely the client is in charge of what information they put in the sub-zone, so it's not the ISP leaking client identifying information. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "Two words: Windows survives." - Craig Mundie, Microsoft senior strategist "So does syphillis. Good thing we have penicillin." - Matthew Alton -- 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 lookups not working when Internet connection failed.
On 11/6/22 6:39 AM, Matus UHLAR - fantomas wrote: 3. allow your servers to to fetch 66.136.193.in-addr.arpa. On 06.11.22 20:05, Grant Taylor via bind-users wrote: Is this 3rd step documented somewhere? I searched for it in RFC 2317 but didn't find it. Maybe I over looked it. This step is not necessary for classless reverse DNS delegation. This step is however necessary for OP's DNS server being able to reverse resolve its own IP range, when its connectivity is down (this the OP's question), because OP's clients will try to resolve names in 66.136.193.in-addr.arpa. alternatively they can choose to 0/28.66.136.193.in-addr.arpa. or 0-15.66.136.193.in-addr.arpa. instead of 0-28.66.136.193.in-addr.arpa. N.B. I've had some problems with the forward slash character "/" in domain names multiple times in the past. I'd stick with the hyphen "-" for compatibility. I've had no problem with that one in the past. TMTOWTDI -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. If Barbie is so popular, why do you have to buy her friends? -- 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: Unexpected extra care needed for building BIND 9.18.8
Thanks for replying so promptly, Ondřej. On 6 Nov 2022, at 15:34, Ondřej Surý wrote: Nope, that’s local to your system. Hard to tell what’s wrong from just a single message, but either there’s cruft somewhere in the path with more priority That was it. Rebuilding the cache cleared the problem. /Niall -- 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
