tvl-depot/lisp/dns
2020-02-21 13:54:53 +00:00
..
client.lisp refactor(lisp/dns): Return dns-answer from query functions 2020-01-27 02:10:39 +00:00
default.nix chore: Rename pkgs->depot in all Nix file headers 2020-02-21 13:54:53 +00:00
message.lisp feat(lisp/dns): Support CNAME & NS record RDATAs 2020-01-27 00:47:53 +00:00
package.lisp refactor(lisp/dns): Return dns-answer from query functions 2020-01-27 02:10:39 +00:00
README.md docs(lisp/dns): Add initial README file 2020-01-27 00:49:34 +00:00

dns

This library is a DNS-over-HTTPS client for Common Lisp.

The ambition is to transform it into a fully-featured DNS resolver instead of piggy-backing on the HTTPS implementation, but ... baby-steps!

Note that there is no Common Lisp HTTP client that fully supports the HTTP2 protocol at the moment, so you can not expect this library to provide equivalent performance to a native DNS resolver (yet).

API

The API is kept as simple as it can be.

Types

The types of this library are implemented as several structs that support binary (de-)serialisation via lisp-binary.

The existing structs are as follows and directly implement the corresponding definitions from RFC 1035:

  • dns-header
  • dns-question
  • dns-rr
  • dns-message

All relevant field accessors for these structs are exported and can be used to inspect query results.

Functions

All lookup functions are of the type (function (string &key doh-url) (dns-message)) and signal a dns:doh-error condition for unsuccessful requests.

If :doh-url is unspecified, Google's public DNS-over-HTTPS servers at [dns.google][https://dns.google] will be used.

Currently implemented lookup functions:

  • lookup-a
  • lookup-mx
  • lookup-txt

Example usage

DNS> (dns-message-answer (lookup-a "git.tazj.in."))
#(#S(DNS-RR
     :NAME #S(QNAME :START-AT 29 :NAMES #(12))
     :TYPE A
     :CLASS 1
     :TTL 286
     :RDLENGTH 4
     :RDATA #(34 98 120 189)))

TODO

Various things in this library are currently broken because I only implemented it to work for my blog setup, but these things will be ironed out.

Most importantly, the following needs to be fixed:

  • Each qname fragment needs to track its offset, not each qname.
  • The RDATA for a TXT record can have multiple counted strings.
  • qnames should be canonicalised after parsing.