Add BGP data as a transformation

[johnhtodd]

Is your feature request related to a problem? Please describe. Many resolvers (authoritative and recursive) even in enterprise environments are using anycast, and that automatically implies a different routing view of the global tables at each location, so this is not an uncommon configuration. We have 260 locations, & we need to understand how each query is being transmitted back to the other side of the communication, so that can be graphed and tracked. BGP is the defacto routing model that every large provider supports, so it seems most reasonable that a BGP-based lookup happens in order to supply the tagging data. Maxmind data is both far too inaccurate and simply cannot possibly contain the path data that we need in order to solve traffic balance forecasting and other traffic engineering decisions or troubleshooting.

Describe the solution you'd like Having go-dnscollector able to add tags containing BGP data as a transformation would be highly useful. Reading in BGP data from a static file that is updated with some frequency would be ideal. These files can be generated in a standard format (MRT) for searching, and results cached for rapid, small-memory footprint lookups.

Describe alternatives you've considered Some of this data (but not all) can be found in Maxmind ASN database files, but those has several significant problems:

1. frequency of update is very long (days? weeks? months?) and ASN data may be outdated
2. the path data does not exist - only origin is present in MaxMind, and path data will be different for each location
3. the origin asn may not be correct on a per-location basis, due to multi-announcers (legitimate or hijack)
4. RFC1918/RFC4193 addresses will not be correctly discovered for internal origins

Additional context We use frr on our telemetry systems for this type of work already, which can easily export MRT structures on a timed basis. MRT seems like a reasonable file format, and is standardized in the routing software community. There is a Go library for reading MRT files. Given the size of the global table, that would seem to strongly suggest better performance would be obtained from caching the results since only a very small subset of the tables will be used at even the largest anycast location.

https://pkg.go.dev/github.com/jackyyf/go-mrt https://datatracker.ietf.org/doc/html/rfc6396 https://docs.frrouting.org/en/latest/packet-dumps.html#packet-binary-dump-format https://docs.frrouting.org/en/stable-9.0/bgp.html#clicmd-dump-bgp-routes-mrt-PATH-INTERVAL

• The MRT files will change (refresh) with some frequency. Probably not more than every minute, but possibly that rapidly. (More realistic: every 5-10 minutes.) There should be a check that if the data is cached, that the new file data is imported on a regular cycle. (configurable as a housekeeping loop?) If the file has not changed size or timestamp, keep the cache and continue on. If the timestamp or size has changed, flush the cache and start doing lookups for new addresses as they are seen. I suppose this could just be a housekeeping loop that looks at the file on a fixes but rapid interval, but it seems like the config should be able to block un-necessarily rapid changes in the MRT file because that would reset the cache and be "expensive" in unpredictable ways.

• If there is no BGP data available in the cache or in the lookup, the insert "0" for origin ASN, "0" for BGP path, and "0.0.0.0/0" for BGP prefix (if they are selected to be tagged.)

• Would it be useful to override the "as-owner" search data with the "real" AS origin? A lookup in this new stanza into the Maxmind files for the actual AS could be performed, to get a value for the "as-owner" for the data we get out of BGP. In exceptionally rare cases that might be interesting to compare the current-ness of the Maxmind data against reality, but I see no other use for that method. I will not include this concept in my examples below, but it seems it would only imply two new lines in the config: the path to the "mmdb-asn-file:" and then a flag to include a "bgp-as-owner:" label.

• Is it too complex to consider that there may be multiple MRT files, used in different transformations in the configuration file? If so, then statistics for prometheus need to be somehow named in the configuration file so that it is possible to distinguish between different behaviors of those different transformation stanzas.

Options:

• include origin ASN
• include full BGP path (this will also include origin ASN)
• include most specific BGP prefix in which origin (or destination) appears to be included

Config options:

• use specific BGP MRT file
• how often to check if the MRT file is updated?
• do we include the origin AS as a tag?
• do we include the BGP path as a tag?

Example configuration stanza:

transforms: bgp: mrt-file: "/var/mrt/full-table.mrt" mrt-checkupdate-interval: 600 bgp-origin-asn: yes bgp-path: yes bgp-prefix: yes

Example tagging:

{ "bgp": { "bgp-origin-asn": "19281", "bgp-path": "174 2914 42 19281", "bgp-prefix": "149.112.112.0/24", },

Logging data for prometheus:

• the number of prefixes that are actively cached from the current MRT file
• the total number of BGP prefixes in the current MRT file
• the timestamp on the current MRT file
• the number of seconds since the current MRT file was seen as "new"
• the amount of memory taken by cached route entries
• the number of times a BGP lookup cache miss has happened
• the number of times a BGP lookup cache hit has happened