dnsdist: ability to append data to packet

[dmccombs]

• Program: dnsdist
• Issue type: Feature request

Short description

This is a feature request that I would intend to implement myself, but want to get a general idea of whether this functionality would be accepted in a pull request before I go forward, so I can weigh other implementation paths I could take before starting.

Usecase

The ability to pass additional environment information from dnsdist to downstreams that would otherwise not have that information, outside of standard DNS data to avoid invalidating TSIG hashes.

Description

I would like to add the following functionality:

• Ability to append data to the end of the DNS packet before it's sent to a downstream from a rule and/or Lua

The use case here is that we would have a dnsdist instance with access to additional client information handling queries signed with TSIG, which needs to pass the additional client information on to downstreams we also control to be used in determining responses, without invalidating the TSIG hash. By appending the data to the end of the packet after the length of DNS data, it would normally be ignored by resolvers.

I recognize this is a pretty specific use case, so I'm trying to get an idea of whether we can add a generic enough and useful feature to dnsdist that would be accepted, but would meet our needs, before we go forward with deciding on how we proceed ourselves. Feedback and thoughts welcome.

[dmccombs]

Any more thought on whether this kind of feature would be accepted before I pursue it any further?

[johnhtodd]

Interesting at least to me. Are you considering using EDNS as the transport mechanism?

[cmouse]

Wonder if XPF extension could be extended for this purpose?

[dmccombs]

@johnhtodd the drawback of using EDNS in this case would be causing the TSIG from the inbound query to no longer be valid, unless you mean using that as the format appended outside of the DNS data at the end of the packet in some way.

[johnhtodd]

@cmouse It seems that XPF is a very limited solution; it would only allow inclusion of IP addresses. I think a more generalized EDNS tagging method would be interesting, though it would imply that the downstream receiver also has some way of then consuming that data into it's process logic. I can see how this might be useful for including (as examples) specific data about how to handle queries based on received IP address, or protocol type (DNS-over-TLS, DoH, DNSCrypt, etc.) or with tagging elements that might change based on geographic lookup data that occurs at the edge of the DNS processing pipeline.

@dmccombs On TSIG - I can't say I have spent much time thinking about it, nor do I have much experience with TSIG. I think adding "magic data" to the end of the packet creates a very limited set of conditions where it is useful, though of course your own situation may be one of those. You'd also have to propose changing whatever resolver (pdns-recursor?) to accept those magic data bytes and permit them to be viewed by higher-level tools like Lua. Doing this somehow with EDNS still seems to be a bit more agreeable, though it may introduce other hacks to deal with TSIG. Thinking out loud: maybe the sender transmits a magic DNS no-op packet that contains the transaction ID of the following packet, a qclass of "254 (NONE)", and the variables in EDNS format a few microseconds before transmitting the real DNS query; then the receiver can keep a few milliseconds worth of "variables" in memory waiting for the real packets to come in and connecting them together by virtue of the transaction ID. Hackish... but possible.

[johnhtodd]

I'd still be very interested in a generic EDNS option:value reading and writing system in dnsdist, pdns-recursor, and pdns-auth. For at least our case of clusters of dnsdist/pdns-recursor systems this might eliminate some out-of-band signaling and other issues which we have to use port selection to signal (which is not an ideal model, especially as cardinality increases.)

After some more thought, the hackish model I suggest in the comment above using two subsequent queries above breaks if there are multiple receivers (anycast) because you can't guarantee that the no-op packet containing the values will go to the same server as the unmodified DNS event packet (update or query.) It also requires creation of another state machine, which probably Bad.

The original suggested model where data is just arbitrarily added on the end of the packet seems fragile, at best. I understand that's the only way it will work with TSIG, and my comments seem to be de-railing your original request with a different concept that is somewhat related but won't solve your problem; sorry about that, it's not my intent. But it seems that your use case is very (very!) slim, whereas an EDNS-based model would be more standards-compliant and would probably be extendable across other DNS software. If you write a patch, it might be useful to others in some edge cases but I have no idea if it would be accepted into the main distribution.