Re: Non-disruptive migration to dnssec-policy possible?
On Thu, Mar 26, 2020 at 7:27 PM Håkan Lindqvist via bind-users < bind-users@lists.isc.org> wrote: > On 2020-03-26 23:00, Mark Andrews wrote: > > dnssec-policy should be independent of inline-signing. If it isn’t then > it is a bug. > > > > It just people like editing master files rather than using nsupdate to > make changes. > > Ok, thank you for clarifying what should be expected. > > I guess that leaves the question of whether I am reading too much into > the new behavior. > > In addition to my DNSKEY issues, I do get two new files when switching a > zone to dnssec-policy: .signed + .signed.jnl. > To me this seems like the result of inline signing having been enabled, > but maybe this could happen for some other reason? > I suspect dnssec-policy is re-using a lot of the code that did inline signing, only applying it to local unsigned zone file rather than one that was fetched from a remote master via zone transfer (hence my last note about a new interpretation of the term). In fact, "rndc zonestatus" reports the same for a very simple dnssec-policy test on a local zone I did: $ rndc zonestatus foo.test name: foo.test type: master files: zones/foo.test/zonefile serial: 100251 signed serial: 100257 nodes: 5 last loaded: Wed, 25 Mar 2020 17:52:09 GMT secure: yes inline signing: yes ^ key maintenance: automatic next key event: Sat, 28 Mar 2020 20:45:44 GMT next resign node: foo.test/NS next resign time: Sat, 28 Mar 2020 08:40:06 GMT dynamic: yes frozen: no reconfigurable via modzone: no Shumon Huque ___ 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: Non-disruptive migration to dnssec-policy possible?
On 2020-03-26 23:00, Mark Andrews wrote: dnssec-policy should be independent of inline-signing. If it isn’t then it is a bug. It just people like editing master files rather than using nsupdate to make changes. Ok, thank you for clarifying what should be expected. I guess that leaves the question of whether I am reading too much into the new behavior. In addition to my DNSKEY issues, I do get two new files when switching a zone to dnssec-policy: .signed + .signed.jnl. To me this seems like the result of inline signing having been enabled, but maybe this could happen for some other reason? As for "inline-signing no;" not working, that actually appears to cause an error regardless of dnssec-policy, so that may be a blemish that is irrelevant to the overall question. Anyway, that just leads to: parser.c:2836: REQUIRE(obj != ((void *)0) && *obj == ((void *)0)) failed, back trace #0 0x55ec613030a3 in ?? #1 0x7f598d6eda90 in ?? #2 0x7f598d77d9ba in ?? #3 0x55ec6130a23c in ?? #4 0x55ec6130f398 in ?? #5 0x55ec61323adc in ?? #6 0x55ec61324b2e in ?? #7 0x7f598d714e51 in ?? #8 0x7f598d1c2669 in ?? #9 0x7f598d0e4323 in ?? exiting (due to assertion failure) /Håkan ___ 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: Non-disruptive migration to dnssec-policy possible?
dnssec-policy should be independent of inline-signing. If it isn’t then it is
a bug.
It just people like editing master files rather than using nsupdate to make
changes.
> On 27 Mar 2020, at 08:02, Shumon Huque wrote:
>
> On Thu, Mar 26, 2020 at 3:35 PM Håkan Lindqvist via bind-users
> wrote:
>
> A related thing that I've noticed in my tests is that "dnssec-policy x"
> seems to also imply "inline-signing yes"?
> Is this intended as a strict requirement, it seems a little awkward?
>
> I'm sure ISC colleagues will elucidate more, but it sounds to me like a new
> interpretation. of "inline-signing", i.e. the dnssec-policy feature takes an
> unsigned local zone file as input, and generates and maintains a new signed
> file ("origfile.signed"). UPDATEs continue to go to the orig file and
> ("inline?") signed deltas go into the signed file (well journal first and
> synced later). It would probably be helpful to have the mechanics of this new
> feature written up in detail somewhere so that operators know what is
> actually going on.
>
> Shumon Huque
>
>
> ___
> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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: Non-disruptive migration to dnssec-policy possible?
On Thu, Mar 26, 2020 at 3:35 PM Håkan Lindqvist via bind-users <
bind-users@lists.isc.org> wrote:
>
> A related thing that I've noticed in my tests is that "dnssec-policy x"
> seems to also imply "inline-signing yes"?
> Is this intended as a strict requirement, it seems a little awkward?
>
I'm sure ISC colleagues will elucidate more, but it sounds to me like a new
interpretation. of "inline-signing", i.e. the dnssec-policy feature takes
an unsigned local zone file as input, and generates and maintains a new
signed file ("origfile.signed"). UPDATEs continue to go to the orig file
and ("inline?") signed deltas go into the signed file (well journal first
and synced later). It would probably be helpful to have the mechanics of
this new feature written up in detail somewhere so that operators know what
is actually going on.
Shumon Huque
___
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: Non-disruptive migration to dnssec-policy possible?
I reported a bug with the requested details: https://gitlab.isc.org/isc-projects/bind9/issues/1706 A related thing that I've noticed in my tests is that "dnssec-policy x" seems to also imply "inline-signing yes"? Is this intended as a strict requirement, it seems a little awkward? On that note, combining "dnssec-policy x" with "inline-signing no" does not seem to be handled gracefully. This makes me suspect that it's not an intended scenario, is that correct? /Håkan On 2020-03-25 16:57, Håkan Lindqvist via bind-users wrote: On 2020-03-25 14:03, Matthijs Mekking wrote: Existing keys do not have a .state file, and so named will try to match those keys with the policy by looking at the data in the .key and .private files. However, perhaps some metadata is different? If so the keys don't match the policy and named will try to replace them (I suspect the DNSKEY TTL is different). Looking at the .key files, I can confirm that the old files (created by dnssec-keygen) omit the TTL field, while the new .key files have a 3600 TTL specified. I suppose that the dnssec-keygen output depends on whether the -L option was used or not (based on this, I would guess that it's quite common to have .key files with no TTL in the wild). You can use the dnssec-settime tool to write the state file, but it is more intended to be a method for debugging and testing. Ok. No, I don't particularly want the .state files, it was just a question of whether they were expected/needed ahead of time. It is odd that it immediately deletes the existing keys. I would like to follow-up on this. Would you be able to rerun the experiment with the dnssec log category set to debug? That way we can see what the internal keymgr decided about those keys. If so, could you create an issue for it on our GitLab repository? https://gitlab.isc.org/isc-projects/bind9/ Ok, I will try this and report back. (Also whether adding a TTL to the .key file avoids the problem) /Håkan ___ 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 ___ 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
DLV issue 2020/03/25
The issue with the dlv.isc.org DNSSEC signatures yesterday (2020/03/25) was caused by an undetected failure to restore the virtual machine that runs the hidden master for that zone following a failed upgrade to the underlying hypervisor. As a result of this issue the internet facing servers were unable to fetch the zone from the hidden master and eventually started serving expired signatures. The ensuing storm of queries to those servers from resolvers with outdated configurations and/or software then impeded our ability to diagnose and correct the issue as quickly as we would have liked. At some future point ISC would like to completely decommision this zone, but the number of clients still configured to use it currently makes that impractical. Per our announcements and presentations in 2015 through 2017 [1], we would urge all resolver operators and software packagers to ensure that DLV is disabled in all configurations. We have provided some additional guidance for this on our Knowledge Base.[2] We apologise for any disruption caused, and will be taking steps to try to ensure that this does not recur, including improvements to our monitoring systems. Ray Bellis Director of DNS Operations, ISC. [1] https://www.isc.org/blogs/dlv/ https://www.isc.org/blogs/dlv-replaced-with-signed-empty-zone/ [2] https://kb.isc.org/docs/disable-dnssec-lookaside-dlv-now-heres-how ___ 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
