Re: Debugging TSIG signed nsupdate problems
It doesn't answer your original question, but I suggest looking at the 'algorithm' of that key. Might it be a hmac-md5 ? If you 'named-conf -px' does it appear in the list of keys? -- 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 5/24/2024 8:17 AM, Erik Edwards via bind-users 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. How can I set debug level log for update events? I've tried "rndc trace 99" which gives *lots* of information expect for UPDATE REFUSED issues even thought the channel is set to dynamic severity. Is there a different way to get named to generate debug level logs for UPDATE events? I'm running BIND 9.18.26 (Extended Support Version) from Fedora 40. The updates and keys had been working correctly until the update to Fedora 40/BIND 9.18.26 The issues I'm experiencing are only applying to a single key & update-policy line, other TSIG's are working correctly. -Erik -- 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: named fails to start with bind-9.18.0
Assurance you are actually trying to compile current code. A statement of what your operating system is. Actual output of your compile steps. Actual logged output of your attempt to launch. -- 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 5/20/2024 8:10 PM, avijeet gupta wrote: Please let me know if more information is needed.-- 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
Special-use names and RPZ
There are several 'special-use' domain names I'm pondering * invalid. * test. * onion. My read of the RFCs indicate they should result in NXDOMAIN, and not be passed for resolution. RFC 6761 (test. Section 6.2.4 / invalid. Section 6.4.4) caching DNS servers SHOULD, by default, generate immediate negative responses for all such queries. RFC 7686 (onion. Section 2.4) where not explicitly adapted to interoperate with Tor, SHOULD NOT attempt to look up records for .onion names. They MUST generate NXDOMAIN for all such queries. Is there some reason these should not just be hammered into our RPZ ? -- -- 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: Switching from rhel base 9.16 to 9.18 copr
This doesn't answer the question you have asked, so feel free to hit 'delete'. I suggest that what you are trying to do has the potential to cause you suffering later. If you are switching to the COPR distribution, don't fight it. Turn off and disable the base service/daemon. Copy your .conf files over to the new location for the COPR distribution. Move on with your life. When you are satisfied that the COPR distribution is meeting your needs (and you aren't going back to the base), replace that .conf in /etc with something defining only localhost. Your installation will look like every one else who is using the COPR distribution, and package updates to the base can happen without affecting the installation you care about. If some update to base does re-enable it, it will behave substantially differently from your real installation, and you will notice it. -- 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 5/5/2024 8:15 AM, Luca vom Bruch via bind-users wrote: Hello, I use bind (stock from alma 9.3) as a nameserver for a webhosting server with webmin/virtualmin. If I install BIND via copr (RHEL9 and derivatives only offer 9.16 instead of 9.18 – I want to experiment with DoT for opportunistic TLS between nameservers, upcoming standard RFC 9539 - Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS (ietf.org) <https://datatracker.ietf.org/doc/rfc9539/> ) what are the necessary steps to make isc-bind read the existing config files? named.conf in /etc and zones in /var/named? will the daemon only listen to /etc/opt/isc/scls/isc-bind/named.conf? should I edit the systemctl .service file to adjust the config path? Thanks, Luca -- 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: Broken DNS QNAME Recovery
On 4/21/2024 10:05 PM, Mark Andrews wrote:
On 19 Apr 2024, at 16:12, Crist Clark wrote:
First, yes, I know. Their DNS is broken. They should fix their DNS. We
shouldn't need to make QNAME-minimization work around broken DNS.
Name and shame a domain name in question,
e1083.d.akamaiedge.akamai.csd.disa.mil
The problem I see: akamai.csd.disa.mil is a delegated zone. All four name
servers for the zone are in the zone. All four of the addresses in the parent's
glue are unresponsive. It's actually the same for
d.akamaiedge.akamai.csd.disa.mil too.
That is breaking resolution for BIND 9.18 servers with default qname-minimization. If
qname-minimization is set "off", it works. That's because the disa.mil NSes
will respond with the answer for that full name. We never go farther up the name to try
to find the non-responsive NS servers.
(And yes, the DNS "authoritative" servers here are questionable too. The TTLs
look like they are caching answers, but all of the responses have AA set.)
Does that assessment look correct? I know BIND defaults to "relaxed" QNAME
minimization. It works around certain cases of brokeness. I guess this is not one of
them? Should it be? It's a case where things work without minimization. The brokeness is
hidden for non-minimizing resolvers.
Again, yeah, they are broken. They should fix it, but it broke someone's Very Important
Work at our shop. And it used to work and it works from home and for other customers so
it must be our DNS that's broken. So we end up setting "qname-minimization off"
globally despite the fact they are really the broken ones. We'd rather keep minimization
on, but it's the only reasonable work around we could find.
Just use a forward zone in forward only mode. When the parent servers give you
non working nameservers for child zones there isn’t a sensible automatic
solution.
zone disa.mil {
type forward;
forward only;
forwarders { 152.229.110.235; 214.3.125.231; 131.77.60.235; };
};
Can such forward-zones be defined in catalog-zones?
--
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: Answers for www.dnssec-failed.org with dnssec-validation auto;
Arrgh. You are correct. I was so far down in the weeds, I didn't notice a rock had fallen on my head. I know I can re-enable SHA1 for everything on the host with: update-crypto-policies --set DEFAULT:SHA1 But that's a fairly broad stroke, when only 'named' needs to accept such signatures. Is there a way to narrow it down? -- 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 4/17/2024 9:21 AM, Ondřej Surý wrote: Let me guess - you are running on RHEL (without SHA-1 support) and dnssec-failed.org is signed with RSA/SHA-1…-- 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: Answers for www.dnssec-failed.org with dnssec-validation auto;
resuming validate 17-Apr-2024 08:40:39.883 validating ./NS: verify rdataset (keyid=5613): success 17-Apr-2024 08:40:39.883 validating ./NS: marking as secure, noqname proof not needed 17-Apr-2024 08:40:39.883 validator @0x7fb8722b7000: dns_validator_destroy 17-Apr-2024 08:40:40.288 validating www.dnssec-failed.org/A: starting 17-Apr-2024 08:40:40.288 validating www.dnssec-failed.org/A: attempting positive response validation 17-Apr-2024 08:40:40.288 validating www.dnssec-failed.org/A: no valid signature found 17-Apr-2024 08:40:40.288 validating www.dnssec-failed.org/A: falling back to insecurity proof 17-Apr-2024 08:40:40.288 validating www.dnssec-failed.org/A: checking existence of DS at 'org' 17-Apr-2024 08:40:40.288 validating org/DS: starting 17-Apr-2024 08:40:40.288 validating org/DS: attempting positive response validation 17-Apr-2024 08:40:40.288 validating org/DS: keyset with trust secure 17-Apr-2024 08:40:40.288 validating org/DS: verify rdataset (keyid=5613): success 17-Apr-2024 08:40:40.289 validating org/DS: marking as secure, noqname proof not needed 17-Apr-2024 08:40:40.289 validator @0x7fb8722b7a00: dns_validator_destroy 17-Apr-2024 08:40:40.289 validating www.dnssec-failed.org/A: in validator_callback_ds 17-Apr-2024 08:40:40.289 validating www.dnssec-failed.org/A: dsset with trust secure 17-Apr-2024 08:40:40.289 validating www.dnssec-failed.org/A: resuming proveunsecure 17-Apr-2024 08:40:40.289 validating www.dnssec-failed.org/A: checking existence of DS at 'dnssec-failed.org' 17-Apr-2024 08:40:40.289 validating dnssec-failed.org/DS: starting 17-Apr-2024 08:40:40.289 validating dnssec-failed.org/DS: attempting positive response validation 17-Apr-2024 08:40:40.322 validating org/DNSKEY: starting 17-Apr-2024 08:40:40.322 validating org/DNSKEY: attempting positive response validation 17-Apr-2024 08:40:40.322 validating org/DNSKEY: verify rdataset (keyid=26974): success 17-Apr-2024 08:40:40.322 validating org/DNSKEY: marking as secure (DS) 17-Apr-2024 08:40:40.322 validator @0x7fb8722b7000: dns_validator_destroy 17-Apr-2024 08:40:40.323 validating dnssec-failed.org/DS: in fetch_callback_dnskey 17-Apr-2024 08:40:40.323 validating dnssec-failed.org/DS: keyset with trust secure 17-Apr-2024 08:40:40.323 validating dnssec-failed.org/DS: resuming validate 17-Apr-2024 08:40:40.323 validating dnssec-failed.org/DS: verify rdataset (keyid=3093): success 17-Apr-2024 08:40:40.323 validating dnssec-failed.org/DS: marking as secure, noqname proof not needed 17-Apr-2024 08:40:40.323 validator @0x7fb8722b7a00: dns_validator_destroy 17-Apr-2024 08:40:40.323 validating www.dnssec-failed.org/A: in validator_callback_ds 17-Apr-2024 08:40:40.323 validating www.dnssec-failed.org/A: dsset with trust secure 17-Apr-2024 08:40:40.323 validating www.dnssec-failed.org/A: resuming proveunsecure 17-Apr-2024 08:40:40.323 validating www.dnssec-failed.org/A: no supported algorithm/digest (dnssec-failed.org/DS) 17-Apr-2024 08:40:40.323 validating www.dnssec-failed.org/A: marking as answer (proveunsecure (2)) 17-Apr-2024 08:40:40.323 validator @0x7fb8722b8e00: dns_validator_destroy -- 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 4/17/2024 12:26 AM, Nick Tait via bind-users wrote: If you have just a single process listening on port 53, then I'd suggest using "tail -f" to watch your BIND logs-- 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
Answers for www.dnssec-failed.org with dnssec-validation auto;
I'm seeing strange behavior with a BIND 9.18.24 resolver and dnssec-failed.org. With no dnssec-validation line (or with "dnssec-validation auto") in the .conf, querying for www.dnssec-failed.org returns SERVFAIL, as expected . . until it doesn't. After several seconds of answering SERVFAIL, I start getting NOERROR responses, and IP addresses in the ANSWER. It isn't a predictable number of seconds; sometimes 9, sometimes 20. Is this supposed to be happening? When I examine the process with delv and my eyeballs, I can't see why it is succeeding with dig and my validating resolver. Maybe I'm not looking for the right things with my eyeballs? I'm stumped, and looking for advice for nest-steps in understanding what's going on. The following one-liner: # rndc flush && while true; do dig -4 www.dnssec-failed.org. A @localhost; sleep 1; done Results in answers like: ; <<>> DiG 9.18.24 <<>> -4 www.dnssec-failed.org. A @localhost ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 62774 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 9fd5ae2d4566c51d0100661f07f2bfc240421b91f851 (good) ;; QUESTION SECTION: ;www.dnssec-failed.org. IN A ;; Query time: 237 msec ;; SERVER: 127.0.0.1#53(localhost) (UDP) ;; WHEN: Tue Apr 16 15:21:22 AKDT 2024 ;; MSG SIZE rcvd: 78 ; <<>> DiG 9.18.24 <<>> -4 www.dnssec-failed.org. A @localhost ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 7693 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 90175bca7b323c830100661f07f3467dc5a561eb4f77 (good) ;; QUESTION SECTION: ;www.dnssec-failed.org. IN A ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(localhost) (UDP) ;; WHEN: Tue Apr 16 15:21:23 AKDT 2024 ;; MSG SIZE rcvd: 78 --- after ~20 more like those --- ; <<>> DiG 9.18.24 <<>> -4 www.dnssec-failed.org. A @localhost ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34572 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 60f5a11077dc97240100661f0809905b6096fd5e287a (good) ;; QUESTION SECTION: ;www.dnssec-failed.org. IN A ;; ANSWER SECTION: www.dnssec-failed.org. 7199 IN A 68.87.109.242 www.dnssec-failed.org. 7199 IN A 69.252.193.191 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(localhost) (UDP) ;; WHEN: Tue Apr 16 15:21:45 AKDT 2024 ;; MSG SIZE rcvd: 110 ; <<>> DiG 9.18.24 <<>> -4 www.dnssec-failed.org. A @localhost ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2987 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 89a4502552606c370100661f080a5dd5f9299ddb95fe (good) ;; QUESTION SECTION: ;www.dnssec-failed.org. IN A ;; ANSWER SECTION: www.dnssec-failed.org. 7198 IN A 68.87.109.242 www.dnssec-failed.org. 7198 IN A 69.252.193.191 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(localhost) (UDP) ;; WHEN: Tue Apr 16 15:21:46 AKDT 2024 ;; MSG SIZE rcvd: 110 -- -- 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
"bad cache-hit" or "bad-cache hit"
Looking in my logs today, I found a confusing line: validating cran.rproject.org/SOA: bad cache hit (rproject.org/DS) I was trying to figure out what was wrong with my cache, and how BIND might be able to determine that a cache hit is bad. To do that, it would need to retrieve the current value and compare it to the value in cache . . and by the time it has done that, why has it bothered to consult the cache? But now I think I may have mis-parsed the line. Maybe it isn't: bad cache-hit (i.e. Something was wrong with the cached value) but is instead: bad-cache hit (i.e. We found what we wanted in the cache of bad entries) Can anyone confirm my hypothesis? -- -- 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
Crafting a NOTIFY message from the command line?
I can use dig to request a zone transfer: dig AXFR foo.com I am unable to find a simple way to craft a NOTIFY message. Can anyone help me out? -- -- 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: BIND 9.16 is approaching EOL in April, 2024
I assume the day is approaching when the packages in the COPR repositories will be changed; isc/bind-esv will have 9.18 (instead of 9.16), and ics/bind will have 9.20 So that we might start weaving this into our maintenance plans, is there a projected date on which this will happen? -- 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/26/2024 7:35 AM, Victoria Risk wrote: The BIND 9.16 release branch is approaching EOL as of April, 2024. We encourage users running 9.16 or (gasp) 9.11, to upgrade to 9.18. The 9.18 branch has consistently out-performed the 9.16 branch, and we are confident that it is more stable than 9.16. One of our support engineers has prepared a helpful knowledgebase article on updating from 9.16 to 9.18 (https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918 <https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918>) which may be useful to you as you plan your migration. For an overview of our release plan, we maintain another knowledgebase article (https://kb.isc.org/docs/aa-00896 <https://kb.isc.org/docs/aa-00896>). This was updated earlier this month, to move the start of future new stable branches from Q1 to Q2. The problem with starting a new stable branch in Q1 is, after the long holiday quiet period, we always have a number of important fixes and changes we need to release *before* we can start a new stable branch. We are currently projecting that our next stable branch, BIND 9.20, will be released in Q2. For your convenience, we also maintain our planned EOL dates listed next to each software release on https://www.isc.org/download/ <https://www.isc.org/download/>. Vicky Risk-- 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
Value of a DNSSEC validating resolver
At first glance, the concept of a validating resolver seemed like a good idea. But in practice, it is turning out to be a hassle. I'm starting to think, "If my clients want their answers validated, they should do it." If they *really* care about the quality of the answers they get, why should my clients be trusting *me* to validate them? Can someone make a good case to me for continuing to perform DNSSEC validation on my central resolvers? -- -- 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
Stop leaking queries for RFC 1918 zones
The global/view option empty-zones-enable yes; isn't behaving as I expected. I had expected that it would cause empty "RFC 1918" zones to be created for those zones for which there were not local zones defined. That is, if there were no local zones of this type defined, it would create all the required empty zones. But if 10.in-addr.arpa was defined locally, it would skip that but define the rest of them. After looking at my logs, and seeing that I'm leaking RFC 1918 queries, I see my expectations were wrong. Is explicitly defining the remaining empty zones the best way to correct this? Or maybe add the un-used RFC 1918 zones to our RPZ? -- -- 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
Unhelpful startup message re: RPZ
I just spent 4 hours* of my life trying to figure out why BIND 9.16 complained on startup: rpz 'rpz.local' is not a master or slave zone when the zone was obviously defined, and was obviously loading. This was easily verified by looking at /named-checkconf -px/ output, and by looking in the logs to see the XFR from its primary. It turns out . . . my global /response-policy/ option worked swimmingly when there was exactly one view defined. When there is more than one view, the reference to the zone becomes ambiguous and bind threw out that (not very) helpful message. When there is more than one view, the /response-policy/ must be specified in each relevant view. Where do I make a 'feature request'? I think I see how to register defects (GitLab). Do feature requests go there, too? I'd love to see the text of that message be a little more explanatory. Maybe, "Dude. The zone you named exist, but with more than one view your reference is ambiguous." And, now that I think about it, it also feels like a defect in /named-checkconf/ that this is not called out. Or maybe I'm expecting too much from /named-checkconf/ ? * Admittedly, the second and third hours were of diminishing value, as my caffeine wore off and my frustration grew. After a night's sleep, and a pot of fresh tea I figured it out. -- -- 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: consolidating in-addr.arpa data
Yep. I understand the IP space can be delegated, and some of it allocated for use by systems registering in MS DNS. But this isn't going to happen. There are multiple MS Active Directories, with registered machines scattered willy-nilly across the 10-dot address-space, sometimes several competing in the same subnets. The "design and delegate" ship sailed years ago. I don't have a prayer of correctly fixing the underlying problem. After thinking harder, I don't even need correct records in all of the publishers of the various 10.in-addr.arpa zones. My goal now is simpler. Get the PTR-records from the zones handled by ISC BIND into (and out of) one particular MS DNS system. I don't need to get the PTRs registered in MS DNS back into the BIND data. I think I can get where I need to be by leveraging /nsdiff/ No. We won't be correctly publishing accurate PTRs from all of the possible DNS services in the environment. But this is achievable, and will address the problem (of our own making) which is causing pain. -- 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 9/15/2023 10:55 PM, Greg Choules wrote: This is because (close your ears MS) it assumes it is the only DNS in town. Why would there be another one? If there is one client with a 10.x.y.z address then there are potentially several billion more, so we'll create 10... just to be on the safe side. This makes MS DNS THE source of truth for all 10, so no-one else can have any of it unless you start creating delegations.-- 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: consolidating in-addr.arpa data
A host which auto-registers in MS DNS, creates an A in foo.alaska.gov and PTR in whatever.10.in-addr.arpa. MS DNS is happy to publish those. But the DNS system running on BIND also has a whatever.10.in-addr.arpa zone. So if I want to find the PTR for 13.12.11.10.in-addr.arpa, I must query both DNS systems in turn. If I get NXDOMAIN from both, then I can say the PTR doesn't exist. On each system, I'd like to be able to take the 10.in-addr.arpa data from the other, compute the differences, and incorporate them locally. Then I'll be able to query either system, and accept an NXDOMAIN with confidence. And since writing my earlier note, I have re-located the code I think I stumbled across earlier Tony Finch's "nsdiff" https://dotat.at/prog/nsdiff/ -- 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 9/15/2023 2:21 PM, Greg Choules wrote: Hi John. Can you tell me a bit more please? - What zones exist in both BIND and MS DNS for something.10.in-addr.arpa? - Where are hosts auto registering to? I'd guess MS, but it would be good to confirm. - What does fragmentation look like? A few real examples would be useful. I'm trying to understand just what is the problem. - How much of 10 do you use? - What do you mean by "...can be published from two different DNS services."? Could you expand on that please? - Is there any zone transfer between BIND and MS DNS? Thanks, Greg On Fri, 15 Sept 2023 at 21:00, John Thurston wrote: This question involves making our BIND system work with Microsoft's DNS software. If this makes it off-topic, let me know and I'll be quiet about it. We use ISC BIND to hold and host most of our zone data. Internally, we have delegated some zones, and they are held in Microsoft DNS. These zones are used for MS Active Directory 'Domains', and accept auto-registration of DNS records from authorized hosts. Because we are using 10-dot addresses internally, the auto-registration by hosts causes fragmentation of the 10.in-addr.arpa zone data. I recall someone once offered a bit of code to mash this zone data back together, so the same information can be published from two different DNS services. I've hunted through this list's archive and have not found the reference. Before I go roll my own, can anyone point me at an existing solution? -- -- 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
consolidating in-addr.arpa data
This question involves making our BIND system work with Microsoft's DNS software. If this makes it off-topic, let me know and I'll be quiet about it. We use ISC BIND to hold and host most of our zone data. Internally, we have delegated some zones, and they are held in Microsoft DNS. These zones are used for MS Active Directory 'Domains', and accept auto-registration of DNS records from authorized hosts. Because we are using 10-dot addresses internally, the auto-registration by hosts causes fragmentation of the 10.in-addr.arpa zone data. I recall someone once offered a bit of code to mash this zone data back together, so the same information can be published from two different DNS services. I've hunted through this list's archive and have not found the reference. Before I go roll my own, can anyone point me at an existing solution? -- -- 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: BIND 9.18 available for Ubuntu from PPA ?
Welp, there I have it. I thought I had until April 2028 :( Sorry for the noise. -- 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 6/23/2023 12:04 PM, 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. Ubuntu 18.04 is EOL (End of Standard Support), and we don’t publishing packages for distributions without security support. You need to upgrade to Ubuntu 20.04 or Ubuntu 22.04. 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 23. 6. 2023, at 21:48, John Thurston wrote: bind9: Installed: 1:9.18.15-1+ubuntu18.04.1+isc+1 Candidate: 1:9.18.15-1+ubuntu18.04.1+isc+1 Version table: *** 1:9.18.15-1+ubuntu18.04.1+isc+1 100 100 /var/lib/dpkg/status 1:9.11.3+dfsg-1ubuntu1.18 500 500 http://azure.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 1:9.11.3+dfsg-1ubuntu1 500 500 http://azure.archive.ubuntu.com/ubuntu bionic/main amd64 Packages -- 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 6/23/2023 11:43 AM, Ondřej Surý wrote: What does apt-cache policy bind9 say? -- Ondřej Surý — ISC (He/Him) -- 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 9.18 available for Ubuntu from PPA ?
bind9: Installed: 1:9.18.15-1+ubuntu18.04.1+isc+1 Candidate: 1:9.18.15-1+ubuntu18.04.1+isc+1 Version table: *** 1:9.18.15-1+ubuntu18.04.1+isc+1 100 100 /var/lib/dpkg/status 1:9.11.3+dfsg-1ubuntu1.18 500 500 http://azure.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 1:9.11.3+dfsg-1ubuntu1 500 500 http://azure.archive.ubuntu.com/ubuntu bionic/main amd64 Packages -- 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 6/23/2023 11:43 AM, Ondřej Surý wrote: What does apt-cache policy bind9 say? -- Ondřej Surý — ISC (He/Him)-- 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
BIND 9.18 available for Ubuntu from PPA ?
I have an Ubuntu instance on which I'm running 9.18. It was installed in 2021 from the PPA, using the instructions at https://launchpad.net/~isc/+archive/ubuntu/bind We have successfully updated the packages many times in the past two years. But apt currently says there are no updates to install. If I 'dpkg -l bind9' I get back '1:9.18.15-1+ubuntu1 amd64' If I cat '/var/lib/apt/lists/ppa.launchpad.net_isc_bind_ubuntu_dists_bionic_InRelease' I see the same as if I look at http://ppa.launchpad.net/isc/bind/ubuntu/dists/bionic/InRelease When I look at https://launchpad.net/~isc/+archive/ubuntu/bind I think it is telling me that 1:9.18.16-1+ubuntu22.04.1+isc+1 should be available. Has anyone successfully updated to 9.18.16 from this PPA? Can you suggest what I'm doing wrong today? -- -- 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
Reverse Policy Zone to make MS Azure stuff work?
Due to a requirement to use something Microsoft crafted, we are being asked to assert (internally) authority over 3rd-level names under appserviceenvironment.net I've pushed back on this, because I don't think it's nice to publish "authoritative" answers in domains we have not been delegated. But I'm told it's all ok, because Microsoft says its ok* Having accepted that the ship has sailed, it's now a question of how to deliver such answers. One obvious way is to define a zone for each 3rd level under appserviceenvironment.net, and publish them in a way our resolvers can find them. In the absence of catalog-zones, this could be a lot of additional work (for me). Then I wondered if adding these 'hijacked' names to our RPZ would meet the need. I first thought, "Yeah. It'll work.", but then I re-read the statement from MS saying each 3rd level was going to need to have a 4th level zone defined. A zone definition requires at least an SOA and NS record . . and last time I checked, an RPZ would not deliver an NS record. So it seems that idea may be squashed. Who else has need to publish locally-defined appserviceenvironment.net names? Were you able to do it with your RPZ? * https://learn.microsoft.com/en-us/azure/app-service/environment/create-ilb-ase -- -- 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
Delegation NS-records when zones share an authority server
I uncovered an oddity in my zone definitions, which I'm trying to wrap my head around. We have authority over state.ak.us, which we publish as a public zone. We also publish challenge.state.ak.us as a public zone. The public NS records for state.ak.us are: ns4.state.ak.us and ns3.state.ak.us The NS records for challenge.state.ak.us are the same. I recently noticed there were no NS records _in the state.ak.us zone_ for challenge.state.ak.us. This had me scratching my head . . "how can this be working?", until I remembered the same instances of BIND were serving out both zones. There _were_ NS records in the challenge.state.ak.us zone, BIND had them, was authoritative, so would answer with them; BIND didn't need to look in the state.ak.us zone to find them. Some experimentation shows that even if I insert NS records into state.ak.us (for challenge.state.ak.us), BIND does not add them to its answer when asked "dig NS challenge.state.ak.us". I interpret this to mean that while this instance of BIND is authoritative for both zones, it answers with information from the most specific zone it has, and ignores values in the delegating zone. And that makes sense to me. Now the question is, should I insert NS records into state.ak.us (for challenge.state.ak.us) anyway? Arguments in favor: * Every other zone we delegate is handled by some other set of name serves, so we've come to accept (and expect) "every delegated zone will have NS records here". This outlier had me scratching my head, and will cause someone else confusion in the future. * The time may come when challenge.state.ak.us is not handled by the same instance of BIND as state.ak.us. Having benign delegation records present, will remind Future-Self to adjust the values to delegate to the new servers. * We parse the state.ak.us zone file to identify all delegated zones, and run periodic tests to confirm those delegates are delivering coherent answers. With no NS records for challenge.state.ak.us, we have not been performing these tests. Arguments against: * Maybe I misunderstand, and such NS records aren't actually benign Unknown: * Does the answer change if we want to start signing either zone? -- -- 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
Use of stale data during dnssec validation
Today, we had a case where one of our resolvers (9.16.37) failed to return an SOA-record for the TLD 'us'. digging with the +cd flag, returned a value, while delving with +vtrace failed: ;; fetch: us/SOA ;; resolution failed: SERVFAIL Fingers pointed to a failure to validate. I dumped the cache to a file, and then did a flushname of 'us.' digging and delving was then successful. When looking in the dumped cache, I see the RRSIG-record for the SOA-record is marked as 'stale', and the DNSKEY-record (id=54159) is marked as 'pending-answer' Is stale data used during the validation of answers? :: From the dumped cache :: us. 84964 SOA a.cctld.us. admin.tldns.godaddy. ( 1677862753 ; serial 1800 ; refresh (30 minutes) 300 ; retry (5 minutes) 604800 ; expire (1 week) 1800 ; minimum (30 minutes) ) ; secure ; stale 84964 RRSIG SOA 8 1 900 ( 20230402170130 20230303160130 54159 us. OKQQZoU8itxdg2T+AYpefOmGILJZRl1aA9zb NXzYL9sXWsMMlctwod9JkEM08/SYGEHTmaEa M+d9PMAjeeJMiChj3RV3TPGKRDubUbBrNJb2 R15fsjZRcVf8Iebhr0EZ/yxTJl4YzcTbUh9v ffNOEULcPuVJmv0Hda7HKvnBmVJszPZImfLX YIx3SyzRBp7jiZT1t7oyfZSlAbuRjX7zOw== ) ; secure 82614 DS 46144 8 2 ( 0C67E6017124BF19D50BE565CC486FF3CFE2 A278FE2E5983FF97B2A453386419 ) ; secure 82614 RRSIG DS 8 1 86400 ( 2023031605 2023030304 951 . NHCxlyjA2/t38e03sjyEnXMszz/2whq5GFmP Jf2Ttx9bUy1d/gq2n2PiM1BFZYKQvMGynB4f 58NK8905TG1fveBUTouF/eNo2gmHj/uBuPJm g19lPm05tIK5OCCyD+D16K3IncQAjZUKjfcH bT5qE8KF/ofRaO7PgFn27KbQwtnky+F3PXgJ BkFIfkPJ8SFX6WSEaM8FsLojLDiJWllwnoJK Qf6S0Ot8M3yOIb2oKCT0tucB7znRdkm9EEY5 oSe7waJRV+0sQL3rKhJePFVrd/AeTXY6ipaK kIjdEn+1DoxiBAy/E0uhJ18s16USrxcZSSUg D5GfeGeuLiT7f69a+g== ) ; pending-answer 3179 DNSKEY 256 3 8 ( AwEAAatbrQTiZd0FdSVbnkRFiU5jf9ACOPc4 M0CK+G+Gla4gH3ClPunwqBJhvRtMkKdhGE93 lMuzjNkGakBrkFvzwHtIw9pWLxum2Idysf+J xdhfSXNNYEzKcP0lCIjWf+iY2rtXoltVLxgT 2skvDgmbwq+a3Cb/7CAB/SmFRCl8tQJ4YpJl kHiHPbWXljjiPWsj3/52hv45GHKQPi4vRzPe aw0= ) ; ZSK; alg = RSASHA256 ; key id = 54159 3179 DNSKEY 257 3 8 ( AwEAAe5RHQBesQeThYEf56TkLfF5NysJv/H4 g1HeB7pnH25PsMVoVV/anWi7U3dSFsNzJ6nB HwY/sdmxJ/HLunC/mLSo8ugB6G+UgtAgnlL3 u8Uq/3PYiBgpdNL+ldR0luV5WLAx8/1gG8JZ w3Zu9VhurHKdGZso5ajSTFwBiY39lA0wWeDO kZ2z/EV49JODt1i2N6KnvMTe5kD0qHXkP2oH xTWOlf5vqUcmJmgfvLlGB1ROBT84xCm45Sfx 1U4FD8IPiOFrd9f/WcjPcW8MJFmzQmweVfKE pF28s+YZ5wKid3gYESvaCeSvj7FHzdVUCcVh Fr2+XHeB8O8GTLqk7HgfdM8= ) ; KSK; alg = RSASHA256 ; key id = 46144 -- -- 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
Tools for parsing a dumped cache
The first thing I do when I'm trying to diagnose strange behavior of a resolver, is I dump the cache to a file. Later, I end up trolling through it with less and grep, looking for entries (usually incorrect RRSIG or DS records) which will explain the behavior I saw. I have two questions: Is there a spiffy cache-file-parsing tool out there, which will make this work easier? I'm thinking of something like what Wireshark does for packet-capture files. "Here is an A-record. Here is its RRSIG. Here is a error, because we don't have a DS over here." Is there a way to launch an instance of named, convincing it to "freeze in time"? i.e. "Please start, consume this cache file. Consult only your cache, perform no external queries, and do not expire anything." This would let me reproduce the failure-state and dig and delv at my leisure. -- -- 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: 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
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
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: Gratuitous AXFRs of RPZ after 9.18.11
I was never able to uncover the underlying problem with that update. The only clue I had was the service remained in "activating" state, rather than "running". named was listening as expected, was transfering zone data, was caching and serving the correct data, but didn't seem to recognize it had the same data when it next retrieved the SOA record. I eventually restored the secondary host from backup, and performed the upgrade from 9.18.10 --> 9.18.11 again. It behaves exactly as expected; retrieving the SOA record, recognizing it already has that serial number, and waiting patiently for the refresh interval to expire before checking again. -- 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 1/27/2023 1:53 AM, Ondřej Surý wrote: FTR I am not aware of any change between 9.18.10 and 9.18.11 that might cause the described behaviour. That said - in addition to what Greg said, I would suggest increasing the log level to small debug levels if you can and perhaps something will stand out-- 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
Gratuitous AXFRs of RPZ after 9.18.11
I have a primary server and a couple of secondaries. After making adjustments to my RPZ yesterday (which almost never change), I noticed an oddity. One of my secondaries is performing gratuitous AXFRs of the RPZ. This isn't a huge performance issue, as my RPZ is only 7.3KB. I want to understand why it is doing this, when other secondaries are not and when this secondary is _not_ also performing such gratuitous AXFRs of its other zones. Of note, the secondary in question has a "twin", for which the output of named-checkconf -px is identical (excepting the host-specific keys used for rndc access). That "twin" is behaving as expected. To recap, the troublesome server has several secondary zones defined. All but the RPZ is transferring as expected. The troublesome server has a "twin", which is behaving correctly for all of the secondary zones. The SOA-record for my RPZ looks like so: ;; ANSWER SECTION: rpz.local. 300 IN SOA rpz.local. hostmaster.state.ak.us. 22 3600 1800 432000 60 And I can see my several secondaries querying the primary for the SOA-record on a regular basis. With a 'refresh' value in the SOA of only 3600, this is what I expect to see. What I don't expect to see, is the troublesome secondary then follows each of those queries for the SOA with an AXFR request, like so: 26-Jan-2023 15:25:40.175 client @0x7f19691c1280 10.213.96.197#37631/key from-azw (rpz.local): view azw: query: rpz.local IN SOA -SE(0) (10.203.163.72) 26-Jan-2023 15:25:40.274 client @0x7f1968118970 10.213.96.197#44769/key from-azw (rpz.local): view azw: query: rpz.local IN AXFR -ST (10.203.163.72) 26-Jan-2023 15:27:10.665 client @0x7f196925d6f0 10.213.96.197#60123/key from-azw (rpz.local): view azw: query: rpz.local IN SOA -SE(0) (10.203.163.72) 26-Jan-2023 15:27:10.763 client @0x7f1968118970 10.213.96.197#46011/key from-azw (rpz.local): view azw: query: rpz.local IN AXFR -ST (10.203.163.72) When I dump the zone database from the secondary (rndc dumpdb -zone rpz.local), I can see the RPZ in it with the expected serial number and all of the expected records. And after typing all of the above, I did an rndc status to get the versions of each, and discovered that the "twins" are not actually twins! The troublesome host is: 9.18.11-1+ubuntu18.04.1+isc+2-Ubuntu Its "twin" is: 9.18.10-1+ubuntu18.04.1+isc+1-Ubuntu And now when I study my xfer.log more closely, the behavior changed this morning when I completed the update from 9.18.10 -> 9.18.11 I'm not yet ready to revert, because this isn't affecting my business (this is a really small zone). Is anyone else seeing similar behavior? -- -- 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: Resolving and caching illegal names
I hadn't had enough coffee when I wrote that. I was doing in-addr.arpa translation in my head and confusing what was the TLD of the query being submitted. If a customer is stupid enough to ask for an A-record for 10.1.2.3, then the TLD of that name is "3", not "10" . . duh. So to make the RPZ work, I needed to stuff the zone file with 256 new entries. I did this by dusting off my knowledge of the GENERATE directive (which involved RTFM): $GENERATE 0-255 *.$ CNAME . I also needed to populate the "validate-except" option with 256 new entries. I could find no elegant way to generate, abstract, or 'include' this, so just needed to put the long string of characters inline: 0; 1; 2; 3; 4; 5; 6; 7; 8; 9; 10; 11; 12; . . . and it now behaves as desired; returning an unvalidated NXDOMAIN for queries for ip addresses. -- 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 1/25/2023 8:36 AM, John Thurston wrote: Off-list, it was suggested to me that I _could_ handle this in my RPZ, by enumerating all 255 illegal TLDs (e.g. *.10 CNAME . ) I tried this, and it works as expected when dnssec validation is disabled (either globally, or with "validate-except". My idea right now is I can enumerate TLD of the numerics I see in my logs, and ignore the rest. I think this will get me what I want, at a level of complexity I can accept. -- 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: Resolving and caching illegal names
- Why *must* you forward everything to Akamai?
I am forced to "forward only;" to Akamai for all external queries. It
hasn't always been this way, but the decision was made "above my pay
grade", and it is not open to negotiation.
- Was that a real example of a daft query: 10.11.12.13 type A?
"10.11.12.13 is, indeed, a query I found in my log.
what's the issue with returning SERVFAIL?
On my validating "recursive" servers, "SERVFAIL" is the response from
_my_ server. That is the result of Akamai saying "Here's your answer!"
and my server going through the work of trying to validate it (and failing).
On my non-validating "recursive" servers, I send back the answer Akamai
sends me:
;; ANSWER SECTION:
10.11.12.13. 10 IN A 10.11.12.13
I think SERVFAIL is the correct answer for all of these queries. I do
not want to encourage any customers in thinking they can get an address
back from me by asking for the address of an address.
- Do Akamai have any knobs you can tweak
{chuckle} I'm not allowed in the control room. And Akamai's response to
my question was quoted in my original message. From their perspective,
this behavior is a feature, not a defect. I don't expect them to let
their customer disable their "features". If I want to change this
behavior, I'm going to have to do it within my sphere of influence.
Off-list, it was suggested to me that I _could_ handle this in my RPZ,
by enumerating all 255 illegal TLDs (e.g. *.10 CNAME . )
I tried this, and it works as expected when dnssec validation is
disabled (either globally, or with "validate-except". My idea right now
is I can enumerate TLD of the numerics I see in my logs, and ignore the
rest. I think this will get me what I want, at a level of complexity I
can accept.
--
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 1/24/2023 10:26 PM, Greg Choules wrote:
- Why *must* you forward everything to Akamai?
- Was that a real example of a daft query: 10.11.12.13 type A? If not,
do you have some real examples of queries being made to your servers
please?
- Notwithstanding the nature of these illegal queries, if they *are*
illegal (or misguided, or errors, or malicious, or whatever - anything
but valid), what's the issue with returning SERVFAIL? GIGO Or does
that then prejudice genuine queries, for some reason?
- Are you *only* forwarding to Akamai?
- Do you have "forward only;" or "forward first;"?
- Do Akamai have any knobs you can tweak (I believe they have a
customer web portal for viewing/changing settings?) that would make
them behave like an RFC compliant DNS server?--
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
Resolving and caching illegal names
My "resolvers" running BIND 9.18.10 and 9.16.36, accept and attempt to resolve queries for illegal names. They will cache answers for these names, and answer from cache when asked. What's the thinking here? I suppose it could be, "The specifications of what is a legal name may change with time, and we don't want to burden the resolver code by asking it to validate the string before trying to resolve it." This comes up because my "resolvers" don't actually resolve. All they are allowed to do is forward external queries to Akamai, and accept the response from Akamai. And Akamai (thank you very much), is happy to accept queries like "What is the A-record for 10.11.12.13?" and reply with "The answer is 10.11.12.13, and is good for 10 seconds." Akamai's explanation for this behavior is, ..." the query was made in error (likely/maybe meant to be type "PTR") and we are trying to save the resolver from doing the work a query like this would entail." But what it really means is my validating "resolver" then does the work of trying to validate the reply it got. It is unable to do so, and returns a SERVFAIL to the customer. I haven't yet tried, but I don't expect I can define an RPZ to trap such illegal names. Can I? If I could, it would reduce the traffic to Akamai, and the number of validations I'm trying to do. -- -- 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: Finding dnssec validation failures in the logs
It sounds like I'm correct that lines of the sort: validating com/SOA: got insecure response; parent indicates it should be secure are my indication that dnssec is doing its job. (Whether I should be reacting to messages like the above remains to be seen.) Let me rephrase my original question (which remains unanswered): Are there other strings in the log which similarly indicate dnssec is doing its job and logging responses which can not be validated? Of the lines like the above (for a sample day), 92% of them indicate failure to validate SOA-records. Only 4% are for A-records. Of those same lines, the most prevalent entris are the SOA-records for: 2% io 2% us 2% ip6.arpa 2% pure.cloud 2% org 4% impervadns.net 6% net 7% cloudflare.net 9% . 33% com It concerns me the SOA records I'm requesting are so often being rejected as invalid. I have my suspicions of what's happening, but not enough information to form a solid hypothesis or perform tests. I want higher confidence that I'm recognizing the important lines in the logs before I start casting stones. -- 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 1/24/2023 5:26 AM, Michael Richardson wrote: John Thurston wrote: > On a resolver running ISC BIND 9.16.36 with "dnssec-validation auto;" I am > writing "category dnssec" to a log file at "severity info;" When I look in > the resulting log file, I'm guessing that lines like this: > validating com/SOA: got insecure response; parent indicates it should be > secure > Are an indication I have a problem I should investigate. Maybe. It could be that DNSSEC is simply defending you against attackers who are trying to race insecure answers to your queries in the belief that "nobody validates" If it were systematic (every query, every query to some servers...) then you should suspect that there is a on-path attacker modifying the responses. That's unlikely in general, but it's why we have DNSSEC. It could also be the result of corrupted packets that survive the UDP checksum, or which go through a middle box that "fixes" that. Some satellite systems do that. I imagine that Alaska might have at least one satellite link. It doesn't sound like it's systematic, so I think they are off-path attackers, and it looks like it's queries on .com? Most likely, there is little you can do.-- 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
Finding dnssec validation failures in the logs
On a resolver running ISC BIND 9.16.36 with "dnssec-validation auto;" I am writing "category dnssec" to a log file at "severity info;" When I look in the resulting log file, I'm guessing that lines like this: validating com/SOA: got insecure response; parent indicates it should be secure Are an indication I have a problem I should investigate. My question is: Are there other strings I should be reacting to in that log? I interpret the many lines like this: validating wunderkind.co/SOA: no valid signature found to mean "We looked for signing information for wunderkind.co and found none. That's cool, we didn't expect them to be." -- -- 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: Bind 9.16.1 crash
To me, the next step is to get your instance of BIND somewhat up to date. I'm not a "gotta be on the bleeding edge" kinda guy, but running a version released in first quarter of 2020 is old even by my standards. Is there some business reason to keep running a +2 year old version of BIND? -- 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 12/7/2022 10:32 AM, Ben Bridges wrote: The BIND version is 9.16.1 running on a fully patched Ubuntu 20.04.5 server.-- 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: Zone transfer over VPN
If you are dealing with two totally private networks, do you even need
the ACL?
But if you do need to limit access, then I suggest using TSIG to
identify and authorize. This avoids the whole question of
source/destination IP addresses. If the transfer request is made using
the correct key, it will work.
I do this by defining a specific key for each secondary server. Then, in
the appropriate view on the hidden primary, I use:
match-clients { none; };
allow-transfer { key nameofkeyhere; };
and on each secondary, I define a 'primaries' and use that in the zone
definitions:
primaries hiddenprimary { 10.20.30.40 key nameofkeyhere; };
zone "foo.bar.com" { type secondary; primaries { hiddenprimary; }; };
The address of the secondary does not matter. As long as it makes the
connection to the primary using the key 'nameofkeyhere', it can do the
zone transfers.
--
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 9/6/2022 2:31 PM, Greg Choules via bind-users wrote:
Hi Michael.
Have you tried without the "allow-transfer" statements at all? I find
it usually works best to start simple, get it working, then apply
security bit by bit.
Do you have logs from all servers? What are they telling you
specifically about what is the issue?
Lastly, get packet captures of port 53. Evidence is always handy to
see what is actually going on, rather than guessing what you *think*
should be going on.
Cheers, Greg
On Tue, 6 Sept 2022 at 23:16, Michael De Roover wrote:
Hello everyone,
I have currently 2 internal networks under my control, both of
which have BIND
name servers in them. The "main" network uses the 192.168.10.0/24
<https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2F192.168.10.0%2F24=05%7C01%7Cjohn.thurston%40alaska.gov%7C0b4f0d284fe74f09bbf108da9057ba85%7C20030bf67ad942f7927359ea83fcfa38%7C0%7C0%7C637981003716453668%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=m4PWz1DpiHERIwtojthnVS%2FqlwZSOVlo2b92ppc2UQs%3D=0>
subnet,
while the "satellite" network uses the 192.168.20.0/24
<https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2F192.168.20.0%2F24=05%7C01%7Cjohn.thurston%40alaska.gov%7C0b4f0d284fe74f09bbf108da9057ba85%7C20030bf67ad942f7927359ea83fcfa38%7C0%7C0%7C637981003716453668%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=ip1uyLLXepntzC%2BEY1IHwUBmbRaMcP9l4z6W6VDJ0e8%3D=0>
subnet. Following this,
I will refer to these as main and satellite. You may consider the
satellite
network sort of like a road warrior setup, though both are
fully-fledged
networks with hosts in them.
The main network has a set of two gateways with IP addresses
192.168.10.51,
and 192.168.10.52. They perform VRRP to each other, with floating IP
192.168.10.9. Both of them make a VPN connection to two VPS's
using WireGuard.
The VPS's have IP ranges 10.8.2.0/24
<https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2F10.8.2.0%2F24=05%7C01%7Cjohn.thurston%40alaska.gov%7C0b4f0d284fe74f09bbf108da9057ba85%7C20030bf67ad942f7927359ea83fcfa38%7C0%7C0%7C637981003716453668%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=6An6ZttdBhIJDCfAW2uPJ7l3hcwAWdBmoVcGq3SFJSY%3D=0>
and 10.8.3.0/24
<https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2F10.8.3.0%2F24=05%7C01%7Cjohn.thurston%40alaska.gov%7C0b4f0d284fe74f09bbf108da9057ba85%7C20030bf67ad942f7927359ea83fcfa38%7C0%7C0%7C637981003716610384%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=IAbKqjHmQi9WoT67xkh0oXkM9mk78n2w0DJZtkNM0Po%3D=0>
respectively. Pretty much
all traffic that's relevant here (AXFR/IXFR on TCP 53) goes
through the former.
The satellite network does the same thing, it also connects to the
VPS's but
does not perform VRRP with another node. The gateway on the
satellite network
uses IP address 192.168.20.1.
The name servers on these networks are 192.168.10.4, 192.168.10.5 and
192.168.10.6 on the main network, and 192.168.20.3 on the
satellite network.
This is running on BIND 9.16.25 for Alpine on the main network,
and BIND
9.11.5-P4-5.1+deb10u7-Debian for Debian on the satellite network.
All of them
are running in LXC with bridged networking.
Now I would like to get both of these networks to share their
local zones. So
in the name servers' configs I would initially declare an ACL for
this and add
that to the zone entries, on the main network. This worked fine
for those,
being in the same subnet. But once I tried to do the
Re: Reminder: BIND 9.11 is going EOL in March 2022
On 1/26/2022 9:09 AM, Victoria Risk wrote: For those using the ISC BIND packages: Because we are still patching 9.11, and we haven’t yet issued a new development branch, we are putting 9.18.0 into the bind-dev repositories, for now. In April, we plan to do a version rollover: - bind-esv will go from 9.11 to 9.16 - bind will go from 9.16 to 9.18 - bind-dev will go from 9.18.1 to 9.19.0 BIND 9.19.0 will be the new development branch. We've reached April, 2022. I expect, in the next 30-days or so, we'll be seeing an announcement regarding the change of contents of bind-esv, bind, and bind-dev Is it reasonable to expect these changes will occur in about the middle of the month? -- 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: Using nsupdate in scripts
On 3/14/2022 3:11 PM, Philip Prindeville wrote: I was hoping that there's a trivial way to parse the named.conf file and figure out what it listens on for updates using a Bind utility, but I guess not... The utility 'rndc status' will return the full path of the configuration file: rndc status | grep "configuration file:" And the utility 'named-checkconf -px configfile' will print out the configuration in canonical form, from which you could grab anything you like. But if what you want isn't in the configuration file (e.g. passed as a command-line parameter, or compiled in), then named-checkconf isn't going to help. To learn those, I think you'll need to query the operating system for information about the specif process. I'd be looking at pgrep and ps, but there's probably better ways to do it. -- 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: Capabilities and limitations of catalog zones
On 2/9/2022 2:36 AM, Tony Finch wrote: John Thurston wrote: Are we not able to use catalog zones to propagate zone-configuration for anything other than 'master' zones? > It is only for configuring authoritative secondary zones. That's unfortunate, but thanks for the confirmation. I had been looking forward to making this work :( We have only a couple of authoritative zones, but over 60 forward zones. And I expect far more growth and complexity in forward zones than in our authoritative zones (thanks to "cloud", and split private/public name-spaces). At least I now know to draw a line through "catalog zones", and pursue other distribution options. -- 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
Capabilities and limitations of catalog zones
Are we not able to use catalog zones to propagate zone-configuration for
anything other than 'master' zones? I've been playing with catalog zones
in the lab, and am stuck.
I have defined a catalog zone on my primary, with a zone file that looks
like:
$TTL 300
@ IN SOA @ hostmaster.ak.gov. ( 123 60 60 432000 60 )
IN NS invalid.
version IN TXT "2"
e6db03231540bd80933ff1e504e3f43dbdb8f0cd.zones IN PTR ak.gov.
eb1a9a3baa50b96663357a8fe204983748769ed9.zones IN PTR localhost.
I have defined a secondary and told it to consume from the primary. In
the logs, I can see the XFR requests, and the transfer of the zone
'localhost' completes as expected. The zone "ak.gov' does not.
The difference between them is 'localhost' is defined on the primary
like so:
zone "localhost" {
type master;
file "db.localhost";
};
while 'ak.gov' is defined on the primary like so:
zone "ak.gov" {type forward;forward only;forwarders
{ 10..11.12.13; };
};
--
--
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: ISC BIND & Windows
Check the list archives beginning April 2021 for the thread: Deprecating BIND 9.18+ on Windows (or making it community improved and supported) -- 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/1/2022 7:14 AM, jukka.pakka...@qnet.fi 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. Just read from the 9.18.0 release notes that Windows is not supported. Since don't remember reading expressly stated that Windows support would end with 9.16.x branch, inquiring if there is more information about future Windows compatibility available... is the plan to include support to Windows at some point, to some current or future Windows Server version, or is it a fact already, that no more Windows past 9.16.x? Jukka -- 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
9.11, 9.16 and ESV designation
We're running mostly 9.11, with a couple of hosts running 9.16. We've been sticking with 9.11 while we waited for 9.16 to be labeled the Extended Support Version (ESV). The recent announcement of 9.18 made me go digging to learn . .. 9.16 _is_ the ESV and 9.11 is EOL and will no longer be supported after March 2022! https://kb.isc.org/docs/aa-01540 Here are our current ESV versions and their EOL dates: BIND 9.11 is our out-going Stable/Extended Support Version, currently in EOL status, supported until March, 2022. BIND 9.16 is our current Stable/ESV version. BIND 9.18 is our newest Stable version. That document was last updated on Jan 5, 2022, so this news is at least three weeks old. I don't recall seeing anything on the "Announce" mailing list regarding the change in ESV designation. Nor do I see any difference in the COPR packages: https://copr.fedorainfracloud.org/coprs/isc/bind-esv/ which continue to offer 9.11. Now, I don't expect my 9.11 installation to give me any trouble, and I don't expect it suddenly stop working in April. But I do expect someone with a clipboard and checklist to drag me over the coals if they discover I'm running an "end of life" version without a mitigation plan. So I gotta start sketching paths from 9.11 -> 9.16 and 9.16 -> 9.18. To assist me in that, I'm looking for answers to two questions: A) Where was the ESV-switch announced? (I though I had my bases covered by subscribing to 'announce' and 'user' mailing lists. I need to find and plug this communication hole.) B) What are the plans for the 'bind-esv' COPR? (Will it soon start serving 9.16? Do I need to manually switch from 'bind-esv' to 'bind'? Is COPR dead?) -- -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ Please 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: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
On 1/3/2022 8:35 AM, Grant Taylor via bind-users wrote: In short, how do you get a /purely/ /recursive/ server to know that internal-corp-lan.example (or any domain not in the global DNS hierarchy) is served by some other /purely/ /authoritative/ DNS server inside the company? It must have a 'forward' zone defined on it for each of those stupid domains. And yes, you are right . . at that point it is no longer only performing recursion. But there is no other way to do it. Even in a combined recursive/authoritative design, your server would have no way to resolve names in those stupid domains; there must be an explicit 'forward' zone defined. -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ Please 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: Recursion Question
Define an explicit forward-zone on the recursive server for private.dns.com In the zone definition, put the addresses of the servers which can answer for private.dns.com. -- 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 12/20/2021 11:05 AM, LeBlanc, Daniel James via bind-users wrote: The Recursive DNS server is unaware of this domain and sends the request to its Forwarding DNS ___ Please 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: insecurity proof failed for a domain
If you update your resolver to 9.16, I think you can do exactly what you
want with the "validate-execpt" option.
{rolls eyes} been there. done that. for exactly the same reason :/
--
--
Do things because you should, not just because you can.
John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
___
Please 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: RPZ rule to apply to NS record requests?
On 11/16/2021 2:41 AM, Tony Finch wrote: John Thurston wrote: If I have a Reverse Policy Zone (RPZ) defined, I can define a specific answer to be sent for a specific record-type for a specific name: foo.bar.com IN A 10.11.12.13 foo.bar.com IN TXT "Hello World" But I can't seen to define one for the record-type NS Is this possible? The RPZ documentation doesn't say you can't include NS records as "local data", but I guess you might trip over BIND's checks for what makes sense at a zone cut: in a normal zone you can't have A and TXT and NS at the same name (unless it's the zone apex). But even if it did work, it's unlikely to do what you want. (You didn't say why you want NS records so that's a somewhat risky assumption...) TLDR; I'm trying to cover up someone else's mess I didn't describe the reason because it is painful. We use products from Major Software (hereafter referred to as MS). They use DNS to provide pointers to public and private versions of similar services. These pointers are served from public or private authoritative servers owned and operated by MS. The zones defined on the public authorities contain both SOA and NS records for each zone. The zones defined on the private authorities have only the SOA records. Per RFC, an SOA and NS are the minimal records required of a zone. When we define forward-zones in our internal resolvers (e.g. Please send queries for these private names directly to this MS resolver), our automated monitoring system goes berserk. "Danger! Danger! The zone privatelink.MS.net is invalid! It has no NS record!! Danger! Something is wrong! Stop forwarding! Call the Authorities!" I recognize MS probably doesn't care they are serving up an invalid zone. I also recognize that my bosses probably are not going to quit using products and services from MS. I don't want to try to dismantle (or cripple) the monitoring system which is keeping an eye on all the other zones for which we forward. I'm, therefore, left trying to imagine someway to abuse something in my control so my monitoring system doesn't notice these private MS zones are invalid. I had _hoped_ I could use an RPZ to say: privatelink.MS.net IN NS 127.0.0.1 My monitoring system would query DNS, find the SOA (from the real authorities) and an NS (from my RPZ) and go away happy. I recognize that the correct answer is to convince MS to correctly publish their private zones. But after a couple of decades of working with products from Major Software, I have more confidence I'll score on the next Powerball than they will acknowledge the deficiency (let alone consider correcting it). -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ Please 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
RPZ rule to apply to NS record requests?
If I have a Reverse Policy Zone (RPZ) defined, I can define a specific answer to be sent for a specific record-type for a specific name: foo.bar.com IN A 10.11.12.13 foo.bar.com IN TXT "Hello World" But I can't seen to define one for the record-type NS Is this possible? -- -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ Please 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: acl type construct for update-policy
On 11/10/2021 6:25 AM, Giddings, Bret wrote: Is there any other facility for including effectively the same grant statements within multiple zones? I am not aware of any -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ Please 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: named service suddenly fails to start
On 11/4/2021 11:27 AM, Bruce Johnson via bind-users wrote: named-checkconf -z revealed a name had been entered with underscores. The person responsible has been sacked. (not really, merely reminded no underscores are allowed in A records :-) Sounds to me like you might want to incorporate some validity checks into your edit/deploy process. -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ Please 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: Switching key types for authorizing updates
On 8/12/2021 5:00 AM, Tony Finch wrote: i.e. using the "subdomain" rule type instead of "selfsub", so the domain name (second foo...) doesn't need to match the keyname (first foo...) Yes, indeed. That's the ticket. Thank you very much, Tony. -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ Please 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
Switching key types for authorizing updates
I have a zone defined in which I permit dynamic updates. Many years ago,
I defined a key per name, and added that key into the update-policy
attribute in the zone definition.
For example:
key "foo.bar.baz.com" {
algorithm hmac-md5;
secret "12345..890";
};
zone "bar.baz.com" {
type master;
update-policy {
grant "foo.bar.baz.com" selfsub foo.bar.baz.com TXT;
};
};
The theory being, the holder of the key named "foo.bar.baz.com" is able
to manipulate TXT records in foo.bar.baz.com and all of its subdomains.
But now I'd like to move away from those old md5 keys. I would like to
find a way to define a second key which will work along side, during the
transition, the existing md5 key. When everyone is using the new key,
I'd then remove the old md5 key.
But as far as I can tell, the name of the key needs to match the
hostname in the update-policy statement. I can define a new aes-256 key,
but it can't have the name "foo.bar.baz.com" while the current md5 key
is defined. Nor can I find a way to craft an update-policy statement
line to let a new key with a different name manipulate the desired TXT
records, while letting the current key continue to work.
Is there a way to get the configuration I want? or must I make a
wholesale swap of each md5 key for something newer?
--
--
Do things because you should, not just because you can.
John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
___
Please 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: Only zones with wildcards affected on authoritative servers
On 6/17/2021 11:03 PM, Ondřej Surý wrote: # Are the ISC packages affected? The packages with the hotfix applied were pushed into the repository and are either already built or are building and will be available shortly The Ubuntu and Centos Copr packages are showing different version numbers, though I suspect they both contain the updated code. Can someone confirm my suspicion? The CentOS 8 Copr went from 9.16.17-1.1.el8 to 9.16.17-1.2.el8 While the Ubuntu "Personal Package Archive" ppa:isc/bind went from 9.16.17-1 to 9.16.18-1 from 'named -v' the two return BIND 9.16.17 (Stable Release) BIND 9.16.18-Ubuntu (Stable Release) -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ Please 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
Limit actions on control channel?
I see I can define (using the 'controls' statement) a 'read-only' inet channel. I suspect I could define a couple of channels on the same address if I put them on different ports. Is there a way to define a single 'read-write' channel, and then limit certain keys to read-only access on it? Here's the scenario: I'd like to have a single control channel listening (on port 953, for example). I'd like to say the key named "foo" can do lots of things, but the key named "bar" can only submit a "status" message. This would let our monitoring application ask for "status" without also letting it ask for "reload" or "flushname". -- -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ Please 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: Syslog with BIND on CentOS
On 5/20/2021 2:17 PM, Anand Buddhdev wrote: You could also log directly to files (bypassing syslog), and then have some process follow the files and send the logs to a remote server. This seems rather inefficient, but there are established and flexible tools to do just this. Without changing the configuration of my named (which is currently logging to a local file), I can make rsyslogd consider that file an input source. Once in, the parsing and output modules can then work on it. This relies on the input module "imfile", and the output module "omfwd" https://rsyslog-doc.readthedocs.io/en/latest/configuration/modules/idx_input.html imfile appears to follow log rotations cleanly. A limitation I see is everything is assigned the same syslog facility.priority values. It remains to be seen if this process can keep up with the query volume. Warning: When started for the first time, imfile will read the existing file and start forwarding. If the query log already contains 800MB of lines, those will all be read in and passed through the parser and output modules. -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ Please 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
Syslog with BIND on CentOS
Many years ago, when we ran ISC BIND on Solaris, we created a logging channel to send the logged-queries to the local syslogd. We then had our local syslogd forward most of the traffic on to a central syslog server. I just tried to re-implement something like that on CentOS, and thought I had it working . . until it was exposed to full production traffic load. The output to our central syslog server was truncated, and my local system log was filled with messages saying jourald was activating ratelimiting. !? My subsequent read of the docs indicates that BIND on CentOS 7, while being told it is sending to 'syslogd', is sending to 'journald' which is handling all the messages and forwarding them on to 'syslogd'. I don't want journald handling my thousands of messages per second from BIND. I don't want that information in my journal logs. I just want it out in the central syslog server. Is there some direct way to get the logging channel of BIND pointed directly into the local syslogd? (which would then apply its forwarding rules to get traffic to the central syslog server) I thought about trying to rip jourald out entirely, and quickly decided that was a path to madness. The only thing I can come up with is to activate dnstap, and have some other process absorbing the data and spewing it directly to the central syslogd. -- -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ Please 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: rndc stops listening
I now see this same behavior running BIND 9.16.12 on Ubuntu
I have never seen it on my instances running 9.11.x on Centos
I'd sure like to figure out why (or even when) it stops listening on
port 953. Does anyone have any suggestions?
--
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 12/11/2020 11:13 AM, John Thurston wrote:
Running BIND 9.16.9 on CentOS 8
I have the following in my .conf
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "mykey"; };
inet 10.2.0.1 port 953
allow { 10.2.3.3; 10.2.4.3; }
keys { "threekey"; "fourkey"; };
};
And I normally can see the named process is listening on tcp:953 on both
127.0.0.1 and 10.2.0.1. But sometimes later, I find it listening only
on 127.0.0.1. If I do an 'rndc reconfig', it starts listening again on
both addresses. Normal DNS service has continued uninterrupted.
I can't find footprints left from anything falling down. I'd could just
install a watchdog to 'reconfig' whenever port 953 stops answering, but
I'd rather figure out why it is stopping and correct the problem. To do
that, I need more information.
Am I not looking in the correct log?
Do I need to crank up the logging level for something?
If so, for what? and how high?
___
Please 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: replication time for dynamic records from primary to secondary servers
On 3/30/2021 12:30 PM, Cuttler, Brian R (HEALTH) via bind-users wrote: We are seeing a delay in the primary DNS server updating the secondary and would like to shorten that interval. Can you post the pertinent bits of your primary's and secondary's config for the zone? In the absence of that, I pose a few questions: How long is it taking now? What is your target interval? Do you have NOTIFY enabled on the primary? How large is the zone? If you look in the log, do you see XFRs queuing? How many secondaries are there? Do you have limits defined on the number of simultaneous transfers? -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ Please 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
BIND 9.16.10 launchpad package for Ubuntu ?
I'm exploring Ubuntu as a possible platform, and have been eyeing the ISC-offered packages at launchpad.net: https://launchpad.net/~isc The most recent build I see in the standard path is 9.16.9 (Nov 26, 2020). In the ESV path, I see 9.11.26 (Dec 16, 2020) 9.16.10 was released Dec 16, 2020 and appeared in the COPR releases (for CentOS/RHEL) the next day. If I'm reading the footprints at launchpad correctly, I don't see any failed builds for 9.16.10. Is there a reason it isn't out there? Can we expect it to be built and published at launchpad.net sometime? -- -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ Please 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
BIND through COPR after CentOS
We have been using the ISC COPR packages for BIND on CentOS. With the demise of CentOS, we (along with a few other people on the planet) need to consider where we will move our applications. We have been completely happy with the packages provided by ISC through COPR. Does anyone want to offer up other linux distributions on which they have had unqualified success with these same packages? -- -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ Please 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
rndc stops listening
Running BIND 9.16.9 on CentOS 8
I have the following in my .conf
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "mykey"; };
inet 10.2.0.1 port 953
allow { 10.2.3.3; 10.2.4.3; }
keys { "threekey"; "fourkey"; };
};
And I normally can see the named process is listening on tcp:953 on both
127.0.0.1 and 10.2.0.1. But sometimes later, I find it listening only
on 127.0.0.1. If I do an 'rndc reconfig', it starts listening again on
both addresses. Normal DNS service has continued uninterrupted.
I can't find footprints left from anything falling down. I'd could just
install a watchdog to 'reconfig' whenever port 953 stops answering, but
I'd rather figure out why it is stopping and correct the problem. To do
that, I need more information.
Am I not looking in the correct log?
Do I need to crank up the logging level for something?
If so, for what? and how high?
--
--
Do things because you should, not just because you can.
John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
___
Please 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: getting a later-version of BIND on various linux OS's
On 11/8/2020 10:18 PM, Rob McEwen wrote: is there an */easier/simpler/* way to get the most common linux operating systems (Debian, Ubuntu, CentOs, etc) - to a later version of BIND - beyond what auto-installs when you issue a command like "apt-get install bind9" - but /without/ having to download and compile the source code? Please take a look at the ISC "Software Collection": https://copr.fedorainfracloud.org/coprs/isc/ We use those packages with CentOS 7 and 8 to deliver ISC BIND 9.11 and 9.16. -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ Please 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
"in-view" behavior
I need to define several views. They will be largely identical, probably
differing in only one zone definition. What I had hoped to do was define
all the common zones in an unused-view, and then use "in-view" to
reference the several zones in the other views.
view "initial" { {match-clients "none"; };
zone foo { . . .};
zone bar { . . .};
};
view "v1" { {match-clients key v1-key; };
allow-transfer { key v1-key; };
zone foo { in-view initial; };
zone bar { in-view initial; };
zone baz { . . .};
};
I had expected the zones foo and bar to be shared from a single instance
in memory, that BIND would use the match-client to get the traffic to
the appropriate view, and then use that view's allow-transfer list. But
the behavior I'm observing is the allow-transfer of view v1 isn't being
used.
When I use:
rndc zonestatus bar IN v1
I can see the zone is defined on the primary. But when I try to transfer
it to the secondary using the v1-key, the request is REFUSED.
When I stuff the allow-transfer line from the "v1" view into the
"initial" view, the transfer initiated with v1-key succeeds.
I had been thinking of "allow-transfer" to be a property of a _view_,
but it now appears it may be assigned as a property to the _zones_
defined in that view.
So my specific questions are:
A) When I reference a zone with "in-view", can any properties be
superseded?
B) If so, which properties?
(FWIW, BIND version 9.11.24 on the primary and 9.16.8 on the secondary.)
--
--
Do things because you should, not just because you can.
John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
___
Please 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
9.11 -> 9.16 via COPR
We're happily running the BIND 9.11 ESV on CentOS 7 by way of: isc-bind-esv/x86_64 Copr repo for bind-esv owned by isc The roadmap I recall indicates 9.11 will move to "security only" updates at the end of 2020, at which time 9.16 is slated to become the ESV. I figure it is time for me to get a 9.16 instance running and see what will be involved in making it work for us. My questions are two: A) How will the upcoming change in ESV-designation appear to users of the COPR packages? Will there come a time when the repository/package "isc-bind-esv" will just deliver 9.16 rather than 9.11? B) If I have a host currently using "isc-bind-esv/x86_64", and I want it instead to use "isc-bind/x86_64", what's the suggested process? Do I "yum remove", replace the "bind-esv" repository with "bind", and "yum install"? Is it simpler than that? -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ Please 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: Request for review of performance advice
On 7/7/2020 5:57 PM, Victoria Risk wrote: A while ago we created a KB article with tips on how to improve your performance with our Kea dhcp server. The tips were fairly obvious to our developers and this was pretty successful. We would like to do something similar for BIND, provide a dozen or so tips for how to maximize your throughput with BIND. However, as usual, everything is more complicated with BIND. This is an excellent idea. If it comes to fruition, I ask there be some guidance offered on when such optimizations are useful. I've seen places where such a guide-sheet is followed when the guidelines were suitable for a business with 10X or 100X the traffic the customer sees. That is, a configuration which benefits an organization seeing 100,000 qps may be excessively complex (or brittle) for one seeing 100 qps. -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska Can those of you who care about performance, who have worked to improve your performance, share some of your suggestions that have the most impact? Please also comment if you think any of these ideas below are stupid or dangerous. I have combined advice for resolvers and for authoritative servers, I hope it is clear which is which... The ideas we have fall into four general categories: System design 1a) Use a load balancerto specialize your resolvers and maximize your cache hit ratio. A load balancer is traditionally designed to spread the traffic out evenly among a pool of servers, but it can also be used to concentrate related queries on one server to make its cache as hot as possible. For example, if all queries for domains in .info are sent to one server in a pool, there is a better chance that an answer will be in the cache there. 1b) If you have a large authoritative system with many servers, consider dedicating some machines to propagate transfers. These machines, called transfer servers, would not answer client queries, but just send notifies and process IXFR requests. 1c) Deploy ghost secondaries. If you store copies of authoritative zones on resolvers (resolvers as undelegated secondaries), you can avoid querying those authoritative zones. The most obvious uses of this would be mirroring the root zone locally or mirroring your own authoritative zones on your resolver. we have other system design ideas that we suspect would help, but we are not sure, so I will wait to see if anyone suggests them. OS settings and the system environment 2a) Run on bare metal if possible, not on virtual machines or in the cloud. (any idea how much difference this makes? the only reference we can cite is pretty out of date - https://indico.dns-oarc.net/event/19/contributions/234/attachments/217/411/DNS_perf_OARC_Apr_14.pdf <https://urldefense.com/v3/__https://indico.dns-oarc.net/event/19/contributions/234/attachments/217/411/DNS_perf_OARC_Apr_14.pdf__;!!J2_8gdp6gZQ!7sRXGLQDm9waSVfgufc44e2-G1iYoLGoT_iBOLgmPYx3xAW8jKIAFbCB5OVJYYfEBpbu8w$> ) 2b) Consider using with-tuning-large. (https://kb.isc.org/docs/aa-01314 <https://urldefense.com/v3/__https://kb.isc.org/docs/aa-01314__;!!J2_8gdp6gZQ!7sRXGLQDm9waSVfgufc44e2-G1iYoLGoT_iBOLgmPYx3xAW8jKIAFbCB5OVJYYdvKmJFZQ$>) This is a compile time option, so not something you can switch on and off during production. 2c) Consider which R/W lock choice you want to use - https://kb.isc.org/docs/choosing-a-read-write-lock-implementation-to-use-with-named <https://urldefense.com/v3/__https://kb.isc.org/docs/choosing-a-read-write-lock-implementation-to-use-with-named__;!!J2_8gdp6gZQ!7sRXGLQDm9waSVfgufc44e2-G1iYoLGoT_iBOLgmPYx3xAW8jKIAFbCB5OVJYYftHIt-qg$> For the highest tested query rates (> 100,000 queries per second), pthreads read-write locks with hyper-threading /enabled/seem to be the best-performing choice by far. 2d) Pay attention to your choice of NIC cards. We have found wide variations in their performance. (Can anyone suggest what specifically to look for?) 2e) Make sure your socket send buffers are big enough. (not sure if this is obsolete advice, do we need to tell people how to tell if their buffers are causing delays?) 2f) When the number of CPUs is very large (32 or more), the increase in UDP listeners may not provide any performance improvement and might actually reduce throughput slightly due to the overhead of the additional structures and tasks. We suggest trying different values of -U to find the optimal one for your production environment. named Features 3a) Minimize logging. Query logging is expensive (can cost you 20% or more of your throughput) so don’t do it unless you are using the logs for something. Logging with dnstap is lower impact, but still fairly expensive. Don’t run in debug mode unless necessary. 3b) Use named.conf option minimal-responses yes; to reduce the amount of
Re: Log rolling stopped working in 9.11.12 ?
On 11/19/2019 8:34 AM, Reindl Harald wrote: Am 19.11.19 um 18:23 schrieb John Thurston: A) Should I expect these file permissions be altered by a minor update? I know I started at 9.11.8 and have updated to 9.11.9 and 9.11.10 without seeing this behavior. yes, every by a package owned directory or file has it's permissions in the rpm database and they are ensured everytime a package get updated I am certain I didn't need to reapply those file permissions with my earlier version updates. But if this is the expected behavior with each update, then that experience was an outlier. I will explore relocating my logs to a location not affected by package updates. Thank you for the information and insight. which is why we don't need to reinstall our Linux boxes all the time when things become messy over the years I find this somewhat humorous I have recently started using linux. I am amazed how often the operating system changes radically, and how short the support windows are . . . when compared to the Solaris environment we are turning off. -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Log rolling stopped working in 9.11.12 ?
Thank you for the obvious suggestion, Mark. It hadn't occurred to me that a yum update might have clobbered my existing permissions. Sure enough, there it was - 755 root:root /var/opt/isc/isc-bind/log/ Everything in that directory was still - 644 named:named but the user "named" was unable to create anything new Looking at my installation notes from earlier this year, I found the following: Adjust the log directory permissions. chown named:named /var/opt/isc/isc-bind/log chmod 775 /var/opt/isc/isc-bind/log I have re-applied that permission change, and things are happy again. Which brings me to two follow-up questions. A) Should I expect these file permissions be altered by a minor update? I know I started at 9.11.8 and have updated to 9.11.9 and 9.11.10 without seeing this behavior. B) Should I not be logging to /var/opt/isc/isc-bind/log? The log path in my named.conf is currently set to a relative path "../../log/query.log", but I could easily change it to an absolute path "/var/log/named/query.log" -- 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 11/18/2019 6:49 PM, Mark Andrews wrote: There have been no changes. I would be checking directory permissions. Anything that would stop rename() succeeding. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Log rolling stopped working in 9.11.12 ?
I recently updated from 9.11.10 to 9.11.12 with the ISC-provided package for CentOS 7. Everything looked ok, until today when my monitoring application told me I was running out of disk space. ACK! Log rolling on my servers stopped. My named.conf has lines like: file "query.log" versions 10 size 1000m; In my directory, I have: query.log.9 query.log.8 query.log.7 query.log.6 query.log.5 query.log.4 query.log.3 query.log.2 query.log.1 query.log.0 query.log Log numbers 0-9 are 1001M (as expected). The current log is 28G and growing :( I've looked over the BIND release notes and don't see anything about a change to the logging behavior. Did I miss something? Or maybe some kernel (or other package) patch broke some dependency? I'm looking for ideas here. -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Status of experimental COPR packages
On 9/6/2019 12:10 PM, Victoria Risk wrote: I really like what I'm seeing with the COPR distribution: https://copr.fedorainfracloud.org/coprs/isc/ The description there still states "..USE AT YOUR OWN RISK.” John- Do you still see those messages? I don’t see them. I thought I removed all those comments about ‘experimental’ and ‘use at your own risk’ a while ago. No I don't . . . now that you call my attention to it. I had guessed there would be an announcement on the blog, or to the announce-list if its status had changed. Obviously, that wasn't a valid assumption. We did recently start setting up another site, Cloudsmith.io, for some of our packages. We need a site we can control for non-public stuff, like the BIND subscription edition, and private patches, and Cloudsmith allows us to put packages for multiple different OSes in one repo. I need to find out whether we plan to continue updating the COPR site or not. I think we do,(because of course it is easier to ‘find’ than Cloudsmith) but we haven’t discussed it explicitly. Which makes it sound like the future of the COPR distribution isn't yet clear. This is a pretty important topic to us, and I'd welcome any information you can offer. I'm not trying to drive your product offerings, just trying to divine which way the wind is blowing. From my perspective, I'm quite pleased with how the COPR distribution is working out. It was only a little bit of work to make the "software collection" concept meet our needs, and I'd dearly like to be able to consider it stable. -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Status of experimental COPR packages
Back in Sept, 2018 we got word of packages published by ISC for a few common linux distributions. https://www.isc.org/blogs/bind-9-packages/ There have been a couple of trickles of news on this mailing list since then. I'm interested in the prospects, plans, etc for these packages. I really like what I'm seeing with the COPR distribution: https://copr.fedorainfracloud.org/coprs/isc/ The description there still states "..USE AT YOUR OWN RISK." I see the August update to 9.11.10 is available there. Where do I go to learn the planned path for this? Are there plans to stabilize it? Are there outstanding feature requests to be addressed? Is there a timeline somewhere? -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Exempt .local from dnssec validation on resolver?
For historical reasons we have some forward-zones defined on our
resolver (v9.11.9). For example:
zone foo.local {type forward; forwarders { 10.1.2.3; };
zone bar.local {type forward; forwarders { 10.4.5.6; };
These are obviously invalid TLDs, and are defined on servers over which
I have no influence or control. The difficulty is if my named.conf contains:
dnssec-validation auto;
then I'm unable to return records for things like a.foo.local, and my
log contains info-messages of the sort:
---
lame-servers: info: insecurity proof failed resolving
'foo.local/SOA/IN': 10.1.2.3#53
dnssec: info: validating foo.local/SOA: got insecure response; parent
indicates it should be secure
---
Is there any way to tell my resolver it shouldn't be validating
responses for foo.local?
Or must I assert authority over .local and delegate authority for 'foo'
and 'bar' back to the servers which are already answering for them?
--
Do things because you should, not just because you can.
John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Status of experimental packages
Back in Sept, 2018 we got word of packages published by ISC for a few common linux distributions. https://www.isc.org/blogs/bind-9-packages/ There have been a couple of trickles of news on this mailing list since then. I'm interested in the prospects, plans, etc for these packages. I really like what I'm seeing with the COPR distribution: https://copr.fedorainfracloud.org/coprs/isc/ The description there still states "..USE AT YOUR OWN RISK." Where do I go to learn the planned path for this? Are there plans to stabilize it? Are there outstanding feature requests to be addressed? Is there a timeline somewhere? -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
factor addresses out of 'forwarders' statement
I have a number of 'forward' zones defined. Many of them look exactly
the same except for their name. It would be helpful to abstract the
addresses of my forwarders out and name them only once. But I can't find
any way to do this.
An ACL doesn't make sense. A 'masters' list doesn't work.
Is there some way to do this?
alias { 10.10.1.2; 10.10.3.4; 10.10.5.6; }
zone "foo" {type forward; forwarders ( alias;}; };
--
Do things because you should, not just because you can.
John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
rndc - sync before reload?
On a server with both static and dynamic zones, is there any reason to perform an: rndc sync prior to issuing an: rndc reload -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A policy for removing named.conf options.
On 6/13/2019 4:37 AM, Lightner, Jeffrey wrote: I'd suggest also giving warnings for deprecated options when running named-checkconf (and named-checkzone if applicable). You mention the logs but not the commands. Jeffrey C. Lightner Sr. UNIX/Linux Administrator I hope this is implemented in named-checkconf/zone. It would also be nice to include some sort of option on named-checkconf to 'whitelist' or ignore the deprecation warnings, as I use named-checkconf two different ways. When I'm setting up a server, or making a configuration change, I use it interactively. In this case, I would love to know if an option I'm trying to use is going away. I have automated deployment processes which call named-checkconf. In most of these cases, I only need to know that my .conf is valid even if it isn't optimal. I'll uncover the warnings with my next interactive work, but I don't want my automated processes to stop working because something will be going away at some point in the near future. -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Preferred log location with ISC copr package
On 5/21/2019 5:08 AM, Michał Kępień wrote: A directory was created as part of the package installation: /var/opt/isc/isc-bind/log/ Correct, this directory is a part of the standard Software Collection runtime which is created at package build time according to macros provided by Red Hat. Since I'm new the "Software Collection" paradigm, I don't know if this is an acceptable location for my operational logs. It is as acceptable as any other location to which named has write access. The default path I mentioned above is set up automatically upon package installation; if you would like to log to a different file, you will have to take care of ensuring proper filesystem permissions and SELinux labelling yourself. You can also consider logging to a syslog daemon and configuring it to your liking as an alternative to logging directly to a file. I did a fresh installation from isc/bind-esv onto CentOS 7. It doesn't look to me like the permissions on the log directory were set correctly. drwxr-xr-x. 2 root root 6 May 15 23:29 /var/opt/isc/isc-bind/log drwxr-x---. 3 root named 18 May 20 15:01 /var/opt/isc/isc-bind/named drwxrwx---. 2 named named 77 May 20 15:52 /var/opt/isc/isc-bind/named/data The helpful suggestion above had me expecting the log directory would be set similar to the named/data directory, with write permissions for the process UID. My follow-up question is: Should the package installation have set different owner:group and permissions on /var/opt/isc/isc-bind/log? -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Preferred log location with ISC copr package
I'm considering changing one of my BIND installations to use the experimental ISC-provided packages: https://www.isc.org/blogs/bind-9-packages/ With these packages, what it the recommended location for log files? A directory was created as part of the package installation: /var/opt/isc/isc-bind/log/ Since I'm new the "Software Collection" paradigm, I don't know if this is an acceptable location for my operational logs. Is that location going to get trashed when I install the next update? -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
