Pipeline queries and match reordered replies
03Pipelining means sending another query before the earlier reply arrives. A fast second lookup may finish first, even though TCP preserves the bytes in each direction.
ID 17 with picnic.example. IN A matches the remaining outstanding query on C1. Both transactions are now complete.
Source for this drawing: RFC 7766 · Read RFC section 7 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Match the transaction, not its position in the queue.
- Clients SHOULD pipeline queries and SHOULD NOT wait for each outstanding reply. Servers MUST expect pipelined queries, SHOULD process them concurrently, and SHOULD answer all of them.
- Clients MUST NOT reuse the DNS Message ID of an in-flight query on the same connection. Stub and recursive resolvers MUST handle replies in a different order from requests.
- Clients MUST match replies to outstanding queries on the same TCP connection using Message ID. If a question is present, they MUST also match QNAME (queried name), QCLASS (record class) and QTYPE (record type).
Servers are RECOMMENDED to prepare responses in parallel and send them out of order; recursive servers SHOULD return them as available. This is not reordered TCP bytes: complete B response bytes precede A response bytes. The failure gate illustrates preventing wrong delivery, not a mandated DNS error code. An absent question does not add a new requirement to reject an otherwise matching Message ID. Message matching is not authentication.
Read the RFC section ↗