Re: Resolving and caching illegal names
Hi John. A few questions, if I may. - 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? Cheers, Greg On Tue, 24 Jan 2023 at 21:17, John Thurston wrote: > 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-8591john.thurs...@alaska.gov > Department of Administration > State of Alaska > > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Resolving and caching illegal names
Am 24.01.2023 um 12:15:58 Uhr schrieb John Thurston: > 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." Then Akamai is doing nasty things. Why don't they answer the correct answer . 3600IN SOA a.root-servers.net. nstld.verisign-grs.com. 2023012500 1800 900 604800 86400 and let applications fail that don't query PTR records in in-addr.apra/ip6.arpa? -- 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
I would be looking for packet loss and / or a bad firewall that is dropping fragmented packets which is triggering fallback to non EDNS requests If you are forwarding ensure that the entire forwarding chain is validating. -- Mark Andrews > On 25 Jan 2023, at 04:53, John Thurston wrote: > > > 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 -- 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 yes/no?
On Tue, Jan 24, 2023 at 04:48:34PM -, David Carvalho via bind-users wrote: > Hello. > > I hope someone could help to understand the following. > > I have "my.domain.pt" and a master and slave server for the "my" part. I > have been using "recursion yes" in both named.conf, as I want them to be > both authoritative and cache for my clients. > > Last week I migrated my slave DNS server to version 9.16 and only today, > after having issues with the primary server migration, I realized that for > most queries, my slave DNS does not answer the "ADDITIONAL SECTION" unless I > specify "+norec" with the dig command. You didn't mention what version you were upgrading from, but I guess 9.11, because the default setting of "minimal-responses" was changed in 9.12. It used to default to "no", but it now defaults to "no-auth-recursive". From the ARM: minimal-responses takes one of four values: - no: the server is as complete as possible when generating responses. - yes: the server only adds records to the authority and additional sections when such records are required by the DNS protocol (for example, when returning delegations or negative responses). This provides the best server performance but may result in more client queries. - no-auth: the server omits records from the authority section except when they are required, but it may still add records to the additional section. - no-auth-recursive: the same as no-auth when recursion is requested in the query (RD=1), or the same as no if recursion is not requested. no-auth and no-auth-recursive are useful when answering stub clients, which usually ignore the authority section. no-auth-recursive is meant for use in mixed-mode servers that handle both authoritative and recursive queries. So when recursion is requested in the query, the server omits the NS records from the authority section, and if there's no NS records then there won't need to be corresponding A or records in the additional section. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- 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 yes/no?
Hi David. "recursion yes;" tells named that it can (if it has to) make queries to other places if it needs more information in order to answer a client query. Pure authoritative servers shouldn't need it and should have "recursion no;". So the first question is, do your servers make queries out to other places? If so, recursion must be enabled. Secondly, do you have "minimal-responses" configured on either/both servers? If so, what is it set to? There were changes in 9.16 so maybe these explain your observations. Cheers, Greg On Tue, 24 Jan 2023 at 16:49, David Carvalho via bind-users < bind-users@lists.isc.org> wrote: > Hello. > > I hope someone could help to understand the following. > > I have “my.domain.pt” and a master and slave server for the “my” part. I > have been using “recursion yes” in both named.conf, as I want them to be > both authoritative and cache for my clients. > > Last week I migrated my slave DNS server to version 9.16 and only today, > after having issues with the primary server migration, I realized that for > most queries, my slave DNS does not answer the “ADDITIONAL SECTION” unless > I specify “+norec” with the dig command. > > > > My named.conf files only differ in IPs and “master/slave” setting. > > > > My questions: > > Should I use recursion on both? (Bear in mind that I also want them to > provide chache to clients) > > Why do I need “dig +norec” to get the exact output on my slave server? > > > > Kind regards > > David > -- > 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: 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
recursion yes/no?
Hello. I hope someone could help to understand the following. I have "my.domain.pt" and a master and slave server for the "my" part. I have been using "recursion yes" in both named.conf, as I want them to be both authoritative and cache for my clients. Last week I migrated my slave DNS server to version 9.16 and only today, after having issues with the primary server migration, I realized that for most queries, my slave DNS does not answer the "ADDITIONAL SECTION" unless I specify "+norec" with the dig command. My named.conf files only differ in IPs and "master/slave" setting. My questions: Should I use recursion on both? (Bear in mind that I also want them to provide chache to clients) Why do I need "dig +norec" to get the exact output on my slave server? Kind regards David -- 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
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. signature.asc Description: PGP signature -- 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: [KASP] Key rollover
Hello,
I don't why DSState: hidden, it's ok with some online check tools like :
- https://dnssec-analyzer.verisignlabs.com/
- https://zonemaster.net/fr/run-test
my master is hidden, it can be related ? How i can debug this DSState:
hidden ?
I found this command to check actual status : rndc dnssec -status **
This is the output :
key: 46358 (ECDSAP256SHA256), KSK
published: yes - since Tue Jan 17 17:55:03 2023
key signing:yes - since Tue Jan 17 17:55:03 2023
Next rollover scheduled on Tue Jan 24 17:55:03 2023
- goal: omnipresent
- dnskey: omnipresent
- ds: hidden
- key rrsig: omnipresent
...
Regards Adrien
Le mar. 24 janv. 2023 à 09:27, Matthijs Mekking a écrit :
> Hi Adrien,
>
> I don't think it is fine yet. I see in your state file the following line:
>
> > DSState: hidden
>
> This means the DS is not published according to BIND.
>
> > From my understanding, the second KSK should appear because I put the
> > parameter "publish-safety 3d;" that is to say 3 days before the
> > expiration ("retired") of the key in use. is that right?
>
> In addition to the DNSKEY TTL yes. The successor KSK should be
> pre-published the sum of dnskey-ttl, publish-safety, and
> zone-propagation-delay, prior to its retirement.
>
> Best regards,
>
> Matthijs
>
> On 1/24/23 09:08, adrien sipasseuth wrote:
> > Hello Matthijs,
> >
> > Indeed I had not published the DS at my registar because I thought that
> > the second KSK would have appeared anyway at the time of the rollover.
> >
> > I published the DS yesterday and I reported to BIND with the command you
> > gave me. I didn't find any error in the logs so everything must have
> > been fine!
> >
> > here is the state file of the KSK in use :
> > ; This is the state of key 46358, for ***.
> > Algorithm: 13
> > Length: 256
> > Lifetime: 604800
> > Predecessor: 28887
> > KSK: yes
> > ZSK: no
> > Generated: 20230117165503 (Tue Jan 17 17:55:03 2023)
> > Published: 20230117165503 (Tue Jan 17 17:55:03 2023)
> > Active: 20230120180003 (Fri Jan 20 19:00:03 2023)
> > Retired: 20230127180003 (Fri Jan 27 19:00:03 2023)
> > Removed: 20230131190003 (Tue Jan 31 20:00:03 2023)
> > DSPublish: 20230123081513 (Mon Jan 23 09:15:13 2023)
> > PublishCDS: 20230120180003 (Fri Jan 20 19:00:03 2023)
> > DNSKEYChange: 20230120180003 (Fri Jan 20 19:00:03 2023)
> > KRRSIGChange: 20230120180003 (Fri Jan 20 19:00:03 2023)
> > DSChange: 20230117165503 (Tue Jan 17 17:55:03 2023)
> > DNSKEYState: omnipresent
> > KRRSIGState: omnipresent
> > DSState: hidden
> > GoalState: omnipresent
> >
> > From my understanding, the second KSK should appear because I put the
> > parameter "publish-safety 3d;" that is to say 3 days before the
> > expiration ("retired") of the key in use. is that right?
> >
> > that is to say tonight at 7pm, I will see tomorrow if this one appears.
> >
> > regards, Adrien
> >
> >
> >
> > Le jeu. 19 janv. 2023 à 09:13, Matthijs Mekking > > a écrit :
> >
> > Hi Adrien,
> >
> > Without any logs or key **state** files, I can't really tell what is
> > going on.
> >
> > My only gut feeling is that you have never signaled BIND 9 that the
> DS
> > has been published. You can run 'rndc dnssec -checkds -key 12345
> > published example.com ' or set up
> > parental-agents to do it for you.
> >
> > Best regards,
> >
> > Matthijs
> >
> > On 1/17/23 09:38, adrien sipasseuth wrote:
> > > Hello,
> > >
> > > I put the management of DNSSEC with KASP, the zone is well
> > functional.
> > > (dig with "AD" flag etc)
> > >
> > > On the other hand, I can't see when the key rollover period for
> > my KSK
> > > is over (2 KSKs with a dig DNSKEY...)
> > >
> > > Without KASP, it was easy because I generated the second KSK key
> but
> > > with KASP, it is managed automatically.
> > >
> > > So, I have to adapt my scripts to check that there is :
> > > - a used KSK key and a next KSK key
> > > - Or only one KSK key used (if we are not in rollover phase)
> > >
> > > Except that with my current policy, I never see 2 KSKs via a "dig
> > > DNSKEY...".
> > > here is my policy :
> > >
> > > dnssec-policy "test" {
> > > keys {
> > > ksk lifetime P7D algorithm ecdsa256;
> > > zsk lifetime P3D algorithm ecdsa256;
> > > };
> > > purge-keys 1d;
> > > publish-safety 3d;
> > > retire-safety 3d;
> > > };
> > >
> > > I see either my KSK in use or my next KSK (via "dig DNSKEY...")
> but
> > > never both at the same time.
> > >
> > > Is this a normal behavior or am I doing it wrong?
> > >
> > > Regards, Adrien
> > >
> > --
> > Visit https://lists.isc.org/mailman/listinfo/bind-users
> >
Re: Finding dnssec validation failures in the logs
I looked in logs of my resolver in my home network and see a similar message from January 6th: 06-Jan-2023 17:09:23.677 dnssec: info: validating in-addr.arpa/SOA: got insecure response; parent indicates it should be secure I interpret that to mean that someone’s DNS is misconfigured. I guess it could mean someone is trying to serve up wrong answers ... Found many lines of 'no valid signature found’ I think you are probably OK. > On Jan 23, 2023, at 7:44 PM, 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. > 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 Thurston 907-465-8591 > john.thurs...@alaska.gov > Department of Administration > State of Alaska > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [KASP] Key rollover
Hi Adrien,
I don't think it is fine yet. I see in your state file the following line:
> DSState: hidden
This means the DS is not published according to BIND.
> From my understanding, the second KSK should appear because I put the
> parameter "publish-safety 3d;" that is to say 3 days before the
> expiration ("retired") of the key in use. is that right?
In addition to the DNSKEY TTL yes. The successor KSK should be
pre-published the sum of dnskey-ttl, publish-safety, and
zone-propagation-delay, prior to its retirement.
Best regards,
Matthijs
On 1/24/23 09:08, adrien sipasseuth wrote:
Hello Matthijs,
Indeed I had not published the DS at my registar because I thought that
the second KSK would have appeared anyway at the time of the rollover.
I published the DS yesterday and I reported to BIND with the command you
gave me. I didn't find any error in the logs so everything must have
been fine!
here is the state file of the KSK in use :
; This is the state of key 46358, for ***.
Algorithm: 13
Length: 256
Lifetime: 604800
Predecessor: 28887
KSK: yes
ZSK: no
Generated: 20230117165503 (Tue Jan 17 17:55:03 2023)
Published: 20230117165503 (Tue Jan 17 17:55:03 2023)
Active: 20230120180003 (Fri Jan 20 19:00:03 2023)
Retired: 20230127180003 (Fri Jan 27 19:00:03 2023)
Removed: 20230131190003 (Tue Jan 31 20:00:03 2023)
DSPublish: 20230123081513 (Mon Jan 23 09:15:13 2023)
PublishCDS: 20230120180003 (Fri Jan 20 19:00:03 2023)
DNSKEYChange: 20230120180003 (Fri Jan 20 19:00:03 2023)
KRRSIGChange: 20230120180003 (Fri Jan 20 19:00:03 2023)
DSChange: 20230117165503 (Tue Jan 17 17:55:03 2023)
DNSKEYState: omnipresent
KRRSIGState: omnipresent
DSState: hidden
GoalState: omnipresent
From my understanding, the second KSK should appear because I put the
parameter "publish-safety 3d;" that is to say 3 days before the
expiration ("retired") of the key in use. is that right?
that is to say tonight at 7pm, I will see tomorrow if this one appears.
regards, Adrien
Le jeu. 19 janv. 2023 à 09:13, Matthijs Mekking > a écrit :
Hi Adrien,
Without any logs or key **state** files, I can't really tell what is
going on.
My only gut feeling is that you have never signaled BIND 9 that the DS
has been published. You can run 'rndc dnssec -checkds -key 12345
published example.com ' or set up
parental-agents to do it for you.
Best regards,
Matthijs
On 1/17/23 09:38, adrien sipasseuth wrote:
> Hello,
>
> I put the management of DNSSEC with KASP, the zone is well
functional.
> (dig with "AD" flag etc)
>
> On the other hand, I can't see when the key rollover period for
my KSK
> is over (2 KSKs with a dig DNSKEY...)
>
> Without KASP, it was easy because I generated the second KSK key but
> with KASP, it is managed automatically.
>
> So, I have to adapt my scripts to check that there is :
> - a used KSK key and a next KSK key
> - Or only one KSK key used (if we are not in rollover phase)
>
> Except that with my current policy, I never see 2 KSKs via a "dig
> DNSKEY...".
> here is my policy :
>
> dnssec-policy "test" {
> keys {
> ksk lifetime P7D algorithm ecdsa256;
> zsk lifetime P3D algorithm ecdsa256;
> };
> purge-keys 1d;
> publish-safety 3d;
> retire-safety 3d;
> };
>
> I see either my KSK in use or my next KSK (via "dig DNSKEY...") but
> never both at the same time.
>
> Is this a normal behavior or am I doing it wrong?
>
> Regards, Adrien
>
--
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/
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: [KASP] Key rollover
Hello Matthijs,
Indeed I had not published the DS at my registar because I thought that the
second KSK would have appeared anyway at the time of the rollover.
I published the DS yesterday and I reported to BIND with the command you
gave me. I didn't find any error in the logs so everything must have been
fine!
here is the state file of the KSK in use :
; This is the state of key 46358, for ***.
Algorithm: 13
Length: 256
Lifetime: 604800
Predecessor: 28887
KSK: yes
ZSK: no
Generated: 20230117165503 (Tue Jan 17 17:55:03 2023)
Published: 20230117165503 (Tue Jan 17 17:55:03 2023)
Active: 20230120180003 (Fri Jan 20 19:00:03 2023)
Retired: 20230127180003 (Fri Jan 27 19:00:03 2023)
Removed: 20230131190003 (Tue Jan 31 20:00:03 2023)
DSPublish: 20230123081513 (Mon Jan 23 09:15:13 2023)
PublishCDS: 20230120180003 (Fri Jan 20 19:00:03 2023)
DNSKEYChange: 20230120180003 (Fri Jan 20 19:00:03 2023)
KRRSIGChange: 20230120180003 (Fri Jan 20 19:00:03 2023)
DSChange: 20230117165503 (Tue Jan 17 17:55:03 2023)
DNSKEYState: omnipresent
KRRSIGState: omnipresent
DSState: hidden
GoalState: omnipresent
>From my understanding, the second KSK should appear because I put the
parameter "publish-safety 3d;" that is to say 3 days before the expiration
("retired") of the key in use. is that right?
that is to say tonight at 7pm, I will see tomorrow if this one appears.
regards, Adrien
Le jeu. 19 janv. 2023 à 09:13, Matthijs Mekking a écrit :
> Hi Adrien,
>
> Without any logs or key **state** files, I can't really tell what is
> going on.
>
> My only gut feeling is that you have never signaled BIND 9 that the DS
> has been published. You can run 'rndc dnssec -checkds -key 12345
> published example.com' or set up parental-agents to do it for you.
>
> Best regards,
>
> Matthijs
>
> On 1/17/23 09:38, adrien sipasseuth wrote:
> > Hello,
> >
> > I put the management of DNSSEC with KASP, the zone is well functional.
> > (dig with "AD" flag etc)
> >
> > On the other hand, I can't see when the key rollover period for my KSK
> > is over (2 KSKs with a dig DNSKEY...)
> >
> > Without KASP, it was easy because I generated the second KSK key but
> > with KASP, it is managed automatically.
> >
> > So, I have to adapt my scripts to check that there is :
> > - a used KSK key and a next KSK key
> > - Or only one KSK key used (if we are not in rollover phase)
> >
> > Except that with my current policy, I never see 2 KSKs via a "dig
> > DNSKEY...".
> > here is my policy :
> >
> > dnssec-policy "test" {
> > keys {
> > ksk lifetime P7D algorithm ecdsa256;
> > zsk lifetime P3D algorithm ecdsa256;
> > };
> > purge-keys 1d;
> > publish-safety 3d;
> > retire-safety 3d;
> > };
> >
> > I see either my KSK in use or my next KSK (via "dig DNSKEY...") but
> > never both at the same time.
> >
> > Is this a normal behavior or am I doing it wrong?
> >
> > Regards, Adrien
> >
> --
> 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
