Conflict between `hsd` and the DNS RFCs

[james-stevens]

There is a conflict between the way hsd and an RFC DNS server treats the status of record in the blockchain / ROOT Zone. Obviously, by the time I've used this plug-in to pull the records out, they are no longer in the blockchain, as such.

Namebase set up all their TLDs like this

handshake.              21600   IN      NS      ns1.handshake.
ns1.handshake.          21600   IN      A       44.231.6.183

I have no idea why they didn't use a single NS for all of them, like ns1.namebase, or simply give all of them either a single CNAME or single IPv4, there is really no need to delegate them at all, but hey - it is what it is.

hsd will treat these records as authoritative & resolve the domain fine. However, bind will (correctly) treat these both as GLUE records and re-query for them from the authoritative source - in this case 44.231.6.183.

Namebase's mistake is that, according to 44.231.6.183, not only does ns1.handshake not exist, but also handshake also has no NS records. Therefore, correctly bind will not resolve this domain, however hsd will.

In a way this is a philosophical question as to the status of the records in the blockchain, but from an RFC DNS point of view, when a subdomain is delegated, it's the delegated NS that are the authoritative source of truth (AA=1) & all records (except the DS) in the parent zone are treated as GLUE records - "hearsay". You can't really have two different authoritative sources of truth, becuase they could give different answers.

However, if hsd was "fixed" to be RFC compliant, all namebase helds TLDs (except those staked & delegated to the registry) will almost certainly stop working - so at least 99% of Handshake TLDs.

My guess would be that unbound using the light-client plug-in would behave the same as bind, unless the light client tags the blockchain records as AA=1. It would be interesting to know.

I reported this issue to namebase, but the person who responded gave the response that they didn't understand what was being reported.

When I use the term "correctly", I only mean "as per the DNS RFCs", not as any kind of moral judgement.

[buffrr]

hsd will treat these records as authoritative & resolve the domain fine. However, bind will (correctly) treat these both as GLUE records and re-query for them from the authoritative source - in this case 44.231.6.183.

hsd root server doesn't treat those as authoritative and correctly sets AA=0. It's doing the right thing and sending a referral to those broken nameservers. It's the job of recursive resolvers to re query the authoritative NS records from the child zone.

Notice no AA bit here when querying root for handshake tld

dig @127.0.0.1 -p 5349 handshake NS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18531
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 3

;; QUESTION SECTION:
;handshake.                     IN      NS

;; AUTHORITY SECTION:
handshake.              21600   IN      NS      ns1.handshake.

;; ADDITIONAL SECTION:
ns1.handshake.          21600   IN      A       44.231.6.183

If you mean hsd's built-in recursive it uses Unbound which is more lenient on those errors compared to Bind and Knot resolvers.

My guess would be that unbound using the light-client plug-in would behave the same as bind, unless the light client tags the blockchain records as AA=1. It would be interesting to know.

Unbound is less picky about those errors unfortunately. If you use hsd root server directly with Bind or Knot resolver, it'll work correctly and break those names but Unbound will be fine with it. The light client's (hnsd) DNS & DNSSEC is currently broken there are a few open PRs that'll fix it soon.

However, if hsd was "fixed" to be RFC compliant

I'm not sure what would be fixed in hsd. I think hsd root is doing the right thing. I believe Unbound tries to be more lenient to avoid breaking sites.

an RFC DNS point of view, when a subdomain is delegated, it's the delegated NS that are the authoritative source of truth (AA=1) & all records (except the DS) in the parent zone are treated as GLUE records - "hearsay". You can't really have two different authoritative sources of truth, becuase they could give different answers.

Correct and that's exactly what hsd is doing.

all namebase helds TLDs (except those staked & delegated to the registry) will almost certainly stop working - so at least 99% of Handshake TLDs.

There's no content in 99% of those TLDs. It just show a blank page. Honestly, I say it's fine to break them it's useless content over HTTP, broken DNS and without DNSSEC or DANE. Bind is doing us a favor breaking those sites!

They just need to add NS records. Adding them in the parent zone only is not enough and not that hard to fix.

Btw, are you running a public recursive resolver? I'm looking for a hosting provider/CDN with anycast IPs. Buying an entire IP block is pretty expensive. So far fly.io seems like a good choice since it allows deploying docker containers to multiple locations and gives you an anycast IP address. Still, their VMs and bandwidth are pretty pricey I think.

[james-stevens]

If you mean hsd's built-in recursive it uses Unbound

Ah!

My mistake - I thought the resolver was built-in to hsd.

Bind is doing us a favor breaking those sites!

LOL - my general expectation would be most resolvers would behave like bind

They just need to add NS records. Adding them in the parent zone only is not enough and not that hard to fix.

If you look at the DNS answers, I'd say they're not running standard DNS s/w - or at least something I've not used before. Like this - seems very odd result to me

$ dig @44.231.6.183 handshake. any
;; communications error to 44.231.6.183#53: end of file

;; communications error to 44.231.6.183#53: end of file

Btw, are you running a public recursive resolver?

If you mean one with handshake, sort of, but its not really meant for massive public use. bridge.jrcs.net, but its just a public demo of this container - https://hub.docker.com/r/jamesstevens/handshake-resolver - which is basically bind + the merged ROOT zone I get from this plug-in & sign - its also in my github.

I def don't offer the service you are looking for. Doing your own anycast is a lot more tricky - you need a class-C subnet, an ASN and hosting providers that are willing to let you do BGP - its not that common, cos hijacking other people's IP blocks is so easy (basically BGP has literally zero security), so its quite hard to find. ServerCentral used to - they have four sites in the US.

So seems to me fly.io sounds like a great option - unless you can get something like that from AWS/Google/Azure

[buffrr]

If you look at the DNS answers, I'd say they're not running standard DNS s/w - or at least something I've not used before. Like this - seems very odd result to me

I believe they use powerdns if I try to query for NS I get this SOA:

dig @44.231.6.183 handshake NS
handshake.              3600    IN      SOA     a.misconfigured.powerdns.server. hostmaster.handshake. 2021041003 10800 3600 604800 3600

So they should have access to pdnsutil it can check for zone correctness. It will probably detect the missing NS issue. something like:

$ pdnsutil check-zone handshake
or all zones
$ pdnsutil check-all-zones

[james-stevens]

LOL - yeah def looks like PowerDNS - it must have an option to deny ANY queries I'm not aware of - any-to-tcp just returns TC=1 which should just make dig repeat over tcp. Whenever I use p/dns I never have it public facing, but put bind in the way.

I actually have it as the backend for the registry system, as its DNSSEC is probably the easiest to use.

They need to use my PowerDNS Admin WebUI - https://github.com/james-stevens/powerdns-webui - its actually pretty neat, for admin purposes - 100% JS & uses nothing extra than the built-in rest/api. It looks like a UI designed by a techie for a reason!

[buffrr]

They need to use my PowerDNS Admin WebUI - https://github.com/james-stevens/powerdns-webui - its actually pretty neat, for admin purposes - 100% JS & uses nothing extra than the built-in rest/api. It looks like a UI designed by a techie for a reason!

Ha that looks cool! I might actually use that for my nameserver. I'm currently using Knot DNS but not having a GUI is a bit annoying.

[james-stevens]

It does everything I need - LOL

That includes being able to maintain a bind catalog zone - if you've not used them before they are REALLY useful - basically its a zone that contains a list of zones you want your slave(s) to slave, so you just maintain the catalog zone on the master & the slaves automatically add/remove slave zones as per the catalog.

Dunno if knot does this, but it's not that hard to replicate with a small python script - you just get the DNS slave to slave the catalog & notify the python script when the catalog changes so it can update the dns server's config accordingly. It's how we used to do it before catalog zones came along. Also a handy technique for using DNS to transport all sorts of other info.

[james-stevens]

github doesn't seem to have a person-to-person messaging service, so I'm just adding this on here - sorry

I'm interested in using [handshake] domain names as an alias/store for crypto wallet ids. Do you know of any accepted standard for storing wallet ids in DNS? I found these various ideas, I like the one from Mattias Geniar

https://qualichain-project.eu/quali-data/uploads/2021/07/Blockchain-Address-Transparency-with-DNS-July2021.pdf https://ma.ttias.be/proposal-cryptocurrency-addresses-dns/ https://bitcointalk.org/index.php?topic=100253.0

Steve flagged up this - https://hsd-dev.org/HIPs/proposals/0002/ - but it has a ton more depednancies than just putting ids directly in TLD's zone file.

I was thinking about making it so they could put the wallet ids directly into the TLD zone file (as an alternative to NS records), so they're signed directly by the TLD & there's nothing else the owner needs to do, i.e. they don't have to run any infrastructure/services of their own - assuming they are happy to use the domain name purely as a wallet-id

If they want to use it for DNS & wallet-id, they'll obviously have to just subdomain it in the normal way

Wallet Ids are generally public information, so I don't see any security issues, do you?

[buffrr]

github doesn't seem to have a person-to-person messaging service, so I'm just adding this on here - sorry

No worries. If you ever want to chat and don't like telegram you can send me an email at contact@<myusername>.dev (it's in my Github profile). I'm usually pretty responsive over email too.

I was thinking about making it so they could put the wallet ids directly into the TLD zone file (as an alternative to NS records), so they're signed directly by the TLD & there's nothing else the owner needs to do, i.e. they don't have to run any infrastructure/services of their own - assuming they are happy to use the domain name purely as a wallet-id

Handshake generally tries to keep most things off the blockchain so it can continue to be lightweight/scale better. I believe that's what made HIP-2 avoid storing wallet addresses directly on Handshake. Also for better privacy, HIP-2 supports the ability to show a unique wallet address every time you visit /.well-known/wallets/<some coin> endpoint.

This should be doable with DNS off chain with like TTL = 0/online signing but it's usually easier for web developers/admins to serve things from /.well-known/wallets/<some coin> compared to using DNS I guess.

Wallet Ids are generally public information, so I don't see any security issues, do you?

No security issues mainly privacy & keeping things off chain is what led them to HIP-2 I believe.

[james-stevens]

Handshake generally tries to keep most things off the blockchain

Yeah - I was thinking any DNS in general, not specifically in the handshake blockchain - although if its TXT records, I'm guessing it could be put in the blockchain

it's usually easier for web developers/admins

yeah - it's the non-web/devs I was thinking about - trying to create a lower barrier to entry - so all you have to do is register a domain name & it can be used as a wallet name. I'll make a github repo to write a document in the README

DNS isn't going to provide privacy, but then if its a wallet address you want ppl to send coin to, you're going to have to reveal it anyway - and at least if the zone is signed NSEC3 it won't be walkable - it's something.

[james-stevens]

https://github.com/james-stevens/wallet-ids-in-dns

[buffrr]

Cool I think there's value to supporting wallet addresses at the DNS level. The document is very thorough which I like. It's probably worth mentioning in your document (sorry if it's already mentioned and I didn't notice :D) that if there's both an NS record and a TXT record at the TLD level in the Handshake root zone like this:

example. 86400 IN NS ns1.example.
example. 86400 IN TXT "ico tag:default btc:1AeCyEczAFPVKkvausLSQWP1jcqkccga9m"

TXT record must be ignored and delegation must be followed properly. Just in case users assume it will work this way or client implementers try to use getnameresource or read the TLD zone from somewhere and once they see a TXT with a wallet address, they'll ignore the NS record causing inconsistent behavior. Although it should be obvious with a delegation, other records are ignored (except DS) but not everyone knows that.

[james-stevens]

Thanks for the input, I've added it -> https://github.com/james-stevens/wallet-ids-in-dns

I've also change the title a bit to try & make the aim a little clearer & shuffled the text about a bit. So, I think I'm pretty happy with it now

You don't know anybody at Coinbase, do you? Getting some input / buy-in from there could really make this happen

Beyond that, please share with anybody you think might be interested

Thanks.

[buffrr]

I'm going to close this issue so we focus on improvements related to the plugin and this has more to do with Namebase.