The terms "quarter duplex", "half duplex", and "full duplex" describe how the upstream and downstream data channels may be used simultaneously, or not. Quarter duplex is not a standard term, but [https://en.wikipedia.org/wiki/Duplex_(telecommunications)#Half_duplex half duplex] and [https://en.wikipedia.org/wiki/Duplex_(telecommunications)#Full_duplex full duplex] are. The table below shows what I mean by them. Suppose the client has 3 pieces of data to send (UP1, UP2, UP3) and the server also has 3 pieces of data to send (DOWN1, DOWN2, DOWN3).
The terms "quarter duplex", "half duplex", and "full duplex" describe how the upstream and downstream data channels may be used simultaneously, or not. Quarter duplex is not a standard term, but [half duplex](https://en.wikipedia.org/wiki/Duplex_(telecommunications)#Half_duplex) and [full duplex](https://en.wikipedia.org/wiki/Duplex_(telecommunications)#Full_duplex) are. The table below shows what I mean by them. Suppose the client has 3 pieces of data to send (UP1, UP2, UP3) and the server also has 3 pieces of data to send (DOWN1, DOWN2, DOWN3).
||= Quarter duplex =||= Half duplex =||= Full duplex =||
|= Quarter duplex =|= Half duplex =|= Full duplex =|
@@ -48,9 +49,9 @@ The terms "quarter duplex", "half duplex", and "full duplex" describe how the up
...
@@ -48,9 +49,9 @@ The terms "quarter duplex", "half duplex", and "full duplex" describe how the up
<-- [ok]
<-- [ok]
[poll] -->
[poll] -->
<-- [DOWN3]
<-- [DOWN3]
```
}}}
}}}
}}}
```
{{{#!td valign=top
{{{
{{{
[UP1] -->
[UP1] -->
<-- [DOWN1]
<-- [DOWN1]
...
@@ -58,9 +59,9 @@ The terms "quarter duplex", "half duplex", and "full duplex" describe how the up
...
@@ -58,9 +59,9 @@ The terms "quarter duplex", "half duplex", and "full duplex" describe how the up
<-- [DOWN2]
<-- [DOWN2]
[UP3] -->
[UP3] -->
<-- [DOWN3]
<-- [DOWN3]
```
}}}
}}}
}}}
```
{{{#!td valign=top
{{{
{{{
[UP1] -->
[UP1] -->
[UP2] -->
[UP2] -->
...
@@ -68,35 +69,36 @@ The terms "quarter duplex", "half duplex", and "full duplex" describe how the up
...
@@ -68,35 +69,36 @@ The terms "quarter duplex", "half duplex", and "full duplex" describe how the up
[UP3] -->
[UP3] -->
<-- [DOWN2]
<-- [DOWN2]
<-- [DOWN3]
<-- [DOWN3]
}}}
```
}}}
}}}
|-----------------
|-----------------
||In a single query–response exchange, either the query carries data, or the response carries data, but not both. Sending and receiving 3 pieces of data requires 6 sequential roundtrips.||In a single query–response exchange, both the query and response may carry data, but queries and responses must serialized in a ping-pong fashion. Sending and receiving 3 pieces of data requires 3 sequential roundtrips.||Both queries and responses may carry data, and there is no requirement for one exchange to be finished before starting another one. Sending and receiving 3 pieces of data requires 3 roundtrips, but they may be interleaved.||
|In a single query–response exchange, either the query carries data, or the response carries data, but not both. Sending and receiving 3 pieces of data requires 6 sequential roundtrips.|In a single query–response exchange, both the query and response may carry data, but queries and responses must serialized in a ping-pong fashion. Sending and receiving 3 pieces of data requires 3 sequential roundtrips.|Both queries and responses may carry data, and there is no requirement for one exchange to be finished before starting another one. Sending and receiving 3 pieces of data requires 3 roundtrips, but they may be interleaved.|
DNS tunnels work either at the transport layer (netcat-like) or at the network layer (VPN-like). The network-layer ones have the implementation advantage that they don't have to worry about reliability, because retransmissions etc. are handled by lower-level kernel procedures.
DNS tunnels work either at the transport layer (netcat-like) or at the network layer (VPN-like). The network-layer ones have the implementation advantage that they don't have to worry about reliability, because retransmissions etc. are handled by lower-level kernel procedures.
Upstream queries are more squeezed for bandwidth than downstream responses. Although the protocol [https://tools.ietf.org/html/rfc1035#section-4.1.1 syntactically permits] sending any number of entries in the Question section, in practice the only supported value is QDCOUNT=1.
Upstream queries are more squeezed for bandwidth than downstream responses. Although the protocol [syntactically permits](https://tools.ietf.org/html/rfc1035#section-4.1.1) sending any number of entries in the Question section, in practice the only supported value is QDCOUNT=1.
A single DNS name has a maximum length of 255 bytes ([https://tools.ietf.org/html/rfc1035#section-2.3.4 RFC 1035 §2.3.4]). However, a name is composed of labels, each of which is a maximum of 63 bytes (or 64 bytes if including the length prefix). And the name's null terminator byte is counted in the limit as well. So it's really only 250 usable bytes. And from that you have to subtract the length of the name suffix that the DNS server is actually authoritative for.
A single DNS name has a maximum length of 255 bytes ([RFC 1035 §2.3.4](https://tools.ietf.org/html/rfc1035#section-2.3.4)). However, a name is composed of labels, each of which is a maximum of 63 bytes (or 64 bytes if including the length prefix). And the name's null terminator byte is counted in the limit as well. So it's really only 250 usable bytes. And from that you have to subtract the length of the name suffix that the DNS server is actually authoritative for.
Technically, [https://tools.ietf.org/html/rfc2181#section-11 any 8-bit value] can be part of a name label. However RFC 1035 [https://tools.ietf.org/html/rfc1035#section-2.3.1 recommends] `[A-Za-z][A-Za-z0-9-]*` for compatibility. Additionally, you can't rely on uppercase/lowercase being preserved ([https://developers.google.com/speed/public-dns/docs/security?hl=en#randomize_case Google Public DNS, among others, may randomize letter case]). So you have to encode somehow; base32 or hexadecimal suffices but better efficiency may be possible.
Technically, [any 8-bit value](https://tools.ietf.org/html/rfc2181#section-11) can be part of a name label. However RFC 1035 [recommends](https://tools.ietf.org/html/rfc1035#section-2.3.1)`[A-Za-z][A-Za-z0-9-]*` for compatibility. Additionally, you can't rely on uppercase/lowercase being preserved ([Google Public DNS, among others, may randomize letter case](https://developers.google.com/speed/public-dns/docs/security?hl=en#randomize_case)). So you have to encode somehow; base32 or hexadecimal suffices but better efficiency may be possible.
Supposing base32 encoding and 20 bytes for the length of the server's domain name suffix, the most raw data you can send in a single query is about 140 bytes. ''(Even if upstream queries may contain only one entry in the Question section, it may be possible to stuff extra data into the other sections. EDNS queries have an [https://tools.ietf.org/html/rfc6891#section-6 OPT resource record] in the Additional section—but that one only has hop-by-hop meaning, and isn't forwarded by a recursive server to an authoritative server. But perhaps some possibilities exist.)''
Supposing base32 encoding and 20 bytes for the length of the server's domain name suffix, the most raw data you can send in a single query is about 140 bytes. _(Even if upstream queries may contain only one entry in the Question section, it may be possible to stuff extra data into the other sections. EDNS queries have an [OPT resource record](https://tools.ietf.org/html/rfc6891#section-6) in the Additional section—but that one only has hop-by-hop meaning, and isn't forwarded by a recursive server to an authoritative server. But perhaps some possibilities exist.)_
It's easier to pack data into responses than into queries. Responses have to echo the original question, but they can contain multiple resources records for that query in the Answer section, not to mention the Additional section. You can have multiple resource records of the same or differing types, but the order of resource records within a section is not guaranteed. Resource records can be of any type ([https://tools.ietf.org/html/rfc1035#section-3.4.1 A], [https://tools.ietf.org/html/rfc3596#section-2 AAAA], [https://tools.ietf.org/html/rfc1035#section-3.3.9 MX], [https://tools.ietf.org/html/rfc1035#section-3.3.1 CNAME], etc.). A resource record has a maximum data length of 65535 bytes, but most of them have a fixed format that's shorter than that; e.g. A is 4 bytes and CNAME is up to 255 bytes. The [https://tools.ietf.org/html/rfc1035#section-3.3.14 TXT] type seems practical: it's a byte sequence of any length up to the 64K limit. (The [https://github.com/iagox86/dnscat2/blob/master/doc/protocol.md#dns-record-type dnscat2 docs] say that the Windows DNS client can't handle `'\0'` bytes in TXT records, but that shouldn't be a problem if you use a custom client.) The [https://tools.ietf.org/html/rfc1035#section-3.3.10 NULL] type is marginally more efficient than TXT, but is marked "experimental".
It's easier to pack data into responses than into queries. Responses have to echo the original question, but they can contain multiple resources records for that query in the Answer section, not to mention the Additional section. You can have multiple resource records of the same or differing types, but the order of resource records within a section is not guaranteed. Resource records can be of any type ([A](https://tools.ietf.org/html/rfc1035#section-3.4.1), [AAAA](https://tools.ietf.org/html/rfc3596#section-2), [MX](https://tools.ietf.org/html/rfc1035#section-3.3.9), [CNAME](https://tools.ietf.org/html/rfc1035#section-3.3.1), etc.). A resource record has a maximum data length of 65535 bytes, but most of them have a fixed format that's shorter than that; e.g. A is 4 bytes and CNAME is up to 255 bytes. The [TXT](https://tools.ietf.org/html/rfc1035#section-3.3.14) type seems practical: it's a byte sequence of any length up to the 64K limit. (The [dnscat2 docs](https://github.com/iagox86/dnscat2/blob/master/doc/protocol.md#dns-record-type) say that the Windows DNS client can't handle `'\0'` bytes in TXT records, but that shouldn't be a problem if you use a custom client.) The [NULL](https://tools.ietf.org/html/rfc1035#section-3.3.10) type is marginally more efficient than TXT, but is marked "experimental".
The overall length of a DNS response message cannot be more than 65535 bytes. This holds whether using UDP with EDNS (the [https://tools.ietf.org/html/rfc6891#section-6.1.2 UDP payload size] field is 16 bits, and anyway that's the largest IP datagram size); or TCP (messages are preceded by a [https://tools.ietf.org/html/rfc1035#section-4.2.2 16-bit length field]). In the absence of EDNS, UDP responses are supposed to be [https://tools.ietf.org/html/rfc1035#section-4.2.1 limited to 512 bytes]. But as EDNS has good support, the [https://en.wikipedia.org/wiki/Maximum_transmission_unit MTU] is likely a bigger consideration than any DNS-imposed length limitations. A common value for the EDNS length field is 4096.
The overall length of a DNS response message cannot be more than 65535 bytes. This holds whether using UDP with EDNS (the [UDP payload size](https://tools.ietf.org/html/rfc6891#section-6.1.2) field is 16 bits, and anyway that's the largest IP datagram size); or TCP (messages are preceded by a [16-bit length field](https://tools.ietf.org/html/rfc1035#section-4.2.2)). In the absence of EDNS, UDP responses are supposed to be [limited to 512 bytes](https://tools.ietf.org/html/rfc1035#section-4.2.1). But as EDNS has good support, the [MTU](https://en.wikipedia.org/wiki/Maximum_transmission_unit) is likely a bigger consideration than any DNS-imposed length limitations. A common value for the EDNS length field is 4096.
= dnscat2 =
# dnscat2
[https://github.com/iagox86/dnscat2/blob/master/doc/protocol.md dnscat2] is a DNS tunnel. It works at the socket layer. Despite its name, it doesn't provide a simple netcat-like interface; it overlays a lot of pentesting-oriented functionality like session management and high-level commands like "send a file". But the underlying transport protocol is separable from all that.
[dnscat2](https://github.com/iagox86/dnscat2/blob/master/doc/protocol.md) is a DNS tunnel. It works at the socket layer. Despite its name, it doesn't provide a simple netcat-like interface; it overlays a lot of pentesting-oriented functionality like session management and high-level commands like "send a file". But the underlying transport protocol is separable from all that.
* Uses hexadecimal encoding everywhere (even in TXT records).
* Uses hexadecimal encoding everywhere (even in TXT records).
* Uses CNAME, MX, TXT (randomly selected) by default. Also supports A and AAAA (use `type=A,AAAA` with the `--dns` option).
* Uses CNAME, MX, TXT (randomly selected) by default. Also supports A and AAAA (use `type=A,AAAA` with the `--dns` option).
...
@@ -109,7 +111,7 @@ The overall length of a DNS response message cannot be more than 65535 bytes. Th
...
@@ -109,7 +111,7 @@ The overall length of a DNS response message cannot be more than 65535 bytes. Th
Starts with a [[span(MESSAGE_TYPE_SYN,style=background:coral)]] exchange. The session ID is [[span(48ac,style=background:skyblue)]]. The client and server choose initial sequence numbers of [[span(9037,style=background:orange)]] and [[span(7643,style=background:orange)]] respectively. The client additionally sends a session name of [[span(!command (happy),style=background:lightgray)]].
Starts with a [[span(MESSAGE_TYPE_SYN,style=background:coral)]] exchange. The session ID is [[span(48ac,style=background:skyblue)]]. The client and server choose initial sequence numbers of [[span(9037,style=background:orange)]] and [[span(7643,style=background:orange)]] respectively. The client additionally sends a session name of [[span(!command (happy),style=background:lightgray)]].
Client and server exchange empty [[span(MESSAGE_TYPE_MSG,style=background:coral)]] packets while the connection is idle. (Notice [[span(SEQ,style=background:orange)]] and [[span(ACK,style=background:olive)]] don't change.)
Client and server exchange empty [[span(MESSAGE_TYPE_MSG,style=background:coral)]] packets while the connection is idle. (Notice [[span(SEQ,style=background:orange)]] and [[span(ACK,style=background:olive)]] don't change.)
Now the server has 17 bytes to send. (It happens to be a command to send the contents of the file "dnscat.c", but the details aren't important.) The client has randomly chosen the CNAME response record type, so the server has to format its data as a domain name.
Now the server has 17 bytes to send. (It happens to be a command to send the contents of the file "dnscat.c", but the details aren't important.) The client has randomly chosen the CNAME response record type, so the server has to format its data as a domain name.
The client sends 101 bytes. Notice the client's ACK has advanced 17 bytes from 7643 to [[span(7654,style=background:olive)]]. The data is long enough that the client has to use multiple labels in the DNS name. The server's response advances the ACK from 9037 to [[span(909c,style=background:olive)]].
The client sends 101 bytes. Notice the client's ACK has advanced 17 bytes from 7643 to [[span(7654,style=background:olive)]]. The data is long enough that the client has to use multiple labels in the DNS name. The server's response advances the ACK from 9037 to [[span(909c,style=background:olive)]].
[https://members.loria.fr/LNussbaum/tuns.html TUNS] is an IP-layer (VPN-like) tunnel described in the paper [https://members.loria.fr/LNussbaum/files/tuns-sec09-article.pdf "On Robust Covert Channels Inside DNS"] by Lucas Nussbaum, Pierre Neyron and Olivier Richard. It works at the IP layer (VPN-like). Compared to other tunnels, TUNS aims for better compatibility with existing servers, at the expense of efficiency. (The paper claims that characters such as `'_'` and `'/'`, as used by [[#iodine]] and dns2tcp, are not standards-compliant, but that's not quite true: they are just outside of the maximum-compatibility set recommended by RFC 1035. The authors acknowledge this in the "Future Work" section.)
[TUNS](https://members.loria.fr/LNussbaum/tuns.html) is an IP-layer (VPN-like) tunnel described in the paper ["On Robust Covert Channels Inside DNS"](https://members.loria.fr/LNussbaum/files/tuns-sec09-article.pdf) by Lucas Nussbaum, Pierre Neyron and Olivier Richard. It works at the IP layer (VPN-like). Compared to other tunnels, TUNS aims for better compatibility with existing servers, at the expense of efficiency. (The paper claims that characters such as `'_'` and `'/'`, as used by [[#iodine]] and dns2tcp, are not standards-compliant, but that's not quite true: they are just outside of the maximum-compatibility set recommended by RFC 1035. The authors acknowledge this in the "Future Work" section.)
* Uses CNAME exclusively.
* Uses CNAME exclusively.
* Encodes with base32, using `'0'` as a padding character instead of `'='`.
* Encodes with base32, using `'0'` as a padding character instead of `'='`.
...
@@ -271,9 +269,9 @@ Answers
...
@@ -271,9 +269,9 @@ Answers
* Eschews EDNS.
* Eschews EDNS.
* Caches responses so that duplicated queries get identical responses.
* Caches responses so that duplicated queries get identical responses.
== TUNS sample conversation ==
## TUNS sample conversation
Taken from [https://members.loria.fr/LNussbaum/files/tuns-sec09-article.pdf#page=6 Fig. 2] of the paper.
Taken from [Fig. 2](https://members.loria.fr/LNussbaum/files/tuns-sec09-article.pdf#page=6) of the paper.
* [[span(message type,style=background:coral)]]: `d` for data, `l` for server queue length; `r` for data request
* [[span(message type,style=background:coral)]]: `d` for data, `l` for server queue length; `r` for data request
@@ -282,8 +280,7 @@ Taken from [https://members.loria.fr/LNussbaum/files/tuns-sec09-article.pdf#page
...
@@ -282,8 +280,7 @@ Taken from [https://members.loria.fr/LNussbaum/files/tuns-sec09-article.pdf#page
The client sends [[span(d,style=background:coral)]] data. The server responds with an [[span(l,style=background:coral)]] indicating that it has [[span(4,style=background:gold)]] responses in its queue.
The client sends [[span(d,style=background:coral)]] data. The server responds with an [[span(l,style=background:coral)]] indicating that it has [[span(4,style=background:gold)]] responses in its queue.
The client sends [[span(r,style=background:coral)]] data requests to drain the server's queue. The server sends back [[span(d,style=background:coral)]] data responses.
The client sends [[span(r,style=background:coral)]] data requests to drain the server's queue. The server sends back [[span(d,style=background:coral)]] data responses.
[https://dankaminsky.com/2004/07/29/51/ OzymanDNS] is a suite of DNS tools. droute.pl (client) and nomde.pl (server) implement a tunnel. It implements more of a netcat-like interface, but the code is old and crufty and doesn't work out of the box. Described in the talk [https://events.ccc.de/congress/2004/fahrplan/files/297-black-ops-of-dns-slides.pdf "Black Ops of DNS"] from 2004 (pages 12–17).
[OzymanDNS](https://dankaminsky.com/2004/07/29/51/) is a suite of DNS tools. droute.pl (client) and nomde.pl (server) implement a tunnel. It implements more of a netcat-like interface, but the code is old and crufty and doesn't work out of the box. Described in the talk ["Black Ops of DNS"](https://events.ccc.de/congress/2004/fahrplan/files/297-black-ops-of-dns-slides.pdf) from 2004 (pages 12–17).
* Uses TXT exclusively.
* Uses TXT exclusively.
* Uses base32 (without padding) in queries; base64 (padded, with newline breaks) in responses.
* Uses base32 (without padding) in queries; base64 (padded, with newline breaks) in responses.
* Supports long TXT records (multiple 255-byte-long strings concatenated in one resource record). Seems hardcoded to use exactly two TXT strings in a record.
* Supports long TXT records (multiple 255-byte-long strings concatenated in one resource record). Seems hardcoded to use exactly two TXT strings in a record.
* For serializing messages, allows only one query or response in flight ([https://www.bamsoftware.com/papers/fronting/#sec:deploy-tor like meek]).
* For serializing messages, allows only one query or response in flight ([like meek](https://www.bamsoftware.com/papers/fronting/#sec:deploy-tor)).
* Sort-of has SEQ and ACK fields, but they seem advisory and not really used.
* Sort-of has SEQ and ACK fields, but they seem advisory and not really used.
* Quarter duplex: each query–response pair either sends a piece of data (`up`) or receives a piece of data (`down`), not both.
* Quarter duplex: each query–response pair either sends a piece of data (`up`) or receives a piece of data (`down`), not both.
* Responses encode the number of server-queued messages as the first byte of a `pending` A record in the Additional section.
* Responses encode the number of server-queued messages as the first byte of a `pending` A record in the Additional section.
* Doesn't use EDNS in my tests, though [https://events.ccc.de/congress/2004/fahrplan/files/297-black-ops-of-dns-slides.pdf#page=7 the slides] say Hi Bandwidth Payloads using EDNS are "Under Development". The [[#TUNS]] paper claims OzymanDNS uses EDNS.
* Doesn't use EDNS in my tests, though [the slides](https://events.ccc.de/congress/2004/fahrplan/files/297-black-ops-of-dns-slides.pdf#page=7) say Hi Bandwidth Payloads using EDNS are "Under Development". The [[#TUNS]] paper claims OzymanDNS uses EDNS.
== OzymanDNS sample conversation ==
## OzymanDNS sample conversation
[[attachment:ozymandns.pcap]]
[ozymandns.pcap](None/ozymandns.pcap)
The nomde.pl server supports more than just DNS tunneling, so you have to scope your tunnel requests under a distinguished subdomain (here `myservice`).
The nomde.pl server supports more than just DNS tunneling, so you have to scope your tunnel requests under a distinguished subdomain (here `myservice`).
The session is using session ID [[span(35765,style=background:springgreen)]]. Here the client has sent no data and the server has sent back 12 bytes in response. The first byte [[span(0,style=background:gold)]] of the `pending` A record indicates that the server has no further data queued at the moment.
The session is using session ID [[span(35765,style=background:springgreen)]]. Here the client has sent no data and the server has sent back 12 bytes in response. The first byte [[span(0,style=background:gold)]] of the `pending` A record indicates that the server has no further data queued at the moment.
Now the client has 18 bytes to send. It encodes them into an A query. The first byte `18` of the server's answer just echoes the number of bytes received.
Now the client has 18 bytes to send. It encodes them into an A query. The first byte `18` of the server's answer just echoes the number of bytes received.
{{{
```
#!html
<pre style="background:cornsilk">
<pre style="background:cornsilk">
Transaction ID: 0x9d9a
Transaction ID: 0x9d9a
Flags: 0x0100 Standard query
Flags: 0x0100 Standard query
...
@@ -432,12 +424,11 @@ Answers
...
@@ -432,12 +424,11 @@ Answers
Address: 18.0.0.0
Address: 18.0.0.0
</pre>
</pre>
</blockquote>
</blockquote>
}}}
```
Now the client wants to send 273 bytes, which it splits up into 110+110+53.
Now the client wants to send 273 bytes, which it splits up into 110+110+53.
{{{
```
#!html
<pre style="background:cornsilk">
<pre style="background:cornsilk">
Transaction ID: 0xa5d2
Transaction ID: 0xa5d2
Flags: 0x0100 Standard query
Flags: 0x0100 Standard query
...
@@ -510,12 +501,11 @@ Answers
...
@@ -510,12 +501,11 @@ Answers
Address: 53.0.0.0
Address: 53.0.0.0
</pre>
</pre>
</blockquote>
</blockquote>
}}}
```
Now the server has 298 bytes to send, which it splits up as 220+78. After the first send, the client increments its count of received bytes from 12 to [[span(232,style=background:olive)]] and the server indicates that it has [[span(1,style=background:gold)]] further response queued.
Now the server has 298 bytes to send, which it splits up as 220+78. After the first send, the client increments its count of received bytes from 12 to [[span(232,style=background:olive)]] and the server indicates that it has [[span(1,style=background:gold)]] further response queued.
* Supports all of A, CNAME, MX, SRV, TXT, NULL, and PRIVATE resource records. NULL is like TXT but with slightly less overhead. PRIVATE uses a code in the [https://tools.ietf.org/html/rfc6895#section-3.1 private-use range], relying on other servers [https://tools.ietf.org/html/rfc3597#section-3 not to understand it and to leave it alone].
* Supports all of A, CNAME, MX, SRV, TXT, NULL, and PRIVATE resource records. NULL is like TXT but with slightly less overhead. PRIVATE uses a code in the [private-use range](https://tools.ietf.org/html/rfc6895#section-3.1), relying on other servers [not to understand it and to leave it alone](https://tools.ietf.org/html/rfc3597#section-3).
* Queries can be encoded with any of (autodetected):
* Queries can be encoded with any of (autodetected):
* base32 (but a mutant base32 with a different alphabet: `abcdefghijklmnopqrstuvwxyz012345`)
* base32 (but a mutant base32 with a different alphabet: `abcdefghijklmnopqrstuvwxyz012345`)
* base64 (again mutant with a different order and `'-'` and `'+'` in place of `'+'` and `'/'`) if the server is case-preserving
* base64 (again mutant with a different order and `'-'` and `'+'` in place of `'+'` and `'/'`) if the server is case-preserving
...
@@ -583,16 +573,15 @@ It has a lot of features, like password authentication, compression, and auto-pr
...
@@ -583,16 +573,15 @@ It has a lot of features, like password authentication, compression, and auto-pr
* Caches responses so that duplicated queries get identical responses.
* Caches responses so that duplicated queries get identical responses.
The iodine trace is more complicated than I want to walk through fully.
The iodine trace is more complicated than I want to walk through fully.
...
@@ -600,8 +589,7 @@ The first byte of queries indicates the type: `v` means version, `l` is login, `
...
@@ -600,8 +589,7 @@ The first byte of queries indicates the type: `v` means version, `l` is login, `
Here is a sample data transaction. The client and server have negotiated the base128 codec and the NULL record type. The client with user ID `0` sends a data packet and the server responds with no data (just a two-byte data header `\xa0\x20`). Note the client signals support for EDNS in the Additional section.
Here is a sample data transaction. The client and server have negotiated the base128 codec and the NULL record type. The client with user ID `0` sends a data packet and the server responds with no data (just a two-byte data header `\xa0\x20`). Note the client signals support for EDNS in the Additional section.
{{{
```
#!html
<pre style="background:cornsilk">
<pre style="background:cornsilk">
Transaction ID: 0x5607
Transaction ID: 0x5607
Flags: 0x0100 Standard query
Flags: 0x0100 Standard query
...
@@ -634,12 +622,11 @@ Answers
...
@@ -634,12 +622,11 @@ Answers
Null (data): \xa0\x20
Null (data): \xa0\x20
</pre>
</pre>
</blockquote>
</blockquote>
}}}
```
Here the client sends a `p` ping message. The server responds with a blob of unencoded data.
Here the client sends a `p` ping message. The server responds with a blob of unencoded data.
* According to the [[#TUNS]] paper, uses TXT and base64 (`[A-Za-z0-9/-]`).
* According to the [[#TUNS]] paper, uses TXT and base64 (`[A-Za-z0-9/-]`).
* [http://tadek.pietraszek.org/projects/DNScat/index.html DNScat] by Tadek Pietraszek – ''different'' than the similarly named [https://wiki.skullsecurity.org/Dnscat dnscat] by Ron Bowes that was the predecessor of [[#dnscat2]]
*[DNScat](http://tadek.pietraszek.org/projects/DNScat/index.html) by Tadek Pietraszek – _different_ than the similarly named [dnscat](https://wiki.skullsecurity.org/Dnscat) by Ron Bowes that was the predecessor of [[#dnscat2]]
