Tim,
[ Apologies for coming late to the party. I was on vacation. ]
At 2016-08-16 08:57:04 -0400
Tim Wicinski wrote:
> In Berlin we had two presentations on different methods of returning
> multiple responses:
>
> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/
>
> h
william manning wrote:
>
> Now any v. Concurrent queries. To ensure the resolver gets all the RRs,
But it doesn't want all the RRs, just the relevant ones.
Tony.
--
f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode
Northwest Fitzroy, Sole: Variable 3, becoming southwesterly 4 or 5.
Good thing refuse-any is just a draft then isn't it.
Now any v. Concurrent queries. To ensure the resolver gets all the RRs,
wouldn't you have to query for all defined RR types? Perhaps you want ALL
instead of ANY?
/Wm
On Thursday, 25 August 2016, Tony Finch wrote:
> Edward Lewis > wrote:
>
Matthew Pounsett wrote:
>
> Also take for example the transition from not having HTTP SRV to having
> it. One of the arguments against from the browser developer community is
> the additional round trips. One of those extra round trips is the need to
> request both the A/ of the requested ho
Edward Lewis wrote:
> The question I keep asking myself is: How is this different from a
> client just hitting a server with all anticipated questions at one time?
Me too :-)
I can see an advantage to improving the case where the client can't
predict all the questions in advance, e.g. when the
In message <99ce1d3e-18a0-42e6-949f-e78995afc...@icann.org>, Edward Lewis write
s:
> On 8/16/16, 08:57, "DNSOP on behalf of Tim Wicinski" on behalf of tjw.i...@gmail.com> wrote:
>
> I've only read briefly the drafts and see hints that issues I raise below
> are still lingering.
>
> There's no de
On 8/19/16, 13:24, "william manning" wrote:
>First off, I take exception to the use of the word "dangerous". AXFR isn't
>dangerous, it's just the best way to do the job. If there are other query
>types that are better (or only) can be done over TCP, then so be it. But they
>aren't per se da
On 8/16/16, 08:57, "DNSOP on behalf of Tim Wicinski" wrote:
I've only read briefly the drafts and see hints that issues I raise below are
still lingering.
There's no denying that there's a desire to solve "this". I keep in mind that
this isn't the first time there's been a desire to add this
In message
, =?UTF-8?Q?Marek_Vavru=C5=A1a?= writes:
> Very interesting, so BIND already pushes records for the obvious
> optimisation cases.
> Did you do any research on how many clients use these records (thus
> don't follow up with an extra query) ?
Clients can change. The more servers that r
Very interesting, so BIND already pushes records for the obvious
optimisation cases.
Did you do any research on how many clients use these records (thus
don't follow up with an extra query) ?
Perhaps it would be helpful to look at the it from different perspectives.
As an authoritative DNS impleme
Named returns associated
* A/ records with MX lookups if available
* A/ records with SRV lookups if available
* SRV/A/ records with NAPTR lookups if available
* A/ records with NAPTR lookups if available
As of 9.11 named returns associated
* A//TLSA records with MX lookups i
On Thu, Aug 18, 2016 at 12:52 PM, Paul Hoffman wrote:
> On 18 Aug 2016, at 11:29, Marek Vavruša wrote:
>
>> Or SRV.
>
>
> I disagree that a user, when asking for a SRV record, doesn't know that it
> is likely that they would want the results for the information that comes
> back in the RDATA.
No
On 18 Aug 2016, at 11:29, Marek Vavruša wrote:
Or SRV.
I disagree that a user, when asking for a SRV record, doesn't know that
it is likely that they would want the results for the information that
comes back in the RDATA.
These are cases where authoritative/resolver adding
interesting re
Or SRV. These are cases where authoritative/resolver adding
interesting records as additionals works better.
Authoritatives have been doing that with extra SOA/NS in authority for
a while (for positive answers), but now
resolvers can hardly use them if these records are not secure.
Regardless of w
>Are there QTYPEs that, when I ask for them, I won't know that I should
>also ask for the related info?
NAPTR
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 18 Aug 2016, at 8:04, Matthew Pounsett wrote:
On 18 August 2016 at 10:40, Paul Hoffman
wrote:
Are there QTYPEs that, when I ask for them, I won't know that I
should
also ask for the related info?
Probably not. However, there may be owner names you don't know you
need to
ask for. In
On 18 August 2016 at 10:40, Paul Hoffman wrote:
> On 18 Aug 2016, at 7:19, Matthew Pounsett wrote:
>
> On 18 August 2016 at 01:33, william manning
>> wrote:
>>
>> please help me get over the feeling that this argument is founded on the
>>> same logic as that used by folks who "know" I might want
On 18 Aug 2016, at 7:19, Matthew Pounsett wrote:
On 18 August 2016 at 01:33, william manning
wrote:
please help me get over the feeling that this argument is founded on
the
same logic as that used by folks who "know" I might want, no NEED
that
extra bit of email in my inbox. As I read it,
On 18 August 2016 at 01:33, william manning
wrote:
> please help me get over the feeling that this argument is founded on the
> same logic as that used by folks who "know" I might want, no NEED that
> extra bit of email in my inbox. As I read it, it sounds like DNS Server
> Spam being "PUSHED" t
please help me get over the feeling that this argument is founded on the
same logic as that used by folks who "know" I might want, no NEED that
extra bit of email in my inbox. As I read it, it sounds like DNS Server
Spam being "PUSHED" to the Resolver who may or may not want the data.
Please advi
Status Quo is good for ipv4 to ipv6 migration.
Totally agree with william on PUSH/PULL.
1. Hotest internet service's RDATA always exists in recursive dns cache,
PUSH is not speed up much except hit-miss. ( recursive -> authority )
2. clients known what they want, PULL & prefething is Ockham's R
On 16 August 2016 at 08:57, Tim Wicinski wrote:
> All,
>
>
> In Berlin we had two presentations on different methods of returning
> multiple responses:
>
> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/
>
> https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtype
On Tue, Aug 16, 2016 at 8:57 AM, Tim Wicinski wrote:
> All,
>
>
> In Berlin we had two presentations on different methods of returning
> multiple responses:
>
> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/
>
> https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-
Hello,
> From: Tim Wicinski
> In Berlin we had two presentations on different methods of returning
> multiple responses:
> All of these documents are attempting to solve a larger problem in
> different ways.
> The end result is "Return Associated Answer" to the client.
>
> The question is start
from an attacker POV, I would strongly support PUSH, as it would increase
DDoS effectiveness. The performance enhancement seems to be based on some
presumptions about servers retaining residual knowledge of the resolver
behaviours.
PULL minimizes the attack surface. wrt cache coherence and delay,
my bad. I've been re-framed.
Contextually, PUSH means (to me at least) 'do this promiscuously' and
PULL means (to me at least) 'do this if asked' -which is not what I
previously understood.
In that case, I think PULL makes more sense: do this, if the client
signals its what it wants. Otherwise, d
On 16 Aug 2016, at 5:57, Tim Wicinski wrote:
- Do we want to Server to PUSH any or all Associated Answers, or
- Do we want the Client to PULL any or all Associated Answers, or
- Do we want the Status Quo?
Client pull, which is really just the client saying "if you have this,
send it to me i
On Tue, Aug 16, 2016 at 10:57 PM, Tim Wicinski wrote:
> All of these documents are attempting to solve a larger problem in different
> ways. The end result is "Return Associated Answer" to the client.
>
> The question is starting to coalesce around these two premises:
>
> - Do we want to Server t
All,
In Berlin we had two presentations on different methods of returning
multiple responses:
https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/
https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/
and a presentation in Buenos Aires:
https://datatracker.
29 matches
Mail list logo