Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsext-multi-qtypes-03.txt

From: william manning <[email-masked]>
Date: Thu, 3 Nov 2016 05:21:32 -0700

flogging a dead horse.  Did you see this?
https://www.rfc-editor.org/rfc/rfc6804.txt

On Wed, Oct 26, 2016 at 2:23 AM, Ray Bellis <[email-masked]> wrote:

> This is a very minor update, mostly just to keep the document alive.
>
> Ray
>
> -------- Forwarded Message --------
> Subject: New Version Notification for
> draft-bellis-dnsext-multi-qtypes-03.txt
> Date: Wed, 26 Oct 2016 02:22:55 -0700
> From: [email-masked]
> To: Ray Bellis <[email-masked]>
>
>
> A new version of I-D, draft-bellis-dnsext-multi-qtypes-03.txt
> has been successfully submitted by Ray Bellis and posted to the
> IETF repository.
>
> Name:           draft-bellis-dnsext-multi-qtypes
> Revision:       03
> Title:          DNS Multiple QTYPEs
> Document date:  2016-10-26
> Group:          Individual Submission
> Pages:          6
> URL:
> https://www.ietf.org/internet-drafts/draft-bellis-dnsext-
> multi-qtypes-03.txt
> Status:
> https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/
> Htmlized:
> https://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-03
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-bellis-dnsext-multi-qtypes-03
>
> Abstract:
>    This document specifies a method for a DNS client to request
>    additional DNS record types to be delivered alongside the primary
>    record type specified in the question section of a DNS query.
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Ray Bellis <[email-masked]>
Date: Thu, 3 Nov 2016 12:23:16 +0000

>  https://www.rfc-editor.org/rfc/rfc6804.txt

I didn't see that before, but DNSOP doesn't seem to be able to decide
whether the horse is really dead yet or not.

Of the potential solutions on the table, mine seems to be the simplest.

Ray

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 3 Nov 2016 17:57:04 +0000

Hi Ray,

>    QTn: a 2 byte field (MSB first) specifying a DNS RR type.  The RR
>    type MUST be for a real resource record, and MUST NOT refer to a
>    pseudo RR type such as "OPT", "IXFR", "TSIG", "*", etc.

How is an implementation expected to know which types are pseudo?  Should this document specify the list of forbidden pseudo types at the time of publication?

I don't think the document says how a server should respond to receiving a forbidden pseudo type, does it?

>    A server that is authoritative for the specified QNAME on receipt of
>    a Multiple QTYPE Option MUST attempt to return all specified RR types
>    except where that would result in truncation in which case it may
>    omit some (or all) of the records for the additional RR types.  Those
>    RR types MUST then also be omitted from the Multiple QTYPE Option in
>    the response.

Data in the Additional section also competes for space up to the truncation limit, right?  Which has priority, the Multiple QTYPE data or the normal Additional data?

>    If the DNS client sets the "DNSSEC OK" (DO) bit in the query then the
>    server MUST also return the related DNSSEC records that would have
>    been returned in a standalone query for the same QTYPE.
> 
>    A negative answer from a signed zone MUST contain the appropriate
>    authenticated denial of existence records, per [RFC4034] and
>    [RFC5155].

So we should expect to see single responses that have both positive and negative DNSSEC records together.  That should be fun... :-)

DW

---

From: Ray Bellis <[email-masked]>
Date: Thu, 3 Nov 2016 18:17:15 +0000

> How is an implementation expected to know which types are pseudo?
> Should this document specify the list of forbidden pseudo types at
> the time of publication?

I would take that to be any RR in the ranges set aside for meta types
in the IANA RRTYPE registry, plus OPT.

> I don't think the document says how a server should respond to
> receiving a forbidden pseudo type, does it?

I think you're right.  Do you think it should be FORMERR, or perhaps
just ignore any disallowed types [and omit them from the returned QTn
list] ?

>> A server that is authoritative for the specified QNAME on receipt
>> of a Multiple QTYPE Option MUST attempt to return all specified RR
>> types except where that would result in truncation in which case it
>> may omit some (or all) of the records for the additional RR types.
>> Those RR types MUST then also be omitted from the Multiple QTYPE
>> Option in the response.
> 
> Data in the Additional section also competes for space up to the
> truncation limit, right?  Which has priority, the Multiple QTYPE data
> or the normal Additional data?

My gut reaction is the latter, on the basis that this is closest to
"fallback to non-supporting behaviour".  I'm not sure there's a
definitive correct answer, though.

>> If the DNS client sets the "DNSSEC OK" (DO) bit in the query then
>> the server MUST also return the related DNSSEC records that would
>> have been returned in a standalone query for the same QTYPE.
>> 
> So we should expect to see single responses that have both positive
> and negative DNSSEC records together.  That should be fun... :-)

Yes, AIUI in theory you'd get individual RRSIGs over the QTn records
that exist, and a single NSEC[3] record that proves the existence (or
otherwise) of any others.

FWIW, I don't intend to spend too much more time on this draft until
such time as DNSOP determines that this really is a problem worth solving.

thanks for the review!

Ray