Re: Is this KB example backwards? Re: Multiple master servers for the same zones
Just to clarify, the configuration I was referring to was supposed to have a master and slave DNS server for private zones (only two DNS servers) but something happened during/after upgrade and they both showed master (actually rndc -s 127.0.0.1 -r zonestatus ) reported master and the other primary. On Thursday, September 7, 2023 at 04:09:04 PM CDT, Fred Morris wrote: Hi Greg. So somebody referenced this KB article because presumably it was tangentially relevant, but I don't know that the OP is working with standby infrastructure (good question!). All they say is that after an upgrade all servers were masters. The amount of direct relevance of the article is questionable. Nonetheless, paragraph two seems factually incorrect on its face: changing type master; to type slave; does not swich a server from secondary to master, last I checked it did the opposite. On Thu, 7 Sep 2023, Greg Choules wrote: > > Hi Fred. > No, the sense is correct. > Imagine you have a server with a secondary zone of (say) "example.com", > which transfers data for that zone from a primary somewhere. The KB article talks about multiple masters. At the outset there is no secondary. > The secondary > loads data received during a zone transfer straight into memory and uses it. > It is optional for the secondary to also write that data to a file on its > local storage, if you specify a "file" statement in the zone declaration. All examples (barring questions of relevance) of configuration syntax in the article specify a file statement. In one case it's implicit as in masterfile-format raw; and in the other it's quite explicit (but both of the examples are talking about standby primaries, which are not an explicit thing in the software although they are conceptually understood). Please re-read the second paragraph and try again. > If the server currently being secondary for "example.com" does write that > zone to disc then it is easy to switch it to become primary because it > already has the zone file stored locally. Just change the "type", leave the > "file" statement alone and delete (or comment) the "primaries". Agreed. > Does that help? No. I have personally set up and administered a corosync / pacemaker cluster to do a standby to master promotion (for publishing RPZs with BIND) in a past life. Respectfully... -- Fred -- 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: Is this KB example backwards? Re: Multiple master servers for the same zones
Hi Greg. So somebody referenced this KB article because presumably it was tangentially relevant, but I don't know that the OP is working with standby infrastructure (good question!). All they say is that after an upgrade all servers were masters. The amount of direct relevance of the article is questionable. Nonetheless, paragraph two seems factually incorrect on its face: changing type master; to type slave; does not swich a server from secondary to master, last I checked it did the opposite. On Thu, 7 Sep 2023, Greg Choules wrote: Hi Fred. No, the sense is correct. Imagine you have a server with a secondary zone of (say) "example.com", which transfers data for that zone from a primary somewhere. The KB article talks about multiple masters. At the outset there is no secondary. The secondary loads data received during a zone transfer straight into memory and uses it. It is optional for the secondary to also write that data to a file on its local storage, if you specify a "file" statement in the zone declaration. All examples (barring questions of relevance) of configuration syntax in the article specify a file statement. In one case it's implicit as in masterfile-format raw; and in the other it's quite explicit (but both of the examples are talking about standby primaries, which are not an explicit thing in the software although they are conceptually understood). Please re-read the second paragraph and try again. If the server currently being secondary for "example.com" does write that zone to disc then it is easy to switch it to become primary because it already has the zone file stored locally. Just change the "type", leave the "file" statement alone and delete (or comment) the "primaries". Agreed. Does that help? No. I have personally set up and administered a corosync / pacemaker cluster to do a standby to master promotion (for publishing RPZs with BIND) in a past life. Respectfully... -- Fred -- 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: Is this KB example backwards? Re: Multiple master servers for the same zones
Hi Fred. No, the sense is correct. Imagine you have a server with a secondary zone of (say) "example.com", which transfers data for that zone from a primary somewhere. The secondary loads data received during a zone transfer straight into memory and uses it. It is optional for the secondary to also write that data to a file on its local storage, if you specify a "file" statement in the zone declaration. Optional, but sometimes handy. If the server currently being secondary for "example.com" does write that zone to disc then it is easy to switch it to become primary because it already has the zone file stored locally. Just change the "type", leave the "file" statement alone and delete (or comment) the "primaries". Does that help? Greg On Thu, 7 Sept 2023 at 19:31, Fred Morris wrote: > Re-reading the KB article referenced below... > > On Tue, 5 Sep 2023, Leroy Tennison via bind-users wrote: > > > > [...] I'm assuming i can use > > https://kb.isc.org/docs/managing-manual-multi-master to "demote" one of > > them but is there anything to look for concerning possible > > inconsistencies and how do I check for those issues? > > Second paragraph: > >In BIND 9, it is relatively simple to switch a server from secondary to >primary in real time: if you store the data in a file, simply redefine >the zone type and change type master; to type slave;. > > That seems to me to be saying secondary == master and primary == slave. > > There seems to be a mixing of metaphors here. I don't think combining the > traditional and newspeak terminology contributes to clarity. In any case > I'd rewrite this as: > >In BIND 9, it is relatively simple to switch a server from primary to >secondary in real time: if you store the data in a file, simply redefine >the zone type and change type primary; to type secondary;. > > -- > > Fred Morris > -- > 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: resolver: DNS format errors
Spamhaus’s servers are sending back responses that do not answer the question.
Named is doing QNAME minimisation using NS queries and rather than the servers
sending back a NODATA response for the empty non-terminal names they are
sending back the NS records for the top of the zone.
I suggest that you ask them to fix their DNS servers to correctly answer NS
queries. They appear to need to look at the query name as well as the query
type.
This is what often happens when you write custom DNS servers. You fail to
handle some query you weren’t planning for.
Mark
--
Mark Andrews
> On 8 Sep 2023, at 04:41, Alex wrote:
>
>
> Hi,
>
> I have a fedora38 server with bind-9.18.17 and receiving the following log
> entries for virtually every query (where "mykey" is my registered spamhaus
> DQS key):
> 07-Sep-2023 14:30:13.608 lame-servers: FORMERR resolving
> 'mykey.hbl.dq.spamhaus.net/NS/IN': 66.42.94.100#53
> 07-Sep-2023 14:30:13.625 resolver: DNS format error from 143.215.143.8#53
> resolving mykey.hbl.dq.spamhaus.net/NS for : reply has no answer
> 07-Sep-2023 14:30:13.625 lame-servers: FORMERR resolving
> 'mykey.hbl.dq.spamhaus.net/NS/IN': 143.215.143.8#53
> 07-Sep-2023 14:30:13.628 lame-servers: success resolving
> 'psnobcays3v2r52vapfv5fgvr6pgd6znvuzyhe5ktid3ty3oai4q._file.mykey.hbl.dq.spamhaus.net/A'
> after disabling qname minimization due to 'failure'
>
> 07-Sep-2023 14:39:30.214 lame-servers: success resolving
> '22.10.223.192.bl.spamcop.net/A' after disabling qname minimization due to
> 'ncache nxdomain'
>
> For some reason my config isn't ignoring lame-servers, but it does look
> relevant and related to the resolver errors.
>
> I've tried to experiment with including "minimal responses yes;" in my
> config, based on some reading about a similar issue years ago, but it doesn't
> change anything. This nameserver provides DNS across a VPN link to a remote
> system on a cable modem because having the server (also fedora38) query DNS
> directly on a cable modem was resulting in some other weird errors.
>
> Any ideas greatly appreciated.
>
> acl "trusted" {
> { 127/8; };
> { 68.195.44.40/29; };
> { 147.135.111.126; };
> };
> options {
> listen-on port 53 { 127.0.0.1; 147.135.111.126; };
> listen-on-v6 port 53 { none; };
> directory "/var/named";
> dump-file "/var/named/data/cache_dump.db";
> statistics-file "/var/named/data/named_stats.txt";
> memstatistics-file "/var/named/data/named_mem_stats.txt";
> secroots-file "/var/named/data/named.secroots";
> recursing-file "/var/named/data/named.recursing";
> allow-query { trusted; };
> allow-query-cache { trusted; };
> minimal-responses yes;
> recursion yes;
> managed-keys-directory "/var/named/dynamic";
> geoip-directory "/usr/share/GeoIP";
> pid-file "/run/named/named.pid";
> session-keyfile "/run/named/session.key";
> include "/etc/crypto-policies/back-ends/bind.config";
> };
> logging {
> channel default_debug {
> file "data/named.run";
> severity dynamic;
> };
> channel named_debug {
> severity dynamic;
> file "/var/log/named.debug.log" versions 2 size 100m;
> print-time yes;
> print-category yes;
> };
> category default { named_debug; };
> channel query_info {
>severity info;
>file "/var/log/named.query.log" versions 3 size 5m;
>print-time yes;
>print-category yes;
> };
> category queries { query_info; };
> };
> zone "." IN {
> type hint;
> file "named.ca";
> };
> include "/etc/named.rfc1912.zones";
> include "/etc/named.root.key";
>
> --
> 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
resolver: DNS format errors
Hi,
I have a fedora38 server with bind-9.18.17 and receiving the following log
entries for virtually every query (where "mykey" is my registered spamhaus
DQS key):
07-Sep-2023 14:30:13.608 lame-servers: FORMERR resolving '
mykey.hbl.dq.spamhaus.net/NS/IN': 66.42.94.100#53
07-Sep-2023 14:30:13.625 resolver: DNS format error from 143.215.143.8#53
resolving mykey.hbl.dq.spamhaus.net/NS for : reply has no answer
07-Sep-2023 14:30:13.625 lame-servers: FORMERR resolving '
mykey.hbl.dq.spamhaus.net/NS/IN': 143.215.143.8#53
07-Sep-2023 14:30:13.628 lame-servers: success resolving
'psnobcays3v2r52vapfv5fgvr6pgd6znvuzyhe5ktid3ty3oai4q._
file.mykey.hbl.dq.spamhaus.net/A' after disabling qname minimization due to
'failure'
07-Sep-2023 14:39:30.214 lame-servers: success resolving '
22.10.223.192.bl.spamcop.net/A' after disabling qname minimization due to
'ncache nxdomain'
For some reason my config isn't ignoring lame-servers, but it does look
relevant and related to the resolver errors.
I've tried to experiment with including "minimal responses yes;" in my
config, based on some reading about a similar issue years ago, but it
doesn't change anything. This nameserver provides DNS across a VPN link to
a remote system on a cable modem because having the server (also fedora38)
query DNS directly on a cable modem was resulting in some other weird
errors.
Any ideas greatly appreciated.
acl "trusted" {
{ 127/8; };
{ 68.195.44.40/29; };
{ 147.135.111.126; };
};
options {
listen-on port 53 { 127.0.0.1; 147.135.111.126; };
listen-on-v6 port 53 { none; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
secroots-file "/var/named/data/named.secroots";
recursing-file "/var/named/data/named.recursing";
allow-query { trusted; };
allow-query-cache { trusted; };
minimal-responses yes;
recursion yes;
managed-keys-directory "/var/named/dynamic";
geoip-directory "/usr/share/GeoIP";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
include "/etc/crypto-policies/back-ends/bind.config";
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
channel named_debug {
severity dynamic;
file "/var/log/named.debug.log" versions 2 size 100m;
print-time yes;
print-category yes;
};
category default { named_debug; };
channel query_info {
severity info;
file "/var/log/named.query.log" versions 3 size 5m;
print-time yes;
print-category yes;
};
category queries { query_info; };
};
zone "." IN {
type hint;
file "named.ca";
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
--
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
Is this KB example backwards? Re: Multiple master servers for the same zones
Re-reading the KB article referenced below... On Tue, 5 Sep 2023, Leroy Tennison via bind-users wrote: [...] I'm assuming i can use https://kb.isc.org/docs/managing-manual-multi-master to "demote" one of them but is there anything to look for concerning possible inconsistencies and how do I check for those issues? Second paragraph: In BIND 9, it is relatively simple to switch a server from secondary to primary in real time: if you store the data in a file, simply redefine the zone type and change type master; to type slave;. That seems to me to be saying secondary == master and primary == slave. There seems to be a mixing of metaphors here. I don't think combining the traditional and newspeak terminology contributes to clarity. In any case I'd rewrite this as: In BIND 9, it is relatively simple to switch a server from primary to secondary in real time: if you store the data in a file, simply redefine the zone type and change type primary; to type secondary;. -- Fred Morris -- 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
