Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Masataka Ohta]

Joe Abley wrote:


1035 clearly allows QDCOUNT>1 for responses
to IQUERY and 1034 clearly specifies QDCOUNT=1 for standard
queries and responses.


It sounds like you agree with the archaeology and the
proposed clarification in the draft.


Even though my statement above is made against:

> RFC 1035's ambiguity on the matter needs clarification.

???

That is not a sincere response.


There is no ambiguity.


That you see no need for any clarification while others say
differently is


Because others ignore 1034.

IMHO, those mentioning ambiguity of 1035 without reading
1034 can have no opinion on the matter.

If people feel some ambiguity of 1035 merely because they
ignore 1034, there is no point to publish yet another RFC
for disambiguation, because the new RFC, either, won't
be read.

Read the RFCs.

Masataka Ohta


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Joe Abley]

On Thu, Feb 23, 2023 at 00:22, Masataka Ohta  
wrote:

> 1035 clearly allows QDCOUNT>1 for responses
> to IQUERY and 1034 clearly specifies QDCOUNT=1 for standard
> queries and responses.

It sounds like you agree with the archaeology and the proposed clarification in 
the draft.

> There is no ambiguity.

That you see no need for any clarification while others say differently is a 
second order existence proof of the ambiguity that you say does not exist.

Joe

>___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Masataka Ohta]

Ray Bellis wrote:

Notwithstanding an implementation apparently getting by in the DNSSD 
space, I remain convinced that QDCOUNT > 1 has no place in the global 
DNS and that RFC 1035's ambiguity on the matter needs clarification.


No, not at all. 1035 clearly allows QDCOUNT>1 for responses
to IQUERY and 1034 clearly specifies QDCOUNT=1 for standard
queries and responses.

There is no ambiguity.

Masataka Ohta

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Tim Wicinski]

(as a chair)

On Wed, Feb 22, 2023 at 9:09 PM Joe Abley  wrote:

> On Wed, Feb 22, 2023 at 21:01, Ted Lemon  wrote:
>
> No, my main objection to the current draft is that it’s dismissing the
> problem I raised.
>
>
> Could you restate the problem?
>
> You mentioned that you thought the ambiguity in 1035 was a problem; that's
> what this draft is addressing. I believe Ray is prepared to resurrect his
> EDNS(0) approach to multiple questions in the same query; I thought that
> was the other problem.
>

>From my reading last week I thought Ted's point was that 1035 did not say
you can not use QDCOUNT > 1.
(Ted, if I'm wrong feel free to correct me)

I'm a big supporter of being as explicit as we can to prevent ambiguity. I
also know if there is such an ambiguity for any length of time,
we're going to use such ambiguity for Bad DNS Decisions.  We can't help
ourselves.


> I don’t think qdcount > 1 makes sense on the public internet either.
>
>
> Cool.
>

This sounds like the road to consensus.

> I also think talking about dns messages that are not asking questions and
> have different qdcounts just confuses the issue.
>
>
> Ok, that's reasonable feedback. I thought it was useful to anticipate the
> question of what to do with other opcodes and to demonstrate why they don't
> suffer from the same ambiguity.
>
>
When Ray mentioned that dns messages can not ask questions, I encouraged
him to document that to be complete.
My personal feeling (however misguided) is if we're updating working like
1035, we should be as accurate as possible
to leave no ambiguity.  Always happy to be told I'm wrong.

I personally also have come back around on the multi-qtypes draft.


tim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Joe Abley]

On Wed, Feb 22, 2023 at 21:01, Ted Lemon  wrote:

> No, my main objection to the current draft is that it’s dismissing the 
> problem I raised.

Could you restate the problem?

You mentioned that you thought the ambiguity in 1035 was a problem; that's what 
this draft is addressing. I believe Ray is prepared to resurrect his EDNS(0) 
approach to multiple questions in the same query; I thought that was the other 
problem.

> I don’t think qdcount > 1 makes sense on the public internet either.

Cool.

> I also think talking about dns messages that are not asking questions and 
> have different qdcounts just confuses the issue.

Ok, that's reasonable feedback. I thought it was useful to anticipate the 
question of what to do with other opcodes and to demonstrate why they don't 
suffer from the same ambiguity.

Joe

>>___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Ted Lemon]

No, my main objection to the current draft is that it’s dismissing the
problem I raised. I don’t think qdcount > 1 makes sense on the public
internet either.

I also think talking about dns messages that are not asking questions and
have different qdcounts just confuses the issue.

On Wed, 22 Feb 2023 at 20:14, George Michaelson  wrote:

