When enriching data from a third-party DNS filter for UDM compatibility, which approach aligns with the least effort and maintainability?

• A. Modify ingestion source definition to remap raw fields directly to UDM.
• B. Enable asset enrichment to infer missing fields.
• C. Use a custom parser that outputs raw JSON.
• D. Create a parser extension mapping missing source fields to correct UDM and attach to existing parser.

Answer: (D)

Focusing on a light-touch, maintainable way to align third-party DNS filter data with the UDM schema means extending the existing parsing layer rather than reworking upstream or adding downstream guesswork. By creating a parser extension that maps the missing source fields to the correct UDM fields and attaching it to the current parser, you keep the change localized where the data actually enters your system. This leverages the established ingestion and validation logic, so you preserve consistent data quality and schema conformity without scattering mapping rules across multiple components.

This approach centralizes the field mappings in one place, making updates straightforward if the DNS filter output changes or UDM requirements evolve. It reduces risk because you’re not altering how data is ingested from upstream (which could affect other data or pipelines) and you’re not introducing a separate path that downstream systems must interpret. It also avoids the overhead of building custom parsing that outputs raw JSON, which would require additional downstream work to rehydrate into UDM, increasing maintenance burden and potential for drift.

In contrast, changing the ingestion source to remap fields directly can create upstream dependencies and broader blast-radius changes; using asset enrichment to infer fields can be unreliable or insufficient for full UDM compatibility; and a separate custom parser emitting raw JSON imposes extra parsing logic downstream and more code to maintain.