Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

autohost_tld: fritz.box - not starting up #2961

Closed
3 tasks done
kultfigur opened this issue Apr 15, 2021 · 15 comments
Closed
3 tasks done

autohost_tld: fritz.box - not starting up #2961

kultfigur opened this issue Apr 15, 2021 · 15 comments

Comments

@kultfigur
Copy link

kultfigur commented Apr 15, 2021

v0.106.0-a.126+b3f6592a
I set autohost_tld in AdGuardHome.yaml to fritz.box (the default domain name of all Fritz-Box routers)
AdGuardHome not reachable anymore

Prerequisites

Please answer the following questions for yourself before submitting an issue. YOU MAY DELETE THE PREREQUISITES SECTION.

  • I am running the latest version
  • I checked the documentation and found no answer
  • I checked to make sure that this issue has not already been filed

Issue Details

  • *Version of AdGuard Home server:
  • v0.106.0-a.126+b3f6592a
  • How did you install AdGuard Home:
    Github releases, etc.
  • How did you setup DNS configuration:
    Unbound on 127.0.0.1:5335
  • If it's a router or IoT, please write device model:
    Raspberry Pi 4 Model B)
  • CPU architecture:
    ARM
    Operating system and version:
    Raspbian

Expected Behavior

AdGuardHome coming up after a reboot

Actual Behavior

AdGuardHome not reachable

Screenshots

Screenshot:

Additional Information

@ainar-g
Copy link
Contributor

ainar-g commented Apr 15, 2021

Hi, and thank you for the report. Currently, the autohost TLD is expected to be a top-level domain, so second-level domains aren't supported.

@ameshkov, should we allow any level in that setting? Should we also rename it into something like autohost_namespace?

@kultfigur
Copy link
Author

Would be nice. I thought I could replace these dns settings with it.

resolve local

[/168.192.in-addr.arpa/]192.168.178.1
[/fritz.box/]192.168.178.1

@ameshkov
Copy link
Member

Would be nice. I thought I could replace these dns settings with it.

These aren't needed anymore anyway since PTR resolution is done with the local resolver anyway.

@ameshkov, should we allow any level in that setting? Should we also rename it into something like autohost_namespace?

I am not entirely sure about it.

@kultfigur
Copy link
Author

But without this line [/fritz.box/]192.168.178.1
my browser never resolves http://fritz.box
That's why I thought autohost_tld was made for it

@ainar-g ainar-g self-assigned this Apr 15, 2021
@ainar-g ainar-g added this to the v0.106.0 milestone Apr 15, 2021
@ainar-g
Copy link
Contributor

ainar-g commented Apr 15, 2021

We'll see if we can do this during the current development cycle. I will write if we have any updates.

adguard pushed a commit that referenced this issue Apr 15, 2021
Updates #2961.

Squashed commit of the following:

commit 207eeb8
Author: Ainar Garipov <A.Garipov@AdGuard.COM>
Date:   Thu Apr 15 18:48:50 2021 +0300

    all: allow local non-top-level domains
@ainar-g
Copy link
Contributor

ainar-g commented Apr 15, 2021

@kultfigur, it turned out that this feature was easier to implement than we initially thought. It should be available as of snapshot v0.106.0-a.132+d83091fc on the edge channel. On restart, the name of the parameter will be automatically changed from autohost_tld to local_domain_name to reflect the change.

Can you please check if the new feature works for you?

@kultfigur
Copy link
Author

Ok, here my results. I have set everything accordingly, uncommented my old dns settings, cleared my wlan leases, cleared the browser cache, but still Safari and Chrome on W10 won't open http://fritz.box

9FE76C30-95A8-40EC-B65F-5284E7534879
00D238E8-6F04-4EB6-A34E-D88F0CF5B3BE
9729D519-9099-46F9-9574-0E1F8D6945B9

@ainar-g
Copy link
Contributor

ainar-g commented Apr 15, 2021

I think there is a misunderstanding here. fritz.box is now the domain name under which the other machines in your networks are found. That is, if you have a machine called myphone, and it got its IP from AdGuard Home's DHCP server, you can now access it using the host myphone.fritz.box. local_domain_name has nothing to do with the address of the router in this case.

