Anomalous DNS queries from OPNsense

[pfry]

After reading "Update to latest OPNsense 24.7.9_1-amd64, now have 2 issues" I checked my firewall logs and saw an unusual number of DNS queries from OPNsense. I enabled the query log on my server, and in addition to (possibly) expected queries (e.g. NAT and Spamhaus) I saw:

Jan 09 17:13:00 [named] 09-Jan-2025 17:13:00.255 queries: info: client @0x39630104c20 47.190.83.202#26515 (bogonsv6): query: bogonsv6 IN AAAA + (47.190.83.191)
Jan 09 17:13:00 [named] 09-Jan-2025 17:13:00.255 queries: info: client @0x39630240a70 47.190.83.202#42637 (bogonsv6): query: bogonsv6 IN A + (47.190.83.191)

Yak! In the log:

2025-01-09T17:38:00-06:00   Notice   firewall   resolving 1 hostnames (0 addresses) for Martians_v6 took 0.00 seconds   
2025-01-09T17:38:00-06:00   Error   firewall   The DNS query name does not exist: bogonsv6. [for Martians_v6]

I had one reference to bogonsv6 in a configured alias, as logged. I removed it, which silenced the queries. I had noted that the alias never loaded... but I can't locate the log messages now, only:

2024-12-30T16:58:38-06:00   Notice   firewall    remove old alias bogonsv6

I would prefer to load the alias - it's not as though I don't have the space. Whether or not I need it.
I would prefer not to have the thing mistake a built-in alias for a DNS name and go nuts on it.

(Referring to the other topic, I did not see "<html" or similar queries. I did see a pile of worthless junk from Windows and Firefox - I need to trash this box.)

[dseven]

What type of alias was it? I'm guessing it was URL or URL Table, and "bogonsv6" was the "content"?

[pfry]

What type of alias was it? I'm guessing it was URL or URL Table, and "bogonsv6" was the "content"?

? It was the built-in "bogonsv6" alias. Not something I created. No edit option that I can see.

Which brings up the question: "Why are the bogon aliases special?" OPNsense has perfectly good URL alias capability - just make them standard aliases and optionally disable them by default. That way we could rename, delete, recreate, etc. and avoid the wackiness of a custom element. Just split the existing bogon file (keeping the old for legacy installs, naturally) and go. Stick creation instructions (a la Spamhaus DROP) in the wiki. Am I missing something?

[dseven]

I'm confused - you said "I had one reference to bogonsv6 in a configured alias, as logged. I removed it, which silenced the queries.". What was it that you removed?

[Patrick M. Hausen]

@dseven now that you mention it - bogons and bogons6 are builtin aliases used by the "block bogon networks" function. I wonder what exactly the OP did :)

[pfry]

I'm confused - you said "I had one reference to bogonsv6 in a configured alias, as logged. I removed it, which silenced the queries.". What was it that you removed?

The nested reference. "Martians_v6" contained "Private_v6" and "bogonsv6". I deleted the reference to "bogonsv6"; I now have no references to it. I do not currently use IPv6, so I have no references to any IPv6 aliases within rules.
Naturally I have similar aliases for IPv4, some of which I reference in rules.

@dseven now that you mention it - bogons and bogons6 are builtin aliases used by the "block bogon networks" function. I wonder what exactly the OP did :)

Ain't much to it: I stuck it into another alias. As I understand it there's some oddball code in OPNsense that doesn't load (populate) the "bogonsv6" alias (even though it downloads the data) if it is not referenced in a rule. Nesting the unpopulated alias within another causes it to... malfunction. I assume this is not the desired behavior.

If your "bogonsv6" is unpopulated, i.e. "Loaded#" is blank, insert it into another alias and see what happens (watch your General Firewall log or nameserver query log). I realize I was not clear in my original post - OPNsense made continuous queries with a relatively short retry interval. A moderate spew.
There's always a possibility that my installation is broken - the alias was populated when I first installed OPNsense. Either way the thing's buggy.

[pfry]

[...]
As I understand it there's some oddball code in OPNsense that doesn't load (populate) the "bogonsv6" alias (even though it downloads the data) if it is not referenced in a rule.
[...]

Bah! I was wrong about that. It's worse: it only loads the "bogonsv6" alias when "Block bogon networks" is checked on at least one interface. So I can nest the alias in another, apply it in a rule, and if I uncheck the interface setting, the alias disappears and the system starts making DNS queries for "bogonsv6". Of course I can cheese it - in a completely silent fashion, by applying it to a bridge member interface, where the rules cannot be hit. Fixing cheesy workarounds with cheesy workarounds is double cheese.

[meyergru]

If anything is a bug here, then it is that these internal aliases can be referenced by another user-defined alias. Apparently, this is the only way to do so (e.g. you cannot reference them directly in a rule) and it is probably an oversight. Most of the other internal aliases are prefixed by underscores to hide them, though.

One could argue that bogons and RFC1918 IPs could be exposed as regular aliases, because they come in handy for several purposes. For RFC1918, the definition is very simple. I have one going and would never use an internal alias. If I had an application for bogons, I would find a way to create one myself, too (especially when I now know that there is a URL where I can get it, although the OpnSense variant is handled specially). The way it is handled internally is a mere optimisation, not a bug because you use an unwanted side-effect.

[dseven]

Yeah, I suspect that they're not supposed to be referenced/nested in other aliases, and if it "works" under some circumstances, it's probably by accident, and that does seem like it'd be a bug.

[pfry]

[...]
The way it is handled internally is a mere optimisation, not a bug because you use an unwanted side-effect.

From a philosophical standpoint I disagree. Failing to use standard mechanisms that are available invites such side effects. Occam's razor.
I understand expedience, installed base, "people like it", "I don't have to use it", "sounds like an upstream problem", etc. Bad design is bad. It's also worth fixing.