NXDOMAIN for *.app.link

Hi,

After recent upgrades of unbound and using DoT toward 1.1.1.1 I noticed the following behavior:

  1. Only Android machines are impacted
  2. Any URL shorten-er that translates in an https://[AppName].app.link/ gets an NXDOMAIN as answer from unbound -> Chrome stops

Putting the Android on 4G/GMS data that links is somehow resolved -> chrome then starts the app dedicated to handle those links (ebay.app.link for example).

Is there any way to define the *.app.link in unbound or…anything else that would avoid the NXDOMAIN response? (and Chrome stop)

Thanks!
H&M

If this won’t resolve then 1.1.1.1 must not resolve this either.

I found the issue:

  1. DNS server 1.1.1.1 does resolve any app.link domain
  2. Unbound on the other hand responds with NXDOMAIN

Root Cause: /etc/unbound/local.d/blocklist.conf does contain directive

[root@ipfire ~]# grep app.link -R /etc/unbound/
/etc/unbound/local.d/blocklist.conf:local-zone: “app.link” always_nxdomain

Adding app.link in whitelist.txt solved the issue… now only the dangerous subdomains from app.link are blocked and not entire TLD+1

grep app.link -R /etc/unbound/
/etc/unbound/local.d/blocklist.conf:local-zone: “mangarock.app.link” always_nxdomain
/etc/unbound/local.d/blocklist.conf:local-zone: “mangarock-alternate.app.link” always_nxdomain

Sorry, my fault!
H&M

nslookup amazon.app.link
Server: 127.0.0.1
Address: 127.0.0.1#53

Non-authoritative answer:
Name: amazon.app.link
Address: 13.227.156.92
Name: amazon.app.link
Address: 13.227.156.78
Name: amazon.app.link
Address: 13.227.156.111
Name: amazon.app.link
Address: 13.227.156.12
Name: amazon.app.link
Address: 2600:9000:2017:ac00:19:9934:6a80:93a1
Name: amazon.app.link
Address: 2600:9000:2017:bc00:19:9934:6a80:93a1
Name: amazon.app.link
Address: 2600:9000:2017:4e00:19:9934:6a80:93a1
Name: amazon.app.link
Address: 2600:9000:2017:1400:19:9934:6a80:93a1
Name: amazon.app.link
Address: 2600:9000:2017:1000:19:9934:6a80:93a1
Name: amazon.app.link
Address: 2600:9000:2017:7e00:19:9934:6a80:93a1
Name: amazon.app.link
Address: 2600:9000:2017:0:19:9934:6a80:93a1
Name: amazon.app.link
Address: 2600:9000:2017:9200:19:9934:6a80:93a1

We don’t ship any file in /etc/unbound/local.d/ so it is not an IPFire problem…