Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Async DNS

flak.tedunangst.com

Post reply on HN
Print view View original

41–50 of 50 posts

Re: Async DNS

#41

Post by GoblinSlayer »

frumplestlatz wrote: post #25
dweekly wrote: post #17

I was able in an afternoon to implement a pretty decent completely async Swift DNS resolver client for my app. DNS clients are simple enough to build that rolling your own async is not a big deal anymore. Yes, there is separate work to discern what DNS server the system is currently using: on macOS this requires a call to an undocumented function in libSystem - that both Chromium and Tailscale use!

Even once you use the private `dns_config*()` APIs on macOS, you need to put in heavy lifting to correctly handle scoped, service-specific providers, supplemental matching rules, etc -- none of which is documented, and can change in the future. Since you're not using the system resolver, you won't benefit from mDNSResponder's built-in DNS caching and mDNS resolution/caching/service registration, so you're going to ne…

Doesn't linux run resolved locally? You just send request there and it handles hosts, cache and whatnot.

Re: Async DNS

#42

Post by cryptonector »

frumplestlatz wrote: post #25
dweekly wrote: post #17

I was able in an afternoon to implement a pretty decent completely async Swift DNS resolver client for my app. DNS clients are simple enough to build that rolling your own async is not a big deal anymore. Yes, there is separate work to discern what DNS server the system is currently using: on macOS this requires a call to an undocumented function in libSystem - that both Chromium and Tailscale use!

Even once you use the private `dns_config*()` APIs on macOS, you need to put in heavy lifting to correctly handle scoped, service-specific providers, supplemental matching rules, etc -- none of which is documented, and can change in the future. Since you're not using the system resolver, you won't benefit from mDNSResponder's built-in DNS caching and mDNS resolution/caching/service registration, so you're going to ne…

Browsers don't care about the nsswitch though. There are apps where that complexity can be avoided.

Re: Async DNS

#43

Post by cryptonector »

leshow wrote: post #40
01HNNWZ0MV43FF wrote: post #4

It's weird to me that event-based DNS using epoll or similar doesn't have a battle-tested implementation. I know it's harder to do in C than in Rust but I'm pretty sure that's what Hickory does internally.

I use hickory a lot and have contributed to it. It does have a pretty robust async DNS implementation, and its helpfully split into multiple different crates so you can pick your entry point into the stack. For instance, it offers a recursive resolver, but you can also just import the protocol library and build your own with tokio.

Link?

Re: Async DNS

#44

Post by cryptonector »

bwblabs wrote: post #21
AndyKelley wrote: post #15

Earlier quoted context omitted.

(1) DNS is hard It's really not. Just because some systems took something fundamentally simple and wrapped a bunch of unnecessary complexity around it does not make it hard. At its core, it's an elegant, minimal protocol.

It falls into the category that most people think they understand DNS, the same as JavaScript, or e.g. elections, but the devil is in the detail. And I can tell you, at least for DNS (and Dutch Elections), it's kind of tricky, see fun cases like https://github.com/internetstandards/Internet.nl/issues/1370 and I thought the same before I had my current job which involves quite some tricky DNS stuff (and regarding this…

Dutch elections? How do they come into this?

Re: Async DNS

#45

Post by citrin_ru »

01HNNWZ0MV43FF wrote: post #4

It's weird to me that event-based DNS using epoll or similar doesn't have a battle-tested implementation. I know it's harder to do in C than in Rust but I'm pretty sure that's what Hickory does internally.

Many async frameworks (e. g. libevent [1]) have a DNS client. But it's not something easy to use unless your program uses this specific framework (say libevent) for all network I/O. The problem is not that it's hard to do in C but that there is no single async framework everyone would use.

[1] https://libevent.org/libevent-book/Ref9_dns.html

Re: Async DNS

#46

Post by marcusb »

cryptonector wrote: post #43
leshow wrote: post #40

Earlier quoted context omitted.

I use hickory a lot and have contributed to it. It does have a pretty robust async DNS implementation, and its helpfully split into multiple different crates so you can pick your entry point into the stack. For instance, it offers a recursive resolver, but you can also just import the protocol library and build your own with tokio.

Link?

I'm one of the Hickory maintainers, although I mainly work on the server-side code.

https://github.com/hickory-dns/hickory-dns is our Git repo

Documentation for the resolver including an example: https://docs.rs/hickory-resolver/latest/hickory_resolver/ind...

Re: Async DNS

#47

Post by cryptonector »

marcusb wrote: post #46
cryptonector wrote: post #43

Earlier quoted context omitted.

Link?

I'm one of the Hickory maintainers, although I mainly work on the server-side code. https://github.com/hickory-dns/hickory-dns is our Git repo Documentation for the resolver including an example: https://docs.rs/hickory-resolver/latest/hickory_resolver/ind...

Thank you!

Re: Async DNS

#48

Post by nextaccountic »

cryptonector wrote: post #35
frumplestlatz wrote: post #7

Earlier quoted context omitted.

I am always amused when folks rediscover the bad idea that is `pthread_cancel()` — it’s amazing that it was ever part of the standard. We knew it was a bad idea at the time it was standardized in the 1990s, but politics — and the inevitable allure of a very convenient sounding (but very bad) idea — meant that the bad idea won. Funny enough, while Java has deprecated their version of thread cancellation for the same r…

`pthread_cancel()` is necessary _only_ to interrupt compute-only code without killing the entire process. That's it. The moment you try to use it to interrupt _I/O_ you lose -- you lose BIG .

there is a better way - in any unbounded compute loop, add some code to check for cancellation. it can be very very very cheap

this is not possible if you are calling third party code that you can't modify. in this case it's probably a better idea to run it on another process and use shared memory to communicate back results. this can even be done in an airtight sandboxed manner (browsers do this for example), something that can't really be done with threads

Re: Async DNS

#49

Post by bwblabs »

cryptonector wrote: post #44
bwblabs wrote: post #21

Earlier quoted context omitted.

It falls into the category that most people think they understand DNS, the same as JavaScript, or e.g. elections, but the devil is in the detail. And I can tell you, at least for DNS (and Dutch Elections), it's kind of tricky, see fun cases like https://github.com/internetstandards/Internet.nl/issues/1370 and I thought the same before I had my current job which involves quite some tricky DNS stuff (and regarding this…

Dutch elections? How do they come into this?

There is this list of things tech people think they understand (DNS, javascript), and more common you can see this with everyday people, e.g. with stuff like elections: the basic concept is clear, understandable, but the devil/complexity is in the detail, how to handle certain exceptions. I was employed by the Election Management Body of The Netherlands for a few years, so I can only vouch for the complexity of that relatively simple election system, but I'm pretty sure it will hold for about every country ;)

Re: Async DNS

#50

Post by cryptonector »

nextaccountic wrote: post #48
cryptonector wrote: post #35

Earlier quoted context omitted.

`pthread_cancel()` is necessary _only_ to interrupt compute-only code without killing the entire process. That's it. The moment you try to use it to interrupt _I/O_ you lose -- you lose BIG .

there is a better way - in any unbounded compute loop, add some code to check for cancellation. it can be very very very cheap this is not possible if you are calling third party code that you can't modify. in this case it's probably a better idea to run it on another process and use shared memory to communicate back results. this can even be done in an airtight sandboxed manner (browsers do this for example), someth…

Right, and then you can kill it, but that's essentially what `pthread_cancel()` is. `pthread_cancel()` is just fine as long as that's all you use it for. The moment you go beyond interruption of 100% compute-bound work, you're in for a world of hurt.
Post reply on HN