22 Apr
2023
22 Apr
'23
6:46 p.m.
Hi All,
Is letting bind9 listening on all interfaces a good practice? Or letting it listening on
specific interface best ?
If I set specific address listening, bind9 failed to start and stops listening.
If i set bind9 to listen to all and block using the firewall the interface I do not it to
listen to bind9 to powerdns replication did not work. Powerdns as primary here.
It seems to be working if I set bind9 to listen to all interfaces and not block by the
firewall.
Regards,
-badli
22 Apr
22 Apr
7:33 p.m.
Hi Badli,
On Sat, Apr 22, 2023 at 06:46:10PM +0000, Badli Al Rashid via BitFolk Users wrote:
Is letting bind9 listening on all interfaces a good
practice? Or letting it listening on specific interface best ?
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.
If I set specific address listening, bind9 failed to
start and stops listening.
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".
If i set bind9 to listen to all and block using the
firewall the interface I do not it to listen to bind9 to powerdns replication did not
work. Powerdns as primary here.
It seems to be working if I set bind9 to listen to all interfaces and not block by the
firewall.
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
9:29 p.m.
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:
Is letting bind9 listening on all interfaces a good
practice? Or letting it listening on specific interface best ?
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.
If I set specific address listening, bind9 failed to
start and stops listening.
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".
If i set bind9 to listen to all and block using the
firewall the interface I do not it to listen to bind9 to powerdns replication did not
work. Powerdns as primary here.
It seems to be working if I set bind9 to listen to all interfaces and not block by the
firewall.
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
23 Apr
23 Apr
5:39 a.m.
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 <users(a)mailman.bitfolk.com>
Sent: Sunday, April 23, 2023, 05:34
To: users(a)mailman.bitfolk.com <users(a)mailman.bitfolk.com>
Cc: Iain Harrison <iain(a)hairydog.co.uk>
Subject: [bitfolk] Re: question on bind9 listening.
On 22/04/2023 22:29, Badli Al Rashid via BitFolk Users wrote:
Could be a miss configurations I suppose. Thanks.
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 <users(a)mailman.bitfolk.com>
You're subscribed as <badlialrashid(a)outlook.com>
Unsubscribe:
<https://mailman.bitfolk.com/mailman/postorius/lists/users.mailman.bitfolk.com/>
or send an email to <users-leave(a)mailman.bitfolk.com>
22 Apr
22 Apr
9:54 p.m.
Hi Badli,
On Sat, Apr 22, 2023 at 09:29:58PM +0000, Badli Al Rashid via BitFolk Users wrote:
On the logs it failed to listen x.x.x.x address at
port 53.
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.
Once I put the listen directive to any IP address bind
started to work again.
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
11:16 p.m.
Hi Andy,
Below are the logs for opening up the firewall but I can not find the logs that says fail
to listen on address.
When I open Port 53 was to all not just 2 IP address my axfr was completed.
Hope I be able to explain it properly.
foronedomain.com/IN: sending notifies (serial 20230
41906)
19-Apr-2023 08:36:55.075 general: info: received co
ntrol channel command 'stop'
19-Apr-2023 08:36:55.075 network: info: no longer l
istening on 127.0.0.1#53
19-Apr-2023 08:36:55.075 network: info: no longer l
istening on 85.119.83.49#53
19-Apr-2023 08:36:55.079 network: info: no longer l
istening on 85.119.82.135#53
19-Apr-2023 08:36:55.079 network: info: no longer l
istening on ::1#53
19-Apr-2023 08:36:55.079 network: info: no longer l
istening on 2001:ba8:1f1:f0b5::2#53
19-Apr-2023 08:36:55.079 network: info: no longer l
istening on fe80::216:5eff:fe00:5f5%2#53
Full part.
19-Apr-2023 08:01:45.149 xfer-in: info: 0x7f5d90e31
c00: transfer of 'testingforonedomain.com/IN' from
2400:8901::f03c:93ff:fe63:5988#53: Transfer complet
ed: 3 messages, 14 records, 512 bytes, 0.624 secs (
820 bytes/sec) (serial 2023041906)
19-Apr-2023 08:01:45.149 notify: info: zone testing
foronedomain.com/IN: sending notifies (serial 20230
41906)
19-Apr-2023 08:36:55.075 general: info: received co
ntrol channel command 'stop'
19-Apr-2023 08:36:55.075 network: info: no longer l
istening on 127.0.0.1#53
19-Apr-2023 08:36:55.075 network: info: no longer l
istening on 85.119.83.49#53
19-Apr-2023 08:36:55.079 network: info: no longer l
istening on 85.119.82.135#53
19-Apr-2023 08:36:55.079 network: info: no longer l
istening on ::1#53
19-Apr-2023 08:36:55.079 network: info: no longer l
istening on 2001:ba8:1f1:f0b5::2#53
19-Apr-2023 08:36:55.079 network: info: no longer l
istening on fe80::216:5eff:fe00:5f5%2#53
19-Apr-2023 08:36:55.079 general: notice: stopping
command channel on 127.0.0.1#953
19-Apr-2023 08:36:55.079 general: notice: stopping
command channel on ::1#953
19-Apr-2023 08:36:55.079 general: info: shutting do
wn: flushing changes
19-Apr-2023 08:36:55.119 general: info: configuring
command channel from '/etc/bind/rndc.key'
19-Apr-2023 08:36:55.119 general: notice: command c
hannel listening on 127.0.0.1#953
19-Apr-2023 08:36:55.119 general: info: configuring
command channel from '/etc/bind/rndc.key'
19-Apr-2023 08:36:55.119 general: notice: command c
hannel listening on ::1#953
19-Apr-2023 08:36:55.119 zoneload: info: managed-ke
ys-zone: loaded serial 103
19-Apr-2023 08:36:55.119 zoneload: info: zone 0.in-
addr.arpa/IN: loaded serial 1
19-Apr-2023 08:36:55.119 zoneload: info: zone 127.i
n-addr.arpa/IN: loaded serial 1
19-Apr-2023 08:36:55.119 zoneload: info: zone 255.i
n-addr.arpa/IN: loaded serial 1
19-Apr-2023 08:36:55.119 zoneload: info: zone testi
ngforonedomain.com/IN: loaded serial 2023041906
19-Apr-2023 08:36:55.119 zoneload: info: zone local
host/IN: loaded serial 2
19-Apr-2023 08:36:55.119 zoneload: info: zone zystr
o.xyz/IN: loaded serial 2023041901
19-Apr-2023 08:36:55.119 general: notice: all zones
loaded
19-Apr-2023 08:36:55.119 general: notice: running
19-Apr-2023 08:36:55.119 notify: info: zone zystro.
xyz/IN: sending notifies (serial 2023041901)
19-Apr-2023 08:36:55.119 notify: info: zone testing
foronedomain.com/IN: sending notifies (serial 20230
41906)
19-Apr-2023 08:36:55.123 dnssec: info: managed-keys
-zone: Key 20326 for zone . is now trusted (accepta
nce timer complete)
19-Apr-2023 08:36:55.127 resolver: info: resolver p
riming query complete: success
19-Apr-2023 08:36:55.535 xfer-out: info: client @0x
7f4fb4895c00 2605:2700:0:2:a800:ff:fe69:e7a7#34291
(zystro.xyz): transfer of 'zystro.xyz/IN': IXFR ver
sion not in journal, falling back to AXFR
19-Apr-2023 08:36:55.535 xfer-out: info: client @
Regards,
-badli
________________________________
From: Andy Smith via BitFolk Users <users(a)mailman.bitfolk.com>
Sent: Sunday, April 23, 2023 5:54:36 AM
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 09:29:58PM +0000, Badli Al Rashid via BitFolk Users wrote:
On the logs it failed to listen x.x.x.x address at
port 53.
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.
Once I put the listen directive to any IP address bind
started to work again.
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
11:49 p.m.
Hi Badli,
On Sat, Apr 22, 2023 at 11:16:22PM +0000, Badli Al Rashid via BitFolk Users wrote:
When I open Port 53 was to all not just 2 IP address
my axfr was completed.
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
23 Apr
23 Apr
2:30 a.m.
For powerdns axfr transfer to bind secondary yes.When the firewall was not open the logs
shows the below. 0 bytes as I recall.
19-Apr-2023 07:44:41.419 xfer-in: info: 0x7f9a84a8d
c00: transfer of 'testingforonedomain.com/IN' from
2400:8901::f03c:93ff:fe63:5988#53: Transfer complet
ed: 0 messages, 0 records, 0 bytes, 23.208 secs
For opening port 53 incoming and outgoing on all the interface, no. When it is open and
not set to a specific IP address the AXFR is completed
9-Apr-2023 07:44:41.727 xfer-in: info: zone testin
gforonedomain.com/IN: Transfer started.
19-Apr-2023 07:44:41.967 xfer-in: info: 0x7f5d90e31
000: transfer of 'testingforonedomain.com/IN' from
2400:8901::f03c:93ff:fe63:5988#53: connected using
2400:8901::f03c:93ff:fe63:5988#53
19-Apr-2023 07:44:42.447 xfer-in: info: zone testin
gforonedomain.com/IN: transferred serial 2023041905
19-Apr-2023 07:44:42.447 xfer-in: info: 0x7f5d90e31
000: transfer of 'testingforonedomain.com/IN' from
2400:8901::f03c:93ff:fe63:5988#53: Transfer status:
success
19-Apr-2023 07:44:42.447 xfer-in: info: 0x7f5d90e31
000: transfer of 'testingforonedomain.com/IN' from
2400:8901::f03c:93ff:fe63:5988#53: Transfer complet
ed: 3 messages, 14 records, 512 bytes, 0.480 secs (
1066 bytes/sec) (serial 2023041905)
19-Apr-2023 07:44:42.447 notify: info: zone testing
foronedomain.com/IN: sending notifies (serial 20230
41905)
Below is the zonefile.
root@rambutan:~# cat /etc/bind/named.conf.testingfo
ronedomain.com
zone "testingforonedomain.com" in {
type slave;
file "/var/lib/bind/testingforonedomain.com.save"
;
zone-statistics yes;
masters {
2400:8901::f03c:93ff:fe63:5988;
139.162.3.44;
};
};
For firewall it is ufw. Ssh rule omit
To Action From
-- ------ ----
53/udp ALLOW Anywhere
53/tcp ALLOW Anywhere
53/udp (v6) ALLOW Anywhere (v6
)
53/tcp (v6) ALLOW Anywhere (v6
)
123/udp ALLOW OUT Anywhere
80/tcp ALLOW OUT Anywhere
443/tcp ALLOW OUT Anywhere
53/tcp ALLOW OUT Anywhere
53/udp ALLOW OUT Anywhere
123/udp (v6) ALLOW OUT Anywhere (v6
)
80/tcp (v6) ALLOW OUT Anywhere (v6
)
443/tcp (v6) ALLOW OUT Anywhere (v6
)
53/tcp (v6) ALLOW OUT Anywhere (v6
)
53/udp (v6) ALLOW OUT Anywhere (v6
)
I will just have to let port 53 to open as it can resolve the pdns hosted domian.
Regards,
-badli
________________________________
From: Andy Smith via BitFolk Users <users(a)mailman.bitfolk.com>
Sent: Sunday, April 23, 2023, 07:50
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 11:16:22PM +0000, Badli Al Rashid via BitFolk Users wrote:
When I open Port 53 was to all not just 2 IP address
my axfr was completed.
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
3:03 p.m.
Hi Badli,
On Sun, Apr 23, 2023 at 02:30:36AM +0000, Badli Al Rashid via BitFolk Users wrote:
For powerdns axfr transfer to bind secondary yes.When
the firewall was not open the logs shows the below. 0 bytes as I recall.
19-Apr-2023 07:44:41.419 xfer-in: info: 0x7f9a84a8d
c00: transfer of 'testingforonedomain.com/IN' from
2400:8901::f03c:93ff:fe63:5988#53: Transfer complet
ed: 0 messages, 0 records, 0 bytes, 23.208 secs
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.
For opening port 53 incoming and outgoing on all the
interface, no. When it is open and not set to a specific IP address the AXFR is completed
9-Apr-2023 07:44:41.727 xfer-in: info: zone testin
gforonedomain.com/IN: Transfer started.
19-Apr-2023 07:44:41.967 xfer-in: info: 0x7f5d90e31
000: transfer of 'testingforonedomain.com/IN' from
2400:8901::f03c:93ff:fe63:5988#53: connected using
2400:8901::f03c:93ff:fe63:5988#53
19-Apr-2023 07:44:42.447 xfer-in: info: zone testin
gforonedomain.com/IN: transferred serial 2023041905
19-Apr-2023 07:44:42.447 xfer-in: info: 0x7f5d90e31
000: transfer of 'testingforonedomain.com/IN' from
2400:8901::f03c:93ff:fe63:5988#53: Transfer status:
success
19-Apr-2023 07:44:42.447 xfer-in: info: 0x7f5d90e31
000: transfer of 'testingforonedomain.com/IN' from
2400:8901::f03c:93ff:fe63:5988#53: Transfer complet
ed: 3 messages, 14 records, 512 bytes, 0.480 secs (
1066 bytes/sec) (serial 2023041905)
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.
For firewall it is ufw. Ssh rule omit
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…
To Action From
-- ------ ----
53/udp ALLOW Anywhere
53/tcp ALLOW Anywhere
53/udp (v6) ALLOW Anywhere (v6
)
53/tcp (v6) ALLOW Anywhere (v6
)
123/udp ALLOW OUT Anywhere
80/tcp ALLOW OUT Anywhere
443/tcp ALLOW OUT Anywhere
53/tcp ALLOW OUT Anywhere
53/udp ALLOW OUT Anywhere
123/udp (v6) ALLOW OUT Anywhere (v6
)
80/tcp (v6) ALLOW OUT Anywhere (v6
)
443/tcp (v6) ALLOW OUT Anywhere (v6
)
53/tcp (v6) ALLOW OUT Anywhere (v6
)
53/udp (v6) ALLOW OUT Anywhere (v6
)
…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
24 Apr
24 Apr
12:24 a.m.
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 <users(a)mailman.bitfolk.com>
Sent: Sunday, April 23, 2023 11:03:20 PM
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 Sun, Apr 23, 2023 at 02:30:36AM +0000, Badli Al Rashid via BitFolk Users wrote:
For powerdns axfr transfer to bind secondary yes.When
the firewall was not open the logs shows the below. 0 bytes as I recall.
19-Apr-2023 07:44:41.419 xfer-in: info: 0x7f9a84a8d
c00: transfer of 'testingforonedomain.com/IN' from
2400:8901::f03c:93ff:fe63:5988#53: Transfer complet
ed: 0 messages, 0 records, 0 bytes, 23.208 secs
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.
For opening port 53 incoming and outgoing on all the
interface, no. When it is open and not set to a specific IP address the AXFR is completed
9-Apr-2023 07:44:41.727 xfer-in: info: zone testin
gforonedomain.com/IN: Transfer started.
19-Apr-2023 07:44:41.967 xfer-in: info: 0x7f5d90e31
000: transfer of 'testingforonedomain.com/IN' from
2400:8901::f03c:93ff:fe63:5988#53: connected using
2400:8901::f03c:93ff:fe63:5988#53
19-Apr-2023 07:44:42.447 xfer-in: info: zone testin
gforonedomain.com/IN: transferred serial 2023041905
19-Apr-2023 07:44:42.447 xfer-in: info: 0x7f5d90e31
000: transfer of 'testingforonedomain.com/IN' from
2400:8901::f03c:93ff:fe63:5988#53: Transfer status:
success
19-Apr-2023 07:44:42.447 xfer-in: info: 0x7f5d90e31
000: transfer of 'testingforonedomain.com/IN' from
2400:8901::f03c:93ff:fe63:5988#53: Transfer complet
ed: 3 messages, 14 records, 512 bytes, 0.480 secs (
1066 bytes/sec) (serial 2023041905)
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.
For firewall it is ufw. Ssh rule omit
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…
To Action From
-- ------ ----
53/udp ALLOW Anywhere
53/tcp ALLOW Anywhere
53/udp (v6) ALLOW Anywhere (v6
)
53/tcp (v6) ALLOW Anywhere (v6
)
123/udp ALLOW OUT Anywhere
80/tcp ALLOW OUT Anywhere
443/tcp ALLOW OUT Anywhere
53/tcp ALLOW OUT Anywhere
53/udp ALLOW OUT Anywhere
123/udp (v6) ALLOW OUT Anywhere (v6
)
80/tcp (v6) ALLOW OUT Anywhere (v6
)
443/tcp (v6) ALLOW OUT Anywhere (v6
)
53/tcp (v6) ALLOW OUT Anywhere (v6
)
53/udp (v6) ALLOW OUT Anywhere (v6
)
…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
2:14 a.m.
Badli,
On Mon, Apr 24, 2023 at 12:24:50AM +0000, Badli Al Rashid via BitFolk Users wrote:
If I set the listen to specific, bind9 would fail to
listen. Example.
You don't show HOW you did this. i.e. what exact changes you made to
bind's configuration.
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
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
2:30 a.m.
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 <users(a)mailman.bitfolk.com>
Sent: Monday, April 24, 2023 10:14:48 AM
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.
Badli,
On Mon, Apr 24, 2023 at 12:24:50AM +0000, Badli Al Rashid via BitFolk Users wrote:
If I set the listen to specific, bind9 would fail to
listen. Example.
You don't show HOW you did this. i.e. what exact changes you made to
bind's configuration.
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
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
607
days inactive
609
days old
13 comments
4 participants
participants (4)
-
Andy Smith -
Badli Al Rashid -
Iain Harrison -
Ole-Morten Duesund