On Tue, Jul 04, 2017 at 04:42:21AM -0700,
IETF Secretariat wrote
a message of 11 lines which said:
> The DNSOP WG has placed draft-bellis-dnsext-multi-qtypes in state
> Candidate for WG Adoption
Did anyone was brave enough to make a detailed comparison between this
draft and other proposals l
On Wed, Jul 19, 2017 at 02:28:37PM +0200,
Shumon Huque wrote
a message of 153 lines which said:
> > Suppose I send the list ECDSA;RSA, and I receive only ECDSA
> > signatures. How the resolver/cache would now if it was a complete
> > list?
>
> The response contains the EDNS0 option if the res
On Thu, Jul 20, 2017 at 9:51 AM, Stephane Bortzmeyer
wrote:
> On Wed, Jul 19, 2017 at 02:28:37PM +0200,
> Shumon Huque wrote
> a message of 153 lines which said:
>
> > > Suppose I send the list ECDSA;RSA, and I receive only ECDSA
> > > signatures. How the resolver/cache would now if it was a c
> From: Stephane Bortzmeyer
>> The DNSOP WG has placed draft-bellis-dnsext-multi-qtypes in state
>> Candidate for WG Adoption
>
> Did anyone was brave enough to make a detailed comparison between this
> draft and other proposals like draft-yao-dnsop-accompanying-questions?
>
> (I was thinking my
On 04/07/2017 12:42, IETF Secretariat wrote:
> The DNSOP WG has placed draft-bellis-dnsext-multi-qtypes in state
> Candidate for WG Adoption (entered by Tim Wicinski)
I heard that someone implemented this during the Hackathon at the weekend.
Does anyone know who that was?
thanks,
Ray
__
On Thu, 20 Jul 2017, Woodworth, John R wrote:
Camp#2) Don't break DNS, even for a second
Well, yeah, except that there's no such thing as breaking the DNS for a
second. If we look at the history of DNSSEC, we'd break the DNS for
somewhere between a decade and forever. We have tried very har
On Tue, Jul 11, 2017 at 12:16 AM, Shumon Huque wrote:
> On Mon, Jul 10, 2017 at 5:01 PM, Ólafur Guðmundsson > wrote:
>
>> Shumon,
>>
>> In section 5 your draft says:
>>
>>If an Authoritative Server has no algorithms in common with the
>>Preferred Algorithms list in the incoming query, it
On Thu, Jul 20, 2017 at 10:39 AM, Ólafur Guðmundsson
wrote:
>
>
> I disagree, if a zone operator selects "less-than" common algorithm they
> do that at their own risk,
> if the risk is not acceptable then it should dual sign
>
Yes. The point I was trying to make is that DANE sites (and probab
Hi Jinmei
On Wed, Jul 19, 2017 at 04:14:11PM -0700, 神明達哉 wrote:
> At Tue, 18 Jul 2017 18:20:56 +0530,
> Mukund Sivaraman wrote:
>
> > Dealing with water torture and some other attacks have had several
> > band-aid approaches that don't always work well in practice. The most
> > promising (and wh
On Thu, Jul 20, 2017 at 10:45 AM, Shumon Huque wrote:
> On Thu, Jul 20, 2017 at 10:39 AM, Ólafur Guðmundsson <
> ola...@cloudflare.com> wrote:
>>
>>
>> I disagree, if a zone operator selects "less-than" common algorithm they
>> do that at their own risk,
>> if the risk is not acceptable then it s
The CFP submission deadline is fast approaching. If you'd like to
present at this meeting please get your submissions in soon!
thanks,
Ray
--8<--8<--
The DNS-OARC 27th Workshop will take place in San Jose, CA, USA
on September 29th and 30th 2017, the Friday and Saturday preceding
NANOG 71. Th
Op 20-07-17 om 10:45 schreef Shumon Huque:
> On Thu, Jul 20, 2017 at 10:39 AM, Ólafur Guðmundsson
> mailto:ola...@cloudflare.com>> wrote:
>
>
> I disagree, if a zone operator selects "less-than" common algorithm
> they do that at their own risk,
> if the risk is not acceptable then i
On Thu, Jul 20, 2017 at 11:48 AM, Willem Toorop wrote:
> Op 20-07-17 om 10:45 schreef Shumon Huque:
> > On Thu, Jul 20, 2017 at 10:39 AM, Ólafur Guðmundsson
> > mailto:ola...@cloudflare.com>> wrote:
> >
> >
> > I disagree, if a zone operator selects "less-than" common algorithm
> > they d
Hi,
Thank you for the feed backs Scott. We will address them in the next
version.
The motivation for crypto deprecation is clearly to follow the crypto
recommendations stated by the IETF. However, this requirement for the
validator is to actually "validate" those requirements are effective. The
i
> On 20 Jul 2017, at 03:12, Woodworth, John R
> wrote:
>
> For now, I think we've narrowed the draft opposition to two camps:
>
> Camp#1) Don't force me to use IPv6 reverse, I simply will never
>
> and
>
> Camp#2) Don't break DNS, even for a second
Well I don't recognise either of these cam
Another Data Point:
One of the Apps Area ADs stopped by to tell the chairs that 1) they like
the general idea; 2) their employer has a need for this *outside of the PTR
space*; and 3) would be willing to shepherd the work through. Now, they
also the first to admit that the Application people do
Wes,
It's been a while since I have had a look at this draft, my apologies.
I don't think it is ready for WGLC because I am not convinced the math
is correct. Section 6 defines the waitTime:
waitTime = addHoldDownTime
+ (DNSKEY RRSIG Signature Validity)
+ MAX
John R Levine wrote:
>
> BULK absolutely requires online DNSSEC signing,
This basically means that BULK is a master-only feature, which implies
that there's no need for BULK to work across zone transfers, which implies
the need to standardize it for interop is almost nonexistent.
Tony.
--
f.ant
On Thu, Jul 20, 2017 at 02:34:48PM +0100, Tony Finch wrote:
> This basically means that BULK is a master-only feature, which implies
> that there's no need for BULK to work across zone transfers, which implies
> the need to standardize it for interop is almost nonexistent.
I don't think that follo
On Thu, 20 Jul 2017, Tony Finch wrote:
John R Levine wrote:
BULK absolutely requires online DNSSEC signing,
This basically means that BULK is a master-only feature, which implies
that there's no need for BULK to work across zone transfers, which
implies the need to standardize it for inter
On Tue, Jul 18, 2017 at 06:20:56PM +0530,
Mukund Sivaraman wrote
a message of 27 lines which said:
> It is to put draft-ietf-dnsop-nsec-aggressiveuse to use with unsigned
> zones.
That's quite funny. During the development of RFC 8020
(draft-ietf-dnsop-nxdomain-cut), which addresses the same
Dear colleagues,
On Mon, Jul 10, 2017 at 06:16:53PM -0400, Shumon Huque wrote:
> negotiation from the beginning, fail open would not have been necessary.
> This fail open behavior frequently takes people not in the DNSSEC club by
> complete surprise. I've lost track of how many "WTF" moments I've
On Wed, Jul 19, 2017 at 12:03:58PM +0100,
Jim Reid wrote
a message of 18 lines which said:
> However that doesn't seem to be a compelling reason to modify the
> DNS protocol and change every DNS server on the planet.
No. Only the authoritative servers, and not even all of them (this
BULK feat
On Tue, Jul 18, 2017 at 01:24:33PM -0700,
IETF Secretariat wrote
a message of 11 lines which said:
> The DNSOP WG has placed draft-woodworth-bulk-rr in state
> Candidate for WG Adoption (entered by Tim Wicinski)
>
> The document is available at
> https://datatracker.ietf.org/doc/draft-woodwor
On Wed, Jul 19, 2017 at 09:57:49PM -,
John Levine wrote
a message of 38 lines which said:
> We did this in a horrible ad-hoc way with DNSSEC, and even with
> DNSSEC there's the fallback that the unsigned answers you get from a
> server that doesn't understand RRSIG et al. are for many purp
That's why I don't share the fears about BULK: you cannot easily
deploy a new feature that will require a change in the resolvers,
because you don't know all the resolvers, and cannot change them even
if you know they are too old. But your secondaries are only a small
set of carefully chosen serve
multi-qtypes Security Considerations says:
>The method documented here does not change any of the security
>properties of the DNS protocol itself.
I don't think this statement is true. Why?
a) DNS DDoS threats are real and there was a shift towards minimizing
answers. This goes in th
Hey,
there's one thing I don't really understand from this draft.
Is this useful for DNS at all, or is this targeted at DNS-SD only?
I think this needs some explaining and perhaps a clear cut is needed.
Although it's not mentioned anywhere in the document, the draft makes
much more sense to me,
On Thu, Jul 20, 2017 at 06:45:25PM +0200, Ondřej Surý wrote:
> Is this useful for DNS at all, or is this targeted at DNS-SD only?
I can think of at least one way it would be useful. Large
authoritatives often have a clear population of query sources that ask
a lot -- the "top talkers". It would
For TCP connections, being able to signal session liveness policy is useful
for DNS, not just DNSSD. It seems likely that DNS Push is useful for
things other than DNSSD. I think this is generally useful, not just for
DNSSD. Rather than thinking of this as a DNSSD-specific enhancement,
think o
> But it's certainly another step along the way to DNSbis by accident.
Would it be useful to make it not "by accident"?
That's why I have a love-hate relationship with TLV inside DNS messages.
I have a couple questions:
a) make DNS over TCP/TLS sessions without TLV suck less?
b) make this draf
I probably will not carry the WG with me on this, but I find myself
thinking the PII aspect of client-ID makes it a wider-internet
question and we might have views as a WG, and promote questions as a
WG, but I think the "final call" on this is something which needs more
than WG approval.
Its a big
On Thu, Jul 20, 2017 at 06:59:42PM +0200, Ondřej Surý wrote:
> > But it's certainly another step along the way to DNSbis by accident.
>
> Would it be useful to make it not "by accident"?
Yes. That was basically the point I was trying to make at the
beginning of today's session, about overall ana
It would be nice if there were an RFC to point to that used a method that
didn't include PII. For the use cases of which I am ware, there is no
need to identify individual devices: only policies. What's lacking is a
way to do this in the home router, so the PII winds up getting exported to
the
34 matches
Mail list logo
