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
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. -- 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
The posix boxes are validating the responses and your zone is not properly delegated/signed so DNSSEC validation fails. What does the following return? dig +cd +dnssec mail.jungersen.dk The answer on the internet is signed. -- Mark Andrews > On 19 Feb 2025, at 21:21, 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 @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.3600IN 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 -- Visit https://lists.isc.org/mailman/list
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
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 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 < bind-users@lists.isc.org> 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 @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.3600IN A 65.108.3.114 > > ;; Query time: 852 ms
Re: Authoritative and caching
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. -- Mark Andrews > On 19 Feb 2025, at 21:54, Danjel Jungersen wrote: > > 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: IPv6 Geolocation per /64
On Tue, Feb 18, 2025 at 07:20:26PM -0500, Michael Richardson wrote: ! There is also https://www.rfc-editor.org/info/rfc9632. ! ! This document specifies how to augment the Routing Policy Specification ! Language (RPSL) inetnum: class to refer specifically to geofeed ! comma-separated values (CSV) data files and describes an optional scheme that ! uses the Resource Public Key Infrastructure (RPKI) to authenticate the ! geofeed data files. This document obsoletes RFC 9092. ! Wow, that one is interesting! Needed me a while to understand what this is about, and also I found this: https://www.arin.net/participate/community/acsp/suggestions/2024/2024-10/ In any case, the database I was asking for does apparently exist, and You pointed me to it. Thank You very much! Nevertheless, in my case, a different path is taken. As I finally figured out, there is an agreement between my respective provider and Google, which basically is a geofeed file and contains the data in question, but is apparently not visible in the WHOIS/RPSL. Again, thanks a lot, folks! cheerio,PMc -- 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: Access Control Lists error
> From: bind-users on behalf of Duan Duan
> via bind-users
>
> Hey Guys,
>
> I am upgrading my bind version from 9.11.0 to 9.18.31.
>
> But I have some questions about Access Control Lists(acls).
>
> I am in version 9.11.0 acl file is like this
>
> root@hz#cat tsg_acl
> acl "tsg_acl" {
> ecs 10.56.21.236/30;
> };
>
> But when I upgraded to version 9.18.31, it reported an error.
>
> error : /home/named/acl/tsg_acl:2: missing ';' before '10.56.21.236'
Hi Duan,
It appears that the "ecs" functionality in an ACL was removed in 9.13.1
(according to the release notes):
4952. [func] Authoritative server support in named for the
EDNS CLIENT-SUBNET option (which was experimental
and not practical to deploy) has been removed.
The ECS option is still supported in dig and mdig
via the +subnet option, and can be parsed and logged
when received by named, but it is no longer used
for ACL processing. The "geoip-use-ecs" option
is now obsolete; a warning will be logged if it is
used in named.conf. "ecs" tags in an ACL definition
are also obsolete and will cause the configuration
to fail to load. [GL #32]
Stuart
--
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
Access Control Lists error
Hey Guys,
I am upgrading my bind version from 9.11.0 to 9.18.31.
But I have some questions about Access Control Lists(acls).
I am in version 9.11.0 acl file is like this
root@hz#cat tsg_acl
acl "tsg_acl" {
ecs 10.56.21.236/30;
};
But when I upgraded to version 9.18.31, it reported an error.
error : /home/named/acl/tsg_acl:2: missing ';' before '10.56.21.236'
Why is this? Is there any inconsistency between version 9.11.0 and version
9.18.31 about access control lists?
Thanks,
Kind regards
Duan--
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
?????? Access Control Lists error
1422807...@qq.com -- -- ??: "stuart@registry.godaddy" -- 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 Feb 2025, at 17:35, Danjel Jungersen wrote:
>
>
>
> 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.
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
or
2) configure a negative trust anchor for your namespace on every validating
device
or
3) configure a positive trust anchor for your namespace on every validating
device
or
4) have the names that are being overridden be in unsigned zones
1 and 4 work for every validating device including BYOD
2 and 3 only work for those validating devices that get configured
1 and 3 require you to sign your internal zone
Long 1 is the best long term solution. 2 and 3 are stop gaps with 3 being more
secure than 2. 4 you are going backward security wise.
3 can be converted to 1 by adding a DS record(s) for your internal DNSKEY(s) to
the dk zone in addition to those you have there for the public zone. You will
need to use the same DNSSEC algorithms for the internal and external zones if
you do this.
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.
> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
