> 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 to be able to
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 tha
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 valid
> 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. Vixie
>>
>>
>> I will note there are
> 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
https://www.ietf.org/mailman/listinfo/dnso
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 a
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, such as in
> unbound.
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 configuration direc
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 Data to Improve D
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 a
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 rem
> 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 existing.
+1. The most re
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 c
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 contr
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 2013
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 O
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: 06
Title:
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 downref
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 definition).
The draft is in
> 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 can't find it in the ICA
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 recov
> 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 in the ICANN corres
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 a
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 letter from NTIA (Karen Rose) to ICANN (Louis
28 matches
Mail list logo