Closed singpolyma closed 3 years ago
Interesting use case, and good question!
The hnsd resolver checks the Handshake root zone first for each DNS query. If it doesn't find the query's TLD in the Handshake zone it "falls back" to the ICANN root zone, and attempts recursive resolution from there. The exact logic is here, actually in the hnsd authoritative nameserver:
Instead of actually sending queries to the ICANN root servers (e.g. a.root-servers.net.
) hnsd has a built-in hard-coded copy of the current ICANN root zone. It is stored in this file which is generated from scripts actually in a different handshake-org repo:
SO now we can get to your question. If you want hnsd to "fallback" to an alternative root zone, you can run it through the hs-names process and replace tld.h
with the output.
I think the hard-coded file is a bit of an issue since we will need to update it with every single release and if users don't update, they might have problems resolving on legacy DNS. So long term I think it would be wise to do in hnsd what we do in hsd (the full node) which is actually resolve TLDs from ICANN's root servers.
Note also the in hsd your answer might be easier because you can just replace the ICANN root resolver in the hsd DNS server with... whatever you want.
Side note: we really want to integrate HNS with things like pi-hole but I haven't looked into it yet.
@singpolyma you can use forward-zone
or other config options in unbound.conf and pass them to hnsd
:
https://github.com/handshake-org/hnsd#options
-u, --rs-config <config>
Path to unbound config file.
Closing due to inactivity and @tuxcanfly answer. Feel free to leave more comments if this didn't solve your problem.
I'm trying to forward everything to an external DNS except for HNS domains.
I tried a simple unbound.conf like this one but it does seems to work:
forward-zone:
name: "."
forward-addr: x.x.x.x
Do you have an example ?
@damajor interesting - I'm not sure if "."
would work because wouldn't that forward everything? Could you try one or two known handshake names in there just to test the confiugration actually works? Some examples:
proofofconcept.
nb.
rough.
I confirm that using "."
will forward EVERY query to outside DNS server, even HNS names are forwarded.
So I don't think hnsd
does checks on Handshake root zones before forwarding the queries.
It seems the unbound configuration has some kind of precedence in some use cases.
Here is quick & dirty script to generate an Unbound configuration that will forward any know ICANN TLDs:
#!/bin/sh
wget -O tlds-alpha-by-domain.txt https://data.iana.org/TLD/tlds-alpha-by-domain.txt
for i in $(cat tlds-alpha-by-domain.txt | grep -v "^#")
do
echo "forward-zone:"
echo " name: \"$i.\""
echo " forward-addr: $DNSRELAY"
done > unbound.conf
rm tlds-alpha-by-domain.txt
Replace $DNSRELAY
with your DNS server in charge of regular DNS queries or pihole...
My setup:
Pi-Hole => hnsd => unbound
Would be great if hnsd could check handshake first and only use the forward-zone stuff as a fallback, so that "." could work correctly.
How to make sure that the query for ICANN TLDs is being forwarded properly?
It seems to me that from the logs, the legacy TLDs are still being queried over the handshake peers instead of my forwarded recursor.
I started the hnsd server with the -u unbound-tld-forward.conf
flag where each ICANN zone is listed as a forward-zone:
to my specified recursor.
I run my own DNS server for legacy TLD access, which includes some features I want (including access to some other alt roots and also ad blocking) -- what is the best way to mix in access to handshake names as well?