Re: Bind and systemd-resolved
Good points, thanks. -Original Message- From: Reindl Harald To: bind-users@lists.isc.org Sent: Mon, Apr 18, 2022 12:41 am Subject: Re: Bind and systemd-resolved Am 18.04.22 um 07:26 schrieb Leroy Tennison via bind-users: > When I attempt “dig -t AXFR office.example.com -k > Kexample_dns.+157+18424.key” on the DNS server (Bind 9.11) sudoed to > root I get: > > ;; Couldn't verify signature: expected a TSIG or SIG(0) > ; Transfer failed. > > This is an Ubuntu 18.04 system and /etc/systemd/resolved.conf has > DNS=127.0.0.1 since the DNS server is running on it. Systemd-resolved > has been restarted afterward. I've tried using an actual interface > address but it doesn't help. It seems dig tries to use 127.0.0.53 due > to its being in /etc/resolv.conf and that fails even though dig for > forward/reverse lookups works. > > If I add @127.0.0.1 to the above it works. Is there a way to get this > to work without having to do that and not setting up the entire network > configuration using systemd. I realize it's not a big effort to add > @127.0.0.1 but the reason for the issue is obscure, the error message is > misleading and my distaste for systemd is sufficient enough that I would > prefer avoiding it as much as possible. Thanks for any input so why don't you just disable systemd-resolved? i run Fedora everywhere in production and on workstations, have masked it and after "chattr +i /etc/resolv.conf" nothing messes up resolv.conf (even without resolvd existing it would have the immutable flag to prevent the dhcp client fpr the WAN interface assign the broken ISP resolvers) [root@srv-rhsoft:~]$ systemctl status systemd-resolved.service ○ systemd-resolved.service Loaded: masked (Reason: Unit systemd-resolved.service is masked.) Active: inactive (dead) -- 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/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: Bind and systemd-resolved
Thanks, had looked at 'man dig' but had assumed (oops) that only the items
listed under the various OPTIONS headings were available in .digrc. Glad to
learn that @ can also be used (confirmed with testing).
-Original Message-
From: Ondřej Surý
To: Leroy Tennison
Cc: bind-users@lists.isc.org
Sent: Mon, Apr 18, 2022 1:14 am
Subject: Re: Bind and systemd-resolved
Leroy,
here `man dig` is your friend:
Unless it is told to query a specific name server, dig will try each of the
servers listed in /etc/resolv.conf.When no command line arguments or options
are given, dig will perform an NS query for "." (the root).It is possible to
set per-user defaults for dig via ${HOME}/.digrc. This file is read and any
options in it are applied before the command line arguments.Ondřej --Ondřej
Surý — ISC (He/Him)
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
On 18. 4. 2022, at 7:27, Leroy Tennison via bind-users
wrote:
When I attempt “dig -t AXFR office.example.com -k Kexample_dns.+157+18424.key”
on the DNS server (Bind 9.11) sudoed to root I get:
;; Couldn't verify signature: expected a TSIG or SIG(0); Transfer failed.
This is an Ubuntu 18.04 system and /etc/systemd/resolved.conf has DNS=127.0.0.1
since the DNS server is running on it. Systemd-resolved has been restarted
afterward. I've tried using an actual interface address but it doesn't help.
It seems dig tries to use 127.0.0.53 due to its being in /etc/resolv.conf and
that fails even though dig for forward/reverse lookups works.
If I add @127.0.0.1 to the above it works. Is there a way to get this to work
without having to do that and not setting up the entire network configuration
using systemd. I realize it's not a big effort to add @127.0.0.1 but the
reason for the issue is obscure, the error message is misleading and my
distaste for systemd is sufficient enough that I would prefer avoiding it as
much as possible. Thanks for any input.--
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/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: Why does DNSVIZ complain about the NS RRSET here?
Do you know what a windows DNS admin needs to do to fix that? On 04/18/2022 5:12 pm, Mark Andrews wrote: The parent servers are configured to allow recursion (ra) and rather than returning referrals that are returning answers provided it is cached. Also it is pointless to use NSEC3 in the reverse trees as they contain too much structure. To find 4.b.3.2.b.1.e.f.f.f.5.b.3.e.a.7.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN PTR thebighonker.lerctr.org you just need to query for [0-9a-f].ip6.arpa which will elicit a non NXDOMAIN for 2.ip6.arpa. Then you query for [0-9a-f].2.ip6.arpa, all the way down to [0-9a-f].b.3.2.b.1.e.f.f.f.5.b.3.e.a.7.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. which gives you a non NXDOMAIN response for 4.b.3.2.b.1.e.f.f.f.5.b.3.e.a.7.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. % dig @pdns05.thin-nology.com ns 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa +norec ; <<>> DiG 9.17.22 <<>> @pdns05.thin-nology.com ns 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa +norec ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13592 ;; flags: qr ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. IN NS ;; ANSWER SECTION: 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns1.dnsunlimited.com. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns2.dnsunlimited.com. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns-a.lerctr.org. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns4.dnsunlimited.com. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns3.dnsunlimited.com. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns5.dnsunlimited.com. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns-b.lerctr.org. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns-c.lerctr.org. ;; Query time: 225 msec ;; SERVER: 216.82.192.148#53(pdns05.thin-nology.com) (UDP) ;; WHEN: Tue Apr 19 07:53:04 AEST 2022 ;; MSG SIZE rcvd: 242 % % dig @pdns06.thin-nology.com type1000 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa +norec +dnssec ; <<>> DiG 9.17.22 <<>> @pdns06.thin-nology.com type1000 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa +norec +dnssec ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11871 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 10, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4000 ;; QUESTION SECTION: ;0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. IN TYPE1000 ;; AUTHORITY SECTION: 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns3.dnsunlimited.com. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns-c.lerctr.org. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns-b.lerctr.org. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns-a.lerctr.org. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns2.dnsunlimited.com. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns1.dnsunlimited.com. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns4.dnsunlimited.com. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns5.dnsunlimited.com. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN DS 63984 13 2 F9B8E3F0A1E15E38C32E71BA1D7150B7FB68CC8C06943B065C75C985 0732B48E 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN RRSIG DS 13 18 3600 20220423141314 20220416131314 1535 0.b.d.c.f.2.0.6.2.ip6.arpa. 2Bn8Qtoac1rIpL6IPvUP8EFewC0XLlxidGM6lIT8q12wmSUj3o3jxSxY xQMsK+j/b9nuMPlir+3m+mR7g5nvVQ== ;; Query time: 217 msec ;; SERVER: 216.82.192.149#53(pdns06.thin-nology.com) (UDP) ;; WHEN: Tue Apr 19 07:55:29 AEST 2022 ;; MSG SIZE rcvd: 452 % [snip] -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 -- 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: Why does DNSVIZ complain about the NS RRSET here?
The parent servers are configured to allow recursion (ra) and rather than returning referrals that are returning answers provided it is cached. Also it is pointless to use NSEC3 in the reverse trees as they contain too much structure. To find 4.b.3.2.b.1.e.f.f.f.5.b.3.e.a.7.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN PTR thebighonker.lerctr.org you just need to query for [0-9a-f].ip6.arpa which will elicit a non NXDOMAIN for 2.ip6.arpa. Then you query for [0-9a-f].2.ip6.arpa, all the way down to [0-9a-f].b.3.2.b.1.e.f.f.f.5.b.3.e.a.7.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. which gives you a non NXDOMAIN response for 4.b.3.2.b.1.e.f.f.f.5.b.3.e.a.7.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. % dig @pdns05.thin-nology.com ns 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa +norec ; <<>> DiG 9.17.22 <<>> @pdns05.thin-nology.com ns 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa +norec ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13592 ;; flags: qr ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. IN NS ;; ANSWER SECTION: 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns1.dnsunlimited.com. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns2.dnsunlimited.com. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns-a.lerctr.org. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns4.dnsunlimited.com. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns3.dnsunlimited.com. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns5.dnsunlimited.com. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns-b.lerctr.org. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns-c.lerctr.org. ;; Query time: 225 msec ;; SERVER: 216.82.192.148#53(pdns05.thin-nology.com) (UDP) ;; WHEN: Tue Apr 19 07:53:04 AEST 2022 ;; MSG SIZE rcvd: 242 % % dig @pdns06.thin-nology.com type1000 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa +norec +dnssec ; <<>> DiG 9.17.22 <<>> @pdns06.thin-nology.com type1000 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa +norec +dnssec ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11871 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 10, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4000 ;; QUESTION SECTION: ;0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. IN TYPE1000 ;; AUTHORITY SECTION: 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns3.dnsunlimited.com. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns-c.lerctr.org. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns-b.lerctr.org. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns-a.lerctr.org. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns2.dnsunlimited.com. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns1.dnsunlimited.com. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns4.dnsunlimited.com. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns5.dnsunlimited.com. 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN DS 63984 13 2 F9B8E3F0A1E15E38C32E71BA1D7150B7FB68CC8C06943B065C75C985 0732B48E 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN RRSIG DS 13 18 3600 20220423141314 20220416131314 1535 0.b.d.c.f.2.0.6.2.ip6.arpa. 2Bn8Qtoac1rIpL6IPvUP8EFewC0XLlxidGM6lIT8q12wmSUj3o3jxSxY xQMsK+j/b9nuMPlir+3m+mR7g5nvVQ== ;; Query time: 217 msec ;; SERVER: 216.82.192.149#53(pdns06.thin-nology.com) (UDP) ;; WHEN: Tue Apr 19 07:55:29 AEST 2022 ;; MSG SIZE rcvd: 452 % > On 17 Apr 2022, at 00:52, Larry Rosenman wrote: > > I have a IP6.arpa zone, 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa, that is > delegated from an Windows DNS server, which does NOT allow them to "sign" the > delegation. > > dnsviz.net complains: > 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa/NS: No RRSIG covering the RRset was > returned in the response. (216.82.192.148, 216.82.192.149, 2602:fcdb:0:8::5, > 2602:fcdb:0:8::21, UDP_-_EDNS0_4096_D_KN) > 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa/NS: The Authoritative Answer (AA) > flag was not set in the response. (216.82.192.148, 216.82.192.149, > 2602:fcdb:0:8::5, 2602:fcdb:0:8::21, UDP_-_EDNS0_4096_D_KN) > > Should windows be signing the NS RRSET? or is DNSVIZ being too strict? > > in my zone: > ❯ cat 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa > $ORIGIN . > $TTL 3600 ; 1 hour > 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa IN SOA ns-c.lerctr.org. > ler.lerctr.org. ( > 2022040704 ; serial > 3600 ; refresh (1 hour) > 900; retry (15 minutes) > 360; expire (5 weeks 6 days 16 hours) > 3600 ; minimum (1 hour) > ) > NS ns1.dnsunlimited.com. > NS ns2.dnsunlimited.com. >
Re: How to allow recursion on my own (cross) domains only after upgrade to 9.16.27 (lack of additional-from-auth option) ?
Mark Andrews wrote: > Unless you are pointing recursive clients directly at your > authoritative servers there is no need. The recursive servers will > lookup the CNAME target themselves. Additionally recursive servers just > process the CNAME and ignore the rest of the response to prevent cache > poisoning if there is more there. I think that implicit in Mark's answer is that the additional data that was being returned was just wasted bytes, since it could never be trusted by clients so why waste bytes. Thus the change? signature.asc Description: PGP signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind and systemd-resolved
There are a lot of extraneous details in here. This is not a BIND problem. On Mon, 18 Apr 2022, Leroy Tennison via bind-users wrote: When I attempt “dig -t AXFR office.example.com -k Kexample_dns.+157+18424.key” on the DNS server (Bind 9.11) sudoed to root I get: Why do you need to be root? ;; Couldn't verify signature: expected a TSIG or SIG(0); Transfer ;; failed. This is an Ubuntu 18.04 system and /etc/systemd/resolved.conf has DNS=127.0.0.1 since the DNS server is running on it. Systemd-resolved has been restarted afterward. I've tried using an actual interface address but it doesn't help. It seems dig tries to use 127.0.0.53 due to its being in /etc/resolv.conf and that fails even though dig for forward/reverse lookups works. I take it you believe you have things properly configured and are implying that you have 127.0.0.1 configured but that it isn't updating resolv.conf (which contains the entry 127.0.0.53). If I add @127.0.0.1 to the above it works. BIND is not broken. What happens when you try 127.0.0.53? Is there a way to get this to work without having to do that and not setting up the entire network configuration using systemd. I realize it's not a big effort to add @127.0.0.1 but the reason for the issue is obscure, the error message is misleading To be determined. and my distaste for systemd is sufficient enough that I would prefer avoiding it as much as possible. I hear you, but avoiding doesn't seem to be making it go away. systemd-resolved is a system service that provides network name resolution to local applications. It implements a caching and validating DNS/DNSSEC stub resolver, as well as an LLMNR and MulticastDNS resolver and responder. (And it listens on 127.0.0.53.) Maybe you should turn it off. -- Fred Morris, internet plumber-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How to allow recursion on my own (cross) domains only after upgrade to 9.16.27 (lack of additional-from-auth option) ?
Ok, thanks for the confirmation (no recursive clients are pointing to
this server, it's only used as an authoritative server).
Le lun. 18 avr. 2022 à 10:08, Mark Andrews a écrit :
>
> Unless you are pointing recursive clients directly at your authoritative
> servers there is no need. The recursive servers will lookup the CNAME target
> themselves. Additionally recursive servers just process the CNAME and ignore
> the rest of the response to prevent cache poisoning if there is more there.
>
> --
> Mark Andrews
>
> > On 18 Apr 2022, at 17:57, Thomas Martin wrote:
> >
> > Hello,
> >
> > I recently upgraded from Debian Buster to Debian Bullseye and I'm
> > having a hard time having the same behavior as before with the new
> > bind9 version.
> >
> > Here is my setup :
> > - I have two DNS domain (domain A.com and domain Z.com) for which my
> > server is authoritative (as a slave in this case),
> > - A few of my DNS records on domain Z are CNAME to domain A.
> >
> > My server configuration looks like this :
> > zone "A.com" {
> >type slave;
> >file "A";
> >masters { a.b.c.d; };
> > };
> > zone "Z.com" {
> >type slave;
> >file "Z";
> >masters { a.b.c.d; };
> > };
> >
> > I don't want my server to be recursive but I would like him to answer
> > the full CNAME and A like in 9.11.5 (thanks to additional-from-auth
> > AFAIK) :
> >> $ host www.Z.com 1.2.3.4
> >> www.Z.com is an alias for www.A.com.
> >> www.A.com has address 10.10.10.1
> >
> > Now, with 9.16.27 my answer is only returning the CNAME record, not
> > the A record despite being authoritative for both domains :
> >> $ host www.Z.com 1.2.3.4
> >> www.Z.com is an alias for www.A.com.
> >
> > Is there any chance I can have the same behavior as before ?
> > if I enable recursion it works of course, but I don't want my server
> > to be a public resolver.
> > I tried to play with the "minimal-responses" option with no luck.
> >
> >
> > Thanks.
> > --
> > 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/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: How to allow recursion on my own (cross) domains only after upgrade to 9.16.27 (lack of additional-from-auth option) ?
Unless you are pointing recursive clients directly at your authoritative
servers there is no need. The recursive servers will lookup the CNAME target
themselves. Additionally recursive servers just process the CNAME and ignore
the rest of the response to prevent cache poisoning if there is more there.
--
Mark Andrews
> On 18 Apr 2022, at 17:57, Thomas Martin wrote:
>
> Hello,
>
> I recently upgraded from Debian Buster to Debian Bullseye and I'm
> having a hard time having the same behavior as before with the new
> bind9 version.
>
> Here is my setup :
> - I have two DNS domain (domain A.com and domain Z.com) for which my
> server is authoritative (as a slave in this case),
> - A few of my DNS records on domain Z are CNAME to domain A.
>
> My server configuration looks like this :
> zone "A.com" {
>type slave;
>file "A";
>masters { a.b.c.d; };
> };
> zone "Z.com" {
>type slave;
>file "Z";
>masters { a.b.c.d; };
> };
>
> I don't want my server to be recursive but I would like him to answer
> the full CNAME and A like in 9.11.5 (thanks to additional-from-auth
> AFAIK) :
>> $ host www.Z.com 1.2.3.4
>> www.Z.com is an alias for www.A.com.
>> www.A.com has address 10.10.10.1
>
> Now, with 9.16.27 my answer is only returning the CNAME record, not
> the A record despite being authoritative for both domains :
>> $ host www.Z.com 1.2.3.4
>> www.Z.com is an alias for www.A.com.
>
> Is there any chance I can have the same behavior as before ?
> if I enable recursion it works of course, but I don't want my server
> to be a public resolver.
> I tried to play with the "minimal-responses" option with no luck.
>
>
> Thanks.
> --
> 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/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
How to allow recursion on my own (cross) domains only after upgrade to 9.16.27 (lack of additional-from-auth option) ?
Hello,
I recently upgraded from Debian Buster to Debian Bullseye and I'm
having a hard time having the same behavior as before with the new
bind9 version.
Here is my setup :
- I have two DNS domain (domain A.com and domain Z.com) for which my
server is authoritative (as a slave in this case),
- A few of my DNS records on domain Z are CNAME to domain A.
My server configuration looks like this :
zone "A.com" {
type slave;
file "A";
masters { a.b.c.d; };
};
zone "Z.com" {
type slave;
file "Z";
masters { a.b.c.d; };
};
I don't want my server to be recursive but I would like him to answer
the full CNAME and A like in 9.11.5 (thanks to additional-from-auth
AFAIK) :
> $ host www.Z.com 1.2.3.4
> www.Z.com is an alias for www.A.com.
> www.A.com has address 10.10.10.1
Now, with 9.16.27 my answer is only returning the CNAME record, not
the A record despite being authoritative for both domains :
> $ host www.Z.com 1.2.3.4
> www.Z.com is an alias for www.A.com.
Is there any chance I can have the same behavior as before ?
if I enable recursion it works of course, but I don't want my server
to be a public resolver.
I tried to play with the "minimal-responses" option with no luck.
Thanks.
--
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: Bind and systemd-resolved
Leroy,
here `man dig` is your friend:
Unless it is told to query a specific name server, dig will try each of the
servers listed in /etc/resolv.conf.
When no command line arguments or options are given, dig will perform an NS
query for "." (the root).
It is possible to set per-user defaults for dig via ${HOME}/.digrc. This file
is read and any options in it are applied before the command line arguments.
Ondřej
--
Ondřej Surý — ISC (He/Him)
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
> On 18. 4. 2022, at 7:27, Leroy Tennison via bind-users
> wrote:
>
>
> When I attempt “dig -t AXFR office.example.com -k
> Kexample_dns.+157+18424.key” on the DNS server (Bind 9.11) sudoed to root I
> get:
>
> ;; Couldn't verify signature: expected a TSIG or SIG(0)
> ; Transfer failed.
>
> This is an Ubuntu 18.04 system and /etc/systemd/resolved.conf has
> DNS=127.0.0.1 since the DNS server is running on it. Systemd-resolved has
> been restarted afterward. I've tried using an actual interface address but
> it doesn't help. It seems dig tries to use 127.0.0.53 due to its being in
> /etc/resolv.conf and that fails even though dig for forward/reverse lookups
> works.
>
> If I add @127.0.0.1 to the above it works. Is there a way to get this to
> work without having to do that and not setting up the entire network
> configuration using systemd. I realize it's not a big effort to add
> @127.0.0.1 but the reason for the issue is obscure, the error message is
> misleading and my distaste for systemd is sufficient enough that I would
> prefer avoiding it as much as possible. Thanks for any input.
> --
> 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/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