> Oh, I assumed Ted was moving to a formalism which explicitly
> authorises QDCOUNT > 1 in the public space, and leverages it.
>
> If we're not heading there, and there is only a document heading to
> QDCOUNT is 1 and evermore shall be so, there's no conflict.
>
> -G
>
> On Thu, Feb 23, 2023 at 10:55 AM Joe Abley  wrote:
> >
> > Hi George,
> >
> > On Wed, Feb 22, 2023 at 19:37, George Michaelson 
> wrote:
> >
> > purely administratively, I'd like to understand how the WG chairs and
> > AD intend dealing with fundamentally opposed drafts.
> >
> >
> > There's only one draft here, as far as I know.
> >
> > Ted pointed out a DNS implementation in OpenThread that is based on a
> different interpretation of 1035 than (I think) the more usual
> understanding reflected in DNS implementation in use in the public DNS. The
> purpose of this draft is to highlight some problems with that
> interpretation and to propose a consensus interpretation of 1035 (a
> clarification) so that other people might avoid them.
> >
> > Implementations are free to make whatever choices they want regardless
> of what any working group says. OpenThread's approach might work perfectly
> well in a constrained environment where the DNS servers receiving queries
> with QDCOUNT > 1 are built to suit IoT devices' particular requirements and
> assumptions. That doesn't make it a good idea for the protocol in general.
> >
> > This draft is not about OpenThread's particular situation; it's about
> the base protocol.
> >
> > I don't see any conflict, here.
> >
> >
> > Joe
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[George Michaelson]

Oh, I assumed Ted was moving to a formalism which explicitly
authorises QDCOUNT > 1 in the public space, and leverages it.

If we're not heading there, and there is only a document heading to
QDCOUNT is 1 and evermore shall be so, there's no conflict.

-G

On Thu, Feb 23, 2023 at 10:55 AM Joe Abley  wrote:
>
> Hi George,
>
> On Wed, Feb 22, 2023 at 19:37, George Michaelson  wrote:
>
> purely administratively, I'd like to understand how the WG chairs and
> AD intend dealing with fundamentally opposed drafts.
>
>
> There's only one draft here, as far as I know.
>
> Ted pointed out a DNS implementation in OpenThread that is based on a 
> different interpretation of 1035 than (I think) the more usual understanding 
> reflected in DNS implementation in use in the public DNS. The purpose of this 
> draft is to highlight some problems with that interpretation and to propose a 
> consensus interpretation of 1035 (a clarification) so that other people might 
> avoid them.
>
> Implementations are free to make whatever choices they want regardless of 
> what any working group says. OpenThread's approach might work perfectly well 
> in a constrained environment where the DNS servers receiving queries with 
> QDCOUNT > 1 are built to suit IoT devices' particular requirements and 
> assumptions. That doesn't make it a good idea for the protocol in general.
>
> This draft is not about OpenThread's particular situation; it's about the 
> base protocol.
>
> I don't see any conflict, here.
>
>
> Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Joe Abley]

Hi George,

On Wed, Feb 22, 2023 at 19:37, George Michaelson  wrote:

> purely administratively, I'd like to understand how the WG chairs and
> AD intend dealing with fundamentally opposed drafts.

There's only one draft here, as far as I know.

Ted pointed out a DNS implementation in OpenThread that is based on a different 
interpretation of 1035 than (I think) the more usual understanding reflected in 
DNS implementation in use in the public DNS. The purpose of this draft is to 
highlight some problems with that interpretation and to propose a consensus 
interpretation of 1035 (a clarification) so that other people might avoid them.

Implementations are free to make whatever choices they want regardless of what 
any working group says. OpenThread's approach might work perfectly well in a 
constrained environment where the DNS servers receiving queries with QDCOUNT > 
1 are built to suit IoT devices' particular requirements and assumptions. That 
doesn't make it a good idea for the protocol in general.

This draft is not about OpenThread's particular situation; it's about the base 
protocol.

I don't see any conflict, here.

Joe

>___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[George Michaelson]

purely administratively, I'd like to understand how the WG chairs and
AD intend dealing with fundamentally opposed drafts.

I would think that a formalism here might be needed: if we discuss A
and not B and reject A, have we implicitly accepted B? And vice-versa?

Do we actually need to discuss both together, most of the time, to
come to understanding about this?

I'd suggest the existence of oppositional drafts (by intent, in no
sense do I see this as personal) -the WG adoption question is moot: we
probably need to adopt a problem statement if not the two specifics.

Is there room to unify? (I know that may be nonsensical for drafts
which oppose intent)

I'm asking, because I really hope we can avoid the inevitable appeal process.

-G

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Ray Bellis]

On 17/02/2023 20:58, Ted Lemon wrote:

OpenThread. It’s on GitHub.


Notwithstanding an implementation apparently getting by in the DNSSD 
space, I remain convinced that QDCOUNT > 1 has no place in the global 
DNS and that RFC 1035's ambiguity on the matter needs clarification.


To that end, Joe Abley and I have written draft-bellis-dnsop-qdcount-is-one



We hope that this (short) draft can quickly gain WG acceptance and 
consensus.


I have also revived my ancient multi-qtypes draft (-00 was in 2012!)



If the QDCOUNT draft is accepted I would propose to simplify some of the 
text in the Multi-Qtypes draft to refer to the former instead of laying 
out the whole problem statement again.


Ray

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Ted Lemon]

OpenThread. It’s on GitHub.

On Fri, 17 Feb 2023 at 15:38, John Kristoff  wrote:

> On Wed, 15 Feb 2023 13:52:03 -0500
> Ted Lemon  wrote:
>
> > It clearly is, in the sense that someone is using it and it keeps
> > coming up. :)
>
> Hi Ted,
>
> I'm just catching up on this conversation and maybe I've missed it, but
> can you point me at the implementation(s) that are setting QDCOUNT > 1?
>
> Thanks kindly,
>
> John
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[John Kristoff]

On Wed, 15 Feb 2023 13:52:03 -0500
Ted Lemon  wrote:

> It clearly is, in the sense that someone is using it and it keeps
> coming up. :)

Hi Ted,

I'm just catching up on this conversation and maybe I've missed it, but
can you point me at the implementation(s) that are setting QDCOUNT > 1?

Thanks kindly,

John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Ted Lemon]

To be clear, I am not saying that RFC1034/1035 say that you /can/ use
QDCOUNT > 1. I am saying that they do /not/ say that you /can not/ use
QDCOUNT > 1.

On Thu, Feb 16, 2023 at 5:53 PM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

> Dick Franks wrote:
>
>  >> So, there is no specification to mention queries with
>  >> QDCOUNT>1, either informatively, optionaly or normatively.
>
>  >> Then, 3425 titled "Obsoleting IQUERY" updated 1035.
>
>  >> As such, after 3425, QDCOUNT nomatively must always be 1.
>
> > The last statement is informatively and normatively mistaken.
> > The counterexample is to be found in RFC8490(5.4):
>
> Not up to date. OK. Thanks. But, my statements are enough to deny
> the original statement by Ted as if 1034 had admitted standard
> queries with QDCOUNT>1 and another statement by Joe:
>
>  > But we know that those are old documents that lack normative
>  > clarity.
>
> w.r.t. normative status of standard queries.
>
> As Mark and I stated:
>
> >> It does not prohibit extended query forms be they a different
> >> QDCOUNT for QUERY, a new opcode which supports multiple queries. > Nor
> does it prohibit protocol extentions to allow standard
>  > queries have QDCOUNT>1,
>
> modifying 1034/5 is fine but possibility/existence of such
> modifications can not be a supporting fact for a false
> statement that 1034 had admitted standard queries with
> QDCOUNT>1.
>
> Masataka Ohta
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Masataka Ohta]

Dick Franks wrote:

>> So, there is no specification to mention queries with
>> QDCOUNT>1, either informatively, optionaly or normatively.

>> Then, 3425 titled "Obsoleting IQUERY" updated 1035.

>> As such, after 3425, QDCOUNT nomatively must always be 1.


The last statement is informatively and normatively mistaken.
The counterexample is to be found in RFC8490(5.4):


Not up to date. OK. Thanks. But, my statements are enough to deny
the original statement by Ted as if 1034 had admitted standard
queries with QDCOUNT>1 and another statement by Joe:

> But we know that those are old documents that lack normative
> clarity.

w.r.t. normative status of standard queries.

As Mark and I stated:


It does not prohibit extended query forms be they a different
QDCOUNT for QUERY, a new opcode which supports multiple queries. > Nor does it 
prohibit protocol extentions to allow standard

> queries have QDCOUNT>1,

modifying 1034/5 is fine but possibility/existence of such
modifications can not be a supporting fact for a false
statement that 1034 had admitted standard queries with
QDCOUNT>1.

Masataka Ohta

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Ray Bellis]

If we're looking for more counterexamples, there's also RFC7873#5.4

For servers with DNS Cookies enabled, the QUERY opcode behavior is
extended to support queries with an empty Question Section (a QDCOUNT
of zero (0)), provided that an OPT record is present with a COOKIE
option.  Such servers will send a reply that has an empty
Answer Section and has a COOKIE option containing the Client Cookie
and a valid Server Cookie.


I can see why that was added, but I really wish it hadn't been...

Ray

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Ray Bellis]

On 16/02/2023 12:52, Dick Franks wrote:


The last statement is informatively and normatively mistaken.
The counterexample is to be found in RFC8490(5.4):

   A DSO message begins with the standard twelve-byte DNS message header
   [RFC1035] with the OPCODE field set to the DSO OPCODE (6).  However,
   unlike standard DNS messages, the question section, answer section,
   authority records section, and additional records sections are not
   present.  The corresponding count fields (QDCOUNT, ANCOUNT, NSCOUNT,
   ARCOUNT) MUST be set to zero on transmission.



Good spot, Dick, and one I admit I'd forgotten about, which as a 
co-author of RFC 8490 is slightly embarrassing!


However for OPCODE 0 (QUERY) the assertion still remains valid.

Ray

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Mark Delany]

On 16Feb23, Dick Franks allegedly wrote:
> The last statement is informatively and normatively mistaken.
> The counterexample is to be found in RFC8490(5.4):
> 
>   A DSO message begins with the standard twelve-byte DNS message header
>   [RFC1035] with the OPCODE field set to the DSO OPCODE (6).  However,
>   unlike standard DNS messages, the question section, answer section,
>   authority records section, and additional records sections are not
>   present.  The corresponding count fields (QDCOUNT, ANCOUNT, NSCOUNT,
>   ARCOUNT) MUST be set to zero on transmission.

If we're looking for more counterexamples, there's also RFC7873#5.4

   For servers with DNS Cookies enabled, the QUERY opcode behavior is
   extended to support queries with an empty Question Section (a QDCOUNT
   of zero (0)), provided that an OPT record is present with a COOKIE
   option.  Such servers will send a reply that has an empty
   Answer Section and has a COOKIE option containing the Client Cookie
   and a valid Server Cookie.


Mark.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Dick Franks]

On Thu, 16 Feb 2023 at 01:14, Masataka Ohta
 wrote:

>8

>
> So, there is no specification to mention queries with QDCOUNT>1,
> either informatively, optionaly or normatively.
>
> Then, 3425 titled "Obsoleting IQUERY" updated 1035.
>
> As such, after 3425, QDCOUNT nomatively must always be 1.
>

The last statement is informatively and normatively mistaken.
The counterexample is to be found in RFC8490(5.4):

  A DSO message begins with the standard twelve-byte DNS message header
  [RFC1035] with the OPCODE field set to the DSO OPCODE (6).  However,
  unlike standard DNS messages, the question section, answer section,
  authority records section, and additional records sections are not
  present.  The corresponding count fields (QDCOUNT, ANCOUNT, NSCOUNT,
  ARCOUNT) MUST be set to zero on transmission.


Dick Franks


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Masataka Ohta]

Benno Overeinder wrote:


We would like to point out that discussions should be respectful


which is about the people and the most common and annoying
disrespectful behaviour in IETF is to make meaningless
comments without reading strongly related rfcs, IDs or
mails which is why we have been saying "Read the draft"
against people lacking proper respect to others.

Without such respect, discussions can not be technical.

In this case, people not reading 1034/5, even
after I quote releavant parts of them, totally
lack respect for pioneering contributers (I'm
not) to DNS in early days.

> Note that the DNSOP WG Chairs ensure that the IETF Guidelines for
> Conduct, RFC 7154, are adhered to.

With proper interpretation of "respect", yes.

Note that meaning of "respect" was discussed in main IETF
list several months ago.

Masataka Ohta

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Benno Overeinder]

All,

We would like to point out that discussions should be respectful and 
about technical issues and not about the person.


Note that the DNSOP WG Chairs ensure that the IETF Guidelines for 
Conduct, RFC 7154, are adhered to.


Thanks,

Benno, Suzanne and Tim
co-chairs DNSOP WG

On 16/02/2023 06:01, Masataka Ohta wrote:

Mark Andrews wrote:


It advises against a new QTYPE that returns multiples types and gives
the reasoning behind the decision.  That is not the same as prohibiting
QDCOUNT > 1.


That's in my first mail.

But, we are in subthread on my second mail.

All of you should learn to read the rfcs and, then,
mails you are responding, before writing huge amount
of abstract nonsenses.

     Masataka Ohta

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Masataka Ohta]

Mark Andrews wrote:


The only part of RFC 1035 that actually mentions a value is 4.1.2 and no
it doesn't prohibit other values.


No, of course. See my second mail of the thread.

Masataka Ohta


Your second message describes a standard query.


And the question by Ted, which was quoted by you in your first
mail, is:

: I'm not seeing the place in RFC 1034 where it explicitly specifics any
: value at all for QDCOUNT.

which is already answered by my second mail.


It does not prohibit extended query forms be they a different QDCOUNT for 
QUERY, a new
opcode which supports multiple queries.


Nor does it prohibit protocol extentions to allow standard queries
have QDCOUNT>1, both of which are totally abstract nonsense for
this subthread.

Masataka Ohta

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Masataka Ohta]

Mark Andrews wrote:


It advises against a new QTYPE that returns multiples types and gives
the reasoning behind the decision.  That is not the same as prohibiting
QDCOUNT > 1.


That's in my first mail.

But, we are in subthread on my second mail.

All of you should learn to read the rfcs and, then,
mails you are responding, before writing huge amount
of abstract nonsenses.

Masataka Ohta

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Mark Andrews]

> On 16 Feb 2023, at 15:40, Masataka Ohta  
> wrote:
> 
> Mark Andrews wrote:
> 
>> The only part of RFC 1035 that actually mentions a value is 4.1.2 and no
>> it doesn’t prohibit other values.
> 
> No, of course. See my second mail of the thread.
> 
>   Masataka Ohta

Your second message describes a standard query.  

> 1034:
> 
>3.7.1. Standard queries
>
>A standard query specifies a target domain name (QNAME), query type
>(QTYPE), and query class (QCLASS) and asks for RRs which match.
>
> which *DID* not preclude inverse queries with QDCOUNT=0 and responses
> to them with QDCOUNT>1 as is stated in 1035:
>
>When the response to an inverse query contains one or more QNAMEs,
>
> Anyway, w.r.t. letency, it is meaningless to have standard
> queries with QDCOUNT>1.
>
>   Masataka Ohta

It does not prohibit extended query forms be they a different QDCOUNT for 
QUERY, a new
opcode which supports multiple queries.  If the server only support standard 
queries
for opcode QUERY and receives a request with QDCOUNT != 1 there are error codes 
in STD13
to indicate that the request is not understood.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Mark Andrews]

It advises against a new QTYPE that returns multiples types and gives
the reasoning behind the decision.  That is not the same as prohibiting
QDCOUNT > 1.

> On 16 Feb 2023, at 15:27, Masataka Ohta  
> wrote:
> 
> Ted Lemon wrote:
> 
>> Again, it does not say that explicitly.
> 
> Wrong.
> 
>   Masataka Ohta
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Masataka Ohta]

Mark Andrews wrote:


The only part of RFC 1035 that actually mentions a value is 4.1.2 and no
it doesn’t prohibit other values.


No, of course. See my second mail of the thread.

Masataka Ohta

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Masataka Ohta]

Ted Lemon wrote:


Again, it does not say that explicitly.


Wrong.

Masataka Ohta

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Mark Andrews]

Additionally it was predicated on caches not having the concept
of a negative cache

  "The difficulty is that the presence of one
RR type in a cache doesn't convey any information about the other
because the query which acquired the cached information might have used
a QTYPE of MF, MD, or MAILA (which matched both).”

We have negative caches today.   It’s also not like we don’t know how to
signal that QDCOUNT > 1 is not supported (return FORMERR) or signal that
it is supported (e.g. EDNS=1).  The hardest thing is the broken servers
that don’t return FORMERR correctly making it hard to determine what they
actually support.  Clients can retry with individual queries if they get
FORMERR returned.

The only part of RFC 1035 that actually mentions a value is 4.1.2 and no
it doesn’t prohibit other values.

"4.1.2. Question section format

The question section is used to carry the "question" in most queries,
i.e., the parameters that define what is being asked.  The section
contains QDCOUNT (usually 1) entries, each of the following format:

1  1  1  1  1  1
  0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|   |
/ QNAME /
/   /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QTYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QCLASS|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

QNAME   a domain name represented as a sequence of labels, where
each label consists of a length octet followed by that
number of octets.  The domain name terminates with the
zero length octet for the null label of the root.  Note
that this field may be an odd number of octets; no
padding is used.

QTYPE   a two octet code which specifies the type of the query.
The values for this field include all codes valid for a
TYPE field, together with some more general codes which
can match more than one type of RR.

QCLASS  a two octet code that specifies the class of the query.
For example, the QCLASS field is IN for the Internet."

> On 16 Feb 2023, at 14:08, Ted Lemon  wrote:
> 
> Again, it does not say that explicitly. Your interpretation is valid but not 
> the only possible reading of the test you quoted. It’s certainly not how I 
> read it. 
> 
> On Wed, 15 Feb 2023 at 20:33, Masataka Ohta 
>  wrote:
> Ted Lemon wrote:
> 
> > I'm not seeing the place in RFC 1034 where it explicitly specifics any
> > value at all for QDCOUNT. Can you point to it?
> 
> See my second mail of the thread.
> 
> Masataka Ohta
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Ted Lemon]

Again, it does not say that explicitly. Your interpretation is valid but
not the only possible reading of the test you quoted. It’s certainly not
how I read it.

On Wed, 15 Feb 2023 at 20:33, Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

> Ted Lemon wrote:
>
> > I'm not seeing the place in RFC 1034 where it explicitly specifics any
> > value at all for QDCOUNT. Can you point to it?
>
> See my second mail of the thread.
>
> Masataka Ohta
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Masataka Ohta]

Ted Lemon wrote:


I'm not seeing the place in RFC 1034 where it explicitly specifics any
value at all for QDCOUNT. Can you point to it?


See my second mail of the thread.

Masataka Ohta

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Ted Lemon]

I'm not seeing the place in RFC 1034 where it explicitly specifics any
value at all for QDCOUNT. Can you point to it?

Note that if we think of this in terms of trying to understand what the
writers intended, then your conclusion might make sense, but that's not
good enough. It needs to actually unequivocally say what to do and what not
to do, or else anything that is within the bounds of what is said is
something that is actually said is valid to do. Certainly multiple
questions is within the bounds of what is said, even if you think it is
meaningless to have more than one.

On Wed, Feb 15, 2023 at 8:13 PM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

> Joe Abley wrote:
>
> > I'm not convinced that 1034/5 really allow QDCOUNT > 1,
>
> 1034 specifies standard queries and responses must have
> QDCOUNT=1 but 1035 explicitely allows responses to
> inverse queries have QDCOUNT>1. Inverse queries must
> have QDCOUNT=0.
>
> > even if they left that door temptingly open. But we know that > those
> are old documents that lack normative clarity.
>
> In this case, quite normatively, 1034 states:
>
> Of the possible 16 values,
> one (standard query) is part of the official protocol, two (inverse
> query and status query) are options, one (completion) is obsolete, and
> the rest are unassigned.
>
> but status query is not specified.
>
> So, there is no specification to mention queries with QDCOUNT>1,
> either informatively, optionaly or normatively.
>
> Then, 3425 titled "Obsoleting IQUERY" updated 1035.
>
> As such, after 3425, QDCOUNT nomatively must always be 1.
>
>  > It will be interesting to find out whether using QDCOUNT > 1
>  > in practice is useful.
>
> Meaninglessness of queries matching multiple RR types
> is already documented by 1035. See my first mail of the
> thread.
>
> Masataka Ohta
>
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Masataka Ohta]

Joe Abley wrote:


I'm not convinced that 1034/5 really allow QDCOUNT > 1,


1034 specifies standard queries and responses must have
QDCOUNT=1 but 1035 explicitely allows responses to
inverse queries have QDCOUNT>1. Inverse queries must
have QDCOUNT=0.


even if they left that door temptingly open. But we know that > those are old 
documents that lack normative clarity.


In this case, quite normatively, 1034 states:

   Of the possible 16 values,
   one (standard query) is part of the official protocol, two (inverse
   query and status query) are options, one (completion) is obsolete, and
   the rest are unassigned.

but status query is not specified.

So, there is no specification to mention queries with QDCOUNT>1,
either informatively, optionaly or normatively.

Then, 3425 titled "Obsoleting IQUERY" updated 1035.

As such, after 3425, QDCOUNT nomatively must always be 1.

> It will be interesting to find out whether using QDCOUNT > 1
> in practice is useful.

Meaninglessness of queries matching multiple RR types
is already documented by 1035. See my first mail of the
thread.

Masataka Ohta


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Ted Lemon]

Suresure. My point is, we can expect this to keep happening until we
actually do something. I'm going to try to write something up. We'll see if
it can get consensus.

On Wed, Feb 15, 2023 at 2:46 PM Joe Abley  wrote:

>
> On Wed, Feb 15, 2023 at 13:52, Ted Lemon  wrote:
>
> Actually this is exactly the windmill at which I am tilting. If we haven’t
> written it down in a spec, it is unreasonable to expect random implementers
> to learn about it some other way.
>
>
> Well, it's not like people haven't tried to write it down. Maybe one day
> someone will succeed. In the mean time we work with what we have.
>
>
> Joe
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Joe Abley]

On Wed, Feb 15, 2023 at 13:52, Ted Lemon  wrote:

> Actually this is exactly the windmill at which I am tilting. If we haven’t 
> written it down in a spec, it is unreasonable to expect random implementers 
> to learn about it some other way.

Well, it's not like people haven't tried to write it down. Maybe one day 
someone will succeed. In the mean time we work with what we have.

Joe

>___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Ted Lemon]

On Wed, 15 Feb 2023 at 11:27, Joe Abley  wrote:

> On Wed, Feb 15, 2023 at 08:51, Ted Lemon  wrote:
>
> It’s hard to see how the way that qdcount >1 was “standardized” (by word
> of mouth without any document) was in any sense healthy, unfortunately.
>
>
> I'm not convinced that 1034/5 really allow QDCOUNT > 1, even if they left
> that door temptingly open. But we know that those are old documents that
> lack normative clarity. What the RFCs do or don't allow is not always the
> end of the story, not all open doors lead where you expect, etc.
>

Sure, I guess.

That you can't fully derive the nature of the DNS protocol from documents
> in the IETF alone is surely not news to anybody. However, this is also
> tribal knowledge and also not written down and therefore probably not very
> apparent to people from other tribes. Whether this is healthy is a matter
> of perspective, I guess.
>

Actually this is exactly the windmill at which I am tilting. If we haven’t
written it down in a spec, it is unreasonable to expect random implementers
to learn about it some other way.

It will be interesting to find out whether using QDCOUNT > 1 in practice is
> useful.
>

It clearly is, in the sense that someone is using it and it keeps coming
up. :)

>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Joe Abley]

On Wed, Feb 15, 2023 at 08:51, Ted Lemon  wrote:

> It’s hard to see how the way that qdcount >1 was “standardized” (by word of 
> mouth without any document) was in any sense healthy, unfortunately.

I'm not convinced that 1034/5 really allow QDCOUNT > 1, even if they left that 
door temptingly open. But we know that those are old documents that lack 
normative clarity. What the RFCs do or don't allow is not always the end of the 
story, not all open doors lead where you expect, etc.

That you can't fully derive the nature of the DNS protocol from documents in 
the IETF alone is surely not news to anybody. However, this is also tribal 
knowledge and also not written down and therefore probably not very apparent to 
people from other tribes. Whether this is healthy is a matter of perspective, I 
guess.

It will be interesting to find out whether using QDCOUNT > 1 in practice is 
useful.

Joe

>>___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Ted Lemon]

It’s hard to see how the way that qdcount >1 was “standardized” (by word of
mouth without any document) was in any sense healthy, unfortunately.

On Wed, 15 Feb 2023 at 08:49, Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

> Ted Lemon wrote:
>
> > Oh, I’m sorry, I thought you were referring to something else. You’re
> quite
> > correct about inverse queries!
>
> And IP options and DNS queries matching multiple RR types.
>
> I really hope you learn something from the so healthy
> standardization process to recognize them meaningless.
>
> Masataka Ohta
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Masataka Ohta]

Ted Lemon wrote:


Oh, I’m sorry, I thought you were referring to something else. You’re quite
correct about inverse queries!


And IP options and DNS queries matching multiple RR types.

I really hope you learn something from the so healthy
standardization process to recognize them meaningless.

Masataka Ohta

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Ted Lemon]

On Wed, 15 Feb 2023 at 04:33, Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

> Ted Lemon wrote:
>
> > Clearly it is not meaningless, or someone wouldn't have done it! :)
>
> Simply wrong. Having running code is important to have
> operational experiences on ideas to know whether they
> are meaningful or not, with which, DNS was improved by
> removing meaningless ideas such as inverse queries.


Oh, I’m sorry, I thought you were referring to something else. You’re quite
correct about inverse queries!
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Masataka Ohta]

Ted Lemon wrote:


Clearly it is not meaningless, or someone wouldn't have done it! :)


Simply wrong. Having running code is important to have
operational experiences on ideas to know whether they
are meaningful or not, with which, DNS was improved by
removing meaningless ideas such as inverse queries.

Similarly, IPv4 options are obsolete, allowing
512B DNS messages carryied over UDP with 8B
header over 576B IPv4 with not 60B but 20B
header.

But, the princile was forgotten resulting in
poor protocols like IPv6 not improved from the
original ones through operational experiences.

In this case, however, as the meaninglessness,
known from operational experiences on early
DNS, is already documented in 1035, you don't
have to reinvent a wheel such as IP options.

Masataka Ohta

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Ted Lemon]

Clearly it is not meaningless, or someone wouldn't have done it! :)

On Tue, Feb 14, 2023 at 1:12 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

> Ted Lemon wrote:
>
> > FWIW, I don't think it precludes doing queries with QDCOUNT > 1 to
> > the cache
>
> 1034:
>
> 3.7.1. Standard queries
>
> A standard query specifies a target domain name (QNAME), query type
> (QTYPE), and query class (QCLASS) and asks for RRs which match.
>
> which *DID* not preclude inverse queries with QDCOUNT=0 and responses
> to them with QDCOUNT>1 as is stated in 1035:
>
> When the response to an inverse query contains one or more QNAMEs,
>
> Anyway, w.r.t. letency, it is meaningless to have standard
> queries with QDCOUNT>1.
>
> Masataka Ohta
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Masataka Ohta]

Ted Lemon wrote:


FWIW, I don't think it precludes doing queries with QDCOUNT > 1 to
the cache


1034:

   3.7.1. Standard queries

   A standard query specifies a target domain name (QNAME), query type
   (QTYPE), and query class (QCLASS) and asks for RRs which match.

which *DID* not preclude inverse queries with QDCOUNT=0 and responses
to them with QDCOUNT>1 as is stated in 1035:

   When the response to an inverse query contains one or more QNAMEs,

Anyway, w.r.t. letency, it is meaningless to have standard
queries with QDCOUNT>1.

Masataka Ohta

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Ted Lemon]

Thanks. What you describe in the document certainly makes sense, but I
think is sort of orthogonal to this. If I were to state the fundamental
problem I am trying to address here, it is simply that the RFCs do not
authoritatively say what QDCOUNT > 1 means, nor how to do it, nor do they
authoritatively say that it is invalid. As a consequence of this, an
implementation started using QDCOUNT > 1. So we should do something about
that.

I think what you propose in your draft is exactly what should have been
done, but since we don't say "don't send multiple questions" anywhere, it
wasn't done that way. :)

On Mon, Feb 13, 2023 at 9:46 AM Kazunori Fujiwara 
wrote:

> > From: Ted Lemon 
> > Ohta-san, thanks for pointing out that text about the motivation for MX
> in
> > RFC1035―I hadn't noticed that.
>
> "DNS SRV RR" [RFC 2782] also mentions adding SRV RR Target A/ to
> the additional section.
>
> # draft-ietf-dnsop-svcb-https also mentions adding SVCB/HTTPS target A/
> # to the additional section.
>
> In 2017, 2018, QDCOUNT>1 or multiple qtypes were discussed in dnsop WG.
> At the time, I proposed draft-fujiwara-dnsop-additional-answers-01
> and compared 5 proposals.
>
> At the time, all proposals avoided QDCOUNT>1.
>
> --
> Kazunori Fujiwara  ( = fujiw...@jprs.co.jp )
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Kazunori Fujiwara]

> From: Ted Lemon 
> Ohta-san, thanks for pointing out that text about the motivation for MX in
> RFC1035―I hadn't noticed that.

"DNS SRV RR" [RFC 2782] also mentions adding SRV RR Target A/ to
the additional section.

# draft-ietf-dnsop-svcb-https also mentions adding SVCB/HTTPS target A/
# to the additional section.

In 2017, 2018, QDCOUNT>1 or multiple qtypes were discussed in dnsop WG.
At the time, I proposed draft-fujiwara-dnsop-additional-answers-01
and compared 5 proposals.

At the time, all proposals avoided QDCOUNT>1.

--
Kazunori Fujiwara  ( = fujiw...@jprs.co.jp )

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Ted Lemon]

Ohta-san, thanks for pointing out that text about the motivation for MX in
RFC1035—I hadn't noticed that. It still doesn't exactly prohibit doing
QDCOUNT > 1, but it's a helpful additional note about the history of the
problem. FWIW, I don't think it precludes doing queries with QDCOUNT > 1 to
the cache—it just suggests that the work involved in doing it successfully
is different (more complex) than the simpler problem you have to solve if
QDCOUNT == 1. Having just done an implementation of QDCOUNT > 1, I agree
that it's more complicated! :)

On Mon, Feb 13, 2023 at 4:27 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

> On 2023/02/09 22:54, Ted Lemon wrote:
>
>  > We've been talking elsewhere (Thread) about a small issue that comes
> up in
>  > constrained networks that if we want to do service discovery, and we
> get a
>  > PTR record for a service, then the next thing we need is the SRV and TXT
>  > records for the service instance, and that's two queries.
>
> Then, proper thing to do is to have a new unified RR type,
> which was not the case with .
>
> See below why MX was introduced.
>
> > Now, in general although there is no RFC that expressly forbids QDCOUNT
> > 1
> > (or if there is, I couldn't find it, please clue me in), we don't
> generally
> > support it (my code returns REFUSED, and so does BIND9).
>
> 1035 is clear about meaninglessness of the idea:
>
> For example, the original form of mail exchange binding used two RR
> types one to represent a "closer" exchange (MD) and one to represent a
> "less close" exchange (MF).  The difficulty is that the presence of one
> RR type in a cache doesn't convey any information about the other
> because the query which acquired the cached information might have used
> a QTYPE of MF, MD, or MAILA (which matched both).  The redesigned
> service used a single type (MX) with a "preference" value in the RDATA
> section which can order different RRs.  However, if any MX RRs are
> found
> in the cache, then all should be there.
>
> Masataka Ohta
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Masataka Ohta]

On 2023/02/09 22:54, Ted Lemon wrote:

> We've been talking elsewhere (Thread) about a small issue that comes 
up in
> constrained networks that if we want to do service discovery, and we 
get a

> PTR record for a service, then the next thing we need is the SRV and TXT
> records for the service instance, and that's two queries.

Then, proper thing to do is to have a new unified RR type,
which was not the case with .

See below why MX was introduced.


Now, in general although there is no RFC that expressly forbids QDCOUNT > 1
(or if there is, I couldn't find it, please clue me in), we don't generally
support it (my code returns REFUSED, and so does BIND9).


1035 is clear about meaninglessness of the idea:

   For example, the original form of mail exchange binding used two RR
   types one to represent a "closer" exchange (MD) and one to represent a
   "less close" exchange (MF).  The difficulty is that the presence of one
   RR type in a cache doesn't convey any information about the other
   because the query which acquired the cached information might have used
   a QTYPE of MF, MD, or MAILA (which matched both).  The redesigned
   service used a single type (MX) with a "preference" value in the RDATA
   section which can order different RRs.  However, if any MX RRs are found
   in the cache, then all should be there.

Masataka Ohta


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[Ray Bellis]

On 09/02/2023 08:54, Ted Lemon wrote:


Thotz?


draft-bellis-dnsext-multi-qtypes-04

Ray

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] QDCOUNT > 1 (a modest proposal)

[Ted Lemon]

(I've Bcc'd dnssd, but if you want to join this discussion it's probably
best to do it in one wg, and I think it's most relevant to dnssd, so I put
dnssd in the To: field)

We've been talking elsewhere (Thread) about a small issue that comes up in
constrained networks that if we want to do service discovery, and we get a
PTR record for a service, then the next thing we need is the SRV and TXT
records for the service instance, and that's two queries.

Now, in general although there is no RFC that expressly forbids QDCOUNT > 1
(or if there is, I couldn't find it, please clue me in), we don't generally
support it (my code returns REFUSED, and so does BIND9). This makes sense,
because we don't know how to answer if one query succeeds and the other
fails.

I know Paul Vixie had an idea years back to have an EDNS1 that returns
multiple RCODEs, which might have addressed the problem, but the draft died
before it was published as an RFC.

I have a somewhat less ambitious proposal that I think works and solves the
specific problem we have in DNSSD. The query for the TXT and SRV records
/always/ have the same domain name. So a query for these records can never
return NXDOMAIN for one and not for the other. The other possible errors
that can be returned would most likely be returned for both queries.

That's it, it's that simple: either we return RCODE=0 and zero or more
answers (where ANCOUNT(type)=0 -> no records of that type), or NXDOMAIN,
meaning that there are no records on that name, or some other error,
meaning what that error means.

The downside to this proposal is obviously that supporting it across the
entire great Internet is kind of hard, but we really only need it for
dnssd, and dnssd is very explicitly local, not global. If you are doing
DNSSD through a full-service resolver to a remote domain, that's a weird
configuration.

Also, if your DNSSD resolver /doesn't/ support QDCOUNT==2, you get back a
FORMERR (or maybe it crashes, which is also a good outcome, since it will
lead to them implementing this). In this case you just do the query as two
queries, and you lose in this case, but most of the time you win, so it's
worth making the change.

Thotz?

Note that while it's tempting to think that we might use this in other
cases, where there is more than one name in the query set, in practice I
don't think that would ever make sense for DNSSD. You can't ask for the SRV
and TXT records until you've done a browse, and you don't know the hostname
yet, so really all you can put in the query are the SRV and TXT records.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop