Richard Gibson wrote:
> Because without such a signal, humans using ANY for legitimate diagnostic
> purposes have no means of differentiating section 4.1/4.3 "subset"
> responses from conventional responses where there just happen to be only a
> small number of RRSets at the queried name, encoura
On Mon, Feb 13, 2017 at 8:03 AM, Tony Finch wrote:
> There are several ways to avoid this pitfall:
>
> Use TCP
>
> Look for an NSEC(3) record
>
> Query for the specific types you want to know about
The pitfall comes from unexamined muscle-memory assumptions when inspecting
a DNS response, so no
Richard Gibson wrote:
>
> The pitfall comes from unexamined muscle-memory assumptions when inspecting
> a DNS response, so none of those methods avoid it. They're expecting people
> to remember that longstanding behavior has changed without providing any
> clue about it.
OK. But does an EDNS flag
On Mon, Feb 13, 2017 at 11:46 AM, Tony Finch wrote:
> OK. But does an EDNS flag help? What if you are using old tools?
If you are using old tools, then you don't get new conveniences (the same
is true of using OPT class to specify a maximum payload size exceeding 512
bytes, using the DO bit to
Richard Gibson wrote:
> On Mon, Feb 13, 2017 at 11:46 AM, Tony Finch wrote:
>
> > OK. But does an EDNS flag help? What if you are using old tools?
>
>
> If you are using old tools, then you don't get new conveniences (the same
> is true of using OPT class to specify a maximum payload size excee
On Mon, Feb 13, 2017 at 12:38 PM, Robert Edmonds wrote:
> You think this would actually provide any sort of useful information? No
> operator would understand what "MBZ: 0x" means without re-training,
> and if you're re-training operators you may as well point them to this
> document.
I thi
> On Feb 13, 2017, at 9:50 AM, Richard Gibson wrote:
>
> On Mon, Feb 13, 2017 at 12:38 PM, Robert Edmonds wrote:
> You think this would actually provide any sort of useful information? No
> operator would understand what "MBZ: 0x" means without re-training,
> and if you're re-training opera
On Mon, Feb 13, 2017 at 9:50 AM, Richard Gibson wrote:
> On Mon, Feb 13, 2017 at 12:38 PM, Robert Edmonds wrote:
>
>> You think this would actually provide any sort of useful information? No
>> operator would understand what "MBZ: 0x" means without re-training,
>> and if you're re-training o
On Mon, Feb 13, 2017 at 1:02 PM, Wessels, Duane
wrote:
> Tools like dig, when asked to issue an ANY query over UDP can:
>
> 1) fail with "ANY over UDP is deprecated", or
>
That's not true, though, and tools have no way of knowing whether or not
such a failure is appropriate without the very sign
On Mon, Feb 13, 2017 at 1:05 PM, Ólafur Guðmundsson
wrote:
> HINIFO is such a signal :-)
> thus your request applies only to Send-one and Send-useful responses.
>
Correct, as I covered in my initial message.
I do not think adding complexity will help at all.
>
> ... you want an overhead cost f
> On Feb 13, 2017, at 10:15 AM, Richard Gibson wrote:
>
> On Mon, Feb 13, 2017 at 1:02 PM, Wessels, Duane wrote:
> Tools like dig, when asked to issue an ANY query over UDP can:
>
> 1) fail with "ANY over UDP is deprecated", or
>
> That's not true, though, and tools have no way of knowing whe
We don't need any new signalling. If the answer is truncated you
set tc=1. This works with all existing clients.
If there is only a single RRset + RRSIGs then you don't get tc=1
except for traditional space reasons.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
P
Mark Andrews wrote:
>
> We don't need any new signalling. If the answer is truncated you
> set tc=1. This works with all existing clients.
One of the points of minimal-any is that the answer is not truncated
because you do not want clients to automatically retry over TCP. This is
to hand
> From: Tony Finch
> One of the points of minimal-any is that the answer is not truncated
> because you do not want clients to automatically retry over TCP. This is
> to handle situations where many third-party recursive servers are under
> attack using one of your names, so the recursive servers
In message <201702132243.v1dmhnkr062...@calcite.rhyolite.com>, Vernon Schryver
writes:
> > From: Tony Finch
>
> > One of the points of minimal-any is that the answer is not truncated
> > because you do not want clients to automatically retry over TCP. This is
> > to handle situations where many
Vernon Schryver wrote:
> > From: Tony Finch
>
> > One of the points of minimal-any is that the answer is not truncated
> > because you do not want clients to automatically retry over TCP.
> > This is
> > to handle situations where many third-party recursive servers
> > are under
> > attack u
On Fri, Feb 10, 2017 at 01:12:28PM +, Edward Lewis wrote:
> I have a fundamental problem with that, meaning that a document within
> DNSOP is defining domain names. Work I did to write (the still in progress)
> draft on Domain Names has led me to believe that domain names are a concept
> beyo
On Mon, Feb 13, 2017 at 6:34 PM, Viktor Dukhovni
wrote:
> My beef
> would be with the "zero or more" part, as applied to labels, since
> zero length labels (if construed as actual labels rather than just
> termination sentinels) do not occur except to terminate a domain
> name. Otherwise, if the
>
> Richard Gibson wrote:
> > Because without such a signal, humans using ANY for legitimate diagnostic
> > purposes have no means of differentiating section 4.1/4.3 "subset"
> > responses from conventional responses where there just happen to be only
> a
> > small number of RRSets at the queried
19 matches
Mail list logo
