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] New Version Notification for draft-bellis-dnsop-qdcount-is-one-00.txt

[Ondřej Surý]

Given the uneasy history with firewall implementors, I think it would be best
to expand the document to explicitly say somewhere that messages with
QDCOUNT=0 are valid. The assumption is implicit in the document, but I've
already lost faith in humanity :).

Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.



> On 17. 2. 2023, at 17:20, Ray Bellis  wrote:
> 
>  Forwarded Message 
> Subject: New Version Notification for draft-bellis-dnsop-qdcount-is-one-00.txt
> Date: Fri, 17 Feb 2023 08:12:18 -0800
> From: internet-dra...@ietf.org
> To: Joe Abley , Ray Bellis 
> 
> 
> A new version of I-D, draft-bellis-dnsop-qdcount-is-one-00.txt
> has been successfully submitted by Ray Bellis and posted to the
> IETF repository.
> 
> Name: draft-bellis-dnsop-qdcount-is-one
> Revision: 00
> Title: In the DNS, QDCOUNT is (usually) One
> Document date: 2023-02-17
> Group: Individual Submission
> Pages: 6
> URL: https://www.ietf.org/archive/id/draft-bellis-dnsop-qdcount-is-one-00.txt
> Status: https://datatracker.ietf.org/doc/draft-bellis-dnsop-qdcount-is-one/
> Html: 
> https://www.ietf.org/archive/id/draft-bellis-dnsop-qdcount-is-one-00.html
> Htmlized: 
> https://datatracker.ietf.org/doc/html/draft-bellis-dnsop-qdcount-is-one
> 
> 
> Abstract:
>   This document clarifies the allowable values of the QDCOUNT parameter
>   in DNS messages with OPCODE = 0 (QUERY) and specifies the required
>   behaviour when values that are not allowed are encountered.
> 
> 
> 
> The IETF Secretariat
> 
> 
> ___
> 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