Problems with SOA of reverse DNS
-
My pfSense has the IP 10.4.0.1/16 on the LAN if and has some IPSec VPN tunnels to some 10.x.0.0/16 networks. For any reason dnsmasq claims to be authoritative for 10.in-addr.arpa (by sending the aa flag, as well by providing a SOA record) which it should not do, since this zone is shared by several DNS servers in my infrastructure. Anyway, it does NOT claim to be authoritative for 4.10.in-addr.arpa, which it actually should be.
I tried to set dnsmasq authoritative for 10.4/16 by setting the advanced option "auth-zone=4.10.in-addr.arpa,16", which should be a valid option according to dnsmasq(8). When saving the DNS settings in pfSense UI I receive the error "Invalid custom options". Am I misunderstanding the auth-zone option or is there a parsing-problem in the pfSense UI?
Thanks,
Manuel -
dnsmasq claims to be authoritative for 10.in-addr.arpa (by sending the aa flag, as well by providing a SOA record)
I see the aa flag for specific hosts on a network, but not seeing SOA or aa for parent in-addr.arpa zones.
Can you post some examples of this?
So if I query say 168.192.in-addr.arpa. I get nxdomain
Do you have advanced options already set, do you have domain over rides set?
-
I see the aa flag for specific hosts on a network, but not seeing SOA or aa for parent in-addr.arpa zones.
Okay, I have the same behavior, I do not receive the aa flag (anymore?) for SOA nor for PTR. Sorry for the confusion. Right now I have no additional options set, but I have set some domain overrides (basically for my internal domain and for x.10.in-addr.arpa, which might be the reason for change of behavior?).
But to come back to the main part of my question: I want that dnsmasq responds authoritative for 4.10.in-addr.arpa and also shows that in the SOA, that it is the authoritative DNS server for that domain. Is the option "auth-zone=4.10.in-addr.arpa,16" valid and correct for that behavior?
-
Well you wouldn't use " I don't think, so I did this - see attached, where em0 is my lan interface that has a IP in that network. The other option there is from before, I don't see a point of a 1 second TTL which pfsense use to use.
And here is the response I get when I query SOA for my 192.168.1 network
C:\>dig 1.168.192.in-addr.arpa SOA ; <<>> DiG 9.9.5-W1 <<>> 1.168.192.in-addr.arpa SOA ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47771 ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;1.168.192.in-addr.arpa. IN SOA ;; ANSWER SECTION: 1.168.192.in-addr.arpa. 600 IN SOA pfsense.local.lan. hostmaster.pfsense.local.lan. 1393688694 1200 180 1209600 600 ;; AUTHORITY SECTION: 1.168.192.in-addr.arpa. 600 IN NS pfsense.local.lan. ;; Query time: 80 msec ;; SERVER: 192.168.1.253#53(192.168.1.253) ;; WHEN: Sat Mar 01 09:45:28 Central Standard Time 2014 ;; MSG SIZE rcvd: 174 ``` edit: hmm adding these records seems to have broke normal forwarding and lookups. To be honest seems more like you need full nameserver features I would prob look to the bind package that is available.   -
edit: hmm adding these records seems to have broke normal forwarding and lookups. To be honest seems more like you need full nameserver features I would prob look to the bind package that is available.
I already thought that this might be necessary, but still wanted to check the possibilities of dnsmasq.
May I ask which version of pfSense you are running, since my box ( 2.1-RELEASE (i386) built on Wed Sep 11 18:16:44 EDT 2013, FreeBSD 8.3-RELEASE-p11) keeps refusing the advanced option auth-zone=4.10.in-addr.arpa,16. I even tried 1:1 your example from the screenshot and it also was refused with Invalid custom options.
-
edit: hmm adding these records seems to have broke normal forwarding and lookups. To be honest seems more like you need full nameserver features I would prob look to the bind package that is available.
I already thought that this might be necessary, but still wanted to check the possibilities of dnsmasq.
May I ask which version of pfSense you are running, since my box ( 2.1-RELEASE (i386) built on Wed Sep 11 18:16:44 EDT 2013, FreeBSD 8.3-RELEASE-p11) keeps refusing the advanced option auth-zone=4.10.in-addr.arpa,16. I even tried 1:1 your example from the screenshot and it also was refused with Invalid custom options.
–auth-zone=<domain>[,<subnet>[/<prefix length="">][,<subnet>[/<prefix length="">]…..]]
Define a DNS zone for which dnsmasq acts as authoritative server. Locally defined DNS records which are in the domain will be served. If subnet(s) are given, A and AAAA records must be in one of the specified subnets.
As alternative to directly specifying the subnets, it's possible to give the name of an interface, in which case the subnets implied by that interface's configured addresses and netmask/prefix-length are used; this is useful when using constructed DHCP ranges as the actual address is dynamic and not known when configuring dnsmasq. The interface addresses may be confined to only IPv6 addresses using <interface>/6 or to only IPv4 using <interface>/4. This is useful when an interface has dynamically determined global IPv6 addresses which should appear in the zone, but RFC1918 IPv4 addresses which should not. Interface-name and address-literal subnet specifications may be used freely in the same --auth-zone declaration.The subnet(s) are also used to define in-addr.arpa and ipv6.arpa domains which are served for reverse-DNS queries. If not specified, the prefix length defaults to 24 for IPv4 and 64 for IPv6. For IPv4 subnets, the prefix length should be have the value 8, 16 or 24 unless you are familiar with RFC 2317 and have arranged the in-addr.arpa delegation accordingly. Note that if no subnets are specified, then no reverse queries are answered.</interface></interface></prefix></subnet></prefix></subnet></domain>
examples auth-zone=our.zone.com,1.2.3.0/24 auth-zone=lan.thekelleys.org.uk,2a01:348:29f::/48 auth-zone=demo.deltalibre.org.ar,2a00:1508:1:feca::/64So shouldn't it look more like auth-zone=4.10.in-addr.arpa,subnethere/16 ? It says subnets are also used to define the in-addr domains for reverse queries and that if no subnets are specified no reverse queries are answered.
-
I am running
2.1.1-PRERELEASE (i386)
built on Thu Feb 13 13:59:46 EST 2014
FreeBSD 8.3-RELEASE-p14 -
examples auth-zone=our.zone.com,1.2.3.0/24 auth-zone=lan.thekelleys.org.uk,2a01:348:29f::/48 auth-zone=demo.deltalibre.org.ar,2a00:1508:1:feca::/64So shouldn't it look more like auth-zone=4.10.in-addr.arpa,subnethere/16 ? It says subnets are also used to define the in-addr domains for reverse queries and that if no subnets are specified no reverse queries are answered.
I didn't see that example section so far, in the man page. This part helped me to configure it:
auth-server=server.example.com,eth0 auth-zone=our.zone.com,1.2.3.0/24 and two records in the external DNS server.example.com A 192.0.43.10 our.zone.com NS server.example.comUnhappily dnsmasq stops handling domain overrides when in DNS authoritative mode. Can anyone confirm that, or do I have a configuration issue here?
-
examples auth-zone=our.zone.com,1.2.3.0/24 auth-zone=lan.thekelleys.org.uk,2a01:348:29f::/48 auth-zone=demo.deltalibre.org.ar,2a00:1508:1:feca::/64So shouldn't it look more like auth-zone=4.10.in-addr.arpa,subnethere/16 ? It says subnets are also used to define the in-addr domains for reverse queries and that if no subnets are specified no reverse queries are answered.
I didn't see that example section so far, in the man page. This part helped me to configure it:
auth-server=server.example.com,eth0 auth-zone=our.zone.com,1.2.3.0/24 and two records in the external DNS server.example.com A 192.0.43.10 our.zone.com NS server.example.comUnhappily dnsmasq stops handling domain overrides when in DNS authoritative mode. Can anyone confirm that, or do I have a configuration issue here?
could you add log-queries to advanced options and have a look to see what it actually is doing when it doesn't process the domain override?
