Re: [Doh] special meta QTYPEs

[Tony Finch <[e-mail]>]

Ben Schwartz <bemasc=[e-mail]> wrote:
> On Wed, Jun 6, 2018 at 4:50 PM Tony Finch <[e-mail]> wrote:
> >
> > I think it is reasonable for an implementation to support TKEY or MAILA or
> > MAILB if it wishes. I don't think it's possible to fit AXFR or IXFR into
> > DoH because their responses involve multiple DNS messages.
>
> Do you believe this is an intrinsic property of DoH, or can you imagine a
> future media type that could represent AXFR in a single HTTP response?

It's possible (of course!) but yes, it would require a different media
type, and a document along the lines of RFC 5936 (the AXFR spec) that
describes it.

Maybe your question implies a way for better forwards compatibility:

    A DoH server MUST return a DNS error response, either RCODE=1 (format
    error) or RCODE=4 (not implemented) if it receives a request with an
    unknown meta-QTYPE between 128 and 254 inclusive. The meta-QTYPE 255
    (* or ANY) SHOULD be supported. The meta-QTYPEs 251 (IXFR) and 252
    (AXFR) SHOULD be treated as unknown.

    This is because meta-QTYPEs can affect the way a DNS response is
    framed; for example, AXFR and IXFR responses can span multiple DNS
    messages, whereas an application/dns-message responsecan only contain
    one DNS message.

    Future specifications might extend this protocol to support more
    meta-QTYPEs over HTTP; these are likely to require media types other
    than application/dns-message; so the content type of the response MAY
    depend on the OPCODE and QTYPE of the request.

That last MAY is a biggie, I think, and probably needs to be mentioned
prominently up front.

Tony.
-- 
f.anthony.n.finch  <[e-mail]>  http://dotat.at/
oppose all forms of entrenched privilege and inequality