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 protect its cache from poisonous authorities. > The problem comes in that unlike the stub-resolver interaction where we can > do one key exchange with a service and keep the relationship going for the > life of the device (i.e. years), a resolver has to maintain relationships > with thousands to millions of authoritative servers and we probably can't > rely on these for more than a month or two at a time. Yes :-/ [...] > Resolver is connecting to an authoritative to make a request > really-obvious.com to answer a query from a stub (i.e. this is not a > pre-fetch). > > 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. > It can however be alerted to support for the security protocol in the > DNSSEC information for the zone. This is a bad idea because it makes partial deployment difficult - e.g. staged roll-out of encryption. DNSSEC information is per-zone but encryption has to be per-server. Tony. -- f.anthony.n.finch <d...@dotat.at> http://dotat.at/ German Bight, Humber, Thames: North or northeast 5 or 6, decreasing 4 or 5. Slight or moderate. Mainly fair. Moderate or good, occasionally poor. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
