Question: How could extended logging without EDNS in query be possible with minimal change?

[zbalkan]

Hi Shreyas,

The LogExporterApp works as expected but I need to be able to provide the enriched and extended data whether the query datagram contains EDNS payload or not. So, the DNS query logs must contain the additional data all the time. What do you suggest for this kind of change?

[ShreyasZare]

Thanks for asking. If the request does not support EDNS then the response generated will not have EDNS too. The Log Exporter app will need to handle such issues since there is nothing that can be done about it on the DNS server side as this is part of the protocol.

[zbalkan]

I agree that it's against the protocol to return EDNS when not requested, it's not an opinion but a fact. The essence of the question is more about the elegant and reasonable way to carry the metadata on the blocking. If the query is not against a TXT record OR does not have EDNS, then the logs are crippled.

I cannot fix it in Log Exporter as the data does not exist in the answer datagram. So, for enriched logging purposes, there must be a third object carrying metadata the same way EDNS or TXT records are populated; so, regardless of the record type and EDNS, blocked response can be logged with blocking reason, plugin, etc.

What may be a good way for this? A dedicated Metadata class -or string but a class is better for validationand formatting, and an optional parameter in InsertLogAsync in this type?

[ShreyasZare]

Need to think on this. May be something can be done where the DNS datagram object carries the EDNS info but is not serialized when request does not support EDNS. Adding another metadata class would not be good since DNS requests are generated in many different places and all modules internally follow the DNS protocol to respond to queries. Will need to think on this for a while.

[zbalkan]

That's why I asked for an optional, additional class. It can be used for extended logging without breaking the datagrams, neither requests nor responses. The DnsDatagram class itself is not a POCO or value object for log purposes, so, breaking DNS processing logic for the sake of logging looks counterintuitive. This is for blocking apps to use optionally, so that logging apps can utilize if exists.

[zbalkan]

After some thinking, I believe Enrichment would be a better name than Metadata, which is a vague definition. Enrichment gives more information on what it is designed for semantically.

[zbalkan]

Something like;

Task InsertLogAsync(DateTime timestamp, DnsDatagram request, IPEndPoint remoteEP, DnsTransportProtocol protocol, DnsDatagram response, LogMetadata metadata = null);

would not break existing apps but allows extending functionality. What do you think?

[zbalkan]

I created a new PR for this #1827. It adds a couple of classes, but at the core, it is all about the new DnsQueryLogMetadata and integrating it into all the paths a log record is produced and consumed. With this, it is possible to extend the apps, provide enrichment in a no-schema way thanks to the dictionary.