use fake dns and long domain name to replace ipv6 for collision immune

[xialvjun]

your blog:

https://yggdrasil-network.github.io/2018/07/28/addressing.html#:~:text=Fixing%20that%20is%20on%20my%20wish%2Dlist%20for%20IPv7%2C%20if%20for%20some%20reason%20that%20ever%20happens.

but what if curl http://e5da8447dc2c320edc0fc52fa01885c103de8c118481f683643cacc3220dafce.ygg and yggdrasil's virtual network card offers a fake dns service.

[neilalexander]

Irrespective of a DNS mapping, the IPv6 address still truncates the public key, so this doesn't solve the issue.

[majestrate]

note: if you use base32 it will fit into the size needed for a dns label.

Irrespective of a DNS mapping, the IPv6 address still truncates the public key, so this doesn't solve the issue.

you can use dns64/nat64 it is meant to be used for ephemeral ips for dns then add PTR records which point back.

it is what i was meaning to do in lokinet.

[neilalexander]

That's true, but then we end up with a lot of code to remap IP addresses, rewrite checksum etc. Right now Yggdrasil can pass through IPv6 traffic completely unmodified and that's extremely powerful and far simpler.

For the purposes of what we want to do at this stage, truncating public keys is a tradeoff that we accept. If Yggdrasil ever does end up taking over the world, it would maybe warrant a new address family anyway.

[majestrate]

oh i know very well the pains of doing that, this is just my two cents on the DNS method.

[xialvjun]

Irrespective of a DNS mapping, the IPv6 address still truncates the public key, so this doesn't solve the issue.

But we can use domain name instead ipv6 as yggdrasil node id. And in routing progress, we are talking about node id rather than ipv6.

browser: give me this domain's ip: e5da8447dc2c320edc0fc52fa01885c103de8c118481f683643cacc3220dafce.ygg . 
yggdrasil: its ip is 192.168.234.123  (here we have state: { 192.168.234.123 ->e5da8447dc2c320edc0fc52fa01885c103de8c118481f683643cacc3220dafce  })
browser: connect to 192.168.234.123:80, and send 'hello' to it
yggdrasil: peerA, help me to route `hello` to node e5da8447dc2c320edc0fc52fa01885c103de8c118481f683643cacc3220dafce

IP exists only to be compatible with third-party applications (ie browser)，in fact, there is no ip concept in yggdrasil-network.

In this way, we don't need to truncate anything.

Besides, domain name( in fact domain name is just node id) is just a 256 bit. It needn't to be base32, base58 maybe better, friendly to human eyes.

IP is just a compatible layer, it can be ipv4, ipv6 or whatever the real network support.

We route by node id, and since node id is totally controlled by yggdrasil, it can be 256 bit, 512 bit, or whatever is secure enough to be public key.

fake-dns see some proxy project like clash

[xialvjun]

Note: this way may make real domain dns harder.

old:

yggdrasil-network.ygg -> 200:be32:8098:ba3:75f:50af:5838:c49b

now:

yggdrasil-network.ygg -> e5da8447dc2c320edc0fc52fa01885c103de8c118481f683643cacc3220dafce.ygg
# I don't know if dns service support domain point to another domain just work like a proxy

Besides, I don't know if applications (like curl, browser) support top domain. If support, maybe we needn't to append .ygg after node id.

[majestrate]

IP is just a compatible layer, it can be ipv4, ipv6 or whatever the real network support.

speaking from experience you do not want to support ipv4, that is a mistake because of the mountains of painful things they got wrong, like supporting IP fragmentation.

in fact, there is no ip concept in yggdrasil-network.

there is, in fact that is the distinguishing aspect of yggdrasil.

yggdrasil-network.ygg -> e5da8447dc2c320edc0fc52fa01885c103de8c118481f683643cacc3220dafce.ygg

this does not work, you need to attach an AAAA record after a CNAME in the same reply.

there is a lot more you'll run into with the DNS approach that makes this insanely difficult and then you hit the cache invalidation issues.

[majestrate]

imo, you could make an extended version of yggdrasil which supports this and can do this DNS tomfoolery with other nodes who advertise they support it.

you could put something into some kind of public nodeinfo to advertise this capability or negotiate capabilities with the other end on the fly, falling back to normal addressing if they dont support it.

talking to remotes who support this alternative mode would have their AAAA records resolve in a part of the 64:ff9b::/96 dns64 range selected by each end. otherwise you'd use AAAA records resolving in 200::/7. also each entry has their corresponding PTR record that matches their forward DNS would be a thing to synthesize.

it'd be a fun toy to add on the side for others to use, keeping it separated from yggdrasil internals would let it be used for other networks too like tor and i2p, just use another part of the dns 64 range for those backends. even if you dont support multiple backend networks this is a larger undertaking than you think so it really should not be in scope for yggdrasil proper. trust me i've done something like this before, it's a lot of stuff involved.

[Arceliar]

Some variation of this has come up in discussion a few times. The bigger reason to provide fake domain names is to support applications that don't work right (if at all) without a domain name.

As far as I know, if we shipped our own resolver in ygg, there still isn't a good way to set things up automatically. The user would need to configure their system to use our resolver, and some applications may still bypass it by default (e.g. DoH in modern web browsers), so I expect it would not work well in practice.

[majestrate]

there still isn't a good way to set things up automatically.

this is the secret eternal truth and pain of DNS. I don't think it's THAT bad as people make it out to be but it isn't something to ignore either. yggdrasil cannot fix this, nor can any other dns resolver. this is a system layer issue and thus the sole responsibility of the system layer's maintainer, in the case of yggdrasil, such is the end user's responsibility to babysit. documentation on how to do that with troubleshooting and a discussion area is really all you need.

[NikitaPuzyryov]

Perhaps related article by Tailscale people: https://tailscale.com/blog/sisyphean-dns-client-linux/

[xialvjun]

The bigger reason to provide fake domain names is to support applications that don't work right (if at all) without a domain name.

@Arceliar but what I want to solve is ipv6's 128 bits is too small to save a hash result of pub key by a much more secure hash function like sha256.

Current:

struct ygg_node {
  pri_key,
  pub_key,
  ipv6 = hash(pub_key) // since ipv6 has only 128 bits, and it is too small, we can not use sha256
}

I want it become:

struct ygg_node {
  pri_key,
  pub_key,
  domain = hash(pub_key) // domain is long enough, so we can use sha256 or even sha512 as the hash function
}

Maybe I got yggdrasil-network's essential wrong.

[xialvjun]

besides, in this way, a PC can run both ygg4 and ygg5 at the same time, and even other protocol similar with ygg, distinct with each other by the top level domain (or maybe we can call it suffix).

http://e5da8447dc2c320edc0fc52fa01885c10.3de8c118481f683643cacc3220dafce.ygg4
http://e5da8447dc2c320edc0fc52fa01885c10.3de8c118481f683643cacc3220dafce.ygg5

• add a dot because domain can support at most 63 chars in a domain slot, and total length is <= 253 chars
• so it can save Math.log2(Math.pow(36, 253)) = 1306 bits . Do I calculated it wrong ?
• I found this in a Chinese blog: https://blog.csdn.net/zhangmingcai/article/details/116719599

[xialvjun]

For the purposes of what we want to do at this stage, truncating public keys is a tradeoff that we accept.

OK, maybe we can do this after Yggdrasil taking over the world. 😀

[xialvjun]

@majestrate Oh, I finally got your meaning. Besides, lokinet seems a great project, I'll have it a try.

[majestrate]

besides, in this way, a PC can run both ygg4 and ygg5 at the same time, and even other protocol similar with ygg, distinct with each other by the top level domain (or maybe we can call it suffix).

http://e5da8447dc2c320edc0fc52fa01885c10.3de8c118481f683643cacc3220dafce.ygg4
http://e5da8447dc2c320edc0fc52fa01885c10.3de8c118481f683643cacc3220dafce.ygg5

• add a dot because domain can support at most 63 chars in a domain slot, and total length is <= 253 chars
• so it can save Math.log2(Math.pow(36, 253)) = 1306 bits . Do I calculated it wrong ?
• I found this in a Chinese blog: https://blog.csdn.net/zhangmingcai/article/details/116719599

you still have collison issues here because of how DNS works if you can collide the top most label you can trick caches.

[xialvjun]

you still have collison issues here because of how DNS works if you can collide the top most label you can trick caches.

But that has nothing to do with security. I can even

http://e5da8447dc2c320edc0fc52fa01885c10.3de8c118481f683643cacc3220dafce.my-special-network

And in my-special-network, e5da8447dc2c320edc0fc52fa01885c10.3de8c118481f683643cacc3220dafce is just an id which can even be manually set by user if my-special-network assumes all users are good or it doesn't care who is who (like broadcast, subscription and so on).

Or were your meaning is you are worrying about bad guys registered e5da8447dc2c320edc0fc52fa01885c10.3de8c118481f683643cacc3220dafce.ygg5 or even *.ygg5 before we ? But we are using fake dns which is totally controlled in our PCs.

Poor english and little network programming knowledge make our communication hard, sorry.

[majestrate]

if i can generate a public key xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.3de8c118481f683643cacc3220dafce.ygg where the x is any value, i have collided that label which as caching implications.

[majestrate]

there are a lot of subtleties to DNS like that which seep into upper layers, e.g. CORS rules on http could be bypassed with that kind of collision.