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 10
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 amb
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 IQUE
(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
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 i
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 2
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
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 th
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 bot
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, Jo
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'
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
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 specifica
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
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
opti
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). How
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).
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.
>
Th
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 sayi
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 0
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 que
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, th
> 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.
>
> Masata
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.
>
>
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
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
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
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
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
DN
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 un
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
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 exactl
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 do
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
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 op
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 referr
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.
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
> a
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 qu
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
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 i
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
authoritati
> 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/
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
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 i
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
46 matches
Mail list logo
