@Tescophil, on which page?

The client list has a hostname column, although not visible by default.

This said, I'm using a newer OC (HW/FW) in conjunction with an ER605.

 

Or maybe you're saying that the hostnames displayed are not what you expect.

Currently the host names displayed in the UI come directly from the host itself. What I'm asking is that the controller do a reverse DNS lookup to see if there is a DNS host name set for each host, and then display this in preference to the local device host name.

@Tescophil,

Given the gateway doesn't act as a DNS server (Are there anu plans to implement authoritative DNS server functionality in Omada SDN ? - Business Community (tp-link.com)) even for hosts that it assigns IP addreses to, I assume you setup a local DNS server.

I'm interested in some details of your setup because it seems cumbersome if it's not combined with the DHCP server.

 

Did you offload DHCP to a separate host?

Would your setup handle multiple VLANs?

 

In any case, your request might be easier to satisfy if the gateway had DNS functionality (even if limited to DHCP issued addresses), right?

  @EricPerl 

 

So, I was looking to replace the functionality I had on my previous router having switched to an ER605, but I've now reconfigured my setup to get round this limitation.

 

In the Omada setup I reserve IP addresses for all the devices on my network.

 

Each VLAN subnet has DHCP enabled on the Omada interface and sets the DNS server for all networks to 192.168.100.10 & 11

 

On 192.168.100.10/11 I have an AdGuard Home DNS server setup. This has a host file which defines host names for each device that has a DHCP reservation.

 

 

@Tescophil, thanks for sharing these details.

 

I'm allergic to setups that would have me enter the same information (IP) in 2 different places.

Even if it would be quite manageable at my scale, I just can't settle for such an implementation.

I'd rather spend some time finding a satisfying option.

 

I'm in the process of recycling an older NUC as a linux box for some networking tasks:

• DHCP/DNS (looking into DNSMasq)
• Syslog (if I find a better GUI for viewing than what I have on Windows)
• ...

 

Per another thread, my OC200 might have some trouble handling the meager load I need.

Maybe I'll end up with a software controller!

 

I picked up on your thread because the syslog server I'm using now can be setup to do a reverse lookup of IP addresses in the logs.

Unfortunately, there's no DNS for local devices out of the box, let alone reverse DNS.

Apart from the few hosts I need to access here and there, that would a readability improvement when looking at these logs.

Personally, I'd prefer that DNS functionality (both ways) be available out of the box...

 

Then your request would be more likely to be handled.

As of now, it would rely on customers having some local DNS and I'm not sure what percentage that represents...

  @Tescophil 

 

Whilst I very much appreciate your puritanical approach ;-) I'm also a big fan of simplicity and replaceability.

 

I also looked into creating a DHCP server for multiple VLANS, but its too complicated (as far as I can see...), by far the simplest solution is to let the router handle DHCP for multiple VLANS and create address DHCP address reservations. For each new device I add (I have 90+), I just have to create a reservation on the Omada interface, then put the matching entry in my DNS servers host file.

 

This way, I could easily replace the router with another model, and simply enter the existing address reservations, or I could replace the DNS server which would use my existing hosts file. Also, its SIMPLE. I like the sound of your solution, parsing syslogs, picking out DNS names etc, but it sounds complex, and would not be easy to replace if you switched to another router etc.

 

It's personal preference at the end of the day, but recently I've been trying to move away from more 'involved' solutions and follow the KISS principle. That's why I replaced my Untangle UTM I have been running for over 10 years with an Omada router to match the rest of my network (that, and the increasing licence fees for Untangle...)

 

 

@Tescophil,

 

I can sympathize with the simple approach. OTOH, I could have left the entire network flat and not even bothered with VLANs.

At this point, this is also a learning exercise and things might as well be done in a way that scales.

