dnsdist: ability to append data to packet #6846
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.
The ability to pass additional environment information from
I would like to add the following functionality:
The use case here is that we would have a
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
The text was updated successfully, but these errors were encountered:
@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.
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.