[atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops
- Previous message (by thread): [atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops
- Next message (by thread): [atlas] CAIDA BGP Hackathon 6-7 Feb 2016 -- Call for Participation
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Daniel Karrenberg
daniel.karrenberg at ripe.net
Wed Dec 9 13:05:41 CET 2015
On 8.12.15 17:15 , Philip Homburg wrote: > ... > To give an example, the ssh client I use is linked with getdns. Getdns > will try to fetch RRSIG records, etc. from the local resolver. If that > fails, getdns will become a full recursive resolver. > > When ssh starts, the cache of getdns will be empty. And after DNS > resolution whatever is cached will not be used anymore. Linking full recursive resolver into each application is a poor engineering choice. A better choice is to run a caching resolver on the host system, which is quite practical and helps already. Better still is to run a caching resolver on the home router. Making the poor choices will be noticeable in the responsiveness of the application. This will provide push-back. Unfortunately the perceived cause will appear to be the choice for DNSSEC and not the poor engineering choice in implementing DNSSEC. Personally I have chosen to implement DNSSEC by running unbound on my home router. I realise that this is not for everyone at this point in time. However CPE vendors are free to make a choice like this for new equipment or upgrades of existing CPE software. Daniel
- Previous message (by thread): [atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops
- Next message (by thread): [atlas] CAIDA BGP Hackathon 6-7 Feb 2016 -- Call for Participation
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]