[dns-operations] Algorithm 5 and 7 trends (please move to 8 or 13)

[Viktor Dukhovni]

Enough time has passed since the need to abandon SHA-1 has become
more pressing to discern at least a couple short-term trend-lines.



alg7.pdf
Description: Adobe PDF document


alg5.pdf
Description: Adobe PDF document


It seems that algorithm 7 is indeed slowly trending down (it would be
good to see a larger downward slope), but unfortunately, the number of
algorithm 5 domains is actually growing.

  * If you're continuing to sign new domains with algorithm 5, please
reconsider.

  * If you have existing domains signed with algorithms 5 or 7, please
migrate to 8 or 13.

Separately:

  * If you're managing one of the ~8k domains with 512-bit RSA keys,
please migrate to a more reasonable RSA key size or P256.

-- 
Viktor.

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] .iq contacts?

[Warren Kumari]

On Thu, May 28, 2020 at 6:32 PM Ray Bellis  wrote:

>
>
> On 28/05/2020 22:56, Viktor Dukhovni wrote:
>
> > Indeed this looks rather precarious, and the SOA serial number is not
> > any higher on the other remaining server, the expiration time is 7 days,
> > so not much time left if the primary went down in the 21st.
> >
> > The MX record for cmc.iq is: cmc.iq. IN MX 0 in.hes.trendmicro.eu.  This
> > might be useful for reaching "hostmas...@cmc.iq" should the zone expire
> > in the meantime.  IANA lists a technical contact of "it...@cmc.iq":
> > 
>
> The ISC SNS service was actually due to be shut down on January 31st but
> there's been a few malingerers, including .iq
>
> We've been trying to reach them for *months* via many different comms
> channels, to no avail.
>

Well, perhaps this will finally get someone’s attention then...

Sorry for the snark, but I’d previously spent many many hours trying to
reach iq admins before giving up in disgust...

W



> However this potential failure of all listed NS servers makes this
> somewhat more urgent.
>
> Ray
>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> 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
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Disclosure of root zone TSIG keys

[Wessels, Duane via dns-operations]

--- Begin Message ---
Dear DNS operations community,

Last week Verisign determined that the transaction signature (TSIG) keys used 
to authenticate and secure root zone transfers from our zone distribution 
servers to root server operators were exposed to one or more unauthorized 
parties. For the explanation behind the disclosure, please refer to Appendix A 
below.

We believe that the risks to the root zone from this disclosure were low. Zone 
transfers from Verisign's distribution servers are first protected by whitelist 
access control lists (ACLs) provided by each operator, and the root zone 
content is not sensitive.

Nonetheless, upon learning of the disclosure, we notified ICANN and then worked 
quickly with the root server operators to roll to a new active TSIG key. That 
work was completed by May 26 and all root operators were confirmed to be using 
the new key. The urgency for rolling the key across a series of systems and a 
diverse set of root operators in just a few days rather than weeks / months was 
in part motivated by a recent BIND TSIG bug, which was seen as heightening the 
risk of the disclosure, albeit only slightly. More background on the TSIG 
vulnerability is included in Appendix B below.

If you have questions regarding this disclosure please don’t hesitate to 
contact us at i...@verisign-grs.com

---

Appendix A: Background information on recent root TSIG disclosure

On May 20, 2020 security tools alerted Verisign security teams that two 
internal servers were publicly accessible via a file copy service. Upon 
investigation our teams identified two additional servers that were also 
accessible. Altogether, these four servers were used for testing and/or staging 
functions. We have determined that a failure of network access controls was the 
root cause and that the scope of exposure involves read-only access to a 
constrained set of directories via the file copy service on these four servers.

The DNSSEC keying materials for any Verisign managed zones were not impacted by 
this incident as the impact was limited to testing and staging environments. 
Verisign signing servers and related infrastructure are operated in accordance 
with published DNSSEC practice statements and DNSSEC keys are held in FIPs 
140-2 level 3+ validated Hardware Security Modules (HSMs) as well as offline 
cryptographic systems to ensure the integrity of the signed zones operated by 
Verisign. No Verisign operated TLDs (e.g., COM, NET, etc.), registry 
operations, or other services were impacted by this incident.

Information contained on the servers did include transaction signature (TSIG) 
keys used for distribution of the root zone from Verisign’s servers to the root 
server operators, as well as TSIG keys used by Verisign to retrieve 103 
in-addr.arpa child domains from ARIN. Facts related to the incident include:

• We have concluded the exposure was introduced on August 21, 2019

• Our analysis has determined that files in the read-only directories, 
to include the root zone TSIG keys, as well as TSIG keys for in-addr.arpa child 
zones fetched from ARIN, were accessed by unauthorized parties

• The accessible service had been legitimately enabled on these servers 
for use by Verisign teams; the service should not have been internet-accessible

• The files were legitimately placed on the four servers for testing 
and/or staging purposes

• The directories accessible to the service were read-only

• The operational security stack for the environment was properly 
functioning and the four servers were properly logging to local and remote 
facilities at the time of the investigation

• High frequency internal and external vulnerability scanners were 
properly identifying the services and archiving the condition but not properly 
alerting on them; a supplementary security tool alerted internal teams to the 
issue

• The systems in these environments are continuously patched and are 
frequently wiped and rebuilt

• No personal information was stored on the servers

• The keys used to fetch the ARIN zones were changed on May 22, and the 
keys used for root zone distribution were changed over a ~3-day period and 
completed May 26.

Identified control deficiencies have been corrected to prevent further 
unauthorized access, alerting has been enhanced and new capabilities have been 
developed to prevent and/or more quickly detect and alert on any similar 
incidents going forward.

Current information suggests with a high confidence that no broader internal 
exposure resulted from the incident (e.g., there were no indications of 
unauthorized activity beyond access to the read-only directories, there were no 
indications of system-level compromise, lateral movement, or other subsequent 
related activities).

There are multiple controls around distribution of the root zone file to root 
operators and the contents of the 

Re: [dns-operations] .iq contacts?

[Ray Bellis]

On 28/05/2020 22:56, Viktor Dukhovni wrote:

> Indeed this looks rather precarious, and the SOA serial number is not
> any higher on the other remaining server, the expiration time is 7 days,
> so not much time left if the primary went down in the 21st.
> 
> The MX record for cmc.iq is: cmc.iq. IN MX 0 in.hes.trendmicro.eu.  This
> might be useful for reaching "hostmas...@cmc.iq" should the zone expire
> in the meantime.  IANA lists a technical contact of "it...@cmc.iq":
> 

The ISC SNS service was actually due to be shut down on January 31st but
there's been a few malingerers, including .iq

We've been trying to reach them for *months* via many different comms
channels, to no avail.

However this potential failure of all listed NS servers makes this
somewhat more urgent.

Ray

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] .iq contacts?

[Viktor Dukhovni]

On Thu, May 28, 2020 at 10:15:17PM +0100, Ray Bellis wrote:
> Has anyone got any working contacts whatsoever at .iq (Iraq?)
> 
> Their hidden master has been offline for about a week and of the four
> name servers two are already returning SERVFAIL following the elapsing
> of the SOA expiry timer and ours (sns-pb.isc.org) is due to follow suit
> very soon.
> 
> When that happens there'll only be one functioning NS for the ccTLD, and
> for all I know that one might be about to expire the zone too.

Indeed this looks rather precarious, and the SOA serial number is not
any higher on the other remaining server, the expiration time is 7 days,
so not much time left if the primary went down in the 21st.

The MX record for cmc.iq is: cmc.iq. IN MX 0 in.hes.trendmicro.eu.  This
might be useful for reaching "hostmas...@cmc.iq" should the zone expire
in the meantime.  IANA lists a technical contact of "it...@cmc.iq":


@nsp-anycast.cmc.iq.[194.117.58.42]
iq. IN SOA ns1.cmc.iq. hostmas...@cmc.iq. 2020052140 21600 3600 604800 86400
iq. IN NS sns-pb.isc.org.
iq. IN NS dyn1.cmc.iq.
iq. IN NS ns1.cmc.iq.
iq. IN NS nsp-anycast.cmc.iq.

@nsp-anycast.cmc.iq.[2001:500:14:8001:ad::42]
iq. IN SOA ns1.cmc.iq. hostmas...@cmc.iq. 2020052140 21600 3600 604800 86400
iq. IN NS ns1.cmc.iq.
iq. IN NS dyn1.cmc.iq.
iq. IN NS sns-pb.isc.org.
iq. IN NS nsp-anycast.cmc.iq.

@sns-pb.isc.org.[192.5.4.1]
iq. IN SOA ns1.cmc.iq. hostmas...@cmc.iq. 2020052140 21600 3600 604800 86400
iq. IN NS ns1.cmc.iq.
iq. IN NS nsp-anycast.cmc.iq.
iq. IN NS dyn1.cmc.iq.
iq. IN NS sns-pb.isc.org.

@sns-pb.isc.org.[2001:500:2e::1]
iq. IN SOA ns1.cmc.iq. hostmas...@cmc.iq. 2020052140 21600 3600 604800 86400
iq. IN NS sns-pb.isc.org.
iq. IN NS nsp-anycast.cmc.iq.
iq. IN NS dyn1.cmc.iq.
iq. IN NS ns1.cmc.iq.

@ns1.cmc.iq.[194.117.57.100]
iq. IN SOA ? ; ServFail

@dyn1.cmc.iq.[199.19.5.8]
iq. IN SOA ? ; ServFail

@dyn1.cmc.iq.[2001:500:92::8]
iq. IN SOA ? ; ServFail

@dyn2.cmc.iq.[199.19.6.8]
iq. IN SOA ? ; ServFail

@dyn2.cmc.iq.[2001:500:96::8]
iq. IN SOA ? ; ServFail

-- 
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] .iq contacts?

[Ray Bellis]

Has anyone got any working contacts whatsoever at .iq (Iraq?)

Their hidden master has been offline for about a week and of the four
name servers two are already returning SERVFAIL following the elapsing
of the SOA expiry timer and ours (sns-pb.isc.org) is due to follow suit
very soon.

When that happens there'll only be one functioning NS for the ccTLD, and
for all I know that one might be about to expire the zone too.

thanks,

Ray Bellis
Director of DNS Operations, ISC.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] At least 3 CloudFlare DNS-hosted domains with oddball TLSA lookup ServFail

[Christian Elmerot]

On 27/05/2020 22:11, Viktor Dukhovni wrote:

On Wed, May 27, 2020 at 04:35:29PM -0400, Dave Lawrence wrote:


Viktor Dukhovni writes:

Interesting.  I would have expected the RDATA to just be opaque bytes
when stored, and the server to return what ever it had, e.g.:

 _25._tcp.smtp.example.com. IN TLSA #2 0001
 _25._tcp.smtp.example.com. IN RRSIG TLSA ...

and let the client deal with malformed RDATA.

... you would expect a DNS server to not do validation on the RDATA of
known types and just serve whatever was stuffed in there?

Yes, precisely.  The time to validate input is before the records are
inserted into the zone database.  Once the records are there, (modulo
special considerations around name compression) I'd expect them to be
just binary blobs to be served to clients as-is.


While that in theory is true or how it is handled the SERVFAIL is 
introduced into the equation when DNSSEC live signing is applied to make 
the RRSIG of said content. Some bytes simply does not lend themselves to 
that operation, at least on our setup. Not sure providing an erroneous 
payload with a missing RRSIG would be handled better by clients than a 
SERVFAIL. The proper fix here is to fix the record contents going into 
the signing operation.




So for something like a TLSA record, I'd expect a server to just return
an opaque payload.  Thus, for example, I would also not expect the still
unresolved Verisign public DNS mangling of the army.mil SOA:
 $ dig +nocl +nottl +noall +ans -t soa army.mil @64.6.64.6
 army.mil. SOA ns01.army.mil. 
usarmy.huachuca.netcom.mesg.epdns-global.mail.mil. 2007170737 900 90 2419200 300

when the correct SOA RDATA is:

 $ dig +nocl +nottl +noall +ans -t soa army.mil @1.1.1.1
 army.mil. SOA ns01.army.mil. 
usarmy\.huachuca\.netcom\.mesg\.epdns-global.mail.mil. 2007170737 900 90 
2419200 300

which breaks denial-of-existence for this zone for any downstream
validators, ...


I'm not quite sure I'd expect validators to handle the erroneous TLSA 
payload proper if they can't deal with that mailformed SOA.


/Christian Elmerot, Cloudflare DNS team

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations