Phillip Hallam-Baker wrote:
> On Mon, Mar 10, 2014 at 1:44 PM, Tony Finch 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 domains.
>
> If a
On Mon, Mar 10, 2014 at 1:44 PM, Tony Finch wrote:
> Phillip Hallam-Baker 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
Phillip Hallam-Baker 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
protect its cache
On Mon, Mar 10, 2014 at 1:11 PM, Tony Finch wrote:
> Stephane Bortzmeyer 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 th
Stephane Bortzmeyer 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 shared resolvers. H
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