https://github.com/AdguardTeam/AdGuardHome/wiki/DHCP#autohosts

@kultfigur
Copy link
Author

kultfigur commented Apr 15, 2021

ok, understood. AdGuard is not my DHCP server, that is the Fritz.box router. But nevertheless, why are the browser requests for fritz.box sent upstream? And not to the private dns server?
BB98AF29-CF75-4091-8F3E-DD472CEBE2D2

@ainar-g
Copy link
Contributor

ainar-g commented Apr 15, 2021

Because currently we only consider hostnames of the form *.fritz.box to be local to the network and not fritz.box itself. We'll see if we can make it work that way as well in an acceptable time frame. Please keep the issue open.

In the meantime, writing something like:

192.168.178.1      fritz.box

Into the /etc/hosts file on the machine where AGH is started should make http://fritz.box work for clients. (Assuming your router has the address 192.168.178.1.) The upstream rule for fritz.box should also be kept until we resolve this.

@ainar-g
Copy link
Contributor

ainar-g commented Apr 16, 2021

After considering the issues and the system more thoroughly, I think there was a bit of confusion here:

  1. The local domain name feature currently only makes sense when AGH is the DHCP servers of the network. If AGH is not the DHCP server, it will simply respond with NXDOMAIN to all such queries. So perhaps it's currently better that you don't set your local_domain_name to fritz.box.

  2. Your custom upstream rule seems perfectly fine for the issue at hand. Since AGH is not the DHCP server in your case, using a custom upstream for the requests that you know are local is exactly what you would want. At least with AGH's current feature set.

The two enhancements we can make in a future version are:

  1. If AGH receives a query about a host in the local domain, and AGH doesn't know anything about the host, perhaps it should forward the query to private DNS resolvers. That would probably make your setup work without the custom upstream rule as long as you set the router as your private DNS resolver.

  2. Perhaps we should also make the runtime clients accessible using the local domain. On your screenshot I can see that AGH actually does know about fritz.box and the other machine thanks to AGH's rDNS feature.

We'll look into these enhancements further. In the meantime, does keeping the custom upstream rule and changing the local_domain_name to something else (for example, the default value, lan) make your system work better?

@kultfigur
Copy link
Author

Hi,

thank you very much, I appreciate your efforts. Yes, maybe there are different ideas in our heads what the autohost_tld parameter is all about. What I simply want, after installing AGH, is reaching my local devices via their IP and their names. Including my router on http://fritz.box. Like before I installed AGH. Currently it's only possible when I add these two rules to AGH dns settings:
[/168.192.in-addr.arpa/]192.168.178.1
[/fritz.box/]192.168.178.1
With those two rules everything is fine. So there is no real issue on my side. But, as you say, AGH already has all the necessary information about my local devices and could do without those extra rules. Would make it easier for the users.

@ainar-g
Copy link
Contributor

ainar-g commented Apr 20, 2021

@kultfigur, are you absolutely sure that the first rule is still required? The second rule will have to stay for a while.

@jkreileder
Copy link

For me PTR resolution works fine without extra rules (IPv4 and 6). But I also ran into the same problem, i.e. I also tried replacing [//] by setting local_domain_name. Maybe the documentation should be made clearer here.

@ainar-g
Copy link
Contributor

ainar-g commented Apr 23, 2021

Thank you all for the input! The documentation definitely needs improvement. I filed #3003 as an issue for these improvements. We'll continue keeping possible changes in mind. I'll close this issue for now.

@ainar-g ainar-g closed this as completed Apr 23, 2021
heyxkhoa pushed a commit to heyxkhoa/AdGuardHome that referenced this issue Mar 20, 2023
Updates AdguardTeam#2961.

Squashed commit of the following:

commit 207eeb8
Author: Ainar Garipov <A.Garipov@AdGuard.COM>
Date:   Thu Apr 15 18:48:50 2021 +0300

    all: allow local non-top-level domains
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants