Thanks for this detailed information, Mark. I'll blame it on the antibiotics and old age but I had never noticed the key is actually complete in my dsset file if I don't interpret the space as a delimiter.
So there are two ways to get the DS keys: from the dsset file while ignoring the space between the two values of digest 2, or by using the dnssec-dsfromkey method while querying one's DNS server. My domain registrar has the values now and we're good. Thanks for the assistance. On Wed, May 18, 2022 at 2:16 PM Mark Andrews <ma...@isc.org> wrote: > I suspect that you failed to copy the complete second record or that the > registrar failed to handle the optional white space in the last field. > Without you posting the contents of the dsset file and what you passed to > the registrar there is no way to know. There is also no way to know if it > was miscomputed unless we have a copy of the DNSKEY it was generated from. > > example.com. IN DS 28387 5 1 47145FCABDFC00DD9CDE1369FA6A456F0D196C11 > example.com. IN DS 28387 5 2 > AC92037CEB08E7AF3539D140BC3855FA32AB0055973ABC7A4FB4A49C 385E7C29 > > The second record could be written like below and it would still be > correct. > > example.com. IN DS 28387 5 2 A C 9 2 0 3 7 C E B 0 8 E 7 A F 3 5 3 9 D 1 > 4 0 B C 3 8 5 5 F A 3 2 A B 0 0 5 5 9 7 3 A B C 7 A 4 F B 4 A 4 9 C 3 8 5 E > 7 C 2 9 > > As for how many records there are in the dsset file that has changed over > time. It started out as just type 1 (SHA1), then type 1 (SHA1) and type 2 > (SHA256), and more recently just type 2 (SHA256) as the DNSSEC standards > evolve based on changes in cryptographic best practice. DNSSEC is > approximately 20 years old now and computing capabilities have changed a > lot over that period. > > I know computers are not infallible but dnssec-signzone has been > generating dsset files for almost all of those 20 years now. We would be > getting thousands of reports of errors if it was mis-generating DS > records. Named itself needs to generate 10’s of thousands of DS records a > second to perform DNSSEC validations on a busy validator and > dnssec-signzone uses the same code to generate the DS records it prints out. > > Using ‘example’ is fine until something goes wrong or it is believed to > have gone wrong. At that point you need the actual real names. You don’t > go to your mechanic with a different car when you have a problem with your > car. Using ‘example’ is like doing that. > > Mark > > > > On 17 May 2022, at 04:41, frank picabia <fpica...@gmail.com> wrote: > > > > I've been using open source for decades. Long enough that I rarely need > to use lists for help. > > > > Here's the RFC mentioning reserved domain name use: > https://www.rfc-editor.org/rfc/rfc2606.html > > > > I am ridiculed by an ISC member for using a reserved domain according to > the purpose in the RFC and then > > a second ISC member states I am arrogant? I think there's a bunch of > you that need to check your privilege! > > Or maybe these persons are the chief whips responsible for driving > people from the lists into paying customers? > > > > Check other lists. Postfix. Apache. Whatever. No one ever has an > issue when they see example.com > > It's widely known as the boilerplate value you're leaving out of the > equation for the moment. > > > > In the documentation I see this: > > > > Once the rndc reconfig command is issued, BIND serves a signed zone. The > file dsset-example.com (created by dnssec-signzone when it signed the > example.com zone) contains the DS record for the zone’s KSK. You will > need to pass that to the administrator of the parent zone, to be placed in > the zone. > > > > It seems the first value in dsset file is okay. The documentation > doesn't talk about the second one, and this is where > > the problem is seen. I see one value on the second key (digest 2) in > dsset file, and a different value using the value > > obtained by running something like: > > > > dig @localhost dnskey irrashai.net | dnssec-dsfromkey -f – irrashai.net > > The digest 2 second key here seems to be what should be used with the > domain registrar. I'll soon find out. > > > > > > > > On Mon, May 16, 2022 at 2:54 PM Ondřej Surý <ond...@isc.org> wrote: > > Well, then don’t expect people will want to help you. If you need to > hide the information and you need help then you should be prepared to pay > for the support. Coming to open source list asking for help for free and > expect other people to help you is just plain arrogant behavior. Again, > Bert Hubert was exactly right here: > > > > https://berthub.eu/articles/posts/anonymous-help/ > > > > Ondrej > > -- > > Ondřej Surý — ISC (He/Him) > > > > My working hours and your working hours may be different. Please do not > feel obligated to reply outside your normal working hours. > > > >> On 16. 5. 2022, at 19:06, frank picabia <fpica...@gmail.com> wrote: > >> > >> Suppose I was working on a problem for Barclays > >> Bank, do you suppose they would be thrilled with me posting > >> their networking innards for the world to see? > > -- > > 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 > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > >
-- 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
