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 #dns

Patrick Mevzek »
@pmevzek@framapiaf.org

Quick study on records. Taking the ~192 entries in the list of possible identifers in CAA records, which are domain names loosely identifying CAs, gives 168 distinct domains... on which only 41 do have at least one issue/issuewild CAA record on them! With 24 of those 41 to have themselves as CAA records, but often with other names, hence other CAs. And also obvious errors in CAA records, like using "www.digicert.com" where correct is "digicert.com".

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é!

Sheldon Chang 🇺🇸 »
@sysop408@sfba.social

DNS gurus, am I correct in believing that PTR records are primarily used for mail sending servers and servers that never send mail do not need one?

daks »
@daks@mamot.fr

@80.67.169.40

; @80.67.169.40
;; udp: 1232
;; QUESTION SECTION:
;www.impots.gouv.fr. IN A

;; Query time: 20 msec
;; SERVER: 80.67.169.40#53(80.67.169.40) (UDP)
;; WHEN: Mon May 13 14:19:34 CEST 2024
;; MSG SIZE rcvd: 47
```

très étrange...

Jelle »
@jelle@m.ipoac.nl

Ugh, Turns out letting your server mirror the root zone is a good way to amplify ddos attacks...

Added a rule to that drops incoming packets with RD set while I come up with something more elegant.

The victim seems to be a small Brazilian ISP Jupiter. :(

Wireshark output that shows spoofed DNS requests coming in attacking what seems to be a Brazilian is 'Jupiter'.

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

Jelle »
@jelle@m.ipoac.nl

# telnet mx2.ipoac.nl 25 -4
Trying 86.80.166.233...
telnet: Unable to connect to remote host: Network is unreachable

# telnet mx2.ipoac.nl 25 -6
Trying 2a02:a46f:95b7::1...
Connected to mx2.ipoac.nl.
220 mx2.ipoac.nl ESMTP Postfix

Just amazing that my cable blocks tcp dport 25 outbound over , but is fine apparently.

Still not very useful with a fixed reverse that ends in cable.dynamic.v6.ziggo.nl that seem to love.

Michał "rysiek" Woźniak · 🇺🇦 »
@rysiek@mstdn.social

If is so great, why is there a .int, but not a .float, .char, or .double? 🤔

Shawn Webb »
@lattera@bsd.network

I was able to diagnose a DNS issue because I had my Unbound server sending queries to a remote syslog server.

The PBS video player requires that imasdk.googleapis.com. be allowlisted if it's contained in your DNS-based adblock list.

It was easy to spot by:

$ tail -F /var/log/network/dns-01/2024-04/all.log | grep -F 192.168.1.102

That told me what the client system (192.168.1.102) was trying to resolve in real-time.

Stéphane Bortzmeyer »
@bortzmeyer@mastodon.gougere.fr

Software author: NEVER NEVER NEVER use a dummy, non-existing domain in the default configuration, it may exist one day! crapts.org/2024/04/21/all-frit

KubikPixel™ »
@kubikpixel@chaos.social

A tool where you can check online whether your website is as you expect it to be and whether it has the desired services and DNS functions.

🌐 web-check.xyz

—

Jeroen Ruigrok van der Werven »
@asmodai@mastodon.social

Interesting, seems drill is broken on Debian 12. All TTL values, for any query, are returned as 0. If I use it on FreeBSD I do get the expected TTL values.

Tried on two different Debian 12 installations with same results.

Can anyone else confirm before I send off a bug report?

Ricardo Martín »
@fluxwatcher@mastodon.social

Has anyone tried dns0.eu yet?
dns0.eu/zero

Felix Palmen 📯 »
@zirias@techhub.social

@josephholsten @jhx I didn't try setting up something with (plus a and server) for a very long time now ... but with , it actually isn't *too* bad.

Felix Palmen 📯 »
@zirias@techhub.social

@jhx For writing some kind of "howto", I'll have to find a sane scope ... otherwise there would be just too much to describe I guess 😮

I could of course assume you already have

- network segmentation with a
- a working "domain" setup with a directory and (e.g. , but could be with as well)
- (virtual) machines providing (with in case of or )
- a working mechanism to distribute X.509 (I request them from using and distribute them with simple shell scripts using special-purpose restricted keys)

With all that in place, it would "just" be describing the setup of in a , enabling on all connection paths...

Felix Palmen 📯 »
@zirias@techhub.social

@jhx For writing some kind of "howto", I'll have to find a sane scope ... otherwise there would be just too much to describe I guess 😮

I could of course assume you already have

- network segmentation with a
- a working "domain" setup with a directory and (e.g. , but could be with as well)
- (virtual) machines providing (with in case of or )
- a working mechanism to distribute X.509 (I request them from using and distribute them with simple shell scripts using special-purpose restricted keys)

With all that in place, it would "just" be describing the setup of in a , enabling on all connection paths...

John Shaft »
@shaft@piaille.fr

And v3 of Terminology has been published as 9499 \o/

(v2 was 8499 and v1 7719. I hope v4 will be 9999)

3 versions in 5 years :') (7719 was published in January 2019)

rfc-editor.org/info/rfc9499

Stéphane Bortzmeyer »
@bortzmeyer@mastodon.gougere.fr

Currently, most registration domains use the same TTL for everyone. An EPP draft adds the ability for the registrar to ask for a different TTL, per domain.

ttyS1 »
@ttyS1@bsd.network

@gyptazy @jelle I am using that for my personal domain.
In my opinion everyone should be using ed25519.

Claudius Link »
@realn2s@infosec.exchange

If got a . At least it feels like I should know.

How do I get the registrar information of a () domain?

Edit:
The concrete domain are:

  • sm-q.de (faking sma.de)
  • sma-amerrica.com (faking sma-america.com)

Most of the time I succeed with . But sometimes the WhoIs record doesn't contain the information. Is there a better way?

Context: analyzing lookalike domain used for scams


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?!


Dominik Zajac »
@banym@bsd.network

A good example of cooperation between projects and the responsible handling of security vulnerabilities is probably the handling of cve.org/CVERecord?id=CVE-2023-. Several projects have worked together on solutions and simultaneously published the secured versions and information on the problems. If I have a good overview of all this, you can give a lot of praise for this. Especially when it comes to an important building block of the free Internet like .

Paul Wilde 😺 (snac2 acct) »
@paul@snac.notnull.space

I don't know if I'm just getting myself unnecessarily angry and frustrated or if someone else is just being unhelpful, but if I'm asked to liaise with a web company about making DNS changes so they can move a website to a new server, I expect to liaise with them, plan the time when it's desired to happen, switch the TTL to a low time temporarily so things can switch quickly when needed, and ultimately make the switchover have a little downtime as possible

What I don't expect if the first email after the "can you liaise" one being "can you change the A record to x.x.x.x as soon as possible"

garrrr, does nobody else plan these things? just do it and hope for the best? FFS


KubikPixel™ »
@kubikpixel@chaos.social

«Doing and for your the old way—the way that works:
Are you a with control issues who needs a weekend project? Look no further!»

OK, I use @quad9dns (I don't trust the other big's) but why not set up my one, you do?

🌐 arstechnica.com/information-te

Patrick Mevzek »
@pmevzek@framapiaf.org

@gyptazy At least for , the answer is clearly no: indico.dns-oarc.net/event/48/c

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")


bert hubert 🇺🇦🇪🇺 »
@bert_hubert@fosstodon.org

For my friends, this looks like a pretty neat way of doing DNS/Domain queries on the web - it does a lot more than just port 53. digger.tools/ Also available as source on GitHub

Output of DNS details for the domain fosstodon.org, showing the domain has been registered since the 30th of July 2017 for example, plus IP addresses.

peter hessler @openbsd »
@phessler@bsd.network

Hmmm. I was playing with 's Host Key Rotation feature (blog.djm.net.au/2015/02/key-ro) and publishing the new and old keys as in the .

However, I noticed that the OpenSSH client would only check the primary key offered, and if _any_ of the SSHFP keys didn't match (which, they would not by definition), then it would shout that the already-cached host keys didn't match.

This seems to be intentional, but did surprise me a bit. I was hoping to preload all of the keys, so clients would have an easier upgrade process.

(OpenSSH server 9.5, client 9.6; both as part of )

about this site - powered by snac