Re: Simplistic serial number roll back
Agreed. I'm not considering rolling back to old zone data, but considering changing the algorithm used to generate the serial number for new zone data. The new algorithm would result in the new data being published with serial numbers which would be ignored as being "older" if they were generated with the old algorithm. But I feel like we've wandered off the path. My question is seeking clarification of the behavior of "rndc retransfer" - does this command perform the transfer, regardless of what serial number it has or finds? -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska On 2/17/2023 10:46 AM, Ondřej Surý wrote: Well, the serial number arithmetics is there for a reason - you usually don’t want to rollback to previous version of the zone - you can have multiple primaries with different serial numbers.-- 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: Simplistic serial number roll back
Well, the serial number arithmetics is there for a reason - you usually don’t want to rollback to previous version of the zone - you can have multiple primaries with different serial numbers.I don’t really consider the two step rollover of the serial number that complicated, so something extra needs to be put in place. And it’s something you don’t really do on a daily basis.Ondrej--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 17. 2. 2023, at 20:34, John Thurston wrote: That was my first thought, but stopping the secondary would affect all of the published zones. If retransfer ignores serial number, then using "rndc retransfer" would affect only the specifically-named zone in the specifically-named view. Resolution of the other zones, in all of the other views, would be uninterrupted. -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska On 2/17/2023 10:23 AM, Ondřej Surý wrote: CAUTION: This email originated from outside the State of Alaska mail system. Do not click links or open attachments unless you recognize the sender and know the content is safe. Why so complicated? Stop the secondary, purge the zone files and journal, and start the secondary. The zones will get retransfered as there’s no state now. -- 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 17. 2. 2023, at 20:18, John Thurston wrote: Assumptions: A primary and several secondaries, with the secondaries using XFR to stay up to date. Scenario: Make a change in the serial number algorithm which will result in newer zone-data being published on an "earlier" serial number. The 'correct' method is to increase the serial number (by steps not exceeding 0x7FFF) until it rolls back around to the desired number. These increments are to happen no more frequently than the refresh interval specified in the SOA record. This 'correct' method relies on nothing more than the communication standards defined in RFC. But if we add the assumption: All authorities are running ISC BIND software, and all are under central management. can the whole process be reduced to publishing the new serial number on the primary, and using an "rndc retransfer" on each secondary? The man-file says "retransfer . . . This command retransfers the given secondary zone from the primary server." It doesn't say serial number is considered, nor does it does it say that it is ignored. I'm thinking it makes sense that it ignores the serial number, but I can't think of a good way to test this. -- -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska -- 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 listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://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
Re: Simplistic serial number roll back
That was my first thought, but stopping the secondary would affect all of the published zones. If retransfer ignores serial number, then using "rndc retransfer" would affect only the specifically-named zone in the specifically-named view. Resolution of the other zones, in all of the other views, would be uninterrupted. -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska On 2/17/2023 10:23 AM, Ondřej Surý wrote: *CAUTION:* This email originated from outside the State of Alaska mail system. Do not click links or open attachments unless you recognize the sender and know the content is safe. Why so complicated? Stop the secondary, purge the zone files and journal, and start the secondary. The zones will get retransfered as there’s no state now. -- 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 17. 2. 2023, at 20:18, John Thurston wrote: Assumptions: A primary and several secondaries, with the secondaries using XFR to stay up to date. Scenario: Make a change in the serial number algorithm which will result in newer zone-data being published on an "earlier" serial number. The 'correct' method is to increase the serial number (by steps not exceeding 0x7FFF) until it rolls back around to the desired number. These increments are to happen no more frequently than the refresh interval specified in the SOA record. This 'correct' method relies on nothing more than the communication standards defined in RFC. But if we add the assumption: All authorities are running ISC BIND software, and all are under central management. can the whole process be reduced to publishing the new serial number on the primary, and using an "rndc retransfer" on each secondary? The man-file says "retransfer . . . This command retransfers the given secondary zone from the primary server." It doesn't say serial number is considered, nor does it does it say that it is ignored. I'm thinking it makes sense that it ignores the serial number, but I can't think of a good way to test this. -- -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska -- 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: Simplistic serial number roll back
Why so complicated? Stop the secondary, purge the zone files and journal, and start the secondary. The zones will get retransfered as there’s no state now.--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 17. 2. 2023, at 20:18, John Thurston wrote: Assumptions: A primary and several secondaries, with the secondaries using XFR to stay up to date. Scenario: Make a change in the serial number algorithm which will result in newer zone-data being published on an "earlier" serial number. The 'correct' method is to increase the serial number (by steps not exceeding 0x7FFF) until it rolls back around to the desired number. These increments are to happen no more frequently than the refresh interval specified in the SOA record. This 'correct' method relies on nothing more than the communication standards defined in RFC. But if we add the assumption: All authorities are running ISC BIND software, and all are under central management. can the whole process be reduced to publishing the new serial number on the primary, and using an "rndc retransfer" on each secondary? The man-file says "retransfer . . . This command retransfers the given secondary zone from the primary server." It doesn't say serial number is considered, nor does it does it say that it is ignored. I'm thinking it makes sense that it ignores the serial number, but I can't think of a good way to test this. -- -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://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
Simplistic serial number roll back
Assumptions: A primary and several secondaries, with the secondaries using XFR to stay up to date. Scenario: Make a change in the serial number algorithm which will result in newer zone-data being published on an "earlier" serial number. The 'correct' method is to increase the serial number (by steps not exceeding 0x7FFF) until it rolls back around to the desired number. These increments are to happen no more frequently than the refresh interval specified in the SOA record. This 'correct' method relies on nothing more than the communication standards defined in RFC. But if we add the assumption: All authorities are running ISC BIND software, and all are under central management. can the whole process be reduced to publishing the new serial number on the primary, and using an "rndc retransfer" on each secondary? The man-file says "retransfer . . . This command retransfers the given secondary zone from the primary server." It doesn't say serial number is considered, nor does it does it say that it is ignored. I'm thinking it makes sense that it ignores the serial number, but I can't think of a good way to test this. -- -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska -- 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: Sanity Check
On 17/02/2023 16:06, Bob McDonald wrote:
I'm implementing a caching resolver under FreeBSD 13.1 running on a
RaspberryPI. Bind 9.18.11
My named.conf is below. My question is do these look like workable
options? I include logging and a statistics channel in my preliminary
implementations for more detail on what's going on. That will go away
eventually. Any comments are welcome.
Thanks,
Bob
named.conf:
acl rfc1918-nets {
10.0.0.0/8 ;
172.16.0.0/12 ;
192.168.0.0/16 ;
};
include "/usr/local/etc/namedb/rndc.key";
controls {
inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { rndc-key; };
inet ::1 port 953 allow { ::1; } keys { rndc-key; };
};
options {
directory "/usr/local/etc/namedb/working";
pid-file "/var/run/named/pid";
dump-file "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";
secroots-file "/var/cache/bind/secroots.txt";
memstatistics-file "/var/stats/named_mem_stats.txt";
managed-keys-directory "/var/cache/bind";
session-keyfile "/var/cache/bind/session.key";
recursion yes;
masterfile-format text;
minimal-responses no;
empty-zones-enable yes;
empty-server "raspberrypi-00.ddisupport.tech";
empty-contact "robert\.mcdonald.ddiarchitect.tech";
querylog yes;
query-source address 172.27.255.99;
transfer-source 172.27.255.99;
notify-source 172.27.255.99;
request-nsid yes;
server-id hostname;
zone-statistics full;
dnssec-validation auto;
dnssec-accept-expired no;
listen-on { 127.0.0.1; };
listen-on { 172.27.255.99; };
listen-on-v6 { ::1; };
allow-query { ::1; 127.0.0.1; rfc1918-nets; };
allow-query-cache { ::1; 127.0.0.1; rfc1918-nets; };
allow-recursion { ::1; 127.0.0.1; rfc1918-nets; };
};
zone "localhost" { type master; file
"/usr/local/etc/namedb/primary/localhost-forward.db"; };
zone "127.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/primary/localhost-reverse.db";};
statistics-channels {
inet 172.27.255.99 port 28079 allow { rfc1918-nets; };
};
logging {
channel default_log {
file "/var/log/named/default" versions 3 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel auth_servers_log {
file "/var/log/named/auth_servers" versions 3 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel dnssec_log {
file "/var/log/named/dnssec" versions 3 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel zone_transfers_log {
file "/var/log/named/zone_transfers" versions 3 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel ddns_log {
file "/var/log/named/ddns" versions 3 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel client_security_log {
file "/var/log/named/client_security" versions 3 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel rate_limiting_log {
file "/var/log/named/rate_limiting" versions 3 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel rpz_log {
file "/var/log/named/rpz" versions 3 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel dnstap_log {
file "/var/log/named/dnstap" versions 3 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel queries_log {
file "/var/log/named/queries" versions 600 size 20m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel query-errors_log {
file "/var/log/named/query-errors" versions 5 size 20m;
print-time
Sanity Check
I'm implementing a caching resolver under FreeBSD 13.1 running on a
RaspberryPI. Bind 9.18.11
My named.conf is below. My question is do these look like workable options?
I include logging and a statistics channel in my preliminary
implementations for more detail on what's going on. That will go away
eventually. Any comments are welcome.
Thanks,
Bob
named.conf:
acl rfc1918-nets {
10.0.0.0/8;
172.16.0.0/12;
192.168.0.0/16;
};
include "/usr/local/etc/namedb/rndc.key";
controls {
inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { rndc-key; };
inet ::1 port 953 allow { ::1; } keys { rndc-key; };
};
options {
directory "/usr/local/etc/namedb/working";
pid-file"/var/run/named/pid";
dump-file "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";
secroots-file "/var/cache/bind/secroots.txt";
memstatistics-file "/var/stats/named_mem_stats.txt";
managed-keys-directory "/var/cache/bind";
session-keyfile "/var/cache/bind/session.key";
recursion yes;
masterfile-format text;
minimal-responses no;
empty-zones-enable yes;
empty-server "raspberrypi-00.ddisupport.tech";
empty-contact "robert\.mcdonald.ddiarchitect.tech";
querylog yes;
query-source address 172.27.255.99;
transfer-source 172.27.255.99;
notify-source 172.27.255.99;
request-nsid yes;
server-id hostname;
zone-statistics full;
dnssec-validation auto;
dnssec-accept-expired no;
listen-on { 127.0.0.1; };
listen-on { 172.27.255.99; };
listen-on-v6{ ::1; };
allow-query { ::1; 127.0.0.1; rfc1918-nets; };
allow-query-cache { ::1; 127.0.0.1; rfc1918-nets; };
allow-recursion { ::1; 127.0.0.1; rfc1918-nets; };
};
zone "localhost"{ type master; file
"/usr/local/etc/namedb/primary/localhost-forward.db"; };
zone "127.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/primary/localhost-reverse.db";};
statistics-channels {
inet 172.27.255.99 port 28079 allow { rfc1918-nets; };
};
logging {
channel default_log {
file "/var/log/named/default" versions 3 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel auth_servers_log {
file "/var/log/named/auth_servers" versions 3 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel dnssec_log {
file "/var/log/named/dnssec" versions 3 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel zone_transfers_log {
file "/var/log/named/zone_transfers" versions 3 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel ddns_log {
file "/var/log/named/ddns" versions 3 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel client_security_log {
file "/var/log/named/client_security" versions 3 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel rate_limiting_log {
file "/var/log/named/rate_limiting" versions 3 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel rpz_log {
file "/var/log/named/rpz" versions 3 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel dnstap_log {
file "/var/log/named/dnstap" versions 3 size 1m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel queries_log {
file "/var/log/named/queries" versions 600 size 20m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel query-errors_log {
file "/var/log/named/query-errors" versions 5 size 20m;
print-time yes;
print-category yes;
print-severity yes;
severity dynamic;
};
channel default_syslog {
print-time yes;
