Setting up IPV6 with DNS-over-TLS

[Gar]

I wondered if running VPN on my router was preventing IPv6 from functioning - seems this is so as Nord tells me they do not support IPv6 - so much for that!

Never would have guessed that they don't support v6, good to know. Sorry though that you got burned!

 

[Swistheater]

I wondered if running VPN on my router was preventing IPv6 from functioning - seems this is so as Nord tells me they do not support IPv6 - so much for that!

Essentially most of your VPN providers has an option that blocks the flow of IPV6 since they do not support it. there is like maybe 1 or 2 major vpn providers i can think of that do support implementation of ipv6 via config for the router-- other vpn providers only support it at the app level, for example, the windows app they may provide.

The real question is, does the asus router support implementation of providing an ipv6 address via VPN client. You may find a vpn provider that will provide an address for your ipv6, but the router itself may not fully support assigning that address to where it needs to go. Asus router has the technology in the router, some times they fall short on delivery of the setup as far a functionality goes.

 

[gattaca]

That 2014 article is no longer accurate.
I have Spectrum aka Time Warner as my ISP and have had IPv6 up and running for over a year on my 86U with IPv6 firewall enabled. I still use NAT because not all my devices support IPv6 and not all my destinations are IPv6 enabled.

Wow OK, I have something to try this weekend when the house is "asleep!" I've been on TWC/Spectrum for 20+ years now and I'm betting IPV6 is supported in this area.

I am also edgy / concerned b/c I have amtm installed as well as skynet, diversion, and most of the other tooling in the amtm teamed package. It's working GREAT along with DNS-over-TLS so I sure as *@(*@* don't want to break that. I may play around with this on a spare router instead. Thanks for jumping in!

My gut observation from the responses posted is that most of us have stuck with IPV4 for now in our home setups. It's simpler and maybe offers the best/widest support.

 

[themiron]

I will likely modify dnsmasq and stubby to communicate on IPV4 and IPV6 loopback port 5453.

why?

 

[Swistheater]

why?

I understand your method works perfect on the firmware and that has been tested and proven, but by default stubby by design was made to listen with listening addresses 127.0.0.1#53 and ::0#53, what makes the stubby design in the routers firmware adapt to the original design and work in the way that it has been proven to work?

 

[themiron]

I understand your method works perfect on the firmware and that has been tested and proven, but by default stubby by design was made to listen with listening addresses 127.0.0.1#53 and ::0#53, what makes the stubby design in the routers firmware adapt to the original design and work in the way that it has been proven to work?

Because "stubby design" is not a design but just simple example of bind config options for general case w/o any explicit or well-thought integration into some special environment, i.e into firmware, where kernel/libc ipv6 can be swithed off, not built, etc with the price stubby resolver can only be used only with another dns proxy (not system resolver) on non-standard port and/or w/o any other dns proxy at all.
Don't put much sense into example config, it's just an example, nothing more.
But following general example that currently can fit your config disregret the exact environment settings may play bad joke in the future, when custom settings may become complitely incompatible with the environment.
I'd suggest to keep it as designed unless you really need it this way and understand all the riscs incl. the benefits from config change, for example - as for timeout changes.

 

[Swistheater]

Because "stubby design" is not a design but just simple example of bind config options for general case w/o any explicit or well-thought integration into some special environment, i.e into firmware, where kernel/libc ipv6 can be swithed off, not built, etc with the price stubby resolver can only be used only with another dns proxy (not system resolver) on non-standard port and/or w/o any other dns proxy at all.
Don't put much sense into example config, it's just an example, nothing more.
But following general example that currently can fit your config disregret the exact environment settings may play bad joke in the future, when custom settings may become complitely incompatible with the environment.
I'd suggest to keep it as designed unless you really need it this way and understand all the riscs incl. the benefits from config change, for example - as for timeout changes.

Yes, the way you have shaped it to listen works well, it can be tested in such a way that if only ipv6 listening addresses are chosen, the traffic will only flow via that route. *note* I am not telling people to do that, but it is just one way to better appreciate the functionality of the routers features for confirmation reasons.

 

[bbunge]

why?

