If the A records are owned by the target of a CNAME, or by the names referred to by NS records in the Authority Section, then they're related to the query being made and therefore not really "unsolicited".

To repeat: BIND doesn't have a way to include unrelated/unsolicited A records in a response, and even if it did, responsible resolvers would probably ignore them.

If you're so concerned about the latency of your client browser's DNS lookups then perhaps you should redesign your website(s) to use a much smaller set of unique domain names.

Also, I hope you realize that most modern browsers, as well as most modern operating systems, implement their own name caching right? So query-latency isn't as much of an issue as it once was. Unless, of course, your TTLs are set unreasonably low. In that case, you're defeating caching and creating your own performance problem.

A quick search turns up: http://developer.yahoo.com/performance/rules.html

- Kevin

On 4/19/2010 4:49 PM, Fabian Hahn wrote:
I do see additional "unsolicited" A-records being returned with CNAME-records 
and NS-records. They seem to be honored by the forwarders and resolvers on the way back.

In addition i should have mentioned that these records will be hosts in the 
same domain and this is implemented for a authoritative-only DNS server.

I am hoping that this will decrease the time a user experiences in DNS related 
delays when viewing a web page referencing several URLs in the domain.

   Fabian

On 4/18/2010 5:17 AM, Fabian Hahn wrote:
To speed up queries for the user I need to force the inclusion of additional 
records in a DNS response.

    I.e. when returning  www.domain.com A I would like to force the inclusion 
of A-records for static1.domain.com andstatic2.domain.com since they will be 
used in the same web-page.


No, you can't convince BIND to include "unsolicited" A-records in a
response, and even if you could, most resolvers would reject them
anyway, as Barry pointed out. There are serious security problems with
accepting A-records that weren't found through the regular iterative
process. How can you trust that such A-records are legitimate?

Sledgehammer approach: run a "refreshing" script to periodically query
those names so that you can keep your local cache populated with them.
The frequency of that script should be tuned to the TTL of the relevant
records. If your client usage patterns indicate low activity at certains
times of day/week, then you might want to exclude those times from the
running of the "refreshing" script, so as to reduce the
network-bandwidth overhead.


                                                     - Kevin
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users





_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to