3 ms·

The DNS protocol is just a landmine even for the most experienced developers. Just look at those recursive name fields! I think it's time we come up with somet

by zibzab 5y ago

The DNS protocol is just a landmine even for the most experienced developers. Just look at those recursive name fields! I think it's time we come up with something better.

inshadows 5y ago
Like what? Are you going to split the world into two incompatible protocols because of little things like field names?
- zibzab 5y ago
  Like a DNSv2 with a more sane encoding scheme. Given how slow dnssec is being adopted, maybe if we hurry our children can enjoy DNSv2
  - inshadows 5y ago
    What's insane on DNS encoding scheme? Do you consider binary encoding insane? Would you like to re-engineer protocols down to Ethernet to use JSON? For what reason exactly? You suggest breaking compatibility for everyone on this planet without giving any specific reason for doing so.
    - zibzab 5y ago
      Please read the rfc, then think about how a naive implementation of the name encoding can be abused. We have had many vulnerabilities related to that single section of the standard over 30 years. At some point you have to ask yourself if the problem lies with the developers or the standard.
  - tptacek 5y ago
    DoH has lots of uptake. So does DKIM. The reason DNSSEC is moribund is that it doesn't solve real problems for ordinary people. I wouldn't be so pessimistic about getting real new stuff deployed.
wahern 5y ago
As far as compression algorithms go, DNS' algorithm is ridiculously simple. Switching compression algorithms wouldn't improve security. At best it'd be a lateral move; more likely it'd be a net security loss. We would likely get better compression, though. If the response is that people would just reuse pre-existing compression libraries, the exact same thing could be said here. In fact, Unix systems provide `dn_expand` and `dn_comp` in libc (e.g. BSDs, Linux/glibc, Linux/musl) or another system library (e.g. -lresolv on Solaris). And of course nginx could have used one of countless other DNS libraries, such as libunbound.

by zibzab 5y ago

The DNS protocol is just a landmine even for the most experienced developers. Just look at those recursive name fields! I think it's time we come up with something better.

inshadows 5y ago

Like what? Are you going to split the world into two incompatible protocols because of little things like field names?

zibzab 5y ago
Like a DNSv2 with a more sane encoding scheme. Given how slow dnssec is being adopted, maybe if we hurry our children can enjoy DNSv2
- inshadows 5y ago
  What's insane on DNS encoding scheme? Do you consider binary encoding insane? Would you like to re-engineer protocols down to Ethernet to use JSON? For what reason exactly? You suggest breaking compatibility for everyone on this planet without giving any specific reason for doing so.
  - zibzab 5y ago
    Please read the rfc, then think about how a naive implementation of the name encoding can be abused. We have had many vulnerabilities related to that single section of the standard over 30 years. At some point you have to ask yourself if the problem lies with the developers or the standard.
- tptacek 5y ago
  DoH has lots of uptake. So does DKIM. The reason DNSSEC is moribund is that it doesn't solve real problems for ordinary people. I wouldn't be so pessimistic about getting real new stuff deployed.

wahern 5y ago

As far as compression algorithms go, DNS' algorithm is ridiculously simple. Switching compression algorithms wouldn't improve security. At best it'd be a lateral move; more likely it'd be a net security loss. We would likely get better compression, though. If the response is that people would just reuse pre-existing compression libraries, the exact same thing could be said here. In fact, Unix systems provide `dn_expand` and `dn_comp` in libc (e.g. BSDs, Linux/glibc, Linux/musl) or another system library (e.g. -lresolv on Solaris). And of course nginx could have used one of countless other DNS libraries, such as libunbound.