Abstract image of a woman sitting on books and studying on a laptop

DANE and Application Uses of DNSSEC

Shumon Huque, profile picture
Shumon Huque

This document discusses the application uses of DNSSEC and the Domain Name System Security Extensions protocol. It provides examples of how cryptographic keys can be stored and authenticated using DNSSEC records like SSHFP, TLSA, and OPENPGPKEY. These records allow applications to securely obtain keys from the DNS to enable or strengthen application layer security protocols for services like SSH, TLS, PGP, and email. The document focuses on how the TLSA record and DANE protocol can help address issues with the public certificate authority model by providing name constraints and directly authenticating certificates in the DNS.

Technology
1 of 40
Download to read offline
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
DANE & Application Uses of DNSSEC Shumon Huque, Duane Wessels ICANN 52, Singapore, Singapore February 11th, 2015
Verisign Public Application uses of DNSSEC •  One of the more exciting prospects for DNSSEC •  DNSSEC can be employed to store cryptographic keys in the DNS, and .. •  Allow applications to securely obtain (authenticate) those keys and use them in application security protocols •  Some possible applications: SSH, SSL/TLS, HTTPS, S/ MIME, PGP, SMTP, DKIM, and many others .. •  Existing records: •  SSHFP, IPSECKEY, DKIM TXT record, … •  DANE records: TLSA, OPENPGPKEY •  Upcoming: •  SMIMEA, IPSECA, … 2
Verisign Public SSHFP record 3 grodd.magpi.net.86400 IN SSHFP (1 1 F60AE0994C0B02545D444F7996088E9EA7359CBA) • Secure Shell Host Key Fingerprint (RFC 4255) • Allows you to validate SSH host keys using DNSSEC algorithm number fingerprint type (1= SHA1) fingerprint In OpenSSH, you can use the client configuration directive “VerifyHostKeyDNS” to use this. Enabled by default in some newer operating systems like FreeBSD 10.
Verisign Public IPSECKEY record 4 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 192.0.2.38 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) • RFC 4025: method for storing IPsec keying material in DNS • rdata format: precedence, gateway-type, algorithm, gateway address, public key • Not much uptake of this record • Will likely be superseded by newer proposals, like IPSECA
Verisign Public TLS and the Internet PKI •  A very large number of security protocols authenticate server names with X.509 certificates •  TLS, IPsec, HTTPS, SIPS, SMTP, IMAP, XMPP, … •  These certificates are issued and signed by the Internet PKI, composed of a set of globally trusted public Certification Authorities (CAs) 5
Verisign Public Public CA model issues •  Applications need to trust a large number of global Certification Authorities (CA) •  No namespace constraints! Any CA can issue certificates for any entity on the Internet •  Least common denominator security: our collective security is equal to the weakest one! •  Furthermore, many of them issue subordinate CA certificates to their customers, again with no naming constraints •  Most CAs aren’t capable of issuing certificates with any but the most basic capabilities (e.g. alternate name forms or other extensions) 6
Verisign Public Public CA model issues •  “Analysis of the HTTPS Certificate Ecosystem”, UMich, October 2013, Internet Measurement Conference •  http://conferences.sigcomm.org/imc/2013/papers/imc257- durumericAemb.pdf •  Over 1,800 separate CAs are capable of issuing certificates for anyone! (Root CAs and intermediate CAs issued by them) •  “The Shape & Size of Threats: Defining a Networked System’s Attack Surface” •  Eric Osterweil (Verisign), Danny McPherson (Verisign), Lixia Zhang (UCLA), NPsec 2014 conference 7
Verisign Public Can DNSSEC help? •  Can we leverage DNSSEC to address these deficiencies? •  DNS has hierarchical, decentralized administration •  Certificates and public keys placed in the DNS can be authenticated with DNSSEC signatures •  Name constraints are inherent •  Deployed infrastructure is becoming real •  Root and many of the TLDs are signed, so most organizations can sign their zones and have an intact secure chain of trust to the root •  Validation is also becoming more prevalent (see prior slides in deployment status) 8
Verisign Public DANE and the TLSA record •  RFC 6698: The DNS-based Authentication of Named Entities (DANE) Protocol for Transport Layer Security •  http://tools.ietf.org/html/rfc6698 •  Defines a new DNS record type “TLSA”, that can be used for better & more secure ways to authenticate SSL/TLS certificates •  By specifying constraints on which CA can vouch for a certificate, or which specific PKIX end-entity certificate is valid •  By specifying that a service certificate or a CA can be directly authenticated in the DNS itself. 9
10 _443._tcp.www.example.com. IN TLSA ( 0 0 1 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971 ) port, transport proto & server domain name TLSA rrtype certificate association data usage selector matching type TLSA record example
Verisign Public TLSA configuration parameters 11 Usage field: 0 PKIX-TA: CA Constraint 1 PKIX-EE: Service Certificate Constraint 2 DANE-TA: Trust Anchor Assertion 3 DANE-EE: Domain Issued Certificate Selector field: 0 Match full certificate 1 Match only SubjectPublicKeyInfo Matching type field: 0 Exact match on selected content 1 SHA-256 hash of selected content 2 SHA-512 hash of selected content Certificate Association Data: raw cert data in hex
Verisign Public TLSA configuration parameters 12 Usage field: 0 PKIX-TA: CA Constraint 1 PKIX-EE: Service Certificate Constraint 2 DANE-TA: Trust Anchor Assertion 3 DANE-EE: Domain Issued Certificate Selector field: 0 Match full certificate 1 Match only SubjectPublicKeyInfo Matching type field: 0 Exact match on selected content 1 SHA-256 hash of selected content 2 SHA-512 hash of selected content Certificate Association Data: raw cert data in hex Co-exists with and Strengthens Public CA system Operation without Public CAs
Verisign Public Usage types 13 0 PKIX-TA: CA Constraint Specify which CA should be trusted to authenticate the certificate for the service. Full PKIX certificate chain validation needs to be performed. 1 PKIX-EE: Service Certificate Constraint Define which specific service certificate (“EE cert”) should be trusted for the service. Full PKIX cert validation needs to be performed. 2 DANE-TA: Trust Anchor Assertion Specify a domain operated CA which should be trusted independently to vouch for the service certificate. 3 DANE-EE: Domain Issued Certificate Define a specific service certificate for the service at this domain name.
Verisign Public Example TLSA record (for WWW) 14 _443._tcp.fedoraproject.org. 263 IN TLSA 0 0 1 ( 19400BE5B7A31FB733917700789D2F0A2471C0C9D506 C0E504C06C16D7CB17C0 ) _443._tcp.fedoraproject.org. 263 IN RRSIG TLSA 5 4 300 ( 20141114150617 20141015150617 7725 fedoraproject.org. hrk0si7I/BWTz0wEtMcFZNUCj/0o5796k5FVuZx6eXrc YOe/ChHA/Shu/WHr3iM1yNGi86+8t4wMq9GA+JZthWZC ZmENxf9OTNe/t/LBAc2EDW/fMBJq0JO2b4ZkJHXCEyX0 CDsIYz8shZ20nPGlrsYqwLdQiCeravWcwcJiPuc= ) Usage 0 (“CA Constraint”) – this record says: -  For service at fedoraproject.org tcp port 443 -  only the CA with the specified SHA-256 certificate fingerprint (19400BE5B…) should be trusted
Verisign Public 15
Verisign Public DANE/TLSA tools and software •  TLSA Record Generation •  Command line tools: “swede”, “hash-slinger”, “ldns-dane” •  Web based tool: https://www.huque.com/bin/gen_tlsa •  TLSA validators for web •  Some 3rd party validator plugins are available (Firefox, Chrome, Opera, Safari): •  https://www.dnssec-validator.cz/ •  http://blog.huque.com/2014/02/dnssec-dane-tlsa-browser- addons.html •  Bloodhound Mozilla fork: •  https://www.dnssec-tools.org/wiki/index.php/Bloodhound 16
Verisign Public DANE for SMTP 17
Verisign Public DANE for SMTP •  DANE in conjunction with SMTP over TLS, or SMTP + STARTTLS can be used to more fully secure email delivery •  DANE can authenticate the certificate of the SMTP submission server that the user’s mail client (MUA) communicates with •  DANE can authenticate TLS connections between SMTP servers (“MTA”s or Mail Transfer Agents) •  This second use case is where DANE solves some important problems that are unaddressed today 18
Verisign Public DANE for SMTP •  Most connections between SMTP servers today use encryption opportunistically (i.e. if both sides support and advertise it, it is used) •  Even when encryption is used, it is vulnerable to attack: •  Attackers can strip away the TLS capability advertisement and downgrade the connection to not use TLS •  TLS connections are often unauthenticated (e.g. the use of self signed certificates as well as mismatched certificates is common) •  DANE can address both these vulnerabilities •  Authenticate the certificate using a DNSSEC signed TLSA record •  Use the presence of the TLSA record as an indicator that encryption must be performed (prevent downgrade) •  http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane 19
Verisign Public Example TLSA record (for SMTP) 20 _25._tcp.mx1.freebsd.org. 2389 IN TLSA 3 0 1 ( 5EC0508C3F337D18509F41BFF9D8AB07FED588A132FA 12FA1E223BA6B9403ACB ) _25._tcp.mx1.freebsd.org. 2389 IN RRSIG TLSA 8 5 3600 ( 20141023072418 20141009105807 39939 freebsd.org. ll6DEQ7oP2lbEcOeJyPk+I8tYiGz4CzuDiqiMbr4Mzp3 90UWdej3kdAz4t+1BT0dO3/o0nz0pp3HFsDu+gkwT6YH Jg4C6mi3STPciCP1tjbFuW/dv4lPkCUaN7kJt/qwPrR6 0kQmyvcuUoYgUDPbNYbJNJXai+mFai5WqLS2MEP15ydU nt8KympnjHS5mVLVGXW0e7tLY1afQz1VrIeYsGW8YztM DYUpCXjWiq+YpCFv7rZ7ICejQR6ot1M35CDsfjk68eu0 EAjx+HlqaTdGyilcMB+GduFwqkULDPIgiFu/3xb+srJR zuR89YpHga9OCnz6nXJgQ6cxvSImZWbKuw== ) This is a domain-issued certificate (usage 3), which can be authenticated without a trusted CA.
Verisign Public Early large adopters of SMTP + DANE •  posteo.de •  mailbox.org •  umbkw.de •  bund.de •  denic.de •  freebsd.org •  unitybox.de •  debian.org, debian.net •  ietf.org •  nlnetlabs.nl •  nic.cz •  nic.ch •  torproject.org 21 Quite a few are large email systems in Germany. See a larger list at https://www.tlsa.info/
Verisign Public SMTP servers that support DANE •  Postfix MTA (works today, version 2.11 onwards) •  Exim (currently under development) 22 Quick start for Postfix: postconf -e "smtpd_use_tls = yes” postconf -e "smtp_dns_support_level = dnssec” postconf -e "stmp_tls_security_level = dane”
Verisign Public XMPP servers •  XMPP (Jabber) has seen some uptake of DANE. •  To authenticate the c2s and/or s2s portion of the XMPP protocol •  List of XMPP servers with DANE TLSA records: •  https://xmpp.net/reports.php#dnssecdane 23 Example: _xmpp-server._tcp.mail.de. 3600 IN SRV 10 20 5269 jabber.mail.de. _5269._tcp.jabber.mail.de. 600 IN TLSA 3 1 1 ( A0315F0CF61CAC787140833C2C608550476 246DDA54122D66BB339D5 0FBB10E3 )
Verisign Public OpenPGPKEY •  OPENPGPKEY record •  Used to publish an OpenPGP public keys in the DNS •  DNSSEC signature provides authentication •  Spec under development, but RR code already assigned •  https://tools.ietf.org/html/draft-ietf-dane-openpgpkey 24
Verisign Public Example OPENPGPKEY record 25 sha224(username)._openpgpkey.<domain> e.g. for shuque@huque.com 1st label: sha224 hash of “shuque” = 4f7c2705c0f139ede60573f8537a0790fb64df5d4a819af951d259bc 2nd label: “_openpgpkey” Remaining labels: domain name portion of the email addr: Huque.com Resulting record looks like this: 4f7c2705c0f139ede60573f8537a0790fb64df5d4a819af951d259bc. _openpgpkey.huque.com. IN OPENPGPKEY <base64 encoding of the openpgp key>
Verisign Public SMIMEA •  Using DNSSEC to associate certificates with domain names for S/MIME •  https://tools.ietf.org/html/draft-ietf-dane-smime •  S/MIME is a method of encrypted and signing MIME data used in email messages •  The SMIMEA DNS record proposes to associate S/MIME certificates with DNS domain names •  Verisign DANE/SMIMEA early Mail User Agent Prototype •  http://la51.icann.org/en/schedule/wed-dnssec/presentation- dnssec-dane-smime-15oct14-en 26
Verisign Public getdns: a brief introduction A new application friendly interface to the DNS 27
Verisign Public Application access to any kind of DNS data •  Today’s commonly used DNS application interfaces, like getaddrinfo(), getnameinfo() are designed to obtain the most common types of DNS data, e.g. name to IP address mappings, reverse DNS mappings, etc. •  How do applications ask for other types of data, eg. TLSA, SSHFP records, or even SRV records? •  How can we tell if a response was successfully authenticated with DNSSEC? •  Some lower level, harder to use libraries exist (libresolv etc) that can do some of this, but application developers deserve something much better 28
. (root) .edu upenn.eduwww.upenn.edu referral to .edu + DS, RRSIG recursive resolver endstation (uses DNS stub resolver) 1 2 3 4 5 6 8 7 referral to upenn.edu + DS, RRSIG answer 1.2.3.4 + RRSIG www.upenn.edu set DO bit root’s pubkey (has root’s pubkey) edu pubkey upenn pubkey Stub to Recursive Resolver channel 29 Securing the first hop?
Verisign Public DNS first hop protection •  Applications normally query a DNS stub resolver •  The stub resolver communicates over the network with a recursive resolver. How do we secure that path? •  Complex solutions exist (but rarely used) •  e.g. employ a channel security mechanism between the stub and the validating recursive resolver: •  TSIG, SIG(0), IPsec •  Run full-service validating resolver on endstation •  There may be other solutions, like DNScrypt – not standards based, only supported by a few resolvers, not widely used •  getdns can solve this problem 30
Verisign Public getdns: a new DNS library for applications •  getdns: A new application-friendly interface to the DNS •  Get and use arbitrary data in the DNS easily •  Get this data securely, authenticated with DNSSEC if it’s available •  Full iterative resolver mode with validation •  Validating stub resolver mode •  Designed by application developers. Most previous APIs have been developed by DNS protocol people with less concern for the needs of app developers. 31
Verisign Public getdns •  API specification: •  http://www.getdnsapi.net/spec.html •  Latest revision: January 2015 •  Creative Commons Attribution 3.0 Unported license •  An opensource implementation at http://getdnsapi.net/ •  A joint project of Verisign Labs and NLNet Labs •  First release (0.1.0) in February 2014 •  Latest release (0.1.6) in January 2015 •  C library •  Bindings in Python, and Node.js (upcoming: java, go, ruby, perl) •  BSD 3 License 32
Verisign Public getdns features •  Asynchronous and synchronous modes of operation •  Sensible defaults suitable for consumption by most users •  But behavior highly configurable for users with advanced knowledge of the DNS •  DNS query results are returned in an easy to parse “response dictionary” data structure •  Members of the data structure can be lists, dictionaries, integers, and binary strings •  Can return DNSSEC status, and can be instructed to only return DNSSEC authenticated results 33
Verisign Public getdns functions 34 Four main functions defined. getdns_address() Obtain IPv4 and/or IPv6 addresses getdns_hostname() Obtain reverse DNS mappings getdns_service() Obtain SRV record answers getdns_general() General purpose DNS record query Read the API specification for full details: http://www.getdnsapi.net/spec.html
Verisign Public getdns response dictionary (partial) 35 { "answer_type": GETDNS_NAMETYPE_DNS, "canonical_name": <bindata of "www.internet2.edu.">, "just_address_answers”: [ { "address_data": <bindata for 207.75.164.248>, "address_type": <bindata of "IPv4"> }, { "address_data": <bindata for 2001:48a8:68fe::248>, "address_type": <bindata of "IPv6"> } ], "replies_full": [ <bindata of 0x000081a0000100040000000103777777...>, <bindata of 0x000081a0000100040005000d03777777...> ], …
Verisign Public getdns response dictionary (partial) 36 "dnssec_status": GETDNS_DNSSEC_SECURE, "replies_tree": [ { "additional": [], "answer": [ { "class": GETDNS_RRCLASS_IN, "name": <bindata for www.internet2.edu.>, "rdata": { "cname": <bindata for webprod2.internet2.edu.>, "rdata_raw": <bindata for webprod2.internet2.edu.> }, "ttl": 120, "type": GETDNS_RRTYPE_CNAME }, […]
Verisign Public getdns: example code: hostname lookup 37 # Example python code to query a domain name and # return all associated IPv4 and IPv6 addresses. hostname = sys.argv[1] ctx = getdns.Context() extensions = {"return_both_v4_and_v6”:getdns.GETDNS_EXTENSION_TRUE} results = ctx.address(name=hostname, extensions=extensions) status = results['status'] if status == getdns.GETDNS_RESPSTATUS_GOOD: for addr in results['just_address_answers']: print addr['address_data'] else: print "%s: getdns.address() error: %d" % (hostname, status) $ ./program.py www.internet2.edu 207.75.164.248 2001:48a8:68fe::248
Verisign Public getdns: example code: TLSA record lookup 38 # Example python code to lookup an authenticated TLSA # record for a domain name, transport, & service port. qname = “_443._tcp.fedoraproject.org” qtype = getdns.GETDNS_RRTYPE_TLSA ctx = getdns.Context() extensions = { "dnssec_return_only_secure”:getdns.GETDNS_EXTENSION_TRUE } results = ctx.general(name=qname, request_type=qtype, extensions=extensions) status = results['status'] if status == getdns.GETDNS_RESPSTATUS_GOOD: # here we’d normally parse and do something useful with the # result data. For now just pretty print the dict. pprint.pprint(results) else: print "%s: getdns.address() error: %d" % (hostname, status)
Verisign Public Questions or comments? 39
© 2014 VeriSign, Inc. All rights reserved. VERISIGN and other trademarks, service marks, and designs are registered or unregistered trademarks of VeriSign, Inc. and its subsidiaries in the United States and in foreign countries. All other trademarks are property of their respective owners.

More Related Content

PDF
Carlos García - Pentesting Active Directory [rooted2018]
RootedCON
 
PDF
Carlos García - Pentesting Active Directory Forests [rooted2019]
RootedCON
 
PDF
Jose Selvi - Side-Channels Uncovered [rootedvlc2018]
RootedCON
 
PDF
An Introduction to DANE - Securing TLS using DNSSEC
Carlos Martinez Cagnazzo
 
PDF
Introduction to and survey of TLS Security
Aaron Zauner
 
PDF
No need for Black Chambers: Testing TLS in the E-Mail Ecosystem at Large (hac...
Aaron Zauner
 
PPTX
SSL/TLS Introduction with Practical Examples Including Wireshark Captures
JaroslavChmurny
 
PPTX
BSides SG Practical Red Teaming Workshop
Ajay Choudhary
 
Carlos García - Pentesting Active Directory [rooted2018]
RootedCON
 
Carlos García - Pentesting Active Directory Forests [rooted2019]
RootedCON
 
Jose Selvi - Side-Channels Uncovered [rootedvlc2018]
RootedCON
 
An Introduction to DANE - Securing TLS using DNSSEC
Carlos Martinez Cagnazzo
 
Introduction to and survey of TLS Security
Aaron Zauner
 
No need for Black Chambers: Testing TLS in the E-Mail Ecosystem at Large (hac...
Aaron Zauner
 
SSL/TLS Introduction with Practical Examples Including Wireshark Captures
JaroslavChmurny
 
BSides SG Practical Red Teaming Workshop
Ajay Choudhary
 

What's hot (20)

PDF
Introduction To The DANE Protocol (DNSSEC)
Deploy360 Programme (Internet Society)
 
PDF
State of Transport Security in the E-Mail Ecosystem at Large
Aaron Zauner
 
PPTX
BlueHat v17 || Scaling Incident Response - 5 Keys to Successful Defense at S...
BlueHat Security Conference
 
PDF
Death of Web App Firewall
Brian A. McHenry
 
PPTX
Death of WAF - GoSec '15
Brian A. McHenry
 
PPTX
DoH, DoT and ESNI
Jisc
 
PDF
[Attacks Part] BetterCrypto Workshop @ Hack.lu 2014
Aaron Zauner
 
PDF
ION Santiago - DNSSEC and DANE Based Security for TLS
Deploy360 Programme (Internet Society)
 
PPTX
BlueHat v17 || TLS 1.3 - Full speed ahead... mind the warnings - the great, t...
BlueHat Security Conference
 
PPTX
BlueHat v17 || Detecting Compromise on Windows Endpoints with Osquery
BlueHat Security Conference
 
PDF
Securing PostgreSQL from External Attack
All Things Open
 
PDF
Encrypted DNS - DNS over TLS / DNS over HTTPS
Alex Mayrhofer
 
PDF
TLS/SSL Protocol Design
Nate Lawson
 
PDF
SMTP STS (Strict Transport Security) vs. SMTP with DANE
Men and Mice
 
PDF
Minieri CS6262 Project Poster
Joe Minieri
 
PDF
DNSSEC - Domain Name System Security Extensions
Peter R. Egli
 
PDF
Webinar SSL English
SSL247®
 
PDF
getdns PyCon presentation
Melinda Shore
 
PDF
An Overview of DNSSEC
Carlos Martinez Cagnazzo
 
PDF
Signing DNSSEC answers on the fly at the edge: challenges and solutions
APNIC
 
Introduction To The DANE Protocol (DNSSEC)
Deploy360 Programme (Internet Society)
 
State of Transport Security in the E-Mail Ecosystem at Large
Aaron Zauner
 
BlueHat v17 || Scaling Incident Response - 5 Keys to Successful Defense at S...
BlueHat Security Conference
 
Death of Web App Firewall
Brian A. McHenry
 
Death of WAF - GoSec '15
Brian A. McHenry
 
DoH, DoT and ESNI
Jisc
 
[Attacks Part] BetterCrypto Workshop @ Hack.lu 2014
Aaron Zauner
 
ION Santiago - DNSSEC and DANE Based Security for TLS
Deploy360 Programme (Internet Society)
 
BlueHat v17 || TLS 1.3 - Full speed ahead... mind the warnings - the great, t...
BlueHat Security Conference
 
BlueHat v17 || Detecting Compromise on Windows Endpoints with Osquery
BlueHat Security Conference
 
Securing PostgreSQL from External Attack
All Things Open
 
Encrypted DNS - DNS over TLS / DNS over HTTPS
Alex Mayrhofer
 
TLS/SSL Protocol Design
Nate Lawson
 
SMTP STS (Strict Transport Security) vs. SMTP with DANE
Men and Mice
 
Minieri CS6262 Project Poster
Joe Minieri
 
DNSSEC - Domain Name System Security Extensions
Peter R. Egli
 
Webinar SSL English
SSL247®
 
getdns PyCon presentation
Melinda Shore
 
An Overview of DNSSEC
Carlos Martinez Cagnazzo
 
Signing DNSSEC answers on the fly at the edge: challenges and solutions
APNIC
 
Ad

Similar to DANE and Application Uses of DNSSEC (20)

PPTX
ION Cape Town - DANE: The Future of Transport Layer Security (TLS)
Deploy360 Programme (Internet Society)
 
PDF
Alternatives and Enhancements to CAs for a Secure Web
CASCouncil
 
PDF
IoT Secure Bootsrapping : ideas
Jean-Baptiste Trystram
 
PPTX
Обнаружение вредоносного кода в зашифрованном с помощью TLS трафике (без деши...
Positive Hack Days
 
PPTX
ION Bucharest - Deploying DNSSEC
Deploy360 Programme (Internet Society)
 
PPTX
ION Sri Lanka - DANE: The Future of TLS
Deploy360 Programme (Internet Society)
 
PDF
8 technical-dns-workshop-day4
DNS Entrepreneurship Center
 
PPTX
Let's Encrypt + DANE
Deploy360 Programme (Internet Society)
 
DOCX
Transport Layer Security
Sanjeev Kumar Jaiswal
 
PPTX
All you need to know about transport layer security
Maarten Smeets
 
PPTX
Sequere socket Layer
Raghavendra Rao
 
PPTX
Demystifying SharePoint Infrastructure – for NON-IT People
SPC Adriatics
 
PPT
Cryptography in Human computer interaction powerpoint
ramlaabdikarim001
 
PPT
Dns protocol design attacks and security
Michael Earls
 
PDF
BRKSEC-3771 - WSA with wccp.pdf
MenakaDevi14
 
PPTX
CryptoStandards and protocols for digital secure communications
bipinbhattarai12
 
PDF
Alfresco DevCon 2019: Encryption at-rest and in-transit
Toni de la Fuente
 
PDF
Deploying Next Generation Firewalling with ASA - CX
Cisco Canada
 
PPTX
Understanding DNS Security
Nihal Pasham, CISSP
 
PDF
SSL Secure socket layer
Ahmed Elnaggar
 
ION Cape Town - DANE: The Future of Transport Layer Security (TLS)
Deploy360 Programme (Internet Society)
 
Alternatives and Enhancements to CAs for a Secure Web
CASCouncil
 
IoT Secure Bootsrapping : ideas
Jean-Baptiste Trystram
 
Обнаружение вредоносного кода в зашифрованном с помощью TLS трафике (без деши...
Positive Hack Days
 
ION Bucharest - Deploying DNSSEC
Deploy360 Programme (Internet Society)
 
ION Sri Lanka - DANE: The Future of TLS
Deploy360 Programme (Internet Society)
 
8 technical-dns-workshop-day4
DNS Entrepreneurship Center
 
Let's Encrypt + DANE
Deploy360 Programme (Internet Society)
 
Transport Layer Security
Sanjeev Kumar Jaiswal
 
All you need to know about transport layer security
Maarten Smeets
 
Sequere socket Layer
Raghavendra Rao
 
Demystifying SharePoint Infrastructure – for NON-IT People
SPC Adriatics
 
Cryptography in Human computer interaction powerpoint
ramlaabdikarim001
 
Dns protocol design attacks and security
Michael Earls
 
BRKSEC-3771 - WSA with wccp.pdf
MenakaDevi14
 
CryptoStandards and protocols for digital secure communications
bipinbhattarai12
 
Alfresco DevCon 2019: Encryption at-rest and in-transit
Toni de la Fuente
 
Deploying Next Generation Firewalling with ASA - CX
Cisco Canada
 
Understanding DNS Security
Nihal Pasham, CISSP
 
SSL Secure socket layer
Ahmed Elnaggar
 
Ad

More from Shumon Huque (20)

PDF
DANE and DNSSEC Authentication Chain Extension for TLS
Shumon Huque
 
PDF
Client Certificates in DANE TLSA Records
Shumon Huque
 
PDF
Query-name Minimization and Authoritative Server Behavior
Shumon Huque
 
PDF
Hands-on getdns Tutorial
Shumon Huque
 
PDF
DANE and Application Uses of DNSSEC
Shumon Huque
 
PDF
IPv6 Tutorial; USENIX LISA 2013
Shumon Huque
 
PDF
DNSSEC Tutorial; USENIX LISA 2013
Shumon Huque
 
PDF
IPv6 Transition in Research & Education
Shumon Huque
 
PDF
Authorization at Penn
Shumon Huque
 
PDF
IPv6 Deployment Panel
Shumon Huque
 
PDF
A survey of DNSSEC Deployment in the US R&E Community
Shumon Huque
 
PDF
World IPv6 Launch at Penn
Shumon Huque
 
PDF
IPv6 Security Panel (U of Penn)
Shumon Huque
 
PDF
Open Source VoIP at Penn
Shumon Huque
 
PDF
Kerberos at Penn (MIT Kerberos Consortium)
Shumon Huque
 
PPT
.EDU DNSSEC Testbed - Lessons Learned
Shumon Huque
 
PDF
IPv6 Campus Deployment Panel
Shumon Huque
 
PDF
.EDU DNSSEC Testbed
Shumon Huque
 
PDF
DNSSEC at Penn
Shumon Huque
 
PDF
PennNet and MAGPI
Shumon Huque
 
DANE and DNSSEC Authentication Chain Extension for TLS
Shumon Huque
 
Client Certificates in DANE TLSA Records
Shumon Huque
 
Query-name Minimization and Authoritative Server Behavior
Shumon Huque
 
Hands-on getdns Tutorial
Shumon Huque
 
DANE and Application Uses of DNSSEC
Shumon Huque
 
IPv6 Tutorial; USENIX LISA 2013
Shumon Huque
 
DNSSEC Tutorial; USENIX LISA 2013
Shumon Huque
 
IPv6 Transition in Research & Education
Shumon Huque
 
Authorization at Penn
Shumon Huque
 
IPv6 Deployment Panel
Shumon Huque
 
A survey of DNSSEC Deployment in the US R&E Community
Shumon Huque
 
World IPv6 Launch at Penn
Shumon Huque
 
IPv6 Security Panel (U of Penn)
Shumon Huque
 
Open Source VoIP at Penn
Shumon Huque
 
Kerberos at Penn (MIT Kerberos Consortium)
Shumon Huque
 
.EDU DNSSEC Testbed - Lessons Learned
Shumon Huque
 
IPv6 Campus Deployment Panel
Shumon Huque
 
.EDU DNSSEC Testbed
Shumon Huque
 
DNSSEC at Penn
Shumon Huque
 
PennNet and MAGPI
Shumon Huque
 

Recently uploaded (20)

PDF
Assigned Numbers - 2025 - Bluetooth® Document
Bloombase
 
PPTX
MicrosoftCybserSecurityReferenceArchitecture-April-2025.pptx
SilvioHayashi
 
PDF
Hybrid model detection and classification of lung cancer
IAESIJAI
 
PDF
Hindi spoken digit analysis for native and non-native speakers
IAESIJAI
 
PPTX
The various Industrial Revolutions .pptx
bandileshozi3
 
PDF
Architecture types and enterprise applications.pdf
ChristopherTHyatt
 
PDF
Enhancing emotion recognition model for a student engagement use case through...
IAESIJAI
 
PDF
From MVP to Full-Scale Product A Startup’s Software Journey.pdf
KodekX
 
PDF
STKI Israel Market Study 2025 version august
Dr. Jimmy Schwarzkopf
 
PPTX
Chapter 5: Probability Theory and Statistics
RandyFin
 
PPTX
O2C Customer Invoices to Receipt V15A.pptx
ssuserbfa915
 
PDF
A comparative study of natural language inference in Swahili using monolingua...
IAESIJAI
 
PPTX
Final SEM Unit 1 for mit wpu at pune .pptx
anishtilekar08
 
PPTX
observCloud-Native Containerability and monitoring.pptx
anupsingh76937
 
PPT
Geologic Time for studying geology for geologist
ssuser738f5a
 
PDF
Hybrid horned lizard optimization algorithm-aquila optimizer for DC motor
IAESIJAI
 
PDF
Unlock new opportunities with location data.pdf
Precisely
 
PDF
TrustArc Webinar - Click, Consent, Trust: Winning the Privacy Game
TrustArc
 
PDF
CloudStack 4.21: First Look Webinar slides
ShapeBlue
 
PPT
What is a Computer? Input Devices /output devices
GulJan8
 
Assigned Numbers - 2025 - Bluetooth® Document
Bloombase
 
MicrosoftCybserSecurityReferenceArchitecture-April-2025.pptx
SilvioHayashi
 
Hybrid model detection and classification of lung cancer
IAESIJAI
 
Hindi spoken digit analysis for native and non-native speakers
IAESIJAI
 
The various Industrial Revolutions .pptx
bandileshozi3
 
Architecture types and enterprise applications.pdf
ChristopherTHyatt
 
Enhancing emotion recognition model for a student engagement use case through...
IAESIJAI
 
From MVP to Full-Scale Product A Startup’s Software Journey.pdf
KodekX
 
STKI Israel Market Study 2025 version august
Dr. Jimmy Schwarzkopf
 
Chapter 5: Probability Theory and Statistics
RandyFin
 
O2C Customer Invoices to Receipt V15A.pptx
ssuserbfa915
 
A comparative study of natural language inference in Swahili using monolingua...
IAESIJAI
 
Final SEM Unit 1 for mit wpu at pune .pptx
anishtilekar08
 
observCloud-Native Containerability and monitoring.pptx
anupsingh76937
 
Geologic Time for studying geology for geologist
ssuser738f5a
 
Hybrid horned lizard optimization algorithm-aquila optimizer for DC motor
IAESIJAI
 
Unlock new opportunities with location data.pdf
Precisely
 
TrustArc Webinar - Click, Consent, Trust: Winning the Privacy Game
TrustArc
 
CloudStack 4.21: First Look Webinar slides
ShapeBlue
 
What is a Computer? Input Devices /output devices
GulJan8
 

DANE and Application Uses of DNSSEC

  • 1. DANE & Application Uses of DNSSEC Shumon Huque, Duane Wessels ICANN 52, Singapore, Singapore February 11th, 2015
  • 2. Verisign Public Application uses of DNSSEC •  One of the more exciting prospects for DNSSEC •  DNSSEC can be employed to store cryptographic keys in the DNS, and .. •  Allow applications to securely obtain (authenticate) those keys and use them in application security protocols •  Some possible applications: SSH, SSL/TLS, HTTPS, S/ MIME, PGP, SMTP, DKIM, and many others .. •  Existing records: •  SSHFP, IPSECKEY, DKIM TXT record, … •  DANE records: TLSA, OPENPGPKEY •  Upcoming: •  SMIMEA, IPSECA, … 2
  • 3. Verisign Public SSHFP record 3 grodd.magpi.net.86400 IN SSHFP (1 1 F60AE0994C0B02545D444F7996088E9EA7359CBA) • Secure Shell Host Key Fingerprint (RFC 4255) • Allows you to validate SSH host keys using DNSSEC algorithm number fingerprint type (1= SHA1) fingerprint In OpenSSH, you can use the client configuration directive “VerifyHostKeyDNS” to use this. Enabled by default in some newer operating systems like FreeBSD 10.
  • 4. Verisign Public IPSECKEY record 4 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 192.0.2.38 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) • RFC 4025: method for storing IPsec keying material in DNS • rdata format: precedence, gateway-type, algorithm, gateway address, public key • Not much uptake of this record • Will likely be superseded by newer proposals, like IPSECA
  • 5. Verisign Public TLS and the Internet PKI •  A very large number of security protocols authenticate server names with X.509 certificates •  TLS, IPsec, HTTPS, SIPS, SMTP, IMAP, XMPP, … •  These certificates are issued and signed by the Internet PKI, composed of a set of globally trusted public Certification Authorities (CAs) 5
  • 6. Verisign Public Public CA model issues •  Applications need to trust a large number of global Certification Authorities (CA) •  No namespace constraints! Any CA can issue certificates for any entity on the Internet •  Least common denominator security: our collective security is equal to the weakest one! •  Furthermore, many of them issue subordinate CA certificates to their customers, again with no naming constraints •  Most CAs aren’t capable of issuing certificates with any but the most basic capabilities (e.g. alternate name forms or other extensions) 6
  • 7. Verisign Public Public CA model issues •  “Analysis of the HTTPS Certificate Ecosystem”, UMich, October 2013, Internet Measurement Conference •  http://conferences.sigcomm.org/imc/2013/papers/imc257- durumericAemb.pdf •  Over 1,800 separate CAs are capable of issuing certificates for anyone! (Root CAs and intermediate CAs issued by them) •  “The Shape & Size of Threats: Defining a Networked System’s Attack Surface” •  Eric Osterweil (Verisign), Danny McPherson (Verisign), Lixia Zhang (UCLA), NPsec 2014 conference 7
  • 8. Verisign Public Can DNSSEC help? •  Can we leverage DNSSEC to address these deficiencies? •  DNS has hierarchical, decentralized administration •  Certificates and public keys placed in the DNS can be authenticated with DNSSEC signatures •  Name constraints are inherent •  Deployed infrastructure is becoming real •  Root and many of the TLDs are signed, so most organizations can sign their zones and have an intact secure chain of trust to the root •  Validation is also becoming more prevalent (see prior slides in deployment status) 8
  • 9. Verisign Public DANE and the TLSA record •  RFC 6698: The DNS-based Authentication of Named Entities (DANE) Protocol for Transport Layer Security •  http://tools.ietf.org/html/rfc6698 •  Defines a new DNS record type “TLSA”, that can be used for better & more secure ways to authenticate SSL/TLS certificates •  By specifying constraints on which CA can vouch for a certificate, or which specific PKIX end-entity certificate is valid •  By specifying that a service certificate or a CA can be directly authenticated in the DNS itself. 9
  • 10. 10 _443._tcp.www.example.com. IN TLSA ( 0 0 1 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971 ) port, transport proto & server domain name TLSA rrtype certificate association data usage selector matching type TLSA record example
  • 11. Verisign Public TLSA configuration parameters 11 Usage field: 0 PKIX-TA: CA Constraint 1 PKIX-EE: Service Certificate Constraint 2 DANE-TA: Trust Anchor Assertion 3 DANE-EE: Domain Issued Certificate Selector field: 0 Match full certificate 1 Match only SubjectPublicKeyInfo Matching type field: 0 Exact match on selected content 1 SHA-256 hash of selected content 2 SHA-512 hash of selected content Certificate Association Data: raw cert data in hex
  • 12. Verisign Public TLSA configuration parameters 12 Usage field: 0 PKIX-TA: CA Constraint 1 PKIX-EE: Service Certificate Constraint 2 DANE-TA: Trust Anchor Assertion 3 DANE-EE: Domain Issued Certificate Selector field: 0 Match full certificate 1 Match only SubjectPublicKeyInfo Matching type field: 0 Exact match on selected content 1 SHA-256 hash of selected content 2 SHA-512 hash of selected content Certificate Association Data: raw cert data in hex Co-exists with and Strengthens Public CA system Operation without Public CAs
  • 13. Verisign Public Usage types 13 0 PKIX-TA: CA Constraint Specify which CA should be trusted to authenticate the certificate for the service. Full PKIX certificate chain validation needs to be performed. 1 PKIX-EE: Service Certificate Constraint Define which specific service certificate (“EE cert”) should be trusted for the service. Full PKIX cert validation needs to be performed. 2 DANE-TA: Trust Anchor Assertion Specify a domain operated CA which should be trusted independently to vouch for the service certificate. 3 DANE-EE: Domain Issued Certificate Define a specific service certificate for the service at this domain name.
  • 14. Verisign Public Example TLSA record (for WWW) 14 _443._tcp.fedoraproject.org. 263 IN TLSA 0 0 1 ( 19400BE5B7A31FB733917700789D2F0A2471C0C9D506 C0E504C06C16D7CB17C0 ) _443._tcp.fedoraproject.org. 263 IN RRSIG TLSA 5 4 300 ( 20141114150617 20141015150617 7725 fedoraproject.org. hrk0si7I/BWTz0wEtMcFZNUCj/0o5796k5FVuZx6eXrc YOe/ChHA/Shu/WHr3iM1yNGi86+8t4wMq9GA+JZthWZC ZmENxf9OTNe/t/LBAc2EDW/fMBJq0JO2b4ZkJHXCEyX0 CDsIYz8shZ20nPGlrsYqwLdQiCeravWcwcJiPuc= ) Usage 0 (“CA Constraint”) – this record says: -  For service at fedoraproject.org tcp port 443 -  only the CA with the specified SHA-256 certificate fingerprint (19400BE5B…) should be trusted
  • 16. Verisign Public DANE/TLSA tools and software •  TLSA Record Generation •  Command line tools: “swede”, “hash-slinger”, “ldns-dane” •  Web based tool: https://www.huque.com/bin/gen_tlsa •  TLSA validators for web •  Some 3rd party validator plugins are available (Firefox, Chrome, Opera, Safari): •  https://www.dnssec-validator.cz/ •  http://blog.huque.com/2014/02/dnssec-dane-tlsa-browser- addons.html •  Bloodhound Mozilla fork: •  https://www.dnssec-tools.org/wiki/index.php/Bloodhound 16
  • 18. Verisign Public DANE for SMTP •  DANE in conjunction with SMTP over TLS, or SMTP + STARTTLS can be used to more fully secure email delivery •  DANE can authenticate the certificate of the SMTP submission server that the user’s mail client (MUA) communicates with •  DANE can authenticate TLS connections between SMTP servers (“MTA”s or Mail Transfer Agents) •  This second use case is where DANE solves some important problems that are unaddressed today 18
  • 19. Verisign Public DANE for SMTP •  Most connections between SMTP servers today use encryption opportunistically (i.e. if both sides support and advertise it, it is used) •  Even when encryption is used, it is vulnerable to attack: •  Attackers can strip away the TLS capability advertisement and downgrade the connection to not use TLS •  TLS connections are often unauthenticated (e.g. the use of self signed certificates as well as mismatched certificates is common) •  DANE can address both these vulnerabilities •  Authenticate the certificate using a DNSSEC signed TLSA record •  Use the presence of the TLSA record as an indicator that encryption must be performed (prevent downgrade) •  http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane 19
  • 20. Verisign Public Example TLSA record (for SMTP) 20 _25._tcp.mx1.freebsd.org. 2389 IN TLSA 3 0 1 ( 5EC0508C3F337D18509F41BFF9D8AB07FED588A132FA 12FA1E223BA6B9403ACB ) _25._tcp.mx1.freebsd.org. 2389 IN RRSIG TLSA 8 5 3600 ( 20141023072418 20141009105807 39939 freebsd.org. ll6DEQ7oP2lbEcOeJyPk+I8tYiGz4CzuDiqiMbr4Mzp3 90UWdej3kdAz4t+1BT0dO3/o0nz0pp3HFsDu+gkwT6YH Jg4C6mi3STPciCP1tjbFuW/dv4lPkCUaN7kJt/qwPrR6 0kQmyvcuUoYgUDPbNYbJNJXai+mFai5WqLS2MEP15ydU nt8KympnjHS5mVLVGXW0e7tLY1afQz1VrIeYsGW8YztM DYUpCXjWiq+YpCFv7rZ7ICejQR6ot1M35CDsfjk68eu0 EAjx+HlqaTdGyilcMB+GduFwqkULDPIgiFu/3xb+srJR zuR89YpHga9OCnz6nXJgQ6cxvSImZWbKuw== ) This is a domain-issued certificate (usage 3), which can be authenticated without a trusted CA.
  • 21. Verisign Public Early large adopters of SMTP + DANE •  posteo.de •  mailbox.org •  umbkw.de •  bund.de •  denic.de •  freebsd.org •  unitybox.de •  debian.org, debian.net •  ietf.org •  nlnetlabs.nl •  nic.cz •  nic.ch •  torproject.org 21 Quite a few are large email systems in Germany. See a larger list at https://www.tlsa.info/
  • 22. Verisign Public SMTP servers that support DANE •  Postfix MTA (works today, version 2.11 onwards) •  Exim (currently under development) 22 Quick start for Postfix: postconf -e "smtpd_use_tls = yes” postconf -e "smtp_dns_support_level = dnssec” postconf -e "stmp_tls_security_level = dane”
  • 23. Verisign Public XMPP servers •  XMPP (Jabber) has seen some uptake of DANE. •  To authenticate the c2s and/or s2s portion of the XMPP protocol •  List of XMPP servers with DANE TLSA records: •  https://xmpp.net/reports.php#dnssecdane 23 Example: _xmpp-server._tcp.mail.de. 3600 IN SRV 10 20 5269 jabber.mail.de. _5269._tcp.jabber.mail.de. 600 IN TLSA 3 1 1 ( A0315F0CF61CAC787140833C2C608550476 246DDA54122D66BB339D5 0FBB10E3 )
  • 24. Verisign Public OpenPGPKEY •  OPENPGPKEY record •  Used to publish an OpenPGP public keys in the DNS •  DNSSEC signature provides authentication •  Spec under development, but RR code already assigned •  https://tools.ietf.org/html/draft-ietf-dane-openpgpkey 24
  • 25. Verisign Public Example OPENPGPKEY record 25 sha224(username)._openpgpkey.<domain> e.g. for shuque@huque.com 1st label: sha224 hash of “shuque” = 4f7c2705c0f139ede60573f8537a0790fb64df5d4a819af951d259bc 2nd label: “_openpgpkey” Remaining labels: domain name portion of the email addr: Huque.com Resulting record looks like this: 4f7c2705c0f139ede60573f8537a0790fb64df5d4a819af951d259bc. _openpgpkey.huque.com. IN OPENPGPKEY <base64 encoding of the openpgp key>
  • 26. Verisign Public SMIMEA •  Using DNSSEC to associate certificates with domain names for S/MIME •  https://tools.ietf.org/html/draft-ietf-dane-smime •  S/MIME is a method of encrypted and signing MIME data used in email messages •  The SMIMEA DNS record proposes to associate S/MIME certificates with DNS domain names •  Verisign DANE/SMIMEA early Mail User Agent Prototype •  http://la51.icann.org/en/schedule/wed-dnssec/presentation- dnssec-dane-smime-15oct14-en 26
  • 27. Verisign Public getdns: a brief introduction A new application friendly interface to the DNS 27
  • 28. Verisign Public Application access to any kind of DNS data •  Today’s commonly used DNS application interfaces, like getaddrinfo(), getnameinfo() are designed to obtain the most common types of DNS data, e.g. name to IP address mappings, reverse DNS mappings, etc. •  How do applications ask for other types of data, eg. TLSA, SSHFP records, or even SRV records? •  How can we tell if a response was successfully authenticated with DNSSEC? •  Some lower level, harder to use libraries exist (libresolv etc) that can do some of this, but application developers deserve something much better 28
  • 29. . (root) .edu upenn.eduwww.upenn.edu referral to .edu + DS, RRSIG recursive resolver endstation (uses DNS stub resolver) 1 2 3 4 5 6 8 7 referral to upenn.edu + DS, RRSIG answer 1.2.3.4 + RRSIG www.upenn.edu set DO bit root’s pubkey (has root’s pubkey) edu pubkey upenn pubkey Stub to Recursive Resolver channel 29 Securing the first hop?
  • 30. Verisign Public DNS first hop protection •  Applications normally query a DNS stub resolver •  The stub resolver communicates over the network with a recursive resolver. How do we secure that path? •  Complex solutions exist (but rarely used) •  e.g. employ a channel security mechanism between the stub and the validating recursive resolver: •  TSIG, SIG(0), IPsec •  Run full-service validating resolver on endstation •  There may be other solutions, like DNScrypt – not standards based, only supported by a few resolvers, not widely used •  getdns can solve this problem 30
  • 31. Verisign Public getdns: a new DNS library for applications •  getdns: A new application-friendly interface to the DNS •  Get and use arbitrary data in the DNS easily •  Get this data securely, authenticated with DNSSEC if it’s available •  Full iterative resolver mode with validation •  Validating stub resolver mode •  Designed by application developers. Most previous APIs have been developed by DNS protocol people with less concern for the needs of app developers. 31
  • 32. Verisign Public getdns •  API specification: •  http://www.getdnsapi.net/spec.html •  Latest revision: January 2015 •  Creative Commons Attribution 3.0 Unported license •  An opensource implementation at http://getdnsapi.net/ •  A joint project of Verisign Labs and NLNet Labs •  First release (0.1.0) in February 2014 •  Latest release (0.1.6) in January 2015 •  C library •  Bindings in Python, and Node.js (upcoming: java, go, ruby, perl) •  BSD 3 License 32
  • 33. Verisign Public getdns features •  Asynchronous and synchronous modes of operation •  Sensible defaults suitable for consumption by most users •  But behavior highly configurable for users with advanced knowledge of the DNS •  DNS query results are returned in an easy to parse “response dictionary” data structure •  Members of the data structure can be lists, dictionaries, integers, and binary strings •  Can return DNSSEC status, and can be instructed to only return DNSSEC authenticated results 33
  • 34. Verisign Public getdns functions 34 Four main functions defined. getdns_address() Obtain IPv4 and/or IPv6 addresses getdns_hostname() Obtain reverse DNS mappings getdns_service() Obtain SRV record answers getdns_general() General purpose DNS record query Read the API specification for full details: http://www.getdnsapi.net/spec.html
  • 35. Verisign Public getdns response dictionary (partial) 35 { "answer_type": GETDNS_NAMETYPE_DNS, "canonical_name": <bindata of "www.internet2.edu.">, "just_address_answers”: [ { "address_data": <bindata for 207.75.164.248>, "address_type": <bindata of "IPv4"> }, { "address_data": <bindata for 2001:48a8:68fe::248>, "address_type": <bindata of "IPv6"> } ], "replies_full": [ <bindata of 0x000081a0000100040000000103777777...>, <bindata of 0x000081a0000100040005000d03777777...> ], …
  • 36. Verisign Public getdns response dictionary (partial) 36 "dnssec_status": GETDNS_DNSSEC_SECURE, "replies_tree": [ { "additional": [], "answer": [ { "class": GETDNS_RRCLASS_IN, "name": <bindata for www.internet2.edu.>, "rdata": { "cname": <bindata for webprod2.internet2.edu.>, "rdata_raw": <bindata for webprod2.internet2.edu.> }, "ttl": 120, "type": GETDNS_RRTYPE_CNAME }, […]
  • 37. Verisign Public getdns: example code: hostname lookup 37 # Example python code to query a domain name and # return all associated IPv4 and IPv6 addresses. hostname = sys.argv[1] ctx = getdns.Context() extensions = {"return_both_v4_and_v6”:getdns.GETDNS_EXTENSION_TRUE} results = ctx.address(name=hostname, extensions=extensions) status = results['status'] if status == getdns.GETDNS_RESPSTATUS_GOOD: for addr in results['just_address_answers']: print addr['address_data'] else: print "%s: getdns.address() error: %d" % (hostname, status) $ ./program.py www.internet2.edu 207.75.164.248 2001:48a8:68fe::248
  • 38. Verisign Public getdns: example code: TLSA record lookup 38 # Example python code to lookup an authenticated TLSA # record for a domain name, transport, & service port. qname = “_443._tcp.fedoraproject.org” qtype = getdns.GETDNS_RRTYPE_TLSA ctx = getdns.Context() extensions = { "dnssec_return_only_secure”:getdns.GETDNS_EXTENSION_TRUE } results = ctx.general(name=qname, request_type=qtype, extensions=extensions) status = results['status'] if status == getdns.GETDNS_RESPSTATUS_GOOD: # here we’d normally parse and do something useful with the # result data. For now just pretty print the dict. pprint.pprint(results) else: print "%s: getdns.address() error: %d" % (hostname, status)
  • 40. © 2014 VeriSign, Inc. All rights reserved. VERISIGN and other trademarks, service marks, and designs are registered or unregistered trademarks of VeriSign, Inc. and its subsidiaries in the United States and in foreign countries. All other trademarks are property of their respective owners.