RT-AC88U's Domain Name

[Tedd]

Please see attached image. Is a period not allowed?
My router's DNS server (which uses 1.1.1.1 as upstream) wasn't returning a result for my network's domain name until I changed it to 'lan'.
It was working until I updated to firmware v.384.9.

 

[RMerlin]

Domain names can contains periods, i.e. myhome.lan is valid.

 

[Tedd]

Domain names can contains periods, i.e. myhome.lan is valid.

Thanks for replying. I have a .org domain name, which I've used as my LANs domain for a few years now. It has been working until I updated to the latest merlin firmware. I changed it to 'lan' and now I get the proper IP address answer from dig. I change it back to my domain name and dig gives no answer from my router's DNS. It still gets a reply from 1.1.1.1 regardless.

To be clear, my router's WAN DNS settings is 1.1.1.1 and 1.0.0.1. LAN is blank, which as I understand it, gives DHCP clients the router's own IP as DNS server, which is reflected in my client's NIC status.

 

[RMerlin]

Thanks for replying. I have a .org domain name, which I've used as my LANs domain for a few years now

This is generally a really bad idea, unless you have ALL your LAN clients set to register against the actual authoritative nameserver (which is also a bad idea). Your router's dnsmasq is not considered authoritative for that .org domain.

 

[Tedd]

I'm sorry, what? This is news to me. For what reason is it a bad idea?

 

[RMerlin]

I'm sorry, what? This is news to me. For what reason is it a bad idea?

As I just said because of domain name authority. In your domain registration you defined 2 or more nameservers that are authoritative for that domain. If you have a DHCP server on your LAN, your clients will register their names with your LAN-based nameserver rather than the authoritative one (in Asuswrt's case, the dnsmasq instance on your router). When doing name resolution, that LAN server will believe to be authoritative for the entire domain, preventing (for instance) forwarding requests for "public" entries to the upstream nameserver (to be sent ultimately to the authoritative nameserver for resolution), making it impossible to properly resolve your own domain.

And if you somehow properly configure your LAN's nameserver to not be authoritative, it means all your Windows clients will be spamming your authoritative nameservers with host registration requests that will be rejected, but still will fill up that nameserver's logs with the rejected attempts.

I've seen too many customers having issues caused by this. My public nameservers are getting spammed with registration attempts from Windows clients. Or whenever I make a change to their authoritative DNS, they have to manually replicate the same change to their Windows server's own DNS, otherwise they are unable to access the new entry.

When on a LAN, you should use a non-public domain (more specifically a non-public TLD).

 

[Tedd]

Damn, well I just learned something..

Thanks for your replies, rmerlin. Could you maybe edit the help text for that feature to add a period to the list of allowed characters?

 

[RMerlin]

Damn, well I just learned something..

Thanks for your replies, rmerlin. Could you maybe edit the help text for that feature to add a period to the list of allowed characters?

I'll have to make sure Asus isn't reusing that text elsewhere where it might be more accurate.

 

[L&LD]

I'll have to make sure Asus isn't reusing that text elsewhere where it might be more accurate.

It's attention to little details like this that make your firmware so awesome. Thank you!

 

[sbsnb]

Technically, periods are NOT allowed in a domain name. Periods are delimiters between subdomain.domain.TLD. RFC 1035 specifies:

The labels in the domain name are expressed as character strings and
separated by dots.

They must start with a letter, end with a letter or digit, and have as
interior characters only letters, digits, and hyphen.  There are also some
restrictions on the length.  Labels must be 63 characters or less.

 

[RMerlin]

Technically, periods are NOT allowed in a domain name. Periods are delimiters between subdomain.domain.TLD. RFC 1035 specifies:

The labels in the domain name are expressed as character strings and
separated by dots.

They must start with a letter, end with a letter or digit, and have as
interior characters only letters, digits, and hyphen.  There are also some
restrictions on the length.  Labels must be 63 characters or less.

You need a dot between the TLD and the second level name however, which you have to enter in that field.

 

[RMerlin]

That string is defined in the dictionary files, and I refuse to touch these unless absolutely necessary, otherwise it would become its own project just trying to keep these up-to-date, in the 25 different languages that they currently support.

 

[Caveman]

As I just said because of domain name authority. In your domain registration you defined 2 or more nameservers that are authoritative for that domain. If you have a DHCP server on your LAN, your clients will register their names with your LAN-based nameserver rather than the authoritative one (in Asuswrt's case, the dnsmasq instance on your router). When doing name resolution, that LAN server will believe to be authoritative for the entire domain, preventing (for instance) forwarding requests for "public" entries to the upstream nameserver (to be sent ultimately to the authoritative nameserver for resolution), making it impossible to properly resolve your own domain.

And if you somehow properly configure your LAN's nameserver to not be authoritative, it means all your Windows clients will be spamming your authoritative nameservers with host registration requests that will be rejected, but still will fill up that nameserver's logs with the rejected attempts.

I've seen too many customers having issues caused by this. My public nameservers are getting spammed with registration attempts from Windows clients. Or whenever I make a change to their authoritative DNS, they have to manually replicate the same change to their Windows server's own DNS, otherwise they are unable to access the new entry.

When on a LAN, you should use a non-public domain (more specifically a non-public TLD).

Thanks for explaining this! I did exactly this and broke DNS resolution to my domain.

The reason I did it is I have a local computer (e.g. hostname is "computer") that I wanted to keep on the LAN and have TLS enabled for and got a certificate from LetsEncrypt for say computer.mydomain.com. However, I cannot resolve it unless I enter "mydomain.com" as the domain name in the router, but then as you pointed out, it breaks all my external services on that domain since it assumes my router is the nameserver for my domain. I seem to have a chicken or egg problem.

 

[Caveman]

As a follow-up to my question, I thought I'd share my solution. I issued a certificate using the DNS method then edited the hosts file to have an entry for that DNS name. Now I can have a LAN-only site with a valid certificate. It works great for Docker services that are run on my NAS. It would be ideal if I could permanently edit the hosts file on the router so that all devices get the same benefit. For now though it only needs to be on my development computer.

 

[ColinTaylor]

It would be ideal if I could permanently edit the hosts file on the router so that all devices get the same benefit.

Simple. Just create a custom config file (/jffs/configs/hosts.add) containing the appropriate line.

 

[Caveman]

Simple. Just create a custom config file (/jffs/configs/hosts.add) containing the appropriate line.

Thank you so much! It worked like a charm!