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
19 matches
Mail list logo
