On 03/22/2016 01:15 AM, Paul Vixie wrote:
>
>
> Marek Vavruša wrote:
>> ...
>>
>> https://datatracker.ietf.org/doc/draft-vavrusa-dnsop--for-free/
>
> +1. we ought to have done this from the get-go.
It did not work back then because unexpected RRsets in the answer broke
resolvers. This is
In one of the experiments we are conducting we stuff the response with other
QTYPE data and this seems to not interfere with resolver behaviour (unless we
trigger it). So #3 doesn’t seem to be a common case (we could look in the
fringes for this behaviour).
Towards the resolver’s clients, all
On Tue, Mar 22, 2016 at 6:11 PM, Mark Andrews wrote:
>
> In message <2016030345.29993...@pallas.home.time-travellers.org>,
> Shane Kerr writes:
> > Maybe we just need a new RTYPE. It would be awesome if CloudFlare
> > killed ANY and then gave us ANYA ("any address"). ;)
>
>
On 03/23/2016 09:03 PM, Andrew Sullivan wrote:
> I don't understand how it's a way to evaluate this claim. DNSSEC
> includes a bit (DO) that says you're prepared to handle the additional
> data in the answer section. Indeed, the unpreparedness of people for
> this data was just exactly the
Hi,
On Wed, Mar 23, 2016 at 09:37:57AM -0700, Marek Vavruša wrote:
> > 1. We had no idea what resolvers who weren't expecting the
> > in the Answer section would do. This draft says what is "more
> > likely", but I have no way of evaluating that claim. Without an
> > EDNS0
Marek Vavruša wrote:
>
> 1. No signalling to client when is unavailable
>
> I didn't want to include it in the beginning but I see it has a merit.
Yep. Also, while improving this for direct address queries, it should also
be improved for additional data in MX, NS,
On Thu, Mar 24, 2016 at 7:10 AM, Florian Weimer wrote:
> DO was used initially for SIG and kept for RRSIG. For an early DNSSEC
> implementation, RRSIG was just another unsolicited RR type because it
> could only know about SIG. This suggests (to me at least) that
>
Hi,
On Mon, Mar 21, 2016 at 04:45:51PM -0700, Marek Vavruša wrote:
> Me and Olafur wrote a draft on adding records to A answers and
> treating them as authoritative.
The last time this was proposed, in DNSEXT when Olafur was co-chair,
the proposal was rejected on the following grounds:
On Mon, Mar 21, 2016 at 06:55:00PM -0700, Paul Vixie wrote:
> i think we have to start planning for a world in which EDNS0 never reaches
> 75% penetration due to middleboxes having the high ground.
Well, you could get most of the way there for this proposal by having
just recursives do it. End
Andrew Sullivan wrote:
> On Mon, Mar 21, 2016 at 04:45:51PM -0700, Marek Vavruša wrote:
> > Me and Olafur wrote a draft on adding records to A answers and
> > treating them as authoritative.
>
> The last time this was proposed, in DNSEXT when Olafur was co-chair,
>
Hi Andrew, first of all - thanks for being constructive.
On Wed, Mar 23, 2016 at 6:07 AM, Andrew Sullivan
wrote:
> Hi,
>
> On Mon, Mar 21, 2016 at 04:45:51PM -0700, Marek Vavruša wrote:
> > Me and Olafur wrote a draft on adding records to A answers and
> > treating
>We have a way of measuring DNSSEC algorithms penetration, QNAME
>minimisation-enabled resolvers etc., thus also a way to evaluate this
>claim. I'm setting up a special domain using this I-D and then we can use
>RIPE Atlas or 1x1 test, should Google or someone be interested in testing
>this.
The
On 03/22/2016 12:45 AM, Marek Vavruša wrote:
> there was an interest in reducing latency for address record lookups.
> Me and Olafur wrote a draft on adding records to A answers and
> treating them as authoritative. This fixes latency issues with NS
> A/ discovery in resolvers and
13 matches
Mail list logo