Feature Request: Reverse DNS support

TL;DR: Please:

  • add a reverse-resolution option to monitoring tools
  • let the DNS-update tool submit PTR records
  • let the IPv6 DHCPv6 server provide the RFC4704 FQDN field to the binding-script.

I believe that both forward and reverse naming every device brings order and humanity to a well-designed network. Naming server resources properly is a given, but automatically naming clients is important, too. I relegate all DHCP client names to a subdomain where I don’t care what name the device provides to the DHCP server, but it helps a lot with network monitoring and troubleshooting when the name in both forward and reverse-DNS matches what the device calls itself.

I reverse-name everything so I can quickly tell at a glance what any device may be doing what as I monitor my network. With Mikrotik’s tools, the reverse name cannot be automatically resolved. For example, the Connections in IP/Firewall, The Torch tool, Packet Sniffer, and others. As a network admin, if I have to track down network abuse using those tools, I have to open a terminal and run “dig” manually to find out the reverse name of every address I need to consider. Yes, it takes time to reverse-resolve addresses automatically, but it takes more time for me to do it as a human. To have a checkbox option to turn on reverse name lookup on monitoring tools as needed would lift RouterOS another notch in awesomeness.

Of course, to do this, we have to begin with the ability to easily reverse-name client devices. I realize that I could probably write some kind of web CGI script that can receive name updates REST posts from RouterOS for DNS updates, but that introduces another point of failure and security. It would make so much more sense if the DNS-update tool could support PTR records.

Reverse name lookups are even more critical with IPv6 because IPv6 names are less user-friendly. With RouterOS’s DHCPv6 server, I can’t even automatically forward-name hosts because the binding-script doesn’t have the RFC-4704 option_fqdn variable that a client may provide when they want to be named. (The “FQDN” in the field name is misleading; it doesn’t actually have to be fully-qualified.)

Thanks for listening.

Thank you for the good ideas in a well-described format. Whether there will be time or interest to implement them is in question…