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