|Main Archive Page > Month Archives > bind-users archives|
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
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.
>> 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 mailing list