Re: understanding keymgr handling of KSK
I found this message: May 8 16:41:18 tilapia named[1268]: zone ox.org/IN: zone_rekey:dns_dnssec_keymgr failed: error occurred writing key to disk It would be great if it could tell me the file name that failed to write, and ideally what the error was (EPERM is my guess, but there could also be AppArmor stupids for some people which are really hard to diagnose). Is there a way to put all the keymgr logging into a different debug stream? Ideally, I think I need it emailed to me daily :-) -- 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
understanding keymgr handling of KSK
I have moved from dnssec-tools to having bind9 do all the management itself. There are a couple of things that I don't understand, and I find that the FAQs and howtos I've read are rather too introductory for me. I have been signing my zones since around 2004... I will attempt to blog some of my experiences, but I'm a bit lost. I keep my zones in /etc/domain/foo.com/db.foo.com, usually a few zones in "foo.com" related to foo.com, like foo.net, reverses... and I allow Debian's etckeeper to track changes there. etckeeper is mostly very nice, but there is some interaction among tools that sometimes winds up with my zone files getting truncated to zero. But, it being git, one can keep extra copies. I haven't caught it in the act yet. Probably I should change the key-directory to be a different directory, because maybe letting etckeeper do stuff with keys is a bad idea. (I'm more concerned about keys getting lost due to VMs going bad that I am about keys getting disclosed because I git cloned the repo to my laptop. You may feel different about security, good for you) 1) I'm unclear about freeze/thaw and signing and editing. I prefer to edit my zones with vi/emacs/sshfs/tramp. For that reason, I have them g+w, group bind, and my login is in the "bind" group, and my user id can rndc reload. 2) I've historically had a perl script that updated the SERIAL in place, based upon MMDDLL, where XX was Hour*4 + minutes/15. And LL was always maintained as > than last time. https://www.sandelman.ca/tmp/updateser you care. 3) I have a very few dynamic zones which are updated by DNS update. I have basically CNAME'ed all my dns-01 LetsEncrypt challenges into a single zone that I allow to completely dynamically managed. 4) I don't understand the difference between "auto-dnssec maintain;" and "dnssec-policy default" (given that I haven't overridden anything). 5) Did $INCLUDE change such that it no longer accepts path names relative to the zone file that included it? (no, not really DNSSEC related, but maybe bind 9.11 vs bind 9.16 changes) 6) Sometime yesterday (or maybe Friday night) many of my zones went offline: tuna-[~] lmcr 10002 %dig @8.8.8.8 list.goslingcommunity.org ; <<>> DiG 9.11.5-P4-5.1+deb10u6-Debian <<>> @8.8.8.8 list.goslingcommunity.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 45108 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 looks like failure to find the right keys. I investigated, and the first thing I did was "rndc reload", and magically everything started working again. No idea what happened. I poke around and I look at one of the state files: tilapia-[/etc/domain/brski.org] mcr 10010 %cat Krfc8995.org.+013+65171.state ; This is the state of key 65171, for rfc8995.org. Algorithm: 13 Length: 256 KSK: yes ZSK: no Generated: 20210503023712 (Sun May 2 22:37:12 2021) Published: 20210503023712 (Sun May 2 22:37:12 2021) Active: 20210503023712 (Sun May 2 22:37:12 2021) Retired: 20220505221112 (Thu May 5 18:11:12 2022) Removed: 20220507001112 (Fri May 6 20:11:12 2022)<<< SURPRISING!!! DNSKEYChange: 20220505221612 (Thu May 5 18:16:12 2022) ZRRSIGChange: 20220506231836 (Fri May 6 19:18:36 2022) KRRSIGChange: 20220505221612 (Thu May 5 18:16:12 2022) DSChange: 20220505221112 (Thu May 5 18:11:12 2022) DNSKEYState: hidden ZRRSIGState: hidden KRRSIGState: hidden DSState: hidden GoalState: hidden okay, let's go look at the one that I had the servfail for: tilapia-[/etc/domain/goslingcommunity.org] mcr 10029 %cat Kgoslingcommunity.org.+005+05881.state ; This is the state of key 5881, for goslingcommunity.org. Algorithm: 5 Length: 2048 KSK: yes ZSK: no Generated: 20190808220317 (Thu Aug 8 18:03:17 2019) Published: 20190808220317 (Thu Aug 8 18:03:17 2019) Active: 20190808220317 (Thu Aug 8 18:03:17 2019) Retired: 20220505221645 (Thu May 5 18:16:45 2022) Removed: 20220507001645 (Fri May 6 20:16:45 2022) DNSKEYChange: 20220505222145 (Thu May 5 18:21:45 2022) ZRRSIGChange: 20220506232645 (Fri May 6 19:26:45 2022) KRRSIGChange: 20220505222145 (Thu May 5 18:21:45 2022) DSChange: 20220505221645 (Thu May 5 18:16:45 2022) DNSKEYState: hidden ZRRSIGState: hidden KRRSIGState: hidden DSState: hidden GoalState: hidden Some surprising things here. The key was generated ages ago, great. It was removed on Friday evening what? But, it's a KSK. To update it, I need to visit my registrar and update things. AFAIK, I'm not doing CDS (I'd like to, but I don't know how, and I don't know if .org is doing it). tilapia-[/etc/domain/goslingcommunity.org] mcr 10034 %dig +short @a0.org.afilias-nst.org. goslingcommunity.org. ds 5881 5 1 64E6DE566F8F3E33B83FCF51DDE6746872E51432 5881 5 2 5F7C3229244CFE80835B1FCAE94BE8ED2CF26D31942E1628C3D1E7A9 A026535A No change in the key at .org, and I checked and I don't have a CDS published. So what happened? I shall troll my logs and see
Re: Determining Which Authoritative Sever to Use (Bob McDonald)
On the closest server question it will prefer the closest but a certain percentage will go to servers further away. Additionally depending on the version of BIND and the distance it could lead to the servers further away taking more traffic in high QPS situations. If you are getting high QPS you could fire off a large amount of queries to the "slower" server before it responds and resets its SRTT. I believe newer BIND versions have moved away from a static decrement value and has fixed the issue but even fixes some queries will go out of region. On Sun, May 8, 2022, 12:47 PM Bob McDonald wrote: > Thanks for the answers. A couple more questions and then I'll stand down. > > First, it's Ben Croswell. Just pointing that out. > > Second, my reading of the definition of a static-stub zone in the Bvarm > indicates that its use is to allow a local copy of the NS list which may > differ from the primary zone. I'm not sure that's what I'm looking for. I > think I'm ok with the NS list from the primary zone. Lei me take another > swing and try to be a bit more pedantic to see if that helps. > > I wish to define a global internal DNS environment. > > At the level closest to the client would be a global network of recursive > DNS servers which would handle all internal and external DNS requests. The > internal DNS zones would be housed on a global network of authoritative > only DNS servers. The NS list for the internal DNS zones on these > authoritative only servers would be known to the recursive servers via stub > zones. My question is, if a client in Mumbai submits a DNS request to his > local recursive server for an internal authoritative only zone defined by a > stub zone statement, which authoritative only server does the recursive > server pick from the NS list and will that eventually be the "closest" > server. I'm assuming a global distribution of the authoritative servers. > E.g. Hong Kong, London, US East, US West, South Amer, etc. The use of the > stub zones in this case is to eliminate the need for an internal root. I > want to avoid lookups for example from clients in Asia being sent to > authoritative only servers in South Amer. > > Bob > -- > 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: Determining Which Authoritative Sever to Use (Bob McDonald)
Thanks for the answers. A couple more questions and then I'll stand down. First, it's Ben Croswell. Just pointing that out. Second, my reading of the definition of a static-stub zone in the Bvarm indicates that its use is to allow a local copy of the NS list which may differ from the primary zone. I'm not sure that's what I'm looking for. I think I'm ok with the NS list from the primary zone. Lei me take another swing and try to be a bit more pedantic to see if that helps. I wish to define a global internal DNS environment. At the level closest to the client would be a global network of recursive DNS servers which would handle all internal and external DNS requests. The internal DNS zones would be housed on a global network of authoritative only DNS servers. The NS list for the internal DNS zones on these authoritative only servers would be known to the recursive servers via stub zones. My question is, if a client in Mumbai submits a DNS request to his local recursive server for an internal authoritative only zone defined by a stub zone statement, which authoritative only server does the recursive server pick from the NS list and will that eventually be the "closest" server. I'm assuming a global distribution of the authoritative servers. E.g. Hong Kong, London, US East, US West, South Amer, etc. The use of the stub zones in this case is to eliminate the need for an internal root. I want to avoid lookups for example from clients in Asia being sent to authoritative only servers in South Amer. Bob -- 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: Determining Which Authoritative Sever to Use
I would concur that internally Anycast is best for client facing edge nodes to reduce client configuration complexity as well as reducing impact of a first resolver outage. On Sun, May 8, 2022, 7:59 AM Tony Finch wrote: > Bob McDonald wrote: > > > > My question is this; how do the recursive servers determine from > > the information in the stub zone which name server to query? > > As well as what Bob Croswell said about SRTT (which is entirely correct), > there's a subtlety with stub zones in particular. > > A stub zone works a bit like the root zone hints, in that the name servers > that you configure are just used to find the zone's NS records. This means > that stub zones don't override where queries are routed for these zones. > If you want your resolver to ignore the NS records on your internal zones, > you should use static-stub instead. > > Regarding anycast, it isn't necessary for internal authoritative servers > unless your organization is really huge (and probably not even then): it > is simpler to just use the DNS's standard reliabilty features. All you > need to do is have more than one authoritative server for each zone. > On the other hand, anycast is a good way to improve the availability and > maintainability of your resolvers, because your users' devices talk > directly to them, and if they don't work there might as well not be an > Internet connection. > > -- > Tony Finch(he/they) Cambridge, England > Selsey Bill to Lyme Regis: East or southeast, veering south later, 2 > to 4. Smooth or slight, occasionally moderate for a time offshore. > Fair. Good. > -- > 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: Determining Which Authoritative Sever to Use
Bob McDonald wrote: > > My question is this; how do the recursive servers determine from > the information in the stub zone which name server to query? As well as what Bob Croswell said about SRTT (which is entirely correct), there's a subtlety with stub zones in particular. A stub zone works a bit like the root zone hints, in that the name servers that you configure are just used to find the zone's NS records. This means that stub zones don't override where queries are routed for these zones. If you want your resolver to ignore the NS records on your internal zones, you should use static-stub instead. Regarding anycast, it isn't necessary for internal authoritative servers unless your organization is really huge (and probably not even then): it is simpler to just use the DNS's standard reliabilty features. All you need to do is have more than one authoritative server for each zone. On the other hand, anycast is a good way to improve the availability and maintainability of your resolvers, because your users' devices talk directly to them, and if they don't work there might as well not be an Internet connection. -- Tony Finch(he/they) Cambridge, England Selsey Bill to Lyme Regis: East or southeast, veering south later, 2 to 4. Smooth or slight, occasionally moderate for a time offshore. Fair. Good. -- 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
