Enhancement: DNSTAP parsing of EDNS EDE messages

[johnhtodd]

A note for the community

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Use Cases

There have been a variety of extensions to the DNS in the last few years, one of which is EDE (Extended DNS Errors - https://www.rfc-editor.org/rfc/rfc8914.html) Many resolvers are now including EDE messages, and this is a very important part of parsing why errors happen, which is fundamental to why Vector is implemented on DNSTAP feeds in the first place. Inclusion of additional fault data sent by components is critically important to understanding failures at scale. DNS had a limited set of logging concepts with RCODEs, and this new RFC and message type extends the ability of DNS data to be meaningfully interpreted for failure conditions.

Attempted Solutions

The only other way I see doing this is somehow parsing the raw query data in the DNSTAP message, which is impractical and potentially just not possible within VRL, especially at any volume.

Proposal

I would propose that the DNSTAP modules in Vector correctly parse the type 15 (EDE) EDNS option set. Then, creation of an EDE object that contains the info-code and extra-text fields as part of the DNS object return, if such fields exist in the DNS object.

infoCode = integer purpose = string (associated with "purpose" as listed in the IANA registry - https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#extended-dns-error-codes ; null if no purpose mapping is found) extraText = string (whatever was in the field; null if no data in field)

Example:

  "responseData": {
    "ede": [
      {
        "infoCode": "6",
        "purpose": "DNSSEC Bogus",
        "extraText": "",
      }
    ]

These would appear in the "responseData" section of the output object, as EDE data is only attributable to replies, not queries (though EDNS data in general is applicable to both query and response.)

If extraText is null, then the string would be null. If there is no info-code, then the infoCode would be null (not zero, since zero has meaning.) Theoretically there should be no cases where infoCode is null, but weird things happen.

It is important to understand that there may be MORE THAN ONE set of EDE options returned in a message, so the EDE options must be an array, not a single object, even though currently replies with more than one EDE message are rare.

This is subtly different from https://github.com/vectordotdev/vector/issues/19847 which has as a goal the parsing of more RR types and sub-fields. Those are different from the EDNS EDE fields, which can exist in any/all DNSTAP responses or queries, including NXDOMAIN and SERVFAIL as well as NOERROR - all RCODE responses can have EDE messages, regardless of if there are RR-style answers in the reply or not.

References

https://github.com/vectordotdev/vector/issues/19847

Version

vector 0.36.0 (x86_64-unknown-linux-gnu 52049f8 2024-02-11 04:01:38.226860923)