[dns-operations] Signatures expired at arin.net

Warren Kumari warren at kumari.net
Fri Jan 11 21:43:12 UTC 2019


On Fri, Jan 11, 2019 at 4:12 PM Mark Kosters <markk at arin.net> wrote:

> Hi Everyone
>
> John Curran posted the message below on NANOG.
>
>
While I'm often critical of ARIN, I would like to publicly acknowledge and
thank ARIN for providing a good postmortem. Publishing a clear (and
technical!) postmortem goes a long way towards restoring trust in a system
/ organization -- 'tis easy to screw something up, but takes courage to
explain what it was.

So, thank you again, and well done.
W



> Thanks,
> Mark
>
> Folks -
>
> The ARIN.NET zone on our public signed DNS servers are populated via an
> internal DNS server and associated workflow.  As part of system maintenance
> near the end of 2018, the zone file used by the master internal DNS server
> was updated incorrectly, resulting in an invalid zone file.  Since the zone
> file was invalid, the zone did not reload on our internal master, and the
> associated workflow to DNSSEC sign and push this zone to the public servers
> did not execute.  Our monitoring systems reported being green until the
> signatures expired as they presently check that the SOA's match on the
> internal and external nameservers.
>
> At approximately 8:30AM eastern time today (11 January 2019), ARIN
> operations started seeing issues within its monitoring.   Initial review
> suggested the problem was DNSSEC-related due to expired signatures.  We
> pulled the DS record from the zone so that DNSSEC validation would not be
> performed by those validating resolvers that had not already cached our DS
> records. Upon further investigation we determined that it was the result of
> human error in editing a zone file that went undetected and resulted in
> interruption of our routine zone publication process.  The issue was fixed
> and signed zones where then pushed out at 10:25 AM ET.  The DS record was
> reinstated in the parent at 10:30AM ET.
>
> As a result of this incident, we will add additional alerting to the zone
> loading process for any errors and perform monitoring of zone signature
> lifetimes, with appropriate alerting for any potential expiration of DNSSEC
> signatures.
>
> My apologies for this incident – while ARIN does have some fragility in
> our older systems (which we have been working aggressively to phase out via
> system refresh and replacements), it is not acceptable to have this
> situation with key infrastructure such as our DNS zones.   We will
> prioritize the necessary alert and monitor changes and I will report back
> to the community once that has been completed.
>
> Thank you for your patience in this regard.
> /John
>
> John Curran
> President and CEO
> American Registry for Internet Numbers
>
>
>
>
> On 1/11/19, 10:30 AM, "dns-operations on behalf of Stephane Bortzmeyer" <
> dns-operations-bounces at dns-oarc.net on behalf of bortzmeyer at nic.fr> wrote:
>
>     https://zonemaster.fr/result/b9a10c4558449ffe
>
>     http://dnsviz.net/d/arin.net/XDiYGA/dnssec/
>
>
>     %  dig  NS arin.net
>
>     ; <<>> DiG 9.10.3-P4-Debian <<>> NS arin.net
>     ;; global options: +cmd
>     ;; Got answer:
>     ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64645
>     ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
>
>     ;; OPT PSEUDOSECTION:
>     ; EDNS: version: 0, flags: do; udp: 4096
>     ;; QUESTION SECTION:
>     ;arin.net.          IN NS
>
>     ;; ANSWER SECTION:
>     arin.net.           43196 IN NS u.arin.net.
>     arin.net.           43196 IN NS ns1.arin.net.
>     arin.net.           43196 IN NS ns3.arin.net.
>     arin.net.           43196 IN NS ns2.arin.net.
>     arin.net.           43196 IN RRSIG NS 5 2 43200 (
>                                 20190111131206 20181228121206 11986
> arin.net.
>
> gAdeDWU4F1fHkST9qHC7JcfVFEb5Nmnsewq9DGQM/w8K
>
> KrXdDoG0QIOn2Acdi9m1bW+j4UgU2yDPnIMZoHHV6BoK
>
> 3C6+IEooWRBbEYDEMhrr42zAjlkH/P0jnYKvoBSH99aW
>                                 RA76gSiXRIBe+a3C2SuwEu/r4LoBoDA7KuIayGQ= )
>
>     ;; Query time: 0 msec
>     ;; SERVER: ::1#53(::1)
>     ;; WHEN: Fri Jan 11 15:36:48 CET 2019
>     ;; MSG SIZE  rcvd: 275
>     _______________________________________________
>     dns-operations mailing list
>     dns-operations at lists.dns-oarc.net
>     https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>     dns-operations mailing list
>     https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
>
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations
> <https://lists.dns-oarc.net/mailman/listinfo/dns-operationsdns-operations>
> mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190111/5d457197/attachment.html>


More information about the dns-operations mailing list