Re: [Doh] meta qtypes

Patrick McManus <pmcmanus@mozilla.com> Tue, 20 March 2018 10:11 UTC

Return-Path: <pmcmanus@mozilla.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9647124319 for <doh@ietfa.amsl.com>; Tue, 20 Mar 2018 03:11:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.101
X-Spam-Level: **
X-Spam-Status: No, score=2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VhbWFWxWCrD for <doh@ietfa.amsl.com>; Tue, 20 Mar 2018 03:11:23 -0700 (PDT)
Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 943EF1200F1 for <doh@ietf.org>; Tue, 20 Mar 2018 03:11:23 -0700 (PDT)
Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) by linode64.ducksong.com (Postfix) with ESMTPSA id 02D9F3A04F for <doh@ietf.org>; Tue, 20 Mar 2018 06:11:23 -0400 (EDT)
Received: by mail-oi0-f51.google.com with SMTP id a16-v6so792981oia.13 for <doh@ietf.org>; Tue, 20 Mar 2018 03:11:22 -0700 (PDT)
X-Gm-Message-State: AElRT7EPfAqDk2l6oIUJVj3EucFMCyJv502+75VmQHnoIYaR4cGcea1Z HyyYON1M4nL+iJZ5cqo+tGkntL/sjrtH1Uq67mQ=
X-Google-Smtp-Source: AG47ELv7BQ3F8pIs2jDjyHr1Csp09ZloB3qCsY5bxUGICLHk46KDbHx++Vxk39/5Yjypmetas/uTqwaYOKZp7NIzTy0=
X-Received: by 10.202.6.195 with SMTP id 186mr8450338oig.347.1521540682689; Tue, 20 Mar 2018 03:11:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.137.147 with HTTP; Tue, 20 Mar 2018 03:11:21 -0700 (PDT)
In-Reply-To: <23216.54906.978869.638719@gro.dd.org>
References: <20180318143811.bn5kwr7oqo2ux6qm@miek.nl> <CAOdDvNoNN98zOuPAepS0=0Nt06+UAGV1ZCrxs0J2TzQaVnJz8w@mail.gmail.com> <CAN6NTqwA+Ub22Ajr_RGGh2+32aMMUMcKnPdUrUpkk8zF6TBn1Q@mail.gmail.com> <20180319131134.46hjo2eo757jqe7d@miek.nl> <16CD849A-55B3-487C-A370-CA96FF619BC3@bangj.com> <alpine.DEB.2.11.1803191408010.20806@grey.csi.cam.ac.uk> <23215.52292.616186.468475@gro.dd.org> <3a58b678-e514-b34f-f477-a3f36dbbea15@nic.cz> <23216.54906.978869.638719@gro.dd.org>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Tue, 20 Mar 2018 10:11:21 +0000
X-Gmail-Original-Message-ID: <CAOdDvNrC2tynBgNnoquc5Ewa=F1OqeQMZE3O0DEpmj-jW6EAxw@mail.gmail.com>
Message-ID: <CAOdDvNrC2tynBgNnoquc5Ewa=F1OqeQMZE3O0DEpmj-jW6EAxw@mail.gmail.com>
To: Dave Lawrence <tale@dd.org>
Cc: DoH WG <doh@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c13f9a0e732820567d54b5c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/0uhalLsed0-GQYprwJN0M3ZE-IA>
Subject: Re: [Doh] meta qtypes
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Mar 2018 10:11:26 -0000

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
>