On Sat, 8 Mar 2014, Mark Andrews wrote:
nsupdate requires a new set of credentials, as well as a new API as to
where to send the nsupdate to, possibly with new firewall holes. It
requires dynamic zones or custom software pretending to run dynamic
zones to take the update. The domain owner would
Stephane Bortzmeyer bortzme...@nic.fr wrote:
The only place where server authentication could be useful is between
a stub and the first resolver.
I don't think it is as simple as that.
There are good reasons for using a recursive resolver that is close to
you, e.g. to avoid untrustworthy
On Mon, Mar 10, 2014 at 1:11 PM, Tony Finch d...@dotat.at wrote:
Stephane Bortzmeyer bortzme...@nic.fr wrote:
The only place where server authentication could be useful is between
a stub and the first resolver.
I don't think it is as simple as that.
There are good reasons for using a
Phillip Hallam-Baker hal...@gmail.com wrote:
First off it means that if the recursive is being used in discovery-only
mode it can simply pass data from the authoritative to the stub without
checking the DNSSEC chain.
If the recursive server is cacheing it needs to do DNSSEC validation to
On Mon, Mar 10, 2014 at 1:44 PM, Tony Finch d...@dotat.at wrote:
Phillip Hallam-Baker hal...@gmail.com wrote:
First off it means that if the recursive is being used in discovery-only
mode it can simply pass data from the authoritative to the stub without
checking the DNSSEC chain.
If
Phillip Hallam-Baker hal...@gmail.com wrote:
On Mon, Mar 10, 2014 at 1:44 PM, Tony Finch d...@dotat.at wrote:
Resolver has no session key on file so it sends the request in plaintext.
This leakage is bad expecially for recursors with few users and / or
queries for infrequently visited
