Menu
What's new
By:
Filters Better Search

Search results

  • 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!

  1. T

    [Beta] Asuswrt-Merlin 384.12 Beta is now available

    some thoughts regarding dnssec @ dnsmasq. does anyone ever need gost algos? teaser: https://rootcanary.org/test.html
  2. T

    Setting up IPV6 with DNS-over-TLS

    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
  3. T

    Setting up IPV6 with DNS-over-TLS

    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...
  4. T

    Setting up IPV6 with DNS-over-TLS

    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...
  5. T

    Setting up IPV6 with DNS-over-TLS

    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...
  6. T

    Setting up IPV6 with DNS-over-TLS

    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...
  7. T

    Setting up IPV6 with DNS-over-TLS

    why?
  8. T

    [384.12_Alpha - builds] Testing all variants.

    guess, because mcpd integration is just poorly handled
  9. T

    [384.12_Alpha - builds] Testing all variants.

    from mcpd
  10. T

    [384.12_Alpha - builds] Testing all variants.

    just imagine empty isp dns and dot configured in opportunistic mode. just in case
  11. T

    [Beta] Asuswrt-Merlin 384.11 Beta is now available

    yep, and results are the same with -4 + @127.0.0.1. this means everything works as expected, and any type of address (a/aaaa - ipv4/ipv6) can be requested via any type of transport (ipv4/ipv6 connection). p.s it's possible to use +short for less dig output dig +short aaaa bin.entware.net...
  12. T

    [Beta] Asuswrt-Merlin 384.11 Beta is now available

    not valid. 127.0.1.1 is not ipv6 address, do not use -6 transport option. "a" address type is not the same as -4 transport to get it, same as "aaaa" address is different from ipv6 -6 transport.
  13. T

    [Beta] Asuswrt-Merlin 384.11 Beta is now available

    sorry, it's not available. only dig from bind-dig package
  14. T

    [Beta] Asuswrt-Merlin 384.11 Beta is now available

    not sure about... installing dig/kdig from entware and making aaaa request to different endpoints would give some light on this, I guess. examples: dig aaaa google.com @127.0.0.1 # request dnsmasq dig aaaa google.com @::1 # request dnsmasq dig aaaa google.com @127.0.1.1 # request stubby dig aaaa...
  15. T

    [Beta] Asuswrt-Merlin 384.11 Beta is now available

    If you're looking for confirmation is your way to use it still ok - surely, it's pretty valid for your conditions, no worries. but nothing more than that. Sure, up to you but it would make zero sense. Dns protocol is transport-agnostic, you don't need to have ipv6 connection to get aaaa replies...
  16. T

    [Beta] Asuswrt-Merlin 384.11 Beta is now available

    guess, now it's fixed in git.
  17. T

    [Preview] Asuswrt-Merlin 384.11 with DNS over TLS

    it must be there, othercase authenticated status of reply from stubby will be lost in dnsmasq and will never reach lan clients. because this file is the only valid path with upstream (isp) nameservers that stubby can use. right, not a really great idea to have it configured, taking into...
  18. T

    [Preview] Asuswrt-Merlin 384.11 with DNS over TLS

    dnspriv_enable default is "0", with DoT enabled from web ui - "1", more numeric values are possible in the future (i.e for DoH). so, I guess, correct check for now & possibly compatible with upcoming values would be [ "$(nvram get dnspriv_enable)" = "1" ]
  19. T

    [Preview] Asuswrt-Merlin 384.11 with DNS over TLS

    well, not really, all of them are independent extensions. the only diff between them - with "dnssec" indeterminate (can't be checked due no root) replies are not returned, with "dnssec_return_status" - still will. refer...
  20. T

    [Preview] Asuswrt-Merlin 384.11 with DNS over TLS

    isn't "dnssec" too strict? unlike "dnssec_return_status" it'll drop all the GETDNS_DNSSEC_INTERMEDIATE replies.
Top