Re: dnssec lookaside to dlv.isc.org broke recursion - DNS

This is a discussion on Re: dnssec lookaside to dlv.isc.org broke recursion - DNS ; In message , "D. Stussy" writes: > "Florian Weimer" wrote in message > news:gdqfih$l14$1@sf1.isc.org... > > * Vinny Abello: > > > > > I've got two recursive DNS servers running on FreeBSD 7.0 each with > > > BIND ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: dnssec lookaside to dlv.isc.org broke recursion

  1. Re: dnssec lookaside to dlv.isc.org broke recursion


    In message , "D. Stussy" writes:
    > "Florian Weimer" wrote in message
    > news:gdqfih$l14$1@sf1.isc.org...
    > > * Vinny Abello:
    > >
    > > > I've got two recursive DNS servers running on FreeBSD 7.0 each with
    > > > BIND 9.4.2-P2. I got a call this morning that DNS lookups were broken.

    > >
    > > The annual key rollover for dlv.isc.org happened 30 days ago, and the
    > > transition period is now over. You probably failed to perform that
    > > rollover.

    >
    > I see nothing on the resource https://secure.isc.org/ops/dlv/index.php that
    > tells us that there is a periodic rollover of the key-signing-key for the
    > DLV. I expect that the zone-signing-key ("256") and ONLY that key will be
    > changed every month. The key-signing-key shouldn't be changed very often
    > (if at all). Remember that this is a transitional mechanism that should
    > only be in place for a short number of years.


    See DLV Registry Policy and Practice which is linked off of
    that page.

    https://secure.isc.org/ops/dlv/dlv-pol-pract-v1.0.php

    The trusted keys have always been described as

    "The current DLV KSK public key"

    Which should also be a clear indication that they change.

    Adding a "next scheduled key rollover commencement date" may
    be useful. Note there can always be emergency key rollover
    events so you should be subscribed to the announcement list.

    Mark

    > If isc.org is going to change it annually or so, fine, but then let them
    > publish about 4 key-signing-keys, even if only one is actively used. That
    > would be 4 years worth of keys, which should be enough to cover 4+ years -
    > long enough for ICANN to get off their asses and sign the root zone.
    >
    > Might using the wrong key-signing-key as a trusted key be the cause of the
    > assertion failure I reported in a separate thread?

    --
    Mark Andrews, ISC
    1 Seymour St., Dundas Valley, NSW 2117, Australia
    PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org


  2. dlv web site - was Re: dnssec lookaside to dlv.isc.org broke recursion

    "Mark Andrews" wrote in message
    news:gdtodb$gsr$1@sf1.isc.org...
    > In message , "D. Stussy" writes:
    > > "Florian Weimer" wrote in message
    > > news:gdqfih$l14$1@sf1.isc.org...
    > > > * Vinny Abello:
    > > > > I've got two recursive DNS servers running on FreeBSD 7.0 each with
    > > > > BIND 9.4.2-P2. I got a call this morning that DNS lookups were

    broken.
    > > >
    > > > The annual key rollover for dlv.isc.org happened 30 days ago, and the
    > > > transition period is now over. You probably failed to perform that
    > > > rollover.

    > >
    > > I see nothing on the resource https://secure.isc.org/ops/dlv/index.php

    that
    > > tells us that there is a periodic rollover of the key-signing-key for

    the
    > > DLV. I expect that the zone-signing-key ("256") and ONLY that key will

    be
    > > changed every month. The key-signing-key shouldn't be changed very

    often
    > > (if at all). Remember that this is a transitional mechanism that should
    > > only be in place for a short number of years.

    >
    > See DLV Registry Policy and Practice which is linked off of
    > that page.
    >
    > https://secure.isc.org/ops/dlv/dlv-pol-pract-v1.0.php


    OK, I see the link, but note that it is the bottom link of a list of ANCHORS
    within the current page, so it may be easily overlooked (and was by me,
    expecting a section to address the topic to appear later in the main page).

    If you're going to keep a link to an external page among in-page anchors,
    you should specify somehow that it links to another resource. However, I
    would prefer that you remove the link from the list of anchor links and
    simply show it elsewhere on the page to avoid all confusion.

    > The trusted keys have always been described as ...





+ Reply to Thread