Reverse DNS: BCP163/RFC6303

Software SW help
#1

My Turris Omnia (details further down) implements the default BCP163 behaviour
as expected. I am wondering how to over-ride this so that reverse DNS works
for the RFC1918 and RFC4193 (ULA) addresses which are in use on my network.

From BCP163:

An implementation of this recommendation MUST provide a mechanism to
disable this new behaviour, and SHOULD allow this decision on a zone-
by-zone basis.

Selected details of my Turris:

  • OPENWRT_DEVICE_PRODUCT=“Turris Omnia”
  • OPENWRT_DEVICE_REVISION=“v0”
  • OPENWRT_RELEASE=“TurrisOS 6.2.2 8b46a263ab4afaf9857f0d29d369c2eefbf8a4f4”
#2

Non-global PTR records are still a bit troublesome on Turris. First of all, you’ll want to know how to add configuration for Knot Resolver: Knot resolver (i.e. kresd) - DNS advanced settings for Omnia and MOX [Turris wiki]

Automatic mappings get into DNS if you check the corresponding option in reForis, so it’s possible to get those just by unblocking them

policy.add(policy.suffix(policy.PASS, {todname('1.168.192.in-addr.arpa.')}))

A down-side is that it will also unblock non-existing addresses in that range, so the upstream servers then get asked those queries.

You can do the same with IPv6. There it’s a bit more difficult to write the reverse range. I usually call kdig -x full:IPv6::address and then cut it on the appropriate place (also works the same with dig).

We have WIP upstream to make combining all the rules “just work” the way most people expect, so that no config will be needed in this case, but it surely won’t arrive to Turris soon enough for you.

#3

Thanks for your quick response, Vladimír, and for your advice on how to customize the kresd configuration. I’ll need to think about what will work best for me. It’s not a downside to have kresd forward to either of my carefully-configured local resolvers,
already referenced by a “custom forwarder” configuration, which works as expected
for forward DNS.

It may be less work for me simply to over-ride DHCP option 6 so that it refers to my
resolver addresses rather than to the address of the Turris. In this case, it would make
sense to change (whatever generates) /etc/resolv.conf on the Turris to use those addresses rather than the localhost addresses, and perhaps to disable kresd.

I’m not sure what you mean by “automatic mappings”. Do you mean entries
generated from the DHCP hostname asserted by the client?

Thanks again.

#4

It should be whatever names the DHCP server (dnsmasq) knows about, including statically configured ones.

/etc/resolv.conf probably isn’t very interesting for you, as it’s only for the router itself. DHCP option 6 can be overridden in LuCI; I expect you’ve found that already.

#5

I might want to have the router use my managed resolvers, rather than doing its own thing; fewer moving parts makes for easier troubleshooting …

#6

With

resolution doesn’t work as expected; DNAME/CNAME is not followed.

It seems that I need to use policy.FORWARD() instead of policy.PASS.

I’m not seeing any change in behaviour after /etc/init.d/resolver restart;
it seems that a reboot is necessary.

#7

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.