Reliability is key for me (things tend to break when I'm traveling) so I'm not going to go crazy either.

 

I had started acquiring some Ubiquiti gear but availibilty has been a real issue lately.

It's definitely simpler so stay in one ecosystem. So all tp-link for now.

This said, logging is poor and the lack of DNS is suboptimal so I'll try to shore up where I can.

 

I could circle around when I'm further along but I don't think it would be so hard to replace any pieces.

As long as the router can offload DHCP, I should be fine.

Router does routing. DHCP/DNS lives somewhere else. I suspect it's always the case in larger networks.

DNSMasq seems to have all features I need:

• DHCP over n VLANs/Subnets on 1 instance
• FQDN per subnet
• More DNS than I need 

...

 

I'm also looking for an alternate syslog server.

The one I tried (beyond the fact that I had to put on a machine that had to be in a VLAN that didn't match) ended up having couple fatal flaws.

It used a bunch of no longer supported components and the nice UI can't be used in the free version (despite what the edition comparison chart indicated).

The only "nice" feature that was left was that DNS reverse lookup. It didn't make up for the above.

 

Since this is partially about learning new things, I'll convert an older PC over to Linux to host some of these core services...

@Tescophil , @sReggy 

The following thread would be addressed by this feature request:

TL-ER605 ban DHCP server - Business Community (tp-link.com)

The last reply on that thread (that's now locked) is the OP lamenting that his DNS assigned names are not showing up in the controller's client list.

EricPerl wrote

 

Router does routing. DHCP/DNS lives somewhere else. I suspect it's always the case in larger networks.

  @EricPerl 

Hi,

on this point I would like to share my thoughts and look at three cases.
1. case: large business: you would probably choose a multi-thousand-dollar setup consisting of Microsoft server and cisco or hp hardware, in which you also run dhcp and dns. I don't see any room for a $50 router in such a setup.
2. smaller business: you would choose a setup for a few hundred dollars. e.g. an opnsense appliance. But it also leaves nothing to be desired, so you don't need a TP-Link router either.
3. small office, enthusiast.
If you're on a tighter budget or just have the wish for a single vendor ecosystem (Omada in this case), then there shouldn't be a need to use multiple vendors just to offer local dns. So everything should work out of one box. and that includes local dns in my opinion.
In the case of Omada, this can be done by the router or the controller. Of course, the router would be preferable, because the thing then works in standalone mode also.

 

I don't know why TP-Link has been struggling against a local dns like dnsmasq for years with the business routers. There have been enough forum entries lately where users wish a local dns. I hope TP-Link finally recognizes the need.

One last thought: if I, as a manufacturer, would think that a local dns is unnecessary in my router, then I could also omit the dhcp-server, because that can also run on different hardware. Or vice versa: if I integrate dhcp-server I should also integrate local dns server to have a complete product. The competitors can and do that, so why not TP-Link?

Have a nice day

@nutzich,

 

Tp-link is likely very aware of the market segments they can target with their HW.

There's no point conjecturing here. Some of the "stories" on the website imply you might be a bit pessimistic about their prospects though ;-)

 

I've mentioned it earlier in a reply to the OP. I completely agree with you that some DNS functionality built-in the router seems to be a pre-requisite to this feature request.

It would make little sense to enable a feature that relies on the existence of an external "server".

Some form of internal DNS first, then leverage it in the management interface.

 

I really wish tp-link added DNS. Having played with dnsmasq configuration over the last few days (adding my own DHCP/DNS server to get DNS), I now wonder how easy/difficult it is to build a visual interface to manage it. You just can't ask customers to edit config files. It wouldn't fit. There must be existing art in that space though.

 

But I have to disagree with you on one point. It totally makes sense for tp-link to offer DHCP out of the box for a router.

It's actually pretty typical for consumer routers (wireless or not). The obvious reason is that most customers would not want to have to buy/manage another device for DHCP alone.

Only large customers will want DHCP out of their routers.

 

My quoted argument was about modularity. Offer things in an order that makes sense. DHCP/routing/DNS/reverseDNS/lookups-in-UI.

Allow functionality to be externalized.

Personally, DHCP+DNS is a set that benefits from being together because of the correlation by IP.

I know they can be managed separately but it would kinda blow if a client lost its lease and DNS became stale/incorrect (and fixed IP / reservations is a workaround at best).

IIRC, in Windows environment, DNS is updated after a machine gets its IP (I don't remember who handles that).

IMO, that level of consistency is a must and I don't know how to achieve it without fixed IPs (kinda defeats DHCP) or some sync with DNS (benefit of being in a Windows domain). That's why I'm shooting for co-hosting with dnsmasq.