As said earlier by @frollic and others you need to configure an exception for that address (or even the whole domain):
/ee-wifi.ee.co.uk/{EE dns server address}
That should go into "DNS Forwards" in "DHCP and DNS":
You should be able to see EE's DNS IP in the System Log.
See also Stubby needs extra Start after Restart of Router - #6 by AndrewZ
all of ^ would work too...
and the resolv.conf file.
my problem from the beginning has been finding that elusive dns server ip
so i just reset the router. created just one wireless client. rebooted. and waited..
voila i found dns server in syslog
Sat Apr 16 13:40:46 2022 daemon.notice wpa_supplicant[2427]: wlan0: SME: Trying to authenticate with 6a:a2:22:1a:11:da (SSID='EE WiFi' freq=2437 MHz)
Sat Apr 16 13:40:46 2022 kern.info kernel: [ 980.133256] wlan0: authenticate with 6a:a2:22:1a:11:da
Sat Apr 16 13:40:46 2022 kern.info kernel: [ 980.205816] wlan0: send auth to 6a:a2:22:1a:11:da (try 1/3)
Sat Apr 16 13:40:46 2022 kern.info kernel: [ 980.324506] wlan0: send auth to 6a:a2:22:1a:11:da (try 2/3)
Sat Apr 16 13:40:46 2022 daemon.notice wpa_supplicant[2427]: wlan0: Trying to associate with 6a:a2:22:1a:11:da (SSID='EE WiFi' freq=2437 MHz)
Sat Apr 16 13:40:46 2022 kern.info kernel: [ 980.335869] wlan0: authenticated
Sat Apr 16 13:40:46 2022 kern.info kernel: [ 980.344724] wlan0: associate with 6a:a2:22:1a:11:da (try 1/3)
Sat Apr 16 13:40:46 2022 kern.info kernel: [ 980.355601] wlan0: RX AssocResp from 6a:a2:22:1a:11:da (capab=0x401 status=0 aid=2)
Sat Apr 16 13:40:46 2022 kern.info kernel: [ 980.363537] wlan0: associated
Sat Apr 16 13:40:46 2022 daemon.notice netifd: Network device 'wlan0' link is up
Sat Apr 16 13:40:46 2022 daemon.notice netifd: Interface 'wwan' has link connectivity
Sat Apr 16 13:40:46 2022 daemon.notice netifd: Interface 'wwan' is setting up now
Sat Apr 16 13:40:46 2022 daemon.notice wpa_supplicant[2427]: wlan0: Associated with 6a:a2:22:1a:11:da
Sat Apr 16 13:40:46 2022 daemon.notice wpa_supplicant[2427]: wlan0: CTRL-EVENT-CONNECTED - Connection to 6a:a2:22:1a:11:da completed [id=0 id_str=]
Sat Apr 16 13:40:46 2022 kern.info kernel: [ 980.372343] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Sat Apr 16 13:40:46 2022 kern.info kernel: [ 980.393097] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0-1: link becomes ready
Sat Apr 16 13:40:46 2022 kern.info kernel: [ 980.399957] br-lan: port 2(wlan0-1) entered blocking state
Sat Apr 16 13:40:46 2022 kern.info kernel: [ 980.405541] br-lan: port 2(wlan0-1) entered forwarding state
Sat Apr 16 13:40:46 2022 daemon.notice netifd: Network device 'wlan0-1' link is up
Sat Apr 16 13:40:46 2022 daemon.notice wpa_supplicant[2427]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Sat Apr 16 13:40:46 2022 daemon.notice netifd: wwan (2448): udhcpc: started, v1.30.1
Sat Apr 16 13:40:47 2022 daemon.notice netifd: wwan (2448): udhcpc: sending discover
Sat Apr 16 13:40:50 2022 daemon.notice netifd: wwan (2448): udhcpc: sending discover
Sat Apr 16 13:40:50 2022 daemon.notice netifd: wwan (2448): udhcpc: sending select for 10.9.253.145
Sat Apr 16 13:40:50 2022 daemon.notice netifd: wwan (2448): udhcpc: lease of 10.9.253.145 obtained, lease time 1500
Sat Apr 16 13:40:50 2022 daemon.notice netifd: Interface 'wwan' is now up
Sat Apr 16 13:40:50 2022 daemon.info dnsmasq[1472]: reading /tmp/resolv.conf.auto
Sat Apr 16 13:40:50 2022 daemon.info dnsmasq[1472]: using local addresses only for domain test
Sat Apr 16 13:40:50 2022 daemon.info dnsmasq[1472]: using local addresses only for domain onion
Sat Apr 16 13:40:50 2022 daemon.info dnsmasq[1472]: using local addresses only for domain localhost
Sat Apr 16 13:40:50 2022 daemon.info dnsmasq[1472]: using local addresses only for domain local
Sat Apr 16 13:40:50 2022 daemon.info dnsmasq[1472]: using local addresses only for domain invalid
Sat Apr 16 13:40:50 2022 daemon.info dnsmasq[1472]: using local addresses only for domain bind
Sat Apr 16 13:40:50 2022 daemon.info dnsmasq[1472]: using local addresses only for domain lan
Sat Apr 16 13:40:50 2022 daemon.info dnsmasq[1472]: using nameserver 86.189.0.94#53
thank you
doesn't look very elusive to me ?
you can also run a nslookup directly from the router, to find out.
nothing in resolv.conf
# cat /etc/resolv.conf
search lan
nameserver 127.0.0.1
and dodgy domains
# nslookup ee.co.uk
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: ee.co.uk
Address 1: 198.18.5.42
** server can't find ee.co.uk: SERVFAIL
# nslookup ee-wifi.ee.co.uk
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: ee-wifi.ee.co.uk
Address 1: 217.39.0.50
Address 2: 109.144.192.50
*** Can't find ee-wifi.ee.co.uk: No answer
what do you make of this?
elusive because it doesn't always show up in syslog.. and not the same often
i think they hijack dns queries upstream of me. their routers don't expose dns server configuration at all.
check /tmp/resolv.conf.d/resolv.conf.auto instead
... because it isn't used, for this.
don't appear to belong to EE, are you surprised they don't work ?
are you saying EE announces external DNSes for their internal FQDNs ?
nslookup ee-wifi.ee.co.uk 86.189.0.94
both belong to the parent, AS2856 British Telecommunications PLC
sure, but it doesn't mean they resolve the internal EE FQDNs.
(but no, I didn't know EE belonged to BT).
i think ee purchased bt
some years ago
HaHaHaHa!! EE was acquired by BT in 2016.
Notice that you get a different result for ee-wifi.ee.co.uk depending on whether you are using a public nameserver or the nameservre received over DHCP while not logged in. The latter one will lead to the login page. Using the 217 IP probably leads to a general page about BT or EE and not the page that you need to log in.
It looks like the IP that starts with 88 might be an individual BT customer's IP, because the particular customer's gateway that you have connected to handles your login.
It's not that DNS is being "hjacked" but that captive portal logins usually involve private IPs that are only known by the captive DNS server available to not logged in connections and advertised over DHCP. For proper results, you must use only that DNS server while logging in. After that you can switch to a different one including a secured. As has been mentioned, travelmate includes code to do this automatically.
i think i finally have a working secure dns (https-dns-proxy) thanks to all of you
are you recommending stubby over https-dns-proxy?
Yes I do, but I linked this post mainly because ntp may require the same DNS handling.
Care to explain how the post you made solved the problem OP had ? Cos I'm lost...
curl gives us the captive portal domain name and nslookup shows that the portal IP address is not private, so there is no need to change rebind protection in dnsmasq.
With the "exception" configured - forwarding one domain to specific DNS using /portal_domain/dns_server_ip - it is now safe to forward all the requests to secure DNS server of choice; portal name will be excluded from that and will be served by the ISP DNS.
Once portal authentication is complete, the local secure DNS forwarder or proxy gets access to the Internet and starts serving the requests.
why do you recommend stubby over https-dns-proxy? i find https-dns-proxy is going crazy after a reboot, hogging cpu till i signon captiveportal. sometimes it takes me a while to login.
how to handle dns for ntp? do i use captiveportal dns for ntp servers too?
You said your ISP hijacks DNS requests, in this case you can use any non-encrypted DNS server, like /ee.co.uk/1.1.1.1.
Which exact version of https-dns-proxy are you having these issues with?
ah that works thanks
i see [https-dns-proxy 2021-09-27-1] on settings page in luci