Because I am old, crotchety and set in my ways. As one of the original testers on the Entware Stubby install I feel comfortable with the logic of using a different port to communicate between dnsmasq and stubby.
Please, don't make a federal case out of this. This is my opinion and I do have a right to state what I feel. There is plenty of room for new or old ideas!

Sent from my SM-T380 using Tapatalk

 

[themiron]

Because I am old, crotchety and set in my ways. As one of the original testers on the Entware Stubby install I feel comfortable with the logic of using a different port to communicate between dnsmasq and stubby.
Please, don't make a federal case out of this. This is my opinion and I do have a right to state what I feel. There is plenty of room for new or old ideas!

Sure, no cases, just curious why using one of 16777216 possisble spare addresses with whatever port looks more suspicious than using one of 65536 (well, less) spare ports on the same address?
As one of dnsmasq, stubby, other dns & ipv6 software code contributors I feel I'm missing something here and open to external ideas, just to make related sw better, no other reasons.

 

[bbunge]

My ISP at home does not have native IPV6 but does offer IPV6 over 6RD. AS a test I disabled DoT, DNSSEC and my custom configs. Set up 6RD with Cloudflare DNS. Using https://test-ipv6.com/ tested with 10/10 score.
Enabled DoT and set CF IPV4, CF IPV6, CF IPV4 and CF IPV6 resolvers. Tested with https://cloudflare-dns.com/help/ and the IPV6 resolvers showed no connection (DNSSEC was disabled).

Created /jffs/scripts/stubby.postconf with the following contents:

#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh
pc_insert "  - 127.0.1.1@53" "
  - 0::1@53" $CONFIG

Note the carriage return after the " on line 4
Restarted Stubby, ran the CF test again and the IPV4 and IPV6 resolvers showed connected.

Regardless of what port is used internally I strongly feel that the IPV6 loopback needs to be included in stubby.yml. I have found that not all IPV4 resolvers will do IPV6 addresses.

 

[Swistheater]

My ISP at home does not have native IPV6 but does offer IPV6 over 6RD. AS a test I disabled DoT, DNSSEC and my custom configs. Set up 6RD with Cloudflare DNS. Using https://test-ipv6.com/ tested with 10/10 score.
Enabled DoT and set CF IPV4, CF IPV6, CF IPV4 and CF IPV6 resolvers. Tested with https://cloudflare-dns.com/help/ and the IPV6 resolvers showed no connection (DNSSEC was disabled).

Created /jffs/scripts/stubby.postconf with the following contents:

#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh
pc_insert "  - 127.0.1.1@53" "
  - 0::1@53" $CONFIG

Note the carriage return after the " on line 4
Restarted Stubby, ran the CF test again and the IPV4 and IPV6 resolvers showed connected.

Regardless of what port is used internally I strongly feel that the IPV6 loopback needs to be included in stubby.yml. I have found that not all IPV4 resolvers will do IPV6 addresses.

that completely makes sense for your issue, i believe, cannot confirm, but strongly believe the coding in the router is not addressed for DoT to handle where the 6rd connection is bound at. Miron can investigate this if he likes, but it has to do with where that connection is being bound at.

 

[Swistheater]

My ISP at home does not have native IPV6 but does offer IPV6 over 6RD. AS a test I disabled DoT, DNSSEC and my custom configs. Set up 6RD with Cloudflare DNS. Using https://test-ipv6.com/ tested with 10/10 score.
Enabled DoT and set CF IPV4, CF IPV6, CF IPV4 and CF IPV6 resolvers. Tested with https://cloudflare-dns.com/help/ and the IPV6 resolvers showed no connection (DNSSEC was disabled).

Created /jffs/scripts/stubby.postconf with the following contents:

#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh
pc_insert "  - 127.0.1.1@53" "
  - 0::1@53" $CONFIG

Note the carriage return after the " on line 4
Restarted Stubby, ran the CF test again and the IPV4 and IPV6 resolvers showed connected.

Regardless of what port is used internally I strongly feel that the IPV6 loopback needs to be included in stubby.yml. I have found that not all IPV4 resolvers will do IPV6 addresses.

If I had the free time, i would test it with 6in4 and 6to4, but i cannot afford the down time atm.
Note: i do not recommend the use of those archaic methods of achieving ipv6 unless you are using them to supplement connection for special purposes.

 

[bbunge]

If I had the free time, i would test it with 6in4 and 6to4, but i cannot afford the down time atm.
Note: i do not recommend the use of those archaic methods of achieving ipv6 unless you are using them to supplement connection for special purposes.

I don't think the method of ipv6 matters. At least it shouldn't. The routers I manage that have native ipv6 can't be changed during working hours. Will try DoT on one of them tonight after hours.

Sent from my SM-T380 using Tapatalk

 

[dave14305]

Created /jffs/scripts/stubby.postconf with the following contents:

#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh
pc_insert " - 127.0.1.1@53" "
- 0::1@53" $CONFIG

Note the carriage return after the " on line 4

I think you can get the same result using:

pc_insert "  - 127.0.1.1@53" "\  - 0::1@53" $CONFIG

without using a CR/LF in the script itself, to honor the space indentation.

 

[Swistheater]

yea it would be

pc_insert "listen_addresses:" "\  - 0::1@53" $CONFIG

or if you want it to follow the 127.0.1.1 as well.

 

[Swistheater]

i think the \ causes it to exit out kind of the same as if you did what he did , but it is implied.

 

[themiron]

My ISP at home does not have native IPV6 but does offer IPV6 over 6RD. AS a test I disabled DoT, DNSSEC and my custom configs. Set up 6RD with Cloudflare DNS. Using https://test-ipv6.com/ tested with 10/10 score.
Enabled DoT and set CF IPV4, CF IPV6, CF IPV4 and CF IPV6 resolvers. Tested with https://cloudflare-dns.com/help/ and the IPV6 resolvers showed no connection (DNSSEC was disabled).
Restarted Stubby, ran the CF test again and the IPV4 and IPV6 resolvers showed connected.

Got it, 6RD can make sense, is it static or dynamic (options received by DHCP)?
IPv6 tunnels may have a delay before started to working normally althrough they are stateless by nature.
Especially dymaic 6RD. I didn't test this case, but can confirm 6in4 works as intended, forced to use it here.
Will try to check what can be wrong there with 6RD.

Created /jffs/scripts/stubby.postconf with the following contents:

#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh
pc_insert "  - 127.0.1.1@53" "
  - 0::1@53" $CONFIG

Note the carriage return after the " on line 4
Regardless of what port is used internally I strongly feel that the IPV6 loopback needs to be included in stubby.yml. I have found that not all IPV4 resolvers will do IPV6 addresses.

0::1 is the only available IPv6 loopback address, and 53 port there is already occupied by dnsmasq.
This change gives nothing but conflict stubby vs dnsmasq for one and the same IPv6 port, fortunately IPv4 is still there - so dns should be still working (if dnsamsq/stubby can start in such conditions).

Loopback addresses are not accesible for external clients, they can reach only extranal addresses (i.e LAN IP) where dnsmasq sits.
Internal (running on router) clients by default uses system resolver, which has the only configured upstreams in /etc/resolv.conf.
There two cases for internal clients to query 127.0.0.* and/or ::1 - either /etc/resolv.conf points to that addresses, or /etc/resolv.conf is empty, so loopback is default documented last resort. For both cases only dnsmasq can (and will) serve everything on 127.0.0.1:53/[::1]:53.

