In der heutigen Episode dreht es sich mal wieder um DNS. Dieses Mal jedoch um die einzelnen Arten von Einträgen, die man so findet. Von A bis TXT wird alles besprochen und bis ins kleinste Detail … wen versuche ich hier was vor zu machen. Stefan hat es sich vorgenommen, alles bis ins kleinste zu erklären, ist maßlos über das Ziel geschossen und hat dann 90% rausgeworfen, um in der Zeit zu bleiben. Aber er gibt einen Überblick über die einzelnen Einträge-Typen und wofür man sie verwendet.
Kontakt:
Website: 0x0d.de – Email: [email protected] (PGP)
Mastodon: @[email protected] (Sven), @[email protected] (Stefan)
News
13.06.2025: Fristlose Kündigung wegen Weiterleitung geschäftlicher E-Mails04.03.2019: Bußgeld für offenen E-Mail-Verteiler 13.06.2025: Deutsche Unternehmen gegen Ransomware: Acronis Cyberthreats Report0d107 – Die unterschätzte Bedrohung: Info Stealer Malware | Zeroday 11.7.2025: ‚123456‘ password exposed info for 64 million McDonald’s job applicants 22.07.2025: UK to ban public sector orgs from paying ransomware gangs 26.07.2025: Chatbots: Mistral legt erschreckende Umweltbilanz für KI-Modelle vor – Golem.de25.07.2025: Sysadmin Day: Die verstorbene Funkmaus und andere Admin-Geschichten – Golem.de27.07.2025: Star Trek wird Wissenschaft: Warum Forscher eine Warp-Signatur simulieren | t3n28.07.2025: Trotz Google-Update: Nächstes Pixel-Smartphone geht in Flammen auf | t3nThema: Die Rückkehr der Domain Name Services
Wir reden heute über Ressource Records. Das sind die DNS-Einträge, die wir alle erstellen.
Ich habe mir ein paar wenige rausgesucht, die ich interessant fand und möchte die mal eben kurz vorstellen und erklären:
NameVerwendungRFCAGibt die IP4 des Hosts an RFC 1035AAAAGibt die IP6 des Hosts anRFC 3596ATMAATM Address CAACertification Authority (CA) Blockierung, die zulässige CAs für einen Host bzw. eine Domain beschränken RFC 6844CERTResource Record für das Speichern von Zertifikaten wie PKIX, SPKI und PGPRFC 4398CNAMEKanonischer Name für einen Host (die Domain mit diesem RR ist ein Alias) RFC 1035DNAMEAlias für einen Namen und alle seine Subnamen. Ähnlich wie CNAME, aber anstatt eines Aliases nur für einen übereinstimmenden Namen, ist DNAME für komplette Domains zuständig. Ähnlich wie CNAME wird die Suche im DNS durch ständiges Probieren, den neuen Namen zu finden, weitergeführt.RFC 2672DNSKEYEnthält einen dem Namen zugeordneten Public-Key und löste ab 2004 bei DNSSEC den Typ KEY ab.RFC 4034KEYEnthält einen dem Namen zugeordneten Public-Key und wird seit 2004 nicht mehr von DNSSEC verwendet.Wurde nur für SIG(0) (RFC 2931) und TKEY (RFC 2930[21]) verwendet.[23] RFC 3445 schloss die Nutzung für Anwendungsschlüssel aus und beschränkte ihre Nutzung auf DNSSEC.[24] RFC 3755 kennzeichnet DNSKEY als den Ersatz innerhalb von DNSSEC.[25] RFC 4025 benennt IPSECKEY als Ersatz bei der Nutzung von IPsec.[26RFC 2535 und RFC 2930DSDient der Identifizierung und Verkettung DNSSEC-signierter ZonenLOCFührt einen geografischen Ort (Lokation) auf, der mit einem Domainnamen in Verbindung gebracht werden kann.MXOrdnet den für diese Domain zuständigen Mailserver einer Liste von Mail Transfer Agents zu. RFC 1035 und RFC 7505NSHostname eines autoritativen Nameservers. Überträgt eine DNS Zone, um die vorgegebenen Nameserver zu nutzen. RFC 1035OPENPGPKEYVerknüpfung von OpenPGP-Schlüsseln mit DomainnamenRFC 7929PTRDomain Name Pointer zu einem kanonischen Namen für das Reverse Mapping, um IP-Adressen Namen zuzuweisen. Im Gegensatz zu CNAME wird die DNS-Verarbeitung beendet und lediglich der Name zurückgegeben. Die häufigste allgemeine Verwendung von PTR ist die Implementierung von Reverse Mappings, aber es wird auch für DNS-SD eingesetzt. RFC 1035RPInformation über die verantwortliche(n) Person(en) für die Domain. Üblicherweise eine E-Mail-Adresse, wobei das ‚@‘ durch ein ‚.‘ ersetzt wurde.RFC 1183RRSIGEnthält eine digitale Unterschrift für den Eintrag. Wird seit 2004 von DNSSEC (=DNS Security) verwendet und ersetzt das gleichformatige SIG.RFC 4034SIGEnthält eine digitale Unterschrift, die in SIG(0) (RFC 2931[37]) und TKEY (RFC 2930[21]) benutzt wird.[25] SIG ist veraltet und wurde bis 2004 von DNSSEC (=DNS Security) verwendet. RFC 2535 nennt RRSIG als Ersatz für SIG zur Benutzung in DNSSEC.RFC 2535SMIMEAVerknüpfung von S/MIME-Zertifikaten mit Domainnamen RFC 8162SOAFührt verbindliche Informationen über eine DNS-Zone auf, einschließlich des Primary Nameservers, der E-Mail-Adresse des Administrators der Domäne, der Seriennummer der Domäne und Angaben über mehrere Zeitgeber in Bezug auf die Aktualisierung der Zone. RFC 1035 und RFC 2308SPFDer Eintrag SPF soll das Fälschen der Absenderadresse einer E-Mail verhindern. Es entstand als Verfahren zur Abwehr von Spam. Der Record-Typ ist veraltet und wurde durch TXT ersetzt. NONESRVVerallgemeinernder Eintrag zu angebotenen Diensten (Services). Wird von neueren Protokollen benutzt anstatt protokollspezifische Einträge zu erstellen, wie dies bei MX der Fall ist. RFC 2782SSHFPVeröffentlichung der Fingerprints von SSH-Schlüsseln in das DNS, um die Überprüfung der Echtheit eines Hosts zu unterstützen. RFC 6594[42] definiert die ECC SSH-Schlüssel und die SHA-256 Hashes. Details sind bei der IANA SSHFP RR parameters registry zu finden.[43] RFC 4255TLSAEintrag nötig für das Protokoll DNS-based Authentication of Named Entities (DANE), das dazu dient, den Datenverkehr abzusichern. RFC 6698 definiert die Nutzung des TLSA Resource Records (RR) als Verbindung eines TLS Serverzertifikates oder eines öffentlichen Schlüssels mit dem Domainnamen, wo der Eintrag gefunden wird. Die Verbindung erstellt deshalb eine „TLSA Zertifikatsverbindung“.[48] RFC 6698TXTUrsprünglich erdacht für frei definierbaren und von Menschen lesbaren Text in DNS Einträgen. Seit den frühen 1990ern enthält dieser Eintrag häufig jedoch u. a. auch maschinenlesbare Daten wie in RFC 1464[51] spezifiziert, SPF, DKIM, DMARC, DNS-SD und Google-Site Verification. RFC 1035
Resource Record – Wikipedia0d037 – Domain Name System (DNS) Teil 1 | Zeroday0d039 – Domain Name System (DNS) Teil 2 | Zeroday0d122 – PGP per DNS | ZerodayWas ist DNS-Tunneling? – Palo Alto Networks Aufgenommen am: 29.07.2025
Veröffentlicht am: 30.07.2025
Intro & Outro Chiptune CC BY SA 4.0: Pumped by ROCCOW
Logo CC BY 2.0 Richard Patterson
Disclaimer
In diesem Podcast werden Techniken oder Hardware vorgestellt, die geeignet sind, andere Systeme anzugreifen. Dies geschieht ausschließlich zu Bildungszwecken, denn nur, wenn man die Angriffstechniken kennt, kann man sich effektiv davor schützen. Denkt immer daran, diese Techniken oder Hardware nur bei Geräten anzuwenden, deren Eigner oder Nutzer das erlaubt haben.Der unerlaubte Zugriff auf fremde Infrastruktur ist strafbar (In Deutschland §202a, §202b, §202c StGB).Unsere Aussagen spiegeln ausschließlich unsere eigene individuelle Meinung wider.
