Re: [Doh] meta qtypes

On Tue, Mar 20, 2018 at 9:38 AM, Dave Lawrence <tale@dd.org> wrote:

> Petr Špaček writes:
> > Oh, but in that case the theoretical "proxy" would have re-assemble
> > answers from TCP connection to a DNS server into jumbo-message. Bleh,
> > please do not do this. DNS is complex as hell now and additional layer
> > of complexity in translation is going to be major pain.
>
> If your HTTP server didn't want to do an AXFR because of the extra
> coding involved, it's got HTTP error codes to signal that.  Should the
> doc recommend a specific one for whatever DNS features the HTTPS
> server chooses not to support?
>
>
I know this is sounding like an old refrain - but we want clients to handle
all applicable codes and also need to be aware that HTTP servers other than
DoH servers might be generating error responses. So in general creating
laundry lists of response codes is an anti-pattern of over specification.
BCP56bis talks about this.

In the case of a server that doesn't want to answer a request, 7231
provides all of 5xx to mean that. i.e. the server is aware it has erred or
is incapable of handling the request. Restating just that is less
objectionable but we run the risk of introduce subtle mistakes when all we
want is redundancy. We're much better off just including HTTP by reference
as we're doing.

(personally I would use 501 or maybe 502 if I squinted at it hard.)

> My main point is that on a practical level nothing precludes being
> able to do a DNS response greater than 64k over HTTPS, and if an
> implementer wants to support AXFR for whatever reason I don't see why
> they need to be blocked from that.
>
> personally agree

> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>