Just a point of clarification before the list moderator shuts down
this off-topic thread..
Ed's unstated assumption is that the condition being considered is
communication between two hosts that are both dual-stack. It is not
that he fails to understand that hosts that are now IPv4-only
Along with these good suggestions, the next draft should include a
brief description of why the desired behavior (as seen by the user) is
better performed through DNS tricks than through HTTP tricks.
John
On 2009Jul17, at 12:04 PM, Paul Hoffman wrote:
At 8:16 AM -0400 7/16/09, Livingood,
RFC 2845 - Secret Key Transaction Authentication for DNS (TSIG)
This protocol allows for transaction level authentication using shared
secrets and one way hashing. It can be used to authenticate dynamic
updates as coming from an approved client, or to authenticate
responses as coming from
Locus of control? Or that pesky old trust anchor?
Separable issues: where the validation computations are done, and
setting (and updating) the trust anchor. For computation, the
advantage of caching after validation in the (shared) recursive
resolver probably does not keep up with the
Today's Behave agenda includes DNS.
Behave AGENDA
SESSION TWO
THURSDAY, 09:00-11:30
...
9:55 NAT64 (Marcelo
Bagnulo, 25)
draft-bagnulo-behave-nat64
10:20 DNS64 (Marcelo
Bagnulo, 20)
I think this background about the origin of security through
reverse lookup is helpful. Certainly not hurtful, which is what my
old rant about its use on UUnet's FTP server might be.
John
On May 31, 2007, at 5:24 PM, Andrew Sullivan wrote:
Dear colleagues,
We received a suggestion that
