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: *w
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 KSK/ZSK/NSE
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 cryptographic content
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 ef
In article
you write:
>On Wed, Aug 9, 2017 at 12:31 PM, Stuart Cheshire wrote:
>
>> [*] If you think it’s stupid to suggest a host might not treat “127.0.0.1”
>> as meaning loopback, why is that any more stupid than suggesting that a
>> host might not treat “localhost” as meaning loopback? Both
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 occasional document
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 any level will treat localhost as a special
case. As you may have heard, we are not the Network Police, but
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 any level will treat localhost as a spec
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 make it clear that
non-broken resolvers a
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 that, and I'm not sure that
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 tha
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 shou
12 matches
Mail list logo