Next depending on UI settings, using dnsmasq as system caching resolver is enabled - internal clients will use 127.0.0.1:53 (coz it's in /etc/resolv.conf) where dnsmasq listens (and able to answer AAAA queries). If have it disabled and have empty ISP DNS - internal clients will fallback to 127.0.0.1:53/[::1]:53 where still is dnsmasq (empty /etc/resolv.conf ). If have it disabled and non-empty ISP DNS - only ISP DNS will be used for local clients.
So loopback requests are always handled by dnsmasq, threfore although stubby can be configured for additional IPv6 loopback on different port as additional dnsmasq's upstream, it seems redundant in current design.

 

[Swistheater]

Got it, 6RD can make sense, is it static or dynamic (options received by DHCP)?
IPv6 tunnels may have a delay before started to working normally althrough they are stateless by nature.
Especially dymaic 6RD. I didn't test this case, but can confirm 6in4 works as intended, forced to use it here.
Will try to check what can be wrong there with 6RD.


0::1 is the only available IPv6 loopback address, and 53 port there is already occupied by dnsmasq.
This change gives nothing but conflict stubby vs dnsmasq for one and the same IPv6 port, fortunately IPv4 is still there - so dns should be still working (if dnsamsq/stubby can start in such conditions).

Loopback addresses are not accesible for external clients, they can reach only extranal addresses (i.e LAN IP) where dnsmasq sits.
Internal (running on router) clients by default uses system resolver, which has the only configured upstreams in /etc/resolv.conf.
There two cases for internal clients to query 127.0.0.* and/or ::1 - either /etc/resolv.conf points to that addresses, or /etc/resolv.conf is empty, so loopback is default documented last resort. For both cases only dnsmasq can (and will) serve everything on 127.0.0.1:53/[::1]:53.

Next depending on UI settings, using dnsmasq as system caching resolver is enabled - internal clients will use 127.0.0.1:53 (coz it's in /etc/resolv.conf) where dnsmasq listens (and able to answer AAAA queries). If have it disabled and have empty ISP DNS - internal clients will fallback to 127.0.0.1:53/[::1]:53 where still is dnsmasq (empty /etc/resolv.conf ). If have it disabled and non-empty ISP DNS - only ISP DNS will be used for local clients.
So loopback requests are always handled by dnsmasq, threfore although stubby can be configured for additional IPv6 loopback on different port as additional dnsmasq's upstream, it seems redundant in current design.

as far as the 6rd goes,
i can see where it can be hard to get every connection type correct, especially if you don't necessarily have the environment conducive of testing it, the only way to fix it is by the feed back and your general knowledge against what you are hearing from the feed back.
it makes complete sense that since dnsmasq is handling the loopback, that no additional servers would be needed, so this really all just boils down to how dnsmasq is configured to behave in conjunction with stubby.

 

[bbunge]

I think you can get the same result using:

pc_insert "  - 127.0.1.1@53" "\  - 0::1@53" $CONFIG

without using a CR/LF in the script itself, to honor the space indentation.

Works!
Here is my current stubby.postconf

#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh
pc_insert "  - GETDNS_TRANSPORT_TLS" "dnssec_return_status: GETDNS_EXTENSION_TRUE" $CONFIG
pc_replace "idle_timeout: 9000" "idle_timeout: 2000" $CONFIG
pc_replace "tls_connection_retries: 2" "tls_connection_retries: 5" $CONFIG
pc_replace "timeout: 3000" "timeout: 2000" $CONFIG
pc_replace "round_robin_upstreams: 1" "round_robin_upstreams: 0" $CONFIG
pc_insert "  - 127.0.1.1@53" "\  - 0::1@53" $CONFIG

Should add that I tried DNSSEC from dnsmasq and had connection issues. Will try to work through several things to see if turning off round robin causes issues.

Edit: well, i messed something up! Will get back into testing after my wife gets done with her online work...

 

[Swistheater]

Works!
Here is my current stubby.postconf

#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh
pc_insert "  - GETDNS_TRANSPORT_TLS" "dnssec_return_status: GETDNS_EXTENSION_TRUE" $CONFIG
pc_replace "idle_timeout: 9000" "idle_timeout: 2000" $CONFIG
pc_replace "tls_connection_retries: 2" "tls_connection_retries: 5" $CONFIG
pc_replace "timeout: 3000" "timeout: 2000" $CONFIG
pc_replace "round_robin_upstreams: 1" "round_robin_upstreams: 0" $CONFIG
pc_insert "  - 127.0.1.1@53" "\  - 0::1@53" $CONFIG

Should add that I tried DNSSEC from dnsmasq and had connection issues. Will try to work through several things to see if turning off round robin causes issues.

Edit: well, i messed something up! Will get back into testing after my wife gets done with her online work...

you should check out this option test it out.. tell me what you think.

pc_insert "dnssec_return_status: GETDNS_EXTENSION_TRUE" "return_both_v4_and_v6: GETDNS_EXTENSION_TRUE" $CONFIG