3 ms·

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 pre

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.

frumplestlatz 11mo ago
it’s a weird problem, in that (1) DNS is hard, and (2) you really need the upstream vendor to solve the problem, because correct applications want to use the system resolver. If you don’t use the system resolver, you have to glue into the system’s configuration mechanism for resolvers somehow … which isn’t simple — for example, there’s a lot of complex logic on macOS around handling which resolver to use based on what connections, VPNs, etc, are present. And the there’s nsswitch and other plugin systems that are meant to allow globally configured hooks plug into the name resolution path.
- AndyKelley 11mo ago
  (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.
  - bwblabs 11mo ago
    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 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 we also sometimes encounter bugs in unbound https://github.com/internetstandards/Internet.nl/issues/1803 https://github.com/internetstandards/Internet.nl/issues/1803 ) But maybe DNSSEC is the 'unnecessary complexity' for you (I think it's kind of fundamental to secure DNS). Also without DNSSEC they needed RFC's like https://datatracker.ietf.org/doc/html/rfc8020 https://datatracker.ietf.org/doc/html/rfc8020 to clarify fundamentals (same goes for https://datatracker.ietf.org/doc/html/rfc8482 https://datatracker.ietf.org/doc/html/rfc8482 to fix stuff).
    - cryptonector 11mo ago
      Dutch elections? How do they come into this?
      - bwblabs 10mo ago
        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 ;)
  - tptacek 11mo ago
    Lots of elegant, minimal things are hard to use effectively.
  - kccqzy 11mo ago
    You and GP are talking about completely different things. Yes DNS at its core it’s an elegant minimal protocol. But all the complexity comes from client side configuration before the protocol is even involved. We have complexity like different kinds of VPNs, from network-level VPNs to app-based VPNs to MDM-managed VPNs possibly coexisting. We have on-demand VPNs that only start when a particular domain is being visited: yes VPN starting because of DNS. We have user-provided or admin-provided hardcoded responses in /etc/hosts. We have user-specified resolver overrides (for example the user wants to use 8.8.8.8 not ISP resolver). We have multiple sources of network-provided resolvers from RDNSS to DHCPv6 O mode. It is non-trivial to determine which resolver to even start sending datagrams with that elegant minimal protocol.
leshow 11mo ago
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.
- cryptonector 11mo ago
  Link?
  - marcusb 11mo ago
    I'm one of the Hickory maintainers, although I mainly work on the server-side code. https://github.com/hickory-dns/hickory-dns 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/index.html https://docs.rs/hickory-resolver/latest/hickory_resolver/ind...
    - cryptonector 10mo ago
      Thank you!
citrin_ru 11mo ago
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 https://libevent.org/libevent-book/Ref9_dns.html

frumplestlatz 11mo ago

it’s a weird problem, in that (1) DNS is hard, and (2) you really need the upstream vendor to solve the problem, because correct applications want to use the system resolver. If you don’t use the system resolver, you have to glue into the system’s configuration mechanism for resolvers somehow … which isn’t simple — for example, there’s a lot of complex logic on macOS around handling which resolver to use based on what connections, VPNs, etc, are present. And the there’s nsswitch and other plugin systems that are meant to allow globally configured hooks plug into the name resolution path.

AndyKelley 11mo ago
(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.
- bwblabs 11mo ago
  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 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 we also sometimes encounter bugs in unbound https://github.com/internetstandards/Internet.nl/issues/1803 https://github.com/internetstandards/Internet.nl/issues/1803 ) But maybe DNSSEC is the 'unnecessary complexity' for you (I think it's kind of fundamental to secure DNS). Also without DNSSEC they needed RFC's like https://datatracker.ietf.org/doc/html/rfc8020 https://datatracker.ietf.org/doc/html/rfc8020 to clarify fundamentals (same goes for https://datatracker.ietf.org/doc/html/rfc8482 https://datatracker.ietf.org/doc/html/rfc8482 to fix stuff).
  - cryptonector 11mo ago
    Dutch elections? How do they come into this?
    - bwblabs 10mo ago
      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 ;)
- tptacek 11mo ago
  Lots of elegant, minimal things are hard to use effectively.
- kccqzy 11mo ago
  You and GP are talking about completely different things. Yes DNS at its core it’s an elegant minimal protocol. But all the complexity comes from client side configuration before the protocol is even involved. We have complexity like different kinds of VPNs, from network-level VPNs to app-based VPNs to MDM-managed VPNs possibly coexisting. We have on-demand VPNs that only start when a particular domain is being visited: yes VPN starting because of DNS. We have user-provided or admin-provided hardcoded responses in /etc/hosts. We have user-specified resolver overrides (for example the user wants to use 8.8.8.8 not ISP resolver). We have multiple sources of network-provided resolvers from RDNSS to DHCPv6 O mode. It is non-trivial to determine which resolver to even start sending datagrams with that elegant minimal protocol.

leshow 11mo ago

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.

cryptonector 11mo ago
Link?
- marcusb 11mo ago
  I'm one of the Hickory maintainers, although I mainly work on the server-side code. https://github.com/hickory-dns/hickory-dns 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/index.html https://docs.rs/hickory-resolver/latest/hickory_resolver/ind...
  - cryptonector 10mo ago
    Thank you!

citrin_ru 11mo ago

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 https://libevent.org/libevent-book/Ref9_dns.html