Re: Authoritative and caching
I'm so sorry, but I have to trouble you guys again.
The help below helped, I have no errors from checkconf or checkzone, but
from journalctl I get:
/etc/bind/zones/db.jungersen.dk.jbk: create: permission denied
and
/etc/bind/zones/db.jungersen.dk.signed.jnl: create: permission denied
and some more, but I think these 2 are the causes.
But if I try:
root@ns1:/etc/bind/zones# ps auxw|grep named
bind 57446 0.1 1.2 147948 48140 ? Ssl 17:12 0:01
/usr/sbin/named -f -4 -u bind
root 57472 0.0 0.0 6332 2036 pts/1 S+ 17:21 0:00 grep
named
It look to me like the user is "bind"
I also have:
drwxrwsr-x 2 root bind 4096 Mar 15 16:54 zones
I have added write permission for the bind group.
I have also tried to change owner to bind, same result.
I have .key .private and .state files is /var/cache/bind
What does these errors mean?
I assume that the files that it tries to write are supposed to be written(?)
And why is it rejected?
BR
Danjel
On 12-03-2025 23:49, Mark Andrews wrote:
I shouldn’t have tried to write that on the phone from memory.
dnssec-policy “unlimited” {
keys { csk lifetime unlimited algorithm ECDSAP256SHA256; };
};
zone "jungersen.dk” {
type master;
file "/etc/bind/zones/db.jungersen.dk”;
allow-transfer { 192.168.20.11; };
dnssec-policy "unlimited";
};
Mark
On 13 Mar 2025, at 09:13, Danjel Jungersen wrote:
On 20-02-2025 08:40, Mark Andrews wrote:
The zone is available publicly, but from public serveres not hosted by me
(one.com).
And points to my external ip.
My internal bind redirects local traffic directly to local servers on local
ip's.
DNSSEC is designed to stop spoofed answers being accepted. When you create a
local zone that overrides what is in the public zones you are effectively
spoofing answers. As you have a DNSSEC signed public zone if you want to have
these spoofed answers accepted you need to do one of the following:
1) create a working chain of trust that links to your private zone content
Long 1 is the best long term solution
So this is the way I will try to go.
You currently have the following DS which means you are using ECDSAP256SHA256
(13) as the DNSSEC key algorithm.
jungersen.dk. 7200 IN DS 26658 13 2
23E45B495015A14C3F4FF57C0A36850C013B881BAAF1E32EE4C0C839 FF9CCA52
I would add “dnssec-policy { csk lifetime unlimited algorithm ECDSAP256SHA256;
};” to your internal primary if you choose to do 1 or 3. This will add a
DNSKEY record to the zone and cause it to be signed. You can then take the
generated DNSKEY and install it as a trust anchor on the postfix boxes.
You will need to do some reading first. Others here can give you more advice.
I have now read a lot, and I think that actually understood some of it.
I have:
zone "jungersen.dk" {
type master;
file "/etc/bind/zones/db.jungersen.dk";
allow-transfer { 192.168.20.11; };
dnssec-policy { csk lifetime unlimited algorithm ECDSAP256SHA256; };
};
in named.conf.local
I throws an error, /etc/bind/named.conf.local:15: expected string near '{'
Line 15 is the dnssec-policy line.
If I uncomment this line all is well.
Can anyone tell me what is wrong with this line?
I have copy pasted it from the suggestion, and have read some online, to me it
looks good.
BR
Danjel
--
Med venlig hilsen/Kind regards
Danjel Jungersen
Mail: dan...@jungersen.dk
Mobile: +45 20 42 20 11
Jungersen Grafisk ApS,
Holsbjergvej 39, DK-2620 Albertslund,
Denmark.
Tel: +45 43 64 10 00
WEBSHOP: PRINTLIGHT.DK | WWW.JUNGERSEN.DK
Logo --
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: Authoritative and caching
Off-list I was asked.
root@ns1:/etc/bind# ls -la
total 60
drwxr-sr-x 3 root bind 4096 Mar 15 16:31 .
drwxr-xr-x 71 root root 4096 Jan 6 08:40 ..
-rw-r--r-- 1 root root 2403 Jul 27 2024 bind.keys
-rw-r--r-- 1 root root 255 Jul 27 2024 db.0
-rw-r--r-- 1 root root 271 Jul 27 2024 db.127
-rw-r--r-- 1 root root 237 Jul 27 2024 db.255
-rw-r--r-- 1 root root 353 Jul 27 2024 db.empty
-rw-r--r-- 1 root root 270 Jul 27 2024 db.local
-rw-r--r-- 1 root bind 458 Jul 27 2024 named.conf
-rw-r--r-- 1 root bind 498 Jul 27 2024 named.conf.default-zones
-rw-r--r-- 1 root bind 737 Mar 13 08:41 named.conf.local
-rw-r--r-- 1 root bind 950 Jan 30 08:58 named.conf.options
-rw-r- 1 bind bind 100 Jan 3 15:27 rndc.key
drwxrwsr-x 2 root bind 4096 Mar 15 16:54 zones
-rw-r--r-- 1 root root 1317 Jul 27 2024 zones.rfc1918
root@ns1:/etc/bind/zones# ls -la
total 20
drwxrwsr-x 2 root bind 4096 Mar 15 16:54 .
drwxr-sr-x 3 root bind 4096 Mar 15 16:31 ..
-rw-rw-r-- 1 root bind 445 Jan 5 17:58 db.192.168
-rw-rw-r-- 1 root bind 509 Jan 5 17:12 db.jg1.jungersen.dk
-rw-rw-r-- 1 root bind 681 Mar 15 16:54 db.jungersen.dk
I was also aksed about the setgid bit, I have no reason/explanation for it.
Nor do I have any special wishes, so if it is best practice to do it
differently, I can change it.
Apparmor was also mentioned, I have no experience with that, and have
not changed it in any way (to my knowledge)...
if I have opened up too much in my effort to make it work, please let me
know, I wish to keep it as tight as possible.
:-)
Danjel
On 15-03-2025 17:31, Danjel Jungersen via bind-users wrote:
I'm so sorry, but I have to trouble you guys again.
The help below helped, I have no errors from checkconf or checkzone,
but from journalctl I get:
/etc/bind/zones/db.jungersen.dk.jbk: create: permission denied
and
/etc/bind/zones/db.jungersen.dk.signed.jnl: create: permission denied
and some more, but I think these 2 are the causes.
But if I try:
root@ns1:/etc/bind/zones# ps auxw|grep named
bind 57446 0.1 1.2 147948 48140 ? Ssl 17:12 0:01
/usr/sbin/named -f -4 -u bind
root 57472 0.0 0.0 6332 2036 pts/1 S+ 17:21 0:00 grep
named
It look to me like the user is "bind"
I also have:
drwxrwsr-x 2 root bind 4096 Mar 15 16:54 zones
I have added write permission for the bind group.
I have also tried to change owner to bind, same result.
I have .key .private and .state files is /var/cache/bind
What does these errors mean?
I assume that the files that it tries to write are supposed to be
written(?)
And why is it rejected?
BR
Danjel
On 12-03-2025 23:49, Mark Andrews wrote:
I shouldn’t have tried to write that on the phone from memory.
dnssec-policy “unlimited” {
keys { csk lifetime unlimited algorithm ECDSAP256SHA256; };
};
zone "jungersen.dk” {
type master;
file "/etc/bind/zones/db.jungersen.dk”;
allow-transfer { 192.168.20.11; };
dnssec-policy "unlimited";
};
Mark
On 13 Mar 2025, at 09:13, Danjel Jungersen wrote:
On 20-02-2025 08:40, Mark Andrews wrote:
The zone is available publicly, but from public serveres not hosted by me
(one.com).
And points to my external ip.
My internal bind redirects local traffic directly to local servers on local
ip's.
DNSSEC is designed to stop spoofed answers being accepted. When you create a
local zone that overrides what is in the public zones you are effectively
spoofing answers. As you have a DNSSEC signed public zone if you want to have
these spoofed answers accepted you need to do one of the following:
1) create a working chain of trust that links to your private zone content
Long 1 is the best long term solution
So this is the way I will try to go.
You currently have the following DS which means you are using ECDSAP256SHA256
(13) as the DNSSEC key algorithm.
jungersen.dk. 7200 IN DS 26658 13 2
23E45B495015A14C3F4FF57C0A36850C013B881BAAF1E32EE4C0C839 FF9CCA52
I would add “dnssec-policy { csk lifetime unlimited algorithm ECDSAP256SHA256;
};” to your internal primary if you choose to do 1 or 3. This will add a
DNSKEY record to the zone and cause it to be signed. You can then take the
generated DNSKEY and install it as a trust anchor on the postfix boxes.
You will need to do some reading first. Others here can give you more advice.
I have now read a lot, and I think that actually understood some of it.
I have:
zone "jungersen.dk" {
type master;
file "/etc/bind/zones/db.jungersen.dk";
allow-transfer { 192.168.20.11; };
dnssec-policy { csk lifetime unlimited algorithm ECDSAP256SHA256; };
};
in named.conf.local
I throws an error, /etc/bind/named.conf.local:15: expected string near '{'
Line 15 is the dnssec-policy line.
If I uncomment this line all is well.
Can anyone tell me what is wrong with this line?
I have copy pasted it from the
Re: Authoritative and caching
On 19-02-2025 12:04, Greg Choules wrote: Hi Danjel. To obtain a packet capture use tcpdump, which is probably installed already. If not, add it using your preferred package manager. You can dump to the screen, but I find it more useful to dump to a file, which can then be analysed offline in Wireshark. A typical capture command might be: sudo tcpdump -nvc 1000 -w host "( 192.168.20.10 or 192.168.20.11)" and port 53 OK, I tried that. I also studied the output in wireshark. But since this is my first try, I don't know what to look for, and cannot find out what's wrong. I get: root@mail:~# dig A mail.jungersen.dk @127.0.0.1 ; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> A mail.jungersen.dk @127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47697 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 41461c3ea02342e4010067dfdba11eea65ad9061831f (good) ;; QUESTION SECTION: ;mail.jungersen.dk. IN A ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Sun Mar 23 11:00:01 CET 2025 ;; MSG SIZE rcvd: 74 The mentioned tcpdump command gave the attached result. Just to sum it up: My setup: I have a mailserver (192.168.20.9), on the same box I have bind as resolver. I have 2 bind boxes running as "local authoritative" for the jungersen.dk zone (192.168.20.10 and 192.168.20.11) This was meant to give me the result of 192.168.20.9 when looking up my local mailserver on my local network, while giving the 212.27.12.12 result when asked from the public. The public DNS is hosted at one.com I tried setting up dnssec to satisfy the suggested solution: 1) create a working chain of trust that links to your private zone content But you may have guessed it, it does not work. Does the above give enough info to give me more guidance? TIA Danjel That will capture to disk all DNS traffic to and from your forwarders, up to a limit of 1000 packets, just as a safety net. Once that is running, make your tests to the local machine, stop the capture, upload it here if you wish or just open it in Wireshark and follow the conversations and their timeline. It is almost certainly a DNSSEC problem though, as Mark says. Hope that helps. Cheers, Greg On Wed, 19 Feb 2025 at 10:22, Danjel Jungersen via bind-users wrote: On 19-02-2025 11:11, Marco Moock wrote: > Am Wed, 19 Feb 2025 10:58:14 +0100 > schrieb Danjel Jungersen via bind-users : > >> But if I change /etc/resolv.conf to 127.0.0.1 something happens >> If I do a dig or ping from my postfixbox to something that the 2 main >> bind-boxes are authoratative for, it doesn't work. > Please sniff the DNS traffic between the 2 machines and check if the > request goes out to the authoritative server and check what it replied. > > You can trigger the request by > > dig A/ non-working domain @IP. > > Try +recurse/+norecurse to check if the issue is related to those flags. root@mail:~# dig A mail.jungersen.dk <http://mail.jungersen.dk> @127.0.0.1 <http://127.0.0.1> ; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> A mail.jungersen.dk <http://mail.jungersen.dk> @127.0.0.1 <http://127.0.0.1> ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9792 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: d55e55f5d6573eaf010067b5af13a2e4bdccbb3ce36b (good) ;; QUESTION SECTION: ;mail.jungersen.dk <http://mail.jungersen.dk>. IN A ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Wed Feb 19 11:14:43 CET 2025 ;; MSG SIZE rcvd: 74 dig +recurse A mail.jungersen.dk <http://mail.jungersen.dk> @127.0.0.1 <http://127.0.0.1> ; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> +recurse A mail.jungersen.dk <http://mail.jungersen.dk> @127.0.0.1 <http://127.0.0.1> ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 19526 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 1579e49c3774139b010067b5af24e95ccd20f610d99d (good) ;; QUESTION SECTION: ;mail.jungersen.dk <http://mail.jungersen.dk>. IN A ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Wed Feb 19 11:15:00 CET 2025 ;; MSG SIZE rcvd: 74 dig +norecurse A mail.jungersen.dk <http://m
Re: Authoritative and caching
>I would either change ownership of "/etc/bind" and all files and folders
>below that from "root" to "bind", or, if the group for user "bind" is also
>"bind", leave ownership as root but change group permissions to rwx for
>everything "/etc/bind" and below. You could try starting with just
>"/etc/bind" and see if that helps. Then continue down if not.
>
>Some more Linux-savvy people will no doubt have something to say on the
>matter :)
I read somewhere online that it makes sense to use /var/lib/bind or
/var/cache/bind for signed zones.
???
If bind should be denied write access to /etc/... maybe this is the way to go?
:-)
Danjel
>
>Cheers, Greg
>
>On Sat, 15 Mar 2025 at 21:25, Danjel Jungersen via bind-users <
>bind-users@lists.isc.org> wrote:
>
>> Off-list I was asked.
>>
>> root@ns1:/etc/bind# ls -la
>> total 60
>> drwxr-sr-x 3 root bind 4096 Mar 15 16:31 .
>> drwxr-xr-x 71 root root 4096 Jan 6 08:40 ..
>> -rw-r--r-- 1 root root 2403 Jul 27 2024 bind.keys
>> -rw-r--r-- 1 root root 255 Jul 27 2024 db.0
>> -rw-r--r-- 1 root root 271 Jul 27 2024 db.127
>> -rw-r--r-- 1 root root 237 Jul 27 2024 db.255
>> -rw-r--r-- 1 root root 353 Jul 27 2024 db.empty
>> -rw-r--r-- 1 root root 270 Jul 27 2024 db.local
>> -rw-r--r-- 1 root bind 458 Jul 27 2024 named.conf
>> -rw-r--r-- 1 root bind 498 Jul 27 2024 named.conf.default-zones
>> -rw-r--r-- 1 root bind 737 Mar 13 08:41 named.conf.local
>> -rw-r--r-- 1 root bind 950 Jan 30 08:58 named.conf.options
>> -rw-r- 1 bind bind 100 Jan 3 15:27 rndc.key
>> drwxrwsr-x 2 root bind 4096 Mar 15 16:54 zones
>> -rw-r--r-- 1 root root 1317 Jul 27 2024 zones.rfc1918
>>
>> root@ns1:/etc/bind/zones# ls -la
>> total 20
>> drwxrwsr-x 2 root bind 4096 Mar 15 16:54 .
>> drwxr-sr-x 3 root bind 4096 Mar 15 16:31 ..
>> -rw-rw-r-- 1 root bind 445 Jan 5 17:58 db.192.168
>> -rw-rw-r-- 1 root bind 509 Jan 5 17:12 db.jg1.jungersen.dk
>> -rw-rw-r-- 1 root bind 681 Mar 15 16:54 db.jungersen.dk
>>
>> I was also aksed about the setgid bit, I have no reason/explanation for it.
>> Nor do I have any special wishes, so if it is best practice to do it
>> differently, I can change it.
>>
>> Apparmor was also mentioned, I have no experience with that, and have not
>> changed it in any way (to my knowledge)...
>>
>> if I have opened up too much in my effort to make it work, please let me
>> know, I wish to keep it as tight as possible.
>>
>> :-)
>> Danjel
>>
>>
>> On 15-03-2025 17:31, Danjel Jungersen via bind-users wrote:
>>
>> I'm so sorry, but I have to trouble you guys again.
>>
>> The help below helped, I have no errors from checkconf or checkzone, but
>> from journalctl I get:
>> /etc/bind/zones/db.jungersen.dk.jbk: create: permission denied
>> and
>> /etc/bind/zones/db.jungersen.dk.signed.jnl: create: permission denied
>>
>> and some more, but I think these 2 are the causes.
>>
>> But if I try:
>> root@ns1:/etc/bind/zones# ps auxw|grep named
>> bind 57446 0.1 1.2 147948 48140 ?Ssl 17:12 0:01
>> /usr/sbin/named -f -4 -u bind
>> root 57472 0.0 0.0 6332 2036 pts/1S+ 17:21 0:00 grep
>> named
>>
>> It look to me like the user is "bind"
>>
>> I also have:
>> drwxrwsr-x 2 root bind 4096 Mar 15 16:54 zones
>>
>> I have added write permission for the bind group.
>>
>> I have also tried to change owner to bind, same result.
>>
>> I have .key .private and .state files is /var/cache/bind
>>
>> What does these errors mean?
>> I assume that the files that it tries to write are supposed to be
>> written(?)
>>
>> And why is it rejected?
>>
>> BR
>> Danjel
>> On 12-03-2025 23:49, Mark Andrews wrote:
>>
>> I shouldn’t have tried to write that on the phone from memory.
>>
>> dnssec-policy “unlimited” {
>> keys { csk lifetime unlimited algorithm ECDSAP256SHA256; };
>> };
>>
>> zone "jungersen.dk” {
>> type master;
>> file "/etc/bind/zones/db.jungersen.dk”;
>> allow-transfer { 192.168.20.11; };
>> dnssec-policy "unlimited";
>> };
>>
>> Mark
>>
>>
>> On 13 Mar 2025, at 09:13, Danjel Jungersen
>> wrote:
>>
>> On 20-02-2025 08:40, Mark Andrews wrote:
>>
>> The zone is available publicly, but from public serveres not hosted by me
Re: Authoritative and caching
On 16-03-2025 21:40, Greg Choules wrote: Hi. From what others have said, that makes sense. For BIND's static files to be under /etc and operational files (zone data, journals etc.) to be somewhere else. What are the permissions on /var/lib/bind/ and/or /var/cache/bind? Both is root:bind and bind has write access. I have changed the named.conf.local and moved the db. file of the signed zone to /var/lib/bind and it seems to work. The K files show up in /var/cache/bind THANKS. Now I just need the rest. :-) Danjel -- 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
Authoritative and caching
Hi.
I have a primary and a secondary set up on debian 12.
They both seem to work.
They are authoratative for my own domain that is used to redirect local
traffic to local servers.
There are no (inbound) contact from the outside to bind.
I then have a postfix server, where I need to run a local caching
bind-instance.
I have added my 2 main bind-boxes as forwarders on my postfix box.
If I have the 2 main bind-boxes as resolvers, everything works.
But if I change /etc/resolv.conf to 127.0.0.1 something happens
If I do a dig or ping from my postfixbox to something that the 2 main
bind-boxes are authoratative for, it doesn't work.
External domains like postfix.org work perfectly.
Postfix box setup:
**
acl "trusted" {
127.0.0.1/32;
localhost;
};
and options section:
recursion yes;
allow-query { trusted; };
listen-on { 127.0.0.1; };
allow-transfer { none; };
forwarders {
192.168.20.10;
192.168.20.11;
};
forward only;
dnssec-validation auto;
***
Any clues?
Or any hints of where to look for answers?
Best regards
Danjel
PS: Please forgive me for (possibly) asking stupid questions, bind is
rather new to me.
--
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: Authoritative and caching
On 19-02-2025 11:11, Marco Moock wrote: Am Wed, 19 Feb 2025 10:58:14 +0100 schrieb Danjel Jungersen via bind-users : But if I change /etc/resolv.conf to 127.0.0.1 something happens If I do a dig or ping from my postfixbox to something that the 2 main bind-boxes are authoratative for, it doesn't work. Please sniff the DNS traffic between the 2 machines and check if the request goes out to the authoritative server and check what it replied. You can trigger the request by dig A/ non-working domain @IP. Try +recurse/+norecurse to check if the issue is related to those flags. root@mail:~# dig A mail.jungersen.dk @127.0.0.1 ; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> A mail.jungersen.dk @127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9792 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: d55e55f5d6573eaf010067b5af13a2e4bdccbb3ce36b (good) ;; QUESTION SECTION: ;mail.jungersen.dk. IN A ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Wed Feb 19 11:14:43 CET 2025 ;; MSG SIZE rcvd: 74 dig +recurse A mail.jungersen.dk @127.0.0.1 ; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> +recurse A mail.jungersen.dk @127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 19526 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 1579e49c3774139b010067b5af24e95ccd20f610d99d (good) ;; QUESTION SECTION: ;mail.jungersen.dk. IN A ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Wed Feb 19 11:15:00 CET 2025 ;; MSG SIZE rcvd: 74 dig +norecurse A mail.jungersen.dk @127.0.0.1 ; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> +norecurse A mail.jungersen.dk @127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10118 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 689869318da8e64c010067b5af33f48840b2e116d76e (good) ;; QUESTION SECTION: ;mail.jungersen.dk. IN A ;; AUTHORITY SECTION: . 360 IN NS E.ROOT-SERVERS.NET. . 360 IN NS F.ROOT-SERVERS.NET. . 360 IN NS L.ROOT-SERVERS.NET. . 360 IN NS C.ROOT-SERVERS.NET. . 360 IN NS B.ROOT-SERVERS.NET. . 360 IN NS A.ROOT-SERVERS.NET. . 360 IN NS J.ROOT-SERVERS.NET. . 360 IN NS D.ROOT-SERVERS.NET. . 360 IN NS H.ROOT-SERVERS.NET. . 360 IN NS G.ROOT-SERVERS.NET. . 360 IN NS I.ROOT-SERVERS.NET. . 360 IN NS K.ROOT-SERVERS.NET. . 360 IN NS M.ROOT-SERVERS.NET. ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Wed Feb 19 11:15:15 CET 2025 ;; MSG SIZE rcvd: 297 Not sure how to do the sniff part(?) But I must get some sort of answer... dig A postfix.org @127.0.0.1 ; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> A postfix.org @127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2255 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 6c3f5cf7e1e34e45010067b5b035b878201ed4e8d3fd (good) ;; QUESTION SECTION: ;postfix.org. IN A ;; ANSWER SECTION: postfix.org. 3600 IN A 65.108.3.114 ;; Query time: 852 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Wed Feb 19 11:19:33 CET 2025 ;; MSG SIZE rcvd: 84 Best regards Danjel -- 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: Authoritative and caching
On 19-02-2025 11:44, Mark Andrews wrote: The posix boxes are validating the responses and your zone is not properly delegated/signed so DNSSEC validation fails. Is there a way to overcome this? They are not delegated, since they are not public. - Or am I missing something? But explains why external queries works What does the following return? dig +cd +dnssec mail.jungersen.dk I assume I should use the failing bind, so I ran: dig +cd +dnssec mail.jungersen.dk @127.0.0.1 ; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> +cd +dnssec mail.jungersen.dk @127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48939 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; COOKIE: 52f0a7e82a12fe10010067b5b70dfe529ce9754d3aa8 (good) ;; QUESTION SECTION: ;mail.jungersen.dk. IN A ;; ANSWER SECTION: mail.jungersen.dk. 372094 IN A 192.168.20.9 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Wed Feb 19 11:48:45 CET 2025 ;; MSG SIZE rcvd: 90 BR Danjel -- 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: Authoritative and caching
On 20-02-2025 08:40, Mark Andrews wrote:
The zone is available publicly, but from public serveres not hosted by me
(one.com).
And points to my external ip.
My internal bind redirects local traffic directly to local servers on local
ip's.
DNSSEC is designed to stop spoofed answers being accepted. When you create a
local zone that overrides what is in the public zones you are effectively
spoofing answers. As you have a DNSSEC signed public zone if you want to have
these spoofed answers accepted you need to do one of the following:
1) create a working chain of trust that links to your private zone content
Long 1 is the best long term solution
So this is the way I will try to go.
You currently have the following DS which means you are using ECDSAP256SHA256
(13) as the DNSSEC key algorithm.
jungersen.dk. 7200 IN DS 26658 13 2
23E45B495015A14C3F4FF57C0A36850C013B881BAAF1E32EE4C0C839 FF9CCA52
I would add “dnssec-policy { csk lifetime unlimited algorithm ECDSAP256SHA256;
};” to your internal primary if you choose to do 1 or 3. This will add a
DNSKEY record to the zone and cause it to be signed. You can then take the
generated DNSKEY and install it as a trust anchor on the postfix boxes.
You will need to do some reading first. Others here can give you more advice.
I have now read a lot, and I think that actually understood some of it.
I have:
zone "jungersen.dk" {
type master;
file "/etc/bind/zones/db.jungersen.dk";
allow-transfer { 192.168.20.11; };
dnssec-policy { csk lifetime unlimited algorithm
ECDSAP256SHA256; };
};
in named.conf.local
I throws an error, /etc/bind/named.conf.local:15: expected string near '{'
Line 15 is the dnssec-policy line.
If I uncomment this line all is well.
Can anyone tell me what is wrong with this line?
I have copy pasted it from the suggestion, and have read some online, to
me it looks good.
BR
Danjel
--
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: Authoritative and caching
On 19 February 2025 13:01:01 CET, Mark Andrews wrote: >You can install a negative trust anchor or sign the zone so that DNSSEC >validation works. The zone exists in the public DNS. You can use the same key >material or use different key material and publish multiple DS records for >both the private and public DNSKEYs. > >The later will allow DNSSEC validation to work with BYOD. > >You can also sign your internal zone and add trust anchors for it without >publishing DS records. This won’t work BYOD. I'm very sorry, but you lost me there. The zone is available publicly, but from public serveres not hosted by me (one.com). And points to my external ip. My internal bind redirects local traffic directly to local servers on local ip's. It is 1 zone (jungersen.dk), currently 6 hosts (mail.jungersen.dk ftp.jungersen.dk and a couple of more) 1 server that need this extra caching, the rest of machines are using the "real" bind directly, and this works. Thinking about it makes me wonder why this works. Is it because it is an authoritative server? Even though it is not signed? What would be the easiest route from here? Tia Danjel -- 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: Authoritative and caching
Hi everyone. Thank you for all your help! One key info that I missed, the DS record should be placed on the TLD host. I tried (and failed) using the "normal" public available DNS for my domain. Now back to the original problem, getting DANE set up. All the best! Danjel On 23-03-2025 11:18, Danjel Jungersen via bind-users wrote: On 19-02-2025 12:04, Greg Choules wrote: Hi Danjel. To obtain a packet capture use tcpdump, which is probably installed already. If not, add it using your preferred package manager. You can dump to the screen, but I find it more useful to dump to a file, which can then be analysed offline in Wireshark. A typical capture command might be: sudo tcpdump -nvc 1000 -w host "( 192.168.20.10 or 192.168.20.11)" and port 53 OK, I tried that. I also studied the output in wireshark. But since this is my first try, I don't know what to look for, and cannot find out what's wrong. I get: root@mail:~# dig A mail.jungersen.dk @127.0.0.1 ; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> A mail.jungersen.dk @127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47697 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 41461c3ea02342e4010067dfdba11eea65ad9061831f (good) ;; QUESTION SECTION: ;mail.jungersen.dk. IN A ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Sun Mar 23 11:00:01 CET 2025 ;; MSG SIZE rcvd: 74 The mentioned tcpdump command gave the attached result. Just to sum it up: My setup: I have a mailserver (192.168.20.9), on the same box I have bind as resolver. I have 2 bind boxes running as "local authoritative" for the jungersen.dk zone (192.168.20.10 and 192.168.20.11) This was meant to give me the result of 192.168.20.9 when looking up my local mailserver on my local network, while giving the 212.27.12.12 result when asked from the public. The public DNS is hosted at one.com I tried setting up dnssec to satisfy the suggested solution: 1) create a working chain of trust that links to your private zone content But you may have guessed it, it does not work. Does the above give enough info to give me more guidance? TIA Danjel That will capture to disk all DNS traffic to and from your forwarders, up to a limit of 1000 packets, just as a safety net. Once that is running, make your tests to the local machine, stop the capture, upload it here if you wish or just open it in Wireshark and follow the conversations and their timeline. It is almost certainly a DNSSEC problem though, as Mark says. Hope that helps. Cheers, Greg On Wed, 19 Feb 2025 at 10:22, Danjel Jungersen via bind-users wrote: On 19-02-2025 11:11, Marco Moock wrote: > Am Wed, 19 Feb 2025 10:58:14 +0100 > schrieb Danjel Jungersen via bind-users : > >> But if I change /etc/resolv.conf to 127.0.0.1 something happens >> If I do a dig or ping from my postfixbox to something that the 2 main >> bind-boxes are authoratative for, it doesn't work. > Please sniff the DNS traffic between the 2 machines and check if the > request goes out to the authoritative server and check what it replied. > > You can trigger the request by > > dig A/ non-working domain @IP. > > Try +recurse/+norecurse to check if the issue is related to those flags. root@mail:~# dig A mail.jungersen.dk <http://mail.jungersen.dk> @127.0.0.1 <http://127.0.0.1> ; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> A mail.jungersen.dk <http://mail.jungersen.dk> @127.0.0.1 <http://127.0.0.1> ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9792 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: d55e55f5d6573eaf010067b5af13a2e4bdccbb3ce36b (good) ;; QUESTION SECTION: ;mail.jungersen.dk <http://mail.jungersen.dk>. IN A ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Wed Feb 19 11:14:43 CET 2025 ;; MSG SIZE rcvd: 74 dig +recurse A mail.jungersen.dk <http://mail.jungersen.dk> @127.0.0.1 <http://127.0.0.1> ; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> +recurse A mail.jungersen.dk <http://mail.jungersen.dk> @127.0.0.1 <http://127.0.0.1> ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 19526 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1
