3 ms·

Indeed. I think the particular media type is a little beside the point though as long as it is machine readable. Luckily HTTP has built in content negotiation s

Indeed. I think the particular media type is a little beside the point though as long as it is machine readable. Luckily HTTP has built in content negotiation so it's not a hard problem to deal with.

detaro 6y ago
Then I don't get the proposed benefit of DoH here. curl + parsing a standard DNS response is not really easier than just using a DNS client.
- alangibson 6y ago
  Most developers have never touched a DNS response beyond requesting host name resolution. DoH makes it possible to request the information in a way familiar to far more developers. But DoH is by no means a requirement. If you like the DNS protocol, then by all means have at it.
- akdor1154 6y ago
  Https is a benefit.
- javajosh 6y ago
  Curl + parsing is better because it decouples transportation from interpretation. Dnswalk and other clients that speak "native" DNS provide are monolithic, handling transportation, parsing, and more. And many of these concerns, like data transfer, are dealt with in an ad hoc way, when it might be preferable to always assume URL+DNS+TCP+HTTPS+GET=>JSON. As a one-size-fits-all transport mechanism, it's not bad at all. Still not convinced? Imagine a world where APIs are only called from inside proprietary binary blobs that are built and released by the API provider. In that world the indirection is in the wrong place, at the process invocation level. Luckily this doesn't apply to (most) APIs these days, although it does apply to certain areas of software, like embedded programming (or so I hear). But this is analogous to using a specific binary tool to interact with DNS vs HTTP. Yes, I'm sensitive to the argument that we shouldn't abandon the other parts of the network stack, and forget that there is more to doing networked applications than just TCP+HTTP. But honestly, for practical reasons there should be very compelling reasons to "drop down" the stack and pick something like UDP+DNS for your application.
  - wahern 6y ago
    > Imagine a world where APIs are only called from inside proprietary binary blobs that are built and released by the API provider. I don't have to imagine it. It exists, and it was created by people who insisted on building ridiculously complex software stacks which have made it increasingly difficult to write your own stack. And the few open source stacks are slowly winnowed down because it becomes a feature arms race and eventually the last option standing is the "free" crippled version of some corporate developed library. Sending and receiving a DNS UDP query, and extracting your RR of interest, takes a few dozen lines of C code. (Using TCP is just as easy if not easier.) Now imagine doing something so simple, but first having to build the SSL and HTTP stacks (or, shudder, QUIC). Nobody would do it. Everybody would just use the same piece of software. This is exactly how we ended up with Chrome and an unimaginably empowered Google. And it was for the same reasons--"imagine how easy it will be for a web developer to implement feature FOO if we simply added feature FOO to the browser and he could just call do.FOO!"
    - javajosh 6y ago
      >I don't have to imagine it. It exists. Not sure what you mean, here. HTTP-based APIs have been really good, I think, for the world overall, and not just because exposing services this was allows you to tunnel arbitrary application data through firewalls! Are the real blobs you're referring to the browser? I don't think that's fair, because a browser does far more than curl. And curl-level functionality is a lot simpler. >a few dozen lines of C code... ...built and executed in a specific runtime environment. And since we are talking about distributed programs, by nature, you will be faced with solving all of those painful lessons we've learned about security, performance, and scale, but this time with your own custom starting assumptions. I think it's quite fair to accept the "curl abstraction" (expressed in callback hell form as get(request, callback(response)) as a basic building block of your system, as opposed to doing something lower level.

Indeed. I think the particular media type is a little beside the point though as long as it is machine readable. Luckily HTTP has built in content negotiation so it's not a hard problem to deal with.

detaro 6y ago

Then I don't get the proposed benefit of DoH here. curl + parsing a standard DNS response is not really easier than just using a DNS client.

alangibson 6y ago
Most developers have never touched a DNS response beyond requesting host name resolution. DoH makes it possible to request the information in a way familiar to far more developers. But DoH is by no means a requirement. If you like the DNS protocol, then by all means have at it.
akdor1154 6y ago
Https is a benefit.
javajosh 6y ago
Curl + parsing is better because it decouples transportation from interpretation. Dnswalk and other clients that speak "native" DNS provide are monolithic, handling transportation, parsing, and more. And many of these concerns, like data transfer, are dealt with in an ad hoc way, when it might be preferable to always assume URL+DNS+TCP+HTTPS+GET=>JSON. As a one-size-fits-all transport mechanism, it's not bad at all. Still not convinced? Imagine a world where APIs are only called from inside proprietary binary blobs that are built and released by the API provider. In that world the indirection is in the wrong place, at the process invocation level. Luckily this doesn't apply to (most) APIs these days, although it does apply to certain areas of software, like embedded programming (or so I hear). But this is analogous to using a specific binary tool to interact with DNS vs HTTP. Yes, I'm sensitive to the argument that we shouldn't abandon the other parts of the network stack, and forget that there is more to doing networked applications than just TCP+HTTP. But honestly, for practical reasons there should be very compelling reasons to "drop down" the stack and pick something like UDP+DNS for your application.
- wahern 6y ago
  > Imagine a world where APIs are only called from inside proprietary binary blobs that are built and released by the API provider. I don't have to imagine it. It exists, and it was created by people who insisted on building ridiculously complex software stacks which have made it increasingly difficult to write your own stack. And the few open source stacks are slowly winnowed down because it becomes a feature arms race and eventually the last option standing is the "free" crippled version of some corporate developed library. Sending and receiving a DNS UDP query, and extracting your RR of interest, takes a few dozen lines of C code. (Using TCP is just as easy if not easier.) Now imagine doing something so simple, but first having to build the SSL and HTTP stacks (or, shudder, QUIC). Nobody would do it. Everybody would just use the same piece of software. This is exactly how we ended up with Chrome and an unimaginably empowered Google. And it was for the same reasons--"imagine how easy it will be for a web developer to implement feature FOO if we simply added feature FOO to the browser and he could just call do.FOO!"
  - javajosh 6y ago
    >I don't have to imagine it. It exists. Not sure what you mean, here. HTTP-based APIs have been really good, I think, for the world overall, and not just because exposing services this was allows you to tunnel arbitrary application data through firewalls! Are the real blobs you're referring to the browser? I don't think that's fair, because a browser does far more than curl. And curl-level functionality is a lot simpler. >a few dozen lines of C code... ...built and executed in a specific runtime environment. And since we are talking about distributed programs, by nature, you will be faced with solving all of those painful lessons we've learned about security, performance, and scale, but this time with your own custom starting assumptions. I think it's quite fair to accept the "curl abstraction" (expressed in callback hell form as get(request, callback(response)) as a basic building block of your system, as opposed to doing something lower level.