What's new

Setting up IPV6 with DNS-over-TLS

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

I have been working with one of my remote AC68U's this afternoon that have native IPV6. I switched the IPV4 and IPV6 DNS to CF. Then enabled DoT with alternating CF IPV4 and IPV6 DoT resolvers. The CF DNS help page showed the IPV4 and IPV6 resolvers connected and DoT working. HAve not enabled DNSSEC yet.

So, my issue with 6RD and no connection to IPV6 resolvers is due to something internal? Would it hurt to have Stubby listen on the IPV6 loopback?
 
I have been working with one of my remote AC68U's this afternoon that have native IPV6. I switched the IPV4 and IPV6 DNS to CF. Then enabled DoT with alternating CF IPV4 and IPV6 DoT resolvers. The CF DNS help page showed the IPV4 and IPV6 resolvers connected and DoT working. HAve not enabled DNSSEC yet.

So, my issue with 6RD and no connection to IPV6 resolvers is due to something internal? Would it hurt to have Stubby listen on the IPV6 loopback?
i imagine it wouldn't hurt if you did it on any other port other than #53, because dnsmasq loopback is bound on top of #53 which means dnsmasq will have issues functioning properly since it is the acting cache.

you have 127.0.0.1 Nameserver at #53 then you got dnsmasq looping back to that 0::1#53, so that plays a major role in the initial setup, I imagine you should be able to use those on a different port though.

i would still take the time to leave 127.0.1.1 as a listening address as well though because most of the innards of the router are built around that when using the dnsprivacy funtion.
 
I am also interested in this also but first must enable IPv6 on my RT-AC68U connected to my Telus Actiontec 1200H.
So far am stuck at whether to set Native, Passthrough or Static IPv6. following this instruction:
https://www.asus.com/support/FAQ/113990
I have had no success in getting assistance or information from Telus and am reluctant to experiment as my setup is working so well on latest Merlin stable.
Can anyone please steer me in the right direction?

Actiontec screenshots:
View attachment 18176
View attachment 18177
Teksavvy DSL to the east of you in a region the ISP says supports IPv6 on my connection. I'm using a router they've provided bridged (and with that wifi off) as the modem before my ac86.
and TSI has been similaraly "huh, what?" when I ask for assistance getting it going, saying "it should just pass through and happen"
 
Teksavvy DSL to the east of you in a region the ISP says supports IPv6 on my connection. I'm using a router they've provided bridged (and with that wifi off) as the modem before my ac86.
and TSI has been similaraly "huh, what?" when I ask for assistance getting it going, saying "it should just pass through and happen"
Okay so quite a few means you can enable this for yourself.
you first need to ask ISP what type of connection you are receiving is it "static" or is native, or do you have a ppoe . once you determine that, you have to make sure your modem is in bridge mode (if it is separate from router). This would mean DHCP , NAT, and Firewall is disabled on it. the modem may not support you placing IPV6 dhcp as disabled- it may require and alternative method such as a Pass through method in which the connection would pass through the modem so you could then configure the connection type (native, static, or 6rd, etc) on the router. if the modem is built into the asus router like say for example DSL-68U , then you only need to figure out the type of ipv6 and then enable it.. if all else fails and you cannot get the modem( provided it is separate from the router) you can always leave the IPV6 as unbridged (meaning it still has DHCPv6 capabilities from the modem) and you would then use the Passthrough option on the router where the router will allow the modems ipv6 to pass through and the modem would still be handling the addressing.(note this is worse possible case)
 
you should check out this option test it out.. tell me what you think.
Code:
pc_insert "dnssec_return_status: GETDNS_EXTENSION_TRUE" "return_both_v4_and_v6: GETDNS_EXTENSION_TRUE" $CONFIG
I tried it on one of my remote AC68U's. Did not see that it retrieved any "new"keys and did not seem to improve performance in the limited testing I did.
 
Got it, 6RD can make sense, is it static or dynamic (options received by DHCP)?
Dynamic with Stateless LAN

Loopback addresses are not accesible for external clients, they can reach only extranal addresses (i.e LAN IP) where dnsmasq sits.
In answer to your Why... I was concerned that using port 53 internally may pose issues as external devices on the LAN use port 53 to talk to DNSMASQ. I guess you could disable caching on DNSMASQ and have Stubby listen on the router LAN IP address. Whole lot of options for folks to mess up. Still feel it is not a bad idea for stubby to listen on the IPV6 loopback port 53....
 
i notice more improvement with it from
https://www.dnsleaktest.com/
and ipleak.net
I'm not sure those "DNS Leak Tests" are valid. I've seen nothing other than "you DNS appears to be leaking" no matter what I do. I feel it is more smoke and mirrors to get folks to buy VPN client services. As for me I will use VPN client on a PC or mobile device but not on a router.
 
Still feel it is not a bad idea for stubby to listen on the IPV6 loopback port 53....
I don’t have a comparable setup to see for myself, but when IPv6 is enabled on the router, does dnsmasq point to the Stubby IPv6 loopback in your configuration? Does anything communicate with it? If you run netstat -anlp who is listening on port 53?
 
I'm not sure those "DNS Leak Tests" are valid. I've seen nothing other than "you DNS appears to be leaking" no matter what I do. I feel it is more smoke and mirrors to get folks to buy VPN client services. As for me I will use VPN client on a PC or mobile device but not on a router.
what i mean is you will see more of the servers actually being used.
 
I don’t have a comparable setup to see for myself, but when IPv6 is enabled on the router, does dnsmasq point to the Stubby IPv6 loopback in your configuration? Does anything communicate with it? If you run netstat -anlp who is listening on port 53?
i typed that in on mine and it is one giant list :eek::eek::eek: do you have an option that he can use that would make it specifically target only port 53
 
Dynamic with Stateless LAN
Ok.

Still feel it is not a bad idea for stubby to listen on the IPV6 loopback port 53....

With all the respect to feelings, it is technically known to be the bad idea.
There's no way to force stubby to listen on some tcp ip : port unless you move dnsmasq from there.
Same is true for lan, loopback addresses, no matter the family (v4/v6).

starting stubby with ::1@53 when dnsmasq is already running:
socket(AF_INET6, SOCK_DGRAM, IPPROTO_IP) = 6
setsockopt(6, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(6, SOL_TCP, TCP_FASTOPEN, [1], 4) = -1 ENOPROTOOPT (Protocol not available)
bind(6, {sa_family=AF_INET6, sin6_port=htons(53), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_scope_id=0}, 28) = 0
socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 8
setsockopt(8, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(8, SOL_TCP, TCP_FASTOPEN, [1], 4) = 0
bind(8, {sa_family=AF_INET6, sin6_port=htons(53), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_scope_id=0}, 28) = -1 EADDRINUSE (Address already in use)
close(8) = 0
stubby can't listen on TCP [::1]:53, because port is busy by dnsmasq.
althrough stubby doesn't complain to listen on UDP [::1]:53, but it will work as poor-man per-cpu load-balancing - part of queries to [::1]:53 will go to stubby, other part - to dnsmasq. if dnsmasq has [::1]:53 upstream, half of possible dnsmasq's queries will be looped back into it.

starting dnsmasq when stubby is already running with ::1@53:
socket(AF_INET6, SOCK_DGRAM, IPPROTO_IP) = 18
setsockopt(18, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
fcntl64(18, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(18, F_SETFL, O_RDWR|O_NONBLOCK) = 0
setsockopt(18, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0
bind(18, {sa_family=AF_INET6, sin6_port=htons(53), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_scope_id=0}, 28) = 0
setsockopt(18, SOL_IPV6, IPV6_RECVPKTINFO, [1], 4) = 0
socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 19
setsockopt(19, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
fcntl64(19, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(19, F_SETFL, O_RDWR|O_NONBLOCK) = 0
setsockopt(19, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0
bind(19, {sa_family=AF_INET6, sin6_port=htons(53), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_scope_id=0}, 28) = -1 EADDRINUSE (Address already in use)
close(19) = 0
dnsmasq can't listen on TCP [::1]:53, because port is busy by stubby.
althrough dnsmasq doesn't complain to listen on UDP [::1]:53, it will work as poor-man per-cpu load-balancing - part of queries to [::1]:53 will go to stubby, other part - to dnsmasq. if dnsmasq has [::1]:53 upstream, half of possible dnsmasq's queries will be looped back into it.

more tech details about binding here https://linux.die.net/man/2/bind

solution is to bind stubby and dnsmasq to ::1 (since it's the only ipv6 loopback address, google for ipv6 address types) and to different ports.
for example, stubby - to [::1]:5353, it will be valid config.
okay, but what is the need for that if [::1]:5353 will never be used by anything locally (on router) except dnsmasq which is already configured to reach stubby via 127.0.1.1:53?
the only correct answer - there's no need, except waste of ressources (own time, sockets, cpu power) and curiosity.
 
Last edited:
Sorry
Code:
netstat -anlp | grep :53
so apparently if ipv6 is flowing right through dnsmasq you should see
your
WAN IPv6 Address
LAN IPv6 Address
LAN IPv6 Link-Local Address
all flowing through port 53 being passed off by dnsmasq.

on my setup, the only thing listening for ::1 at port 53 is for
dnsmasq .

that is because ::1 at 53 for dnsmasq loopsback off of the main dnsmasq configuration.

edited because of a bad typo.
 
Last edited:
Ok.



With all the respect to feelings, it is technically known to be the bad idea.
There's no way to force stubby to listen on some tcp ip:port unless you move dnsmasq from there.
Same is true for lan, loopback addresses, no matter the family (v4/v6).

starting stubby with ::1@53 when dnsmasq is already running:

stubby can't listen on TCP [::1]:53, because port is busy by dnsmasq.
althrough stubby doesn't complain to listen on UDP [::1]:53, but it will work as poor-man per-cpu load-balancing - part of queries to [::1]:53 will go to stubby, other part - to dnsmasq. if dnsmasq has [::1]:53 upstream, half of possible dnsmasq's queries will be looped back into it.

starting dnsmasq when stubby is already running with ::1@53:

dnsmasq can't listen on TCP [::1]:53, because port is busy by stubby.
althrough dnsmasq doesn't complain to listen on UDP [::1]:53, it will work as poor-man per-cpu load-balancing - part of queries to [::1]:53 will go to stubby, other part - to dnsmasq. if dnsmasq has [::1]:53 upstream, half of possible dnsmasq's queries will be looped back into it.

more tech details about binding here https://linux.die.net/man/2/bind

solution is to bind stubby and dnsmasq to ::1 (since it's the only ipv6 loopback address, google for ipv6 address types) and to different ports.
for example, stubby - to [::1]:5353, it will be valid config.
okay, but what is the need for that if [::1]:5353 will never be used by anything locally (on router) except dnsmasq which is already configured to reach stubby via 127.0.1.1:53?
the only correct answer - there's no need, except waste of ressources (own time, sockets, cpu power) and curiosity.
I get what you are saying if is IPV6 is not flowing properly it is better to actually solve the problem then try to repackage it or put a band-aid on it. I concur with dave14305 on using
Code:
netstat -anlp | grep :53
because this will show if the IPV6 addresses are flowing properly, to allow for stubby to work, and if it is and stubby is just not linking properly then there is a configuration problem some where with it detecting his actual ipv6 connection.
 
I get what you are saying if is IPV6 is not flowing properly it is better to actually solve the problem then try to repackage it or put a band-aid on it. I concur with dave14305 on using
Code:
netstat -anlp | grep :53
because this will show if the IPV6 addresses are flowing properly, to allow for stubby to work, and if it is and stubby is just not linking properly then there is a configuration problem some where with it detecting his actual ipv6 connection.

yep, tunnel connection could be the root issue. or startup delays, this was recently fixed by Eric.
guess, worth to retry on 12_beta2 regardless my 6rd checks
 
yea i have tested it with 6in4 and 6to4 and it works, but i do not have a way to test 6rd. wish i could.
 
yea i have tested it with 6in4 and 6to4 and it works, but i do not have a way to test 6rd. wish i could.
Here are the settings for my 6RD. May not work outside of my ISP but you can give it a try...
6RD.jpg
 
Thought I would report that I have been running 6to4 with DoT for a day with no issues. Adaptive QOS is even working as it should. With 6RD the ipv6 download shows on the QOS meters as an upload. Am surprised my speeds do not seem to be slowed.

Sent from my SM-T380 using Tapatalk
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top