Only one DS key comes back in query

[frank picabia]

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 <marka at 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 <fpicabia at 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ý <ondrej at 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 <fpicabia at 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 at 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: marka at isc.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220519/8c0bf2ab/attachment.htm>