DNS Privacy Project

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 17 Next »


LDNS (drill) 1.6.17

  • Source: ldns 1.6.17 source code available from this link to NLNet Labs: ldns-1.6.7
  • Patch: Grab and apply the patch to ldns-1.6.17 from out git repository. Also see the notes here.
  • Query: To query this with drill use: (the IP address is used here simply to stop the server name resolution falling back to TCP because your local resolver doesn't support DNS-over-TLS).

    • drill -t             @<serverIP>  <query name>    (to see TCP query)

    • drill -l -p1021 @<serverIP>  <query name>    (to see TLS query)

    • drill -C           @<serverIP>  <query name   (to see STARTTLS query)

    • drill -C -D      @<serverIP>  <query name>    (to do a DNSSEC lookup using STARTTLS)

Digit v1.4

  • Source: Grab the digit client DNS-over-TLS tool from the ISI website:
  • Query: Build digit with openssl:

    • create a file called queries containing a query name

    •  ./digit -f queries -r <serverIP> -V -t tcp     (to see TCP query)

    •  ./digit -f queries -r <serverIP> -V -t ssl      (to see DNS-over-TLS query) 

getdns v0.2

  • Source:  https://github.com/getdnsapi/getdns
  • Query: Use API directly (see below), or use with the wrapper script getdns_query (run 'make test' then getdns_query is found in the test directory):
    • getdns_query @<serverIP> -s -A -O  (Pipelined TCP queries)
    • getdns_query @<serverIP> -s -A -L  (Pipelined TLS queries)
    • getdns_query @<serverIP> -s -A -E  (Pipelined TLS queries with fallback to TCP)

getdns API

In the 0.2 release of getdns there is an experiment implementation of DNS-over-TLS. It is enabled by using one of the following options as the getdns_transport_t value in the getdns_context_set_dns_transport() method:



  • This implementation is hard-coded to attempt to connect to the upstream server on port 1021 for TLS. 
  • These two transport values are not yet fully supported for recursive mode or for stub mode queries that use any of the DNSSEC extensions. See the table below for details.
  • No authentication is done in this implementation with regard to the certificate presented by the upstream server.
 RecursiveStub*Stub +dnssec extension**
  • Not supported. 
Fully supported.
  • Supported but will not keep 
    connections open.
  • Will fallback to TCP without trying TLS 
  • Will not keep connections open
Fully supported.
  • Will fallback to TCP without trying TLS. 
  • Will not keep connections open.

* Uses TLS v1.2 only
**  Uses TLS 1.2 but will fallback to v1.1, v1

Future releases

  • STARTTLS will be available as an option in the next release.
  • Note that the transport options available in the API are under review. It is likely that the API will change to allow the user to specify a list of transports that should be used in order. This will better support flexible fallback mechanisms for TLS/STARTTLS/TCP. Additional transport options will also be added related to TCP/TLS connection management.

How to Decode TLS packets in Wireshark

If you want to decode the DNS packets in Wireshark (use 1.12.1 or later) to get support TLSv1.2

  • Obtain the server key file

  • Configure the key in wireshark in Edit->Preferences

    • open the protocol list in the right hand menu and select SSL from the list
    • Click on the RSA keys list 'Edit' box and then click on 'New' in the dialog that appears
      • Enter remote servers IP address and the port for TLS (1021), and 'http' or 'spdy' for the protocal (DNS is not yet available here).
      • Use the Key File selector to choose the key file you downloaded
    • Save this by hitting OK, OK and Apply.
    • Back in the main window use the Analyze->Decode as... option to choose to decode as SSL
    • Click on one of the packets labelled 'Application data' and you should see an additional tab appear in the Packet bytes view window of wireshark labelled "Decrypted SSL data".


  • No labels