> On Mar 27, 2017, at 5:49 PM, Dave Lawrence wrote:
>
> One of the two drafts I wanted to talk about at dnsop today for WG
> adoption was "Client ID in Forwarded DNS Queries":
> https://datatracker.ietf.org/doc/draft-tale-dnsop-edns0-clientid/
>
> The core idea of this document is
Hi Evan
On Tue, Mar 28, 2017 at 02:41:27AM +, Evan Hunt wrote:
> On Mon, Mar 27, 2017 at 12:45:04PM -0700, Paul Vixie wrote:
> > also, a validator that outputs "secure" based on MD5 inputs is making a
> > promise it can't keep.
>
> MD5 is known to be breakable, but it's not *as* breakable
Oopsie:
On Tue, Mar 28, 2017 at 02:41:27AM +, Evan Hunt wrote:
> MD5 is known to be breakable, but it's not *as* breakable
as a zone
> that hasn't been signed
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
On Mon, Mar 27, 2017 at 12:45:04PM -0700, Paul Vixie wrote:
> also, a validator that outputs "secure" based on MD5 inputs is making a
> promise it can't keep.
MD5 is known to be breakable, but it's not *as* breakable that hasn't been
signed, or a resolver that hasn't turned on validation. A
> On Mar 27, 2017, at 6:46 PM, Robert Edmonds wrote:
>
> Jared Mauch wrote:
>> IOn Mar 27, 2017, at 5:59 PM, P Vix wrote:
>>>
>>> I agree to review and comment. Note that I am provisionally negative to the
>>> idea itself, and my review may reflect that.
> On Mar 27, 2017, at 5:56 PM, Dave Lawrence wrote:
>
> Warren and I are hoping for WG adoption.
[clarification]
I support adoption when the chairs request it.
- Jared
___
DNSOP mailing list
DNSOP@ietf.org
One of the two drafts I wanted to talk about at dnsop today for WG
adoption was "Client ID in Forwarded DNS Queries":
https://datatracker.ietf.org/doc/draft-tale-dnsop-edns0-clientid/
The core idea of this document is to be able to provide
device-specific identification in an EDNS option sent to
Jared Mauch wrote:
> IOn Mar 27, 2017, at 5:59 PM, P Vix wrote:
> >
> > I agree to review and comment. Note that I am provisionally negative to the
> > idea itself, and my review may reflect that. Vixie
>
>
> I will note there are other implementations out there as well,
IOn Mar 27, 2017, at 5:59 PM, P Vix wrote:
>
> I agree to review and comment. Note that I am provisionally negative to the
> idea itself, and my review may reflect that. Vixie
I will note there are other implementations out there as well, such as in
unbound. serve-expired
I agree to review and comment. Note that I am provisionally negative to the
idea itself, and my review may reflect that. Vixie
On March 27, 2017 4:56:58 PM CDT, Dave Lawrence wrote:
>One of the two drafts I wanted to talk about at dnsop today for WG
>adoption was "Serving Stale
One of the two drafts I wanted to talk about at dnsop today for WG
adoption was "Serving Stale Data to Improve DNS Resiliency":
https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/
In short, this describes a method for increasing DNS resiliency by
treating the inability to refresh data
also +1.
if we define them beyond deprecated to REMOVED then we get some
confidence its the pool of dead code who remain at risk, should
threats emerge.
if we leave them in validation, we can't tell if 'modern' technology
is exposed to risk we didn't understand as attacks get better.
RC4 got
> On 27 Mar 2017, at 20:45, Paul Vixie wrote:
>
> all code has bugs, eventually. or at least, there is no
> existence proof to the contrary, and also, no reason to suspect
> otherwise. so, code that is not used will not be reviewed or maintained.
> it's a risk, just by
I support this.
And found a nit, the document says:
The most confusing element of the above equation comes from the "3 *
(DNSKEY RRSIG Signature Validity) / 2"
but the formula just before doesn't include "3 *" anywhere in it.
Cheers,
Ondrej
--
Ondřej Surý -- Technical Fellow
Apologies but I did not hear the full question regarding BULK RR's and the perl
like back-references. If you could please repeat the question we would be
happy to comment.
Thanks,
John
-- THESE ARE THE DROIDS TO WHOM I REFER:
This communication is the property of CenturyLink and may contain
evan hunt of isc just spoke at the microphones and said "an md5
validator implementation that isn't used isn't hurting anybody." on
pressure of time, the microphones had closed, so i'm commenting here.
i disagree. all code has bugs, eventually. or at least, there is no
existence proof to the
Hi,
Further to the comments I made at the mic today, I didn't dig into the
history on this, but the syntactic agreement that we finally came up
with when we had this bunfight years ago was is in RFC 6944. The idea
a the time was that we'd product updates of that. The publication
date claims
On 3/27/2017 2:11 PM, Ondřej Surý wrote:
The draft is missing TLSA records (RFC 6698).
Thanks!
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Hi,
as promised here's copy of my mic comment:
The draft is missing TLSA records (RFC 6698).
Ondřej
On 5 March 2017 18:39:29 internet-dra...@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System
On 3/27/17, 13:52, "internet-dra...@ietf.org" wrote:
A new version of I-D, draft-lewis-domain-names-06.txt
has been successfully submitted by Edward Lewis and posted to the
IETF repository.
Name: draft-lewis-domain-names
Revision:
Reviewer: Jouni Korhonen
Review result: Has Nits
I think would be ready if it passed IDnits. I found the document good
read and found no sinkholes in it. Pointing up two implementations was
also great.
The Proto Write-up seems not be up to date with what IDnits says e.g.,
when it comes to
On 3/16/17, 15:59, "Ralph Droms" wrote:
>Ed - I think your document is ...
With Homenet's session ending early, I removed the "definition" section (and
retitled it to reflect that it is a case for clarifying, not to be confused
with containing an architectural
> On Mar 27, 2017, at 8:41 AM, Ray Bellis wrote:
>
>
>
> On 27/03/2017 02:52, Patrik Fältström wrote:
>
>> One important part is in the letter from NTIA (Karen Rose) to ICANN
>> (Louis Touton) in Appendix A.
>>
>> A letter sent April 28, 2000.
>
> Is it online? I
Hi,
Please find an update of our draft on requirements for DNSSEC resolver.
DNS resolvers hardly enable DNSSEC as 1) resolvers are not robust too DNS
authoritative operations – like KSK roll over, signing errors…. – and 2)
network administrators have little control on these resolvers to
> On 27 Mar 2017, at 13:41, Ray Bellis wrote:
>
> On 27/03/2017 02:52, Patrik Fältström wrote:
>
>> One important part is in the letter from NTIA (Karen Rose) to ICANN
>> (Louis Touton) in Appendix A.
>>
>> A letter sent April 28, 2000.
>
> Is it online? I can't find it
On 27 Mar 2017, at 14:41, Ray Bellis wrote:
> On 27/03/2017 02:52, Patrik Fältström wrote:
>
>> One important part is in the letter from NTIA (Karen Rose) to ICANN
>> (Louis Touton) in Appendix A.
>>
>> A letter sent April 28, 2000.
>
> Is it online? I can't find it in the ICANN correspondence
On 27/03/2017 02:52, Patrik Fältström wrote:
> One important part is in the letter from NTIA (Karen Rose) to ICANN
> (Louis Touton) in Appendix A.
>
> A letter sent April 28, 2000.
Is it online? I can't find it in the ICANN correspondence archive.
Ray
On 26 Mar 2017, at 17:17, Ozgur Karatas wrote:
> 22.03.2017, 10:05, "Jim Reid" :
>
>>> On 21 Mar 2017, at 14:53, Suzanne Woolf wrote:
>>>
>>> RFC 3172 was written in 2001…
>
> the last updated was made in 2013, right?
One important part is in the
28 matches
Mail list logo