Hi Matthew & Paul,
Good question, :-)
SWILD is a feature just for recusive cache optimization, only dealing with
the wildcard subdomain issue (with no nodes below).
DNSSEC + NSEC aggressive is security feature, with cryptographic contents
such as KSK/ZSK/NSEC/NSEC3/NSEC5/...
My assumption is:
On 08/12/2017 12:35 PM, Ted Lemon wrote:
> The document does the right thing on that front, as far as that goes,
> but if this is to be effective I think that it shouldn't be an aside,
> but should be the main point of the document. That is, the title of
> the document should be "DNS servers
On 12 Aug 2017, at 11:44, Richard Barnes wrote:
On Sat, Aug 12, 2017 at 2:36 PM, Paul Hoffman
wrote:
On 12 Aug 2017, at 10:14, Ted Lemon wrote:
El 12 ag 2017, a les 13:09, John Levine va
escriure:
Right. That's why it's long past time that we
On Sat, Aug 12, 2017 at 2:36 PM, Paul Hoffman wrote:
> On 12 Aug 2017, at 10:14, Ted Lemon wrote:
>
> El 12 ag 2017, a les 13:09, John Levine va escriure:
>>
>>> Right. That's why it's long past time that we make it clear that
>>> non-broken resolvers at
El 12 ag 2017, a les 14:36, Paul Hoffman va escriure:
> It's security through interop. It's causing systems that want to hope that
> "localhost" has a particular meaning that has security implications to have a
> better chance that their hope is fulfilled.
Yes, I get
On Saturday, August 12, 2017 8:29:45 AM GMT Lanlan Pan wrote:
> ...
>
> SWILD is a feature just for recusive cache optimization, only dealing with
> the wildcard subdomain issue (with no nodes below).
> DNSSEC + NSEC aggressive is security feature, with cryptographic contents
> such as
On 12 August 2017 at 04:29, Lanlan Pan wrote:
> Hi Matthew & Paul,
>
> Good question, :-)
>
> SWILD is a feature just for recusive cache optimization, only dealing with
> the wildcard subdomain issue (with no nodes below).
> DNSSEC + NSEC aggressive is security feature, with
On 8/12/2017 8:42 AM, Paul Vixie wrote:
we do, though, and we must. DNSSEC development began in 1996,
Hmmm. As I recall, discussions on the topic began in 1990 and I thought
I was cognizant AD, briefly, when the first working group was formed,
after that.
I had understood that the IETF
In article
El 12 ag 2017, a les 13:09, John Levine va escriure:
> Right. That's why it's long past time that we make it clear that
> non-broken resolvers at any level will treat localhost as a special
> case. As you may have heard, we are not the Network Police, but we do
> publish the
Ted Lemon wrote:
...
To recap, my point is that fixing localhost and then relying on it
doesn't fail safe, and there is reason not to be confident that
implementations will conform, because they will appear to work even if
they don't. ...
i'm only excerpting a small bit of ted's text, so
11 matches
Mail list logo