On 8/28/14 10:55 AM, Timothe Litt wrote:
Aside from the use of the word 'absurdity', I'm not offended. I am
trying to educate. And while I recognize that I'm arguing
pragmatism with a market purist,
It's nice to be called "pure," in some context anyway. :) However as I
pointed out I'm not
On 27-Aug-14 20:35, Doug Barton wrote:
> On 8/27/14 3:03 PM, Timothe Litt wrote:
>> So you really meant that validating resolvers should only consult DLV if
>> their administrator knows that users are looking-up names that are in
>> the DLV? That's how I read your advice.
>
> You're correct.
>
>>
On 8/27/14 3:03 PM, Timothe Litt wrote:
So you really meant that validating resolvers should only consult DLV if
their administrator knows that users are looking-up names that are in
the DLV? That's how I read your advice.
You're correct.
I don't see how that can work; hence we'll disagree.
On 27-Aug-14 14:54, Doug Barton wrote:
> On 8/26/14 10:35 AM, Timothe Litt wrote:
>> I think this is misleading, or at least poorly worded and subject to
>> misinterpretation.
>
> I chose my words carefully, and I stand by them.
>
The OP was asking about configuring a resolver (bind's).
Where I th
On 8/26/14 10:35 AM, Timothe Litt wrote:
I think this is misleading, or at least poorly worded and subject to
misinterpretation.
I chose my words carefully, and I stand by them.
I did not say that the DLV has no value, and I specifically mentioned
that there are circumstances when it is valua
Timothe Litt wrote:
>
> There are still registrars that don't accept DNSSEC records, and a
> non-trivial number of domain holders can't easily switch registrars.
In some cases it isn't possible to switch to a better registrar, e.g. if
you need DNSSEC for your reverse DNS.
So yes, there is still
On 26-Aug-14 12:52, Doug Barton wrote:
> On 8/26/14 5:50 AM, Tomas Hozza wrote:
> | On 08/26/2014 02:27 PM, Mark Andrews wrote:
> |>> Why would you expect them to succeed?
> |
> | Because validation using root servers and authoritative servers
> | proved that the domain is intentionally unsecure.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 8/26/14 5:50 AM, Tomas Hozza wrote:
| On 08/26/2014 02:27 PM, Mark Andrews wrote:
|>> Why would you expect them to succeed?
|
| Because validation using root servers and authoritative servers
| proved that the domain is intentionally unsecure.
T
On Tue 26 Aug 2014 03:07:22 PM CEST, Mark Andrews wrote:
> In message <53fc827e.7090...@redhat.com>, Tomas Hozza writes:
>>
>> On 08/26/2014 02:27 PM, Mark Andrews wrote:
>>> Why would you expect them to succeed?
>>
>> Because validation using root servers and authoritative servers proved
>> that t
In message <53fc827e.7090...@redhat.com>, Tomas Hozza writes:
>
> On 08/26/2014 02:27 PM, Mark Andrews wrote:
> > Why would you expect them to succeed?
>
> Because validation using root servers and authoritative servers proved
> that the domain is intentionally unsecure.
No. It only proves th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/26/2014 02:27 PM, Mark Andrews wrote:
> Why would you expect them to succeed?
Because validation using root servers and authoritative servers proved
that the domain is intentionally unsecure.
> If you use DLV you are
> expecting anything for w
On Tue 26 Aug 2014 02:32:24 PM CEST, Kevin Darcy wrote:
> So you care enough about security to implement DNSSEC, but you run your
> forwarder on port 80. Interesting...
>
> - Kevin
It is completely artificial setup for testing purpose onl
So you care enough about security to implement DNSSEC, but you run your
forwarder on port 80. Interesting...
- Kevin
On 8/26/2014 8:19 AM, Tomas Hozza wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello.
I found out that when
Why would you expect them to succeed? If you use DLV you are
expecting anything for which DLV is used as a trust anchor to be
safe from being spoofed. The *only* way this can happen is to fail
if the DLV lookup fails for any reason.
Mark
In message <53fc7b35.6040...@redhat.com>, Tomas Hozza wr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello.
I found out that when bind is configured as recursive resolver with
dnssec-lookaside set to 'auto' and dlv.isc.org is unreachable, all
lookups for unsigned (UNSECURE) names fail even if the validation
succeeds (IOW the validation of NSEC3 answe
15 matches
Mail list logo
