Subject: [Doh] special meta QTYPEs

From: Tony Finch <[email-masked]>
Date: Wed, 6 Jun 2018 15:49:40 +0100

I think there needs to be some specific wording about query meta-types
(i.e. 128 <= QTYPE <= 255).

Meta-types can change the framing rules of the response, e.g. IXFR and
AXFR, so a DoH server needs to understand them even if it is implemented
as a mostly-blind proxy.

My DoH implementation generates its own NOTIMP response if it gets a query
with 128 <= QTYPE <= 254 (it allows QTYPE=*/ANY). The other meta type is
OPT, but it isn't special-cased because it's safe to proxy.

BIND returns FORMERR rather than NOTIMP for unknown meta-types; it
seems to reserve NOTIMP for known but deprecated types.

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.

Suggested wording:

    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) MUST NOT be supported and the DoH server MUST return an error
    response.

    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 A DoH response can only contain one DNS message.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Humber: Variable mainly north, 3 or 4. Moderate at first in northwest,
otherwise slight. Fog patches. Moderate or good, occasionally very poor.

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 7 Jun 2018 12:29:59 +0200

> 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?

Suggested wording:
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>

---

From: Tony Finch <[email-masked]>
Date: Thu, 7 Jun 2018 11:55:46 +0100

> 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:

    (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  <[email-masked]>  http://dotat.at/
oppose all forms of entrenched privilege and inequality

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 7 Jun 2018 12:58:02 -0400

Tony Finch writes:
> I don't think it's possible to fit AXFR or IXFR into

Adding my comment about *XFR from a different thread to this thread
too, for tracking.

Strictly speaking, that's not fully accurate.  I have plenty of zones
that fit in a single DNS/TCP message when sent over AXFR, and
DNS/HTTPS would cover the rest quite easily if left in its current
form.  Adding a restriction on message lengths would make this more
complicated.

---

From: Tony Finch <[email-masked]>
Date: Fri, 8 Jun 2018 14:38:32 +0100

> form.  Adding a restriction on message lengths would make this more

I was speaking in general terms, of course :-) An AXFR client has to be
prepared to handle multiple messages in a response, regardless of the size
of the zone, so a DoH proxy that tries to support AXFR cannot avoid
learning how to cope with multi-message answers from its upstream DNS
server. And it isn't always possible to de-fragment an AXFR response: e.g.
it will break any TSIG authentication.

And as Robert Edmonds pointed out, even if you lift the 64K byte message
size limit, there is still a limit of 64K records (the zone contents are
transferred using the answer section only), and I have plenty of zones
which are bigger than that :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
North Hebrides: Easterly 4 or 5. Moderate. Fair. Good occasionally moderate.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 8 Jun 2018 15:51:39 +0200

> it will break any TSIG authentication.

That's interesting.  Are you saying that a multi-message answer that
is TSIG authenticated cannot be carried in DOH?  I think that's what
this means.  Would it require the use of something like
multipart/related to faithfully carry the answer in that case?

---

From: Tony Finch <[email-masked]>
Date: Fri, 8 Jun 2018 14:56:26 +0100

> > And it isn't always possible to de-fragment an AXFR response: e.g.
> this means.

Yes, if you try to defragment it into a single DNS message so it fits the
definition of application/dns-message.

> Would it require the use of something like multipart/related to
> faithfully carry the answer in that case?

Cunning! I think that could work.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty, Forth, Tyne, Dogger: North, becoming variable, 3 or 4.
Slight, occasionally moderate in Forties. Fair. Good occasionally moderate.