Hi Badli, On Sat, Apr 22, 2023 at 06:46:10PM +0000, Badli Al Rashid via BitFolk Users wrote: I think it's fine. Most of the time you're running a DNS server because you want it to be globally reachable anyway. If it's a resolver then it might make more sense to only have it listen on certain interfaces. Logs will say why. Logs are really good. They save a lot of time from posting messages about how "it failed" as they usually tell you why "it failed". These just sound like misconfigurations. - Decide what you want to do. - Tackle one problem at a time. - Show exact configuration, logs and/or copy of output showing what it did, and explanation of what you actually wanted it to do. You can test if an AXFR works, requesting from your BIND host to your PowerDNS host, without even using BIND. You can test it with just "dig": $ dig -b 192.168.1.2 -t axfr example.com @10.10.1.2 Where: - 192.168.1.2 is the source address you want the AXFR to come from - example.com is the zone you want to transfer from PowerDNS - 10.10.1.2 is the IP address of POwerDNS Get that working first. Once it works, configure BIND to do the same. Cheers, Andy

Hi, On the logs it failed to listen x.x.x.x address at port 53. Once I put the listen directive to any IP address bind started to work again. Anyhow for the powerdns it is both a primary and secondary operations. I put all the IP's for for secondary to the allow-axfr-ips. Yes after doing dig -t axfr testingsforonedomains.com @x.x.x.x the axfr is working on the secondary. Could be a miss configurations I suppose. Thanks. Regards, -badli ________________________________ From: Andy Smith via BitFolk Users <users(a)mailman.bitfolk.com> Sent: Sunday, April 23, 2023, 03:33 To: users(a)mailman.bitfolk.com <users(a)mailman.bitfolk.com> Cc: Andy Smith <andy(a)bitfolk.com> Subject: [bitfolk] Re: question on bind9 listening. Hi Badli, On Sat, Apr 22, 2023 at 06:46:10PM +0000, Badli Al Rashid via BitFolk Users wrote: I think it's fine. Most of the time you're running a DNS server because you want it to be globally reachable anyway. If it's a resolver then it might make more sense to only have it listen on certain interfaces. Logs will say why. Logs are really good. They save a lot of time from posting messages about how "it failed" as they usually tell you why "it failed". These just sound like misconfigurations. - Decide what you want to do. - Tackle one problem at a time. - Show exact configuration, logs and/or copy of output showing what it did, and explanation of what you actually wanted it to do. You can test if an AXFR works, requesting from your BIND host to your PowerDNS host, without even using BIND. You can test it with just "dig": $ dig -b 192.168.1.2 -t axfr example.com @10.10.1.2 Where: - 192.168.1.2 is the source address you want the AXFR to come from - example.com is the zone you want to transfer from PowerDNS - 10.10.1.2 is the IP address of POwerDNS Get that working first. Once it works, configure BIND to do the same. Cheers, Andy

Hi Badli, On Sat, Apr 22, 2023 at 09:29:58PM +0000, Badli Al Rashid via BitFolk Users wrote: You aren't going to get any useful help unless you show the actual relevant log lines, in full (I guarantee this isn't it) without obscuring any IP addresses. The obvious conclusion from that is that you tried to make it listen on an interface:port that it could not listen on, for reasons that it almost certainly has told you in the logs. By not asking it to do that… it doesn't do that. Fine if you didn't actually want to do that. If you did want to make it listen on only specified interfaces, then you have a problem. Let's solve that problem then. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting

Hi Badli, On Sat, Apr 22, 2023 at 11:16:22PM +0000, Badli Al Rashid via BitFolk Users wrote: So is that not what you want to happen? If not then what do you try in order to change that, and what was the result of that? Please show the configuration, firewalling and logs for what you tried and what happened when you tried it. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting

Hi, I dont have have a lot of experience in bind/bind9 configurations but it is really exciting. Regards, -badli ________________________________ From: Iain Harrison via BitFolk Users &lt;users(a)mailman.bitfolk.com&gt; Sent: Sunday, April 23, 2023, 05:34 To: users(a)mailman.bitfolk.com &lt;users(a)mailman.bitfolk.com&gt; Cc: Iain Harrison &lt;iain(a)hairydog.co.uk&gt; Subject: [bitfolk] Re: question on bind9 listening. On 22/04/2023 22:29, Badli Al Rashid via BitFolk Users wrote: That's the snag with bind9. It's really picky about getting the config exactly right. The slightest thing wrong and it will sulk. -- Iain _______________________________________________ BitFolk Users mailing list &lt;users(a)mailman.bitfolk.com&gt; You're subscribed as &lt;badlialrashid(a)outlook.com&gt; Unsubscribe: <https://mailman.bitfolk.com/mailman/postorius/lists/users.mailman.bitfolk.com/> or send an email to &lt;users-leave(a)mailman.bitfolk.com&gt;

Hi Andy, The bind logs is from hostname rambutan/rambutan4. I did not specify the IP address for bind9 as it is set to listen to any. If I set the listen to specific, bind9 would fail to listen. Example. 13-Apr-2023 23:00:07.711 network: info: no longer listening on 2001:ba8:1f1:f0b5::2#53 13-Apr-2023 23:00:07.711 network: info: no longer listening on fe80::216:5eff:fe00:5f5%2#53 13-Apr-2023 23:03:41.664 network: info: no longer listening on 127.0.0.1#53 13-Apr-2023 23:03:41.664 network: info: no longer listening on 85.119.83.49#53 13-Apr-2023 23:03:41.664 network: info: no longer listening on 85.119.82.135#53 13-Apr-2023 23:03:41.664 network: info Anyhow, the defaults for the ufw was to deny incoming and deny outgoing. Below is the iptables -L output. Chain INPUT (policy DROP) target prot opt source destination ufw-before-logging-input all -- anywhere anyw here ufw-before-input all -- anywhere anywhere ufw-after-input all -- anywhere anywhere ufw-after-logging-input all -- anywhere anywh ere ufw-reject-input all -- anywhere anywhere ufw-track-input all -- anywhere anywhere Chain FORWARD (policy DROP) target prot opt source destination ufw-before-logging-forward all -- anywhere an ywhere ufw-before-forward all -- anywhere anywhere ufw-after-forward all -- anywhere anywhere ufw-after-logging-forward all -- anywhere any where ufw-reject-forward all -- anywhere anywhere ufw-track-forward all -- anywhere anywhere Chain OUTPUT (policy DROP) target prot opt source destination ufw-before-logging-output all -- anywhere any where ufw-before-output all -- anywhere anywhere ufw-after-output all -- anywhere anywhere ufw-after-logging-output all -- anywhere anyw here ufw-reject-output all -- anywhere anywhere ufw-track-output all -- anywhere anywhere Chain ufw-after-forward (1 references) target prot opt source destination Chain ufw-after-input (1 references) target prot opt source destination ufw-skip-to-policy-input udp -- anywhere anyw here udp dpt:netbios-ns ufw-skip-to-policy-input udp -- anywhere anyw here udp dpt:netbios-dgm ufw-skip-to-policy-input tcp -- anywhere anyw here tcp dpt:netbios-ssn ufw-skip-to-policy-input tcp -- anywhere anyw here tcp dpt:microsoft-ds ufw-skip-to-policy-input udp -- anywhere anyw here udp dpt:bootps ufw-skip-to-policy-input udp -- anywhere anyw here udp dpt:bootpc ufw-skip-to-policy-input all -- anywhere anyw here ADDRTYPE match dst-type BROADCAST Chain ufw-after-logging-forward (1 references) target prot opt source destination Chain ufw-after-logging-input (1 references) target prot opt source destination Chain ufw-after-logging-output (1 references) target prot opt source destination Chain ufw-after-output (1 references) target prot opt source destination Chain ufw-before-forward (1 references) target prot opt source destination ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT icmp -- anywhere anywhere icmp destination-unreachable ACCEPT icmp -- anywhere anywhere icmp time-exceeded ACCEPT icmp -- anywhere anywhere icmp parameter-problem ACCEPT icmp -- anywhere anywhere icmp echo-request ufw-user-forward all -- anywhere anywhere Chain ufw-before-input (1 references) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ufw-logging-deny all -- anywhere anywhere ctstate INVALID DROP all -- anywhere anywhere ctstate INVALID ACCEPT icmp -- anywhere anywhere icmp destination-unreachable ACCEPT icmp -- anywhere anywhere icmp time-exceeded ACCEPT icmp -- anywhere anywhere icmp parameter-problem ACCEPT icmp -- anywhere anywhere icmp echo-request ACCEPT udp -- anywhere anywhere udp spt:bootps dpt:bootpc ufw-not-local all -- anywhere anywhere ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns ACCEPT udp -- anywhere 239.255.255.250 udp dpt:1900 ufw-user-input all -- anywhere anywhere Chain ufw-before-logging-forward (1 references) target prot opt source destination Chain ufw-before-logging-input (1 references) target prot opt source destination Chain ufw-before-logging-output (1 references) target prot opt source destination Chain ufw-before-output (1 references) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ufw-user-output all -- anywhere anywhere Chain ufw-logging-allow (0 references) target prot opt source destination Chain ufw-logging-deny (2 references) target prot opt source destination Chain ufw-not-local (1 references) target prot opt source destination RETURN all -- anywhere anywhere ADDRTYPE match dst-type LOCAL RETURN all -- anywhere anywhere ADDRTYPE match dst-type MULTICAST RETURN all -- anywhere anywhere ADDRTYPE match dst-type BROADCAST ufw-logging-deny all -- anywhere anywhere limit: avg 3/min burst 10 DROP all -- anywhere anywhere Chain ufw-reject-forward (1 references) target prot opt source destination Chain ufw-reject-input (1 references) target prot opt source destination Chain ufw-reject-output (1 references) target prot opt source destination Chain ufw-skip-to-policy-forward (0 references) target prot opt source destination DROP all -- anywhere anywhere Chain ufw-skip-to-policy-input (7 references) target prot opt source destination DROP all -- anywhere anywhere Chain ufw-skip-to-policy-output (0 references) target prot opt source destination DROP all -- anywhere anywhere Chain ufw-track-forward (1 references) target prot opt source destination Chain ufw-track-input (1 references) target prot opt source destination Chain ufw-track-output (1 references) target prot opt source destination Chain ufw-user-forward (1 references) target prot opt source destination Chain ufw-user-input (1 references) target prot opt source destination tcp -- anywhere rambutan.zystro.xyz tcp dpt:22 ctstate NEW recent: SET name: DEFAULT side: source mask: 255.255.255.255 ufw-user-limit tcp -- anywhere rambutan.zystr o.xyz tcp dpt:22 ctstate NEW recent: UPDATE seconds: 30 hit_count: 6 name: DEFAULT side: source mask: 255.255.255.25 5 ufw-user-limit-accept tcp -- anywhere rambuta n.zystro.xyz tcp dpt:22 tcp -- anywhere rambutan.zystro.xyz tcp dpt:ssh ctstate NEW recent: SET name: DEFAULT side: so urce mask: 255.255.255.255 ufw-user-limit tcp -- anywhere rambutan.zystr o.xyz tcp dpt:ssh ctstate NEW recent: UPDATE seconds: 30 hi t_count: 6 name: DEFAULT side: source mask: 255.255.255.255 ufw-user-limit-accept tcp -- anywhere rambuta n.zystro.xyz tcp dpt:ssh ACCEPT udp -- anywhere anywhere udp dpt:domain ACCEPT tcp -- anywhere anywhere tcp dpt:domain Chain ufw-user-limit (2 references) target prot opt source destination REJECT all -- anywhere anywhere reject-with icmp-port-unreachable Chain ufw-user-limit-accept (2 references) target prot opt source destination ACCEPT all -- anywhere anywhere Chain ufw-user-logging-forward (0 references) target prot opt source destination RETURN all -- anywhere anywhere Chain ufw-user-logging-input (0 references) target prot opt source destination RETURN all -- anywhere anywhere Chain ufw-user-logging-output (0 references) target prot opt source destination RETURN all -- anywhere anywhere Chain ufw-user-output (1 references) target prot opt source destination ACCEPT tcp -- anywhere rambutan.zystro.xyz tcp dpt:22 ACCEPT udp -- anywhere anywhere udp dpt:ntp ACCEPT tcp -- anywhere anywhere tcp dpt:http ACCEPT tcp -- anywhere anywhere tcp dpt:https ACCEPT tcp -- anywhere anywhere tcp dpt:domain ACCEPT udp -- anywhere anywhere udp dpt:domain Regards, -badli ________________________________ From: Andy Smith via BitFolk Users &lt;users(a)mailman.bitfolk.com&gt; Sent: Sunday, April 23, 2023 11:03:20 PM To: users(a)mailman.bitfolk.com &lt;users(a)mailman.bitfolk.com&gt; Cc: Andy Smith &lt;andy(a)bitfolk.com&gt; Subject: [bitfolk] Re: question on bind9 listening. Hi Badli, On Sun, Apr 23, 2023 at 02:30:36AM +0000, Badli Al Rashid via BitFolk Users wrote: This isn't the full log. This is just the log line saying that the transfer is over. Yes it did fail otherwise it would be more than 0 records. But the reason for its failure is in another log line or lines. DNS zone transfers are always pull-based, i.e. they are initiated by the secondary server. The other lines will also be saying which IP address your BIND server chose as its source address for the transfer. That might not be the address you think it should be, if your BIND host has multiple IP addresses. Okay so these are logs from your BIND server (on what IP address?) that successfully did a transfer in from your PowerDNS server at 2400:8901::f03c:93ff:fe63:5988 for the zone testingforonedomain.com. I am not familiar with ufw myself so I'm on shakly ground here and might need to ask to see the actual iptables rules, but… …it looks like you're being strict about what traffic an go OUT as well as what can come IN. Is the above rule set what you have when you are trying to restrict things or is it what you consider to be "open"? I see you have rules allowing anything to come IN to port 53 UDP and TCP so is this the "open" configuration you are referring to? If this is the "open" configuration, tell us what exact rules you are adding to tighten it up. I don't know if ufw adds the rules that try to do connection tracking to link together established and related flows. Even if it does, I don't know if that will be enough to capture all the DNS traffic. Your BIND server is going to source UDP flows from random ports, not just port 53. You need to get your dropped packets to be logged and follow the logs to see what is happening when a zone transfer fails to work. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting

It is okey Andy, and I thank you for the help. I can not get an scp client installed in Android at the moment to give a full copy of the logs. Regards, -badli ________________________________ From: Andy Smith via BitFolk Users &lt;users(a)mailman.bitfolk.com&gt; Sent: Monday, April 24, 2023 10:14:48 AM To: users(a)mailman.bitfolk.com &lt;users(a)mailman.bitfolk.com&gt; Cc: Andy Smith &lt;andy(a)bitfolk.com&gt; Subject: [bitfolk] Re: question on bind9 listening. Badli, On Mon, Apr 24, 2023 at 12:24:50AM +0000, Badli Al Rashid via BitFolk Users wrote: You don't show HOW you did this. i.e. what exact changes you made to bind's configuration. You don't show what commands you typed to restart/reconfigure bind9 after changing its config. You don't show the full logs, only some parts that you think are interesting. Whether restart or reconfig, there would be much more than the above. Also the ones above are from 10 days ago! We can't tell why your bind9 stopped listening on all interfaces when you show neither your config, the full logs nor the commands you typed. It is just too hard to help you with this drip feed of partial information. I can't go another round of asking all the above questions and getting no or partial answers, so I'm going to have to give up now. Sorry. Regards, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting