DNS Forwarder Custom Options always gives "Invalid custom options"
-
@blaize vtnet0 that is a proxmox thing is it not? That is sure not an interface name you would see on pfsense on hardware.
As @stephenw10 showed it works with that simple max-ttl=30 command.. And it works for me using your command and a source IP. Guess I could try it with the interface name.
So it is not working with interface name on 2.7.2, I tried with actual interface name em0, tried with LAN, etc. But that server option works just fine IP address. Possible pfsense is only parsing for IP and not the interface name?
But your saying you can not even get max-ttl=30 working. Where the option box is clear and and only the max-ttl=30 in there?
[2.7.2-RELEASE][admin@test.mydomain.tld]/root: ps -auxwd | grep dnsmasq nobody 3335 0.0 0.5 17900 4568 - I 23:16 0:00.00 |-- /usr/local/sbin/dnsmasq -C /dev/null --no-resolv --all-servers --max-ttl=30 --server=8.8.8.8@192.168.9.34 --dns-forward-max=5 root 55093 0.0 0.0 436 264 0 R+ 23:17 0:00.00 | `-- grep dnsmasq [2.7.2-RELEASE][admin@test.mydomain.tld]/root:I can't duplicate that problem, it works with max-ttl=30 no problem.. But yeah its not taking name for the interface, but it works with IP just fine.
Not sure why your having issues with just the max-ttl, I tried adding spaces in front, after and it still worked, blank line in front even. Your on 2.7.2 right.. Yeah that is what running test on..
Shows its running
[2.7.2-RELEASE][admin@test.mydomain.tld]/root: dnsmasq -v Dnsmasq version 2.89 Copyright (c) 2000-2022 Simon KelleyI tired running the command manually
[2.7.2-RELEASE][admin@test.mydomain.tld]/root: /usr/local/sbin/dnsmasq -C /dev/null --no-resolv --all-servers --max-ttl=30 --server=8.8.8.8@em0 --dns-forward-max=5 dnsmasq: bad command line options: interface binding not supportedAnd it doesn't like using name.. But if use IP it takes it
[2.7.2-RELEASE][admin@test.mydomain.tld]/root: /usr/local/sbin/dnsmasq -C /dev/null --no-resolv --all-servers --max-ttl=30 --server=8.8.8.8@192.168.9.34 --dns-forward-max=5 [2.7.2-RELEASE][admin@test.mydomain.tld]/root:That sort of says it not just a parsing of the options box issue.
-
Mmm, that looks like the issue.
But even if it did work that option would simply tell dnsmasq to use em0 when connecting out to 8.8.8.8. It does not tell it to forward queries from em0 to 8.8.8.8.
-
@stephenw10 true, but just because option doesn't do what he thought it did is not really relevant to his issue. Curious what he has going on that he can't do max-ttl even? Unless he hasn't really tried that all by itself?
-
I think it is a bug. I stopped the daemon in the UI and ran the command in the console like it supposed to be my adding --max-ttl to the command.
/usr/local/sbin/dnsmasq -C /dev/null --rebind-localhost-ok --stop-dns-rebind --no-resolv --server=2600:1701:44d:6000::1 --server=192.168.1.254 --all-servers --dns-forward-max=5000 --cache-size=10000 --local-ttl=1 --max-ttl=30
Works fine. Something about the UI is not taking that parameter. It does not appear to be an issue with dnsmasq per se, rather the UI/backend trying to validate the option before starting the daemon.
-
@johnpoz All that to say, the --server parameter is supposed to specify the upstream server for a filter (ip address, domain name, interface, etc.) while everything else is local unless you suppress it. According to the docs:
"Specify upstream servers directly. Setting this flag does not suppress reading of /etc/resolv.conf, use --no-resolv to do that. If one or more optional domains are given, that server is used only for those domains and they are queried only using the specified server. This is intended for private nameservers: if you have a nameserver on your network which deals with names of the form xxx.internal.thekelleys.org.uk at 192.168.1.1 then giving the flag --server=/internal.thekelleys.org.uk/192.168.1.1 will send all queries for internal machines to that nameserver, everything else will go to the servers in /etc/resolv.conf."
But as I said, my problem looks more like an issue with the UI itself. I'm not sure what's going on there.
-
What exactly does your custom options field look like? I can't replicate the issue here in 2.7.2.
-
@stephenw10 nor can I.. And I tried all kinds of weirdness in how I put max-ttl=30 in the box.. blank lines before it, spaces before and after it etc.. It always took it just fine.
-
@stephenw10 Here's the screenshots.
-
Hmm, some rogue character in there?
Some other odd combination of options?
What does it look like in the config:
<dnsmasq> <enable></enable> <port>5353</port> <interface></interface> <custom_options>bWF4LXR0bD0zMA==</custom_options> </dnsmasq>You probably don't have the custom options value as it sees it as invalid when adding it.
-
@stephenw10 It doesn't save it between attempts.
I thought it might be a random character or something like that, which is why I tried other browsers. It doesn't seem to be a browser issue though.
-
Then I can only imagine it's conflicting with some other option you have set.
Is that line you posted above the actual command that's run by your config?
-
This is the generated line:
/usr/local/sbin/dnsmasq -C /dev/null --rebind-localhost-ok --stop-dns-rebind --no-resolv --server=2600:1701:44d:6000::1 --server=192.168.1.254 --all-servers --dns-forward-max=5000 --cache-size=10000 --local-ttl=1
This is the one I created:
/usr/local/sbin/dnsmasq -C /dev/null --rebind-localhost-ok --stop-dns-rebind --no-resolv --server=2600:1701:44d:6000::1 --server=192.168.1.254 --all-servers --dns-forward-max=5000 --cache-size=10000 --local-ttl=1 --max-ttl=30
Both of these work
The only thing difference is max-ttl. I don't think this has anything to do with dnsmasq.
-
@blaize said in DNS Forwarder Custom Options always gives "Invalid custom options":
The only thing difference is max-ttl. I don't think this has anything to do with dnsmasq.
That is a valid dnsmasq option
--max-ttl=<time>
Set a maximum TTL value that will be handed out to clients. The specified maximum TTL will be given to clients instead of the true TTL value if it is lower. The true TTL value is however kept in the cache to avoid flooding the upstream DNS servers.dnsmasq --help | grep max-ttl --max-ttl=<integer> Specify time-to-live in seconds for maximum TTL to send to clients. -
You have the <dnsmasq> config section generating that?
-
It doesn't matter what I put in the text box. It gives me the error. I was using the max-ttl option just to eliminate the variables. I put it on the the command line to make sure it was not a problem with dnsmasq. It really seems like something between validation for the custom options and starting the daemon.
-
@blaize what do you show in the xml for dnsmasq - like @stephenw10 example above.
-
@blaize The corresponding fix seems easy enough for a patch:
https://redmine.pfsense.org/projects/pfsense/repository/2/revisions/aac5bb5d396a1f1b18d59a532ad262a4d1085a40/diff
-
@Antibiotic said in DNS Forwarder Custom Options always gives "Invalid custom options":
ttps://redmine.pfsense.org/projects/pfsense/repository/2/revisions/aac5bb5d396a1f1b18d59a532ad262a4d1085a40/diff
huh - how is that related to reading a custom options entry? That is about domain overrides.
-
@Antibiotic said in DNS Forwarder Custom Options always gives "Invalid custom options":
https://redmine.pfsense.org/projects/pfsense/repository/2/revisions/aac5bb5d396a1f1b18d59a532ad262a4d1085a40/diff
Mmm, seems unrelated.
But I do have all the recommended patches applied on the 2.7.2 box I'm testing on which might be a difference. I don't see anything dnsmasq related there but....
-
@stephenw10 I can't say that I have the latest patches. I run the updates on the UI pretty frequently and it says I'm up to date.
2.7.2-RELEASE (amd64)
built on Mon Mar 4 14:53:00 EST 2024
FreeBSD 14.0-CURRENTThe system is on the latest version.
Version information updated at Thu Dec 19 12:27:08 EST 2024
