gyptazy.ch is a Fediverse instance that uses the ActivityPub protocol. In other words, users at this host can communicate with people that use software like Mastodon, Pleroma, Friendica, etc. all around the world.

This server runs the snac software and there is no automatic sign-up process.

Admin email
contact@gyptazy.ch
Admin account
@gyptazy@gyptazy.ch

Search results for #dnssec

Stupeflo »
@stupeflo@pipou.academy


J'arrive pas à saisir mon enregistre DNSKEY pour le domaine que j'essaye de saisir, j'ai le message suivant.

L'enregistrement DS demandé ne correspond à aucune DNSKEY publiée

Pourtant, la commande
drill DNSKEY trans13nrv.eu.org lancé depuis une machine extérieure à mon serveur faisant autoritaire, me donne le résultat suivant:

(…)
trans13nrv.eu.org.      3600    IN      DNSKEY  257 3 13 e0Org7Of/JK6J5LZTLnGPVLn3fR01wedEfNS0E66CDCM+0qZpwORpQjL dyoB7TVPvs2Y4SVgDQiPSy+v2M6Orw==
(…)

Elle est donc bien publique.

quelqu'un chez eu.org aurait une idée?

Le boost est très apprécié!

JP Mens »
@jpmens@mastodon.social

Authenticated Bootstrapping in Knot DNS

"DNSSEC Bootstrapping allows the child zone operator to publish a signed copy of the child’s CDS/CDNSKEY records under a different name that has an existing chain of trust."

en.blog.nic.cz/2024/05/10/auth

Juno »
@jutty@mastodon.bsd.cafe

Setting up DNSCrypt was easier than anticipated on my Debian machine without systemd-resolved. I really like the binary distribution, which is available as a self-contained directory with the binary and sample configuration. You can run the whole thing from that portable directory and move it around or specify locations on the command line if you wanna spread it.

Also, the gradual and modular approach to the generic Linux installation was a delight to follow, always being reminded to take small and verifiable steps along the way.

For anyone interested, this is it: github.com/DNSCrypt/dnscrypt-p

0 ★ 0 ↺

gyptazy »
@gyptazy@gyptazy.ch

To all who are hosting their own server with - what do you use in 2024?

or or still on some algorithms? Shorter key length is especially in DNS a benefit but still not all resolvers may be able to support this in 2024?!


Royce Williams »
@tychotithonus@infosec.exchange

New multi-implementation DNSSEC validation DoS vulnerabilities - CVE-2023-50387 ("KeyTrap"), CVE-2023-50868 (NSEC3 vuln)

(living doc, updated regularly - if you prefer a low-edit post to boost, use infosec.exchange/@tychotithonu)

Looks like DNS-OARC coordinated fixes in advance, but I don't see a centralized analysis, other than this announcement from the team who discovered KeyTrap:
athene-center.de/en/news/press
(Details may be still partially embargoed until patching ramps up)?

Analysis:

DoS of all major DNSSEC-validating DNS resolvers (servers, but also maybe local resolvers like systemd's?) at the implementation level. Exploitation described as 'trivial'. Both are CVSS 7.5. DNS is a rich ransom target - but some resolver setups don't even validate DNSSEC.

"In 2012 the vulnerability made its way into the implementation requirements for DNSSEC validation, standards RFC 6781 and RFC 6840" (per ATHENE)

Per the Unbound writeup, both vulns require query to a malicious zone (which is probably not hard to trigger, for any DNSSEC-enabled client or server).

Resolution: patch (recommended); disable DNSSEC validation (discouraged, but can buy you time / mitigate active DoS)

Fixes mitigate the exhaustion by putting caps on validation activities. These caps appear to have been missing from most implementations.

Details:

Two DNSSEC DoS CVEs:

CVE-2023-50387 ("KeyTrap"): "DNSSEC verification complexity can be exploited to exhaust CPU resources and stall DNS resolvers" (CVSS 7.5)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
seclists.org/oss-sec/2024/q1/1

(KeyTrap was discovered by ATHENE - their press release here has very important detail:
athene-center.de/en/news/press)

CVE-2023-50868: "NSEC3 closest encloser proof can exhaust CPU" (CVSS 7.5)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

MITRE links (now populated):
cve.mitre.org/cgi-bin/cvename.
cve.mitre.org/cgi-bin/cvename.

Vulmon queries:
vulmon.com/searchpage?q=CVE-20
vulmon.com/searchpage?q=CVE-20

VulDB:
vuldb.com/?id.253829

Patch status:

ISC BIND (patched - vuln since 2000?):
fosstodon.org/@iscdotorg/11192
kb.isc.org/docs/cve-2023-50387
kb.isc.org/docs/cve-2023-50868
seclists.org/oss-sec/2024/q1/1
isc.org/blogs/2024-bind-securi
(note: posts say "Versions prior to 9.11.37 were not assessed." but also have a range of affected versions starting at 9.0.0 - typo?)

Unbound (patched - vuln since Aug 2007):
nlnetlabs.nl/news/2024/Feb/13/
nlnetlabs.nl/downloads/unbound
seclists.org/oss-sec/2024/q1/1

dnsmasq (patched - 2.90 has fix):
thekelleys.org.uk/dnsmasq/CHAN
lists.thekelleys.org.uk/piperm

Knot (patched in 5.7.1):
knot-resolver.cz/2024-02-13-kn

pfSense:
(Bundled Unbound: plan appears to be to make a separate package available for manual update?; BIND: optional package)
forum.netgate.com/topic/186145
redmine.pfsense.org/issues/152

Pi-Hole (uses dnsmasq - patch available)
patreon.com/posts/dnssec-fix-9
pi-hole.net/blog/2024/02/13/fi

PowerDNS (patched - all versions affected):
blog.powerdns.com/2024/02/13/p
github.com/PowerDNS/pdns/pull/
github.com/PowerDNS/pdns/pull/
seclists.org/oss-sec/2024/q1/1

systemd.resolved:
[?]

OS status:

Fedora:
bodhi.fedoraproject.org/update

FreeBSD:
cgit.freebsd.org/ports/commit/

Gentoo:
bugs.gentoo.org/show_bug.cgi?i

Red Hat:
bugzilla.redhat.com/show_bug.c
access.redhat.com/security/sec [?]

SUSE:
bugzilla.suse.com/show_bug.cgi

Ubuntu:
ubuntu.com/security/CVE-2023-5
ubuntu.com/security/CVE-2023-5
ubuntu.com/security/notices/US

Windows (Server, DNS Role):
msrc.microsoft.com/update-guid

Package status:

BIND:
repology.org/project/bind/vers

dnsmasq:
repology.org/project/dnsmasq/v

Unbound:
repology.org/project/unbound/v

GitHub:
github.com/advisories/GHSA-845

Go (Knot module?)
github.com/golang/vulndb/issue

Non-coverage: (no mentions known yet)

Akamai
akamai.com/blog [?]

AWS
[?]

Azure (Microsoft Server DNS?)
[?]

Cisco Umbrella:
umbrella.cisco.com/blog [?]

Cloudflare
blog.cloudflare.com/ [?]

CoreDNS
coredns.io/blog/ [?]

Google DNS
[?]
(The Register article (see below) says Google is aware)

Infoblox
blogs.infoblox.com/ [?]

Quad9 DNS
quad9.net/news/blog/ [?]

News/Press

theregister.com/2024/02/13/dns

securityweek.com/keytrap-dns-a

Detection/Validation:

Check to see if a server is doing DNSSEC validation (if not an open recursive resolver, you may need to query a zone the server is authoritative for):

# zone signed, server DNSSEC-enabled:
$ delv example.net @8.8.8.8
; fully validated
example.net.            4437    IN      A       93.184.216.34
example.net.            4437    IN      RRSIG   A 13 2 86400 20240225232039 20240204162038 18113 example.net. 94G2PRXins1G9ntfklvCq2mvcgqjB0z9FqQXp77lD/wXR4J3D67ceih1 yNgsYYqlIAOoWKXUekux6Zq9aIwszQ==
# zone unsigned, server DNSSEC-enabled:
$ delv google.com @8.8.8.8
; unsigned answer
google.com.             100     IN      A       142.250.69.206

Tenable:
tenable.com/plugins/pipeline/i

Exploits:

(none yet known / public, but multiple sources describe as "trivial")


about this site - powered by snac