RE: Why two lookups for a CNAME?
> From: bind-users-boun...@lists.isc.org > [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Steve Arntzen > > > > The reason is, when our Bind server is communicating over a satellite link > > with a 600 ms round trip time per transaction, the delay becomes noticeable > > (>1.2 seconds for a single CNAME resolution). Add to that, some of the > > CNAMES have short TTLs, so this happens periodically. > > > Steve, I know you have stated the "prefetch" feature may suit your needs > but would it be possible to put another resolver on the other side of the > link? I understand it is not a zero-cost solution but it would level out > uncached queries from the other side of the link while inside would > still benefit from a local cache. This is just an off-the-cuff idea and > I have not worked through all the little details but thought I would > share. I am also interested in how prefetch works for you. > > > Thanks, > John Disregard. I should have tested this first, still getting same verification query as others with this setup. Thanks, John > > > > > > As a test, I tried forwarding (and forward only) google.com to Google's > > public DNS server. Although the packets did go directly to 8.8.8.8 as > > expected, my Bind server still (for safe verification) performed the > > second look up. Note, the requesting client using dig, sends out one > > request and receives one reply. The test was for "play.google.com". > > > > If anyone has suggestions, please toss them my way. > > "Let it work as designed and deal with it" or similar comments will > > be graciously accepted. > > > > Thanks again, > > > > Steve. > > > This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Why two lookups for a CNAME?
From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Steve Arntzen > > The reason is, when our Bind server is communicating over a satellite link > with a 600 ms round trip time per transaction, the delay becomes noticeable > (>1.2 seconds for a single CNAME resolution). Add to that, some of the > CNAMES have short TTLs, so this happens periodically. Steve, I know you have stated the "prefetch" feature may suit your needs but would it be possible to put another resolver on the other side of the link? I understand it is not a zero-cost solution but it would level out uncached queries from the other side of the link while inside would still benefit from a local cache. This is just an off-the-cuff idea and I have not worked through all the little details but thought I would share. I am also interested in how prefetch works for you. Thanks, John > > As a test, I tried forwarding (and forward only) google.com to Google's > public DNS server. Although the packets did go directly to 8.8.8.8 as > expected, my Bind server still (for safe verification) performed the > second look up. Note, the requesting client using dig, sends out one > request and receives one reply. The test was for "play.google.com". > > If anyone has suggestions, please toss them my way. > "Let it work as designed and deal with it" or similar comments will > be graciously accepted. > > Thanks again, > > Steve. > This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Why two lookups for a CNAME?
Am 23.10.2015 um 10:21 schrieb Matus UHLAR - fantomas: Am 22.10.2015 um 14:01 schrieb Matus UHLAR - fantomas: I wonder if it's not enough to verify that the first response was received from proper server. Since play.l.google.com is a subdomain of play.google.com, the lookup would go throuth google.com nameservers again... when servers for bar.example are the same as servers for foo.example, the already accepted answer for foo.example is expected to contain valid answer for bar.example too... On 22.10.15 14:07, Reindl Harald wrote: well, it's better to keep things simple and whenever possible working the same way instead premature optimization and different behavior to keep them clear and maintainable I don't see what's premature on keeping invalidated responses pending in cache for further validation ... I believe this is very common at many of DNS hosting providers that will return not just the answer but also the glue records so there's in fact no need to check for them once you make sure the NS is correct so we can spare us some RTTs. i guess the opposite: large DNS hosting providers likely use "minimal-responses yes;" which saves here around 20% of DNS traffic, google nameservers do the same (of course DNSSEC validation will still be done, but also optimized). at the end it does not matter most DNS results are coming from caches and if they are not in the cache they are not frequent enough that it would matter it doesn't matter so much that nobody even asked for it on BIND mailing list because of noticing it... just because someone is asking a *question* doe snot change anything in matters or matters not by itself signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Why two lookups for a CNAME?
Am 22.10.2015 um 14:01 schrieb Matus UHLAR - fantomas: I wonder if it's not enough to verify that the first response was received from proper server. Since play.l.google.com is a subdomain of play.google.com, the lookup would go throuth google.com nameservers again... when servers for bar.example are the same as servers for foo.example, the already accepted answer for foo.example is expected to contain valid answer for bar.example too... On 22.10.15 14:07, Reindl Harald wrote: well, it's better to keep things simple and whenever possible working the same way instead premature optimization and different behavior to keep them clear and maintainable I don't see what's premature on keeping invalidated responses pending in cache for further validation ... I believe this is very common at many of DNS hosting providers that will return not just the answer but also the glue records so there's in fact no need to check for them once you make sure the NS is correct so we can spare us some RTTs. (of course DNSSEC validation will still be done, but also optimized). at the end it does not matter most DNS results are coming from caches and if they are not in the cache they are not frequent enough that it would matter it doesn't matter so much that nobody even asked for it on BIND mailing list because of noticing it... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I intend to live forever - so far so good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Why two lookups for a CNAME?
Thank you all for the suggestions. Prefetch sounds like a good solution and still provides the designed behavior for integrity. I see Bind 9.10 introduces “prefetch” and I will look into it. Until we change or upgrade, a simple solution may be our own prefetch (periodic lookup) of popular CNAMES (as we see them in logs). I will share the options and suggestions to those who decide. (sorry for the TOFU) Steve. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Why two lookups for a CNAME?
Am 22.10.2015 um 17:41 schrieb Phil Mayers: On 22/10/15 16:37, Reindl Harald wrote: since in a normal environment that don't matter consider in case of a caching-only nameserver in such an environment using unbound instead of named because it supports "cache-min-ttl" which is also strongly recommended on a inbound mailserver using RBL's cache-min-ttl: 600 cache-max-ttl: 10800 Right, but he'll still see a slow, expired-cache case every min-ttl won't he? Unless unbound does prefetch? onbound *does* prefetch if enabled https://www.unbound.net/documentation/unbound.conf.html prefetch: If yes, message cache elements are prefetched before they expire to keep the cache up to date. Default is no. Turning it on gives about 10 percent more traffic and load on the machine, but popular items do not expire from the cache i like named for many reasons on authoritative nameservers, but for caching only unbound is way easier to maintain with more caching features signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Why two lookups for a CNAME?
>> >> Using dig, I find play.google.com is a CNAME for play.l.google.com. >> >> >> When asked to resolve it, named will first look for play.google.com. The >> result >> will include the CNAME and the IP of the A record. >> >> >> Named then makes a second request to resolve the A record. > > Are you sure about this example? > > That would be the correct behavior if the target of the CNAME were > delegated to different servers than the CNAME itself. But both > google.com and l.google.com are served by ns[1-4].google.com. > > You'll see additional queries like this if you look up servers hosted by > the Akamai CDN, because the CNAME points from the original domain to one > of Akamai's domains. Hi Barry, I just did a double-check (stock RHEL 6 BIND, 9.8.2), and BIND indeed does do the second lookup for play.l.google.com. I've attached a pcap file if anyone's curious. John -- John Miller Systems Engineer Brandeis University johnm...@brandeis.edu play.google.com.pcap Description: application/vnd.tcpdump.pcap ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Why two lookups for a CNAME?
On 22/10/15 16:37, Reindl Harald wrote: since in a normal environment that don't matter consider in case of a caching-only nameserver in such an environment using unbound instead of named because it supports "cache-min-ttl" which is also strongly recommended on a inbound mailserver using RBL's cache-min-ttl: 600 cache-max-ttl: 10800 Right, but he'll still see a slow, expired-cache case every min-ttl won't he? Unless unbound does prefetch? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Why two lookups for a CNAME?
On 22/10/15 16:30, Steve Arntzen wrote: As a test, I tried forwarding (and forward only) google.com to Google's public DNS server. Although the packets did go directly to 8.8.8.8 as expected, my Bind server still (for safe verification) performed the second look up. Note, the requesting client using dig, sends out one request and receives one reply. The test was for "play.google.com". "forward only" was going to be my suggestion but I guess it doesn't work. Likely it's just not implemented to avoid proliferation of code paths. I wonder if the prefetch feature of recent versions of bind would help you; you'd still be doing the queries, but "in advance" of the cache entry expiring, so the client wouldn't see the slow, expired-cache case. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Why two lookups for a CNAME?
Am 22.10.2015 um 17:30 schrieb Steve Arntzen: The reason is, when our Bind server is communicating over a satellite link with a 600 ms round trip time per transaction, the delay becomes noticeable (>1.2 seconds for a single CNAME resolution). Add to that, some of the CNAMES have short TTLs, so this happens periodically. since in a normal environment that don't matter consider in case of a caching-only nameserver in such an environment using unbound instead of named because it supports "cache-min-ttl" which is also strongly recommended on a inbound mailserver using RBL's cache-min-ttl: 600 cache-max-ttl: 10800 P.S.: please don't top-post with full-quotes (TOFU) On October 22, 2015 at 7:07 AM Reindl Harald wrote: Am 22.10.2015 um 14:01 schrieb Matus UHLAR - fantomas: > On 22.10.15 08:01, Mark Andrews wrote: >> To prevent cache poisoning via cnames. It it simpler to always >> lookup the target of the cname that to figure out if we would >> accepted the following data. >> >> server A has zones foo.example and bar.example configured >> server B has zone bar.example configured >> >> bar.example is only delegated to server B of the two server above. >> >> The is a cname from www.foo.example -> www.bar.example >> >> Server A return a complete answer but the www.bar.example data is >> from the wrong zone instance. This happens accidentally in real >> life. > > I wonder if it's not enough to verify that the first response was received > from proper server. > > Since play.l.google.com is a subdomain of play.google.com, the lookup would > go throuth google.com nameservers again... > > when servers for bar.example are the same as servers for foo.example, the > already accepted answer for foo.example is expected to contain valid answer > for bar.example too... well, it's better to keep things simple and whenever possible working the same way instead premature optimization and different behavior to keep them clear and maintainable at the end it does not matter most DNS results are coming from caches and if they are not in the cache they are not frequent enough that it would matter -- Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / CISO / Software-Development m: +43 (676) 40 221 40, p: +43 (1) 595 3999 33 icq: 154546673, http://www.thelounge.net/ http://www.thelounge.net/signature.asc.what.htm signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Why two lookups for a CNAME?
I fully agree. Now, please understand the following question has been asked of me and I fully realize the implications and that it is just not a good idea. I will gladly forward the suggestions to my peers (and bosses). Is there any way to accept the first response (CNAME with IP) and not perform the second look up? The reason is, when our Bind server is communicating over a satellite link with a 600 ms round trip time per transaction, the delay becomes noticeable (>1.2 seconds for a single CNAME resolution). Add to that, some of the CNAMES have short TTLs, so this happens periodically. As a test, I tried forwarding (and forward only) google.com to Google's public DNS server. Although the packets did go directly to 8.8.8.8 as expected, my Bind server still (for safe verification) performed the second look up. Note, the requesting client using dig, sends out one request and receives one reply. The test was for "play.google.com". If anyone has suggestions, please toss them my way. "Let it work as designed and deal with it" or similar comments will be graciously accepted. Thanks again, Steve. > > On October 22, 2015 at 7:07 AM Reindl Harald > wrote: > > > > > Am 22.10.2015 um 14:01 schrieb Matus UHLAR - fantomas: > > On 22.10.15 08:01, Mark Andrews wrote: > >> To prevent cache poisoning via cnames. It it simpler to always > >> lookup the target of the cname that to figure out if we would > >> accepted the following data. > >> > >> server A has zones foo.example and bar.example configured > >> server B has zone bar.example configured > >> > >> bar.example is only delegated to server B of the two server above. > >> > >> The is a cname from www.foo.example -> www.bar.example > >> > >> Server A return a complete answer but the www.bar.example data is > >> from the wrong zone instance. This happens accidentally in real > >> life. > > > > I wonder if it's not enough to verify that the first response was > > received > > from proper server. > > > > Since play.l.google.com is a subdomain of play.google.com, the lookup > > would > > go throuth google.com nameservers again... > > > > when servers for bar.example are the same as servers for foo.example, > > the > > already accepted answer for foo.example is expected to contain valid > > answer > > for bar.example too... > > well, it's better to keep things simple and whenever possible working > the same way instead premature optimization and different behavior to > keep them clear and maintainable > > at the end it does not matter > > most DNS results are coming from caches and if they are not in the cache > they are not frequent enough that it would matter > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Why two lookups for a CNAME?
In article , Steve Arntzen wrote: > I'm sure there's a good, simple reason for this, I just can't seem to find > the > answer searching on the Internet. > > > Why does named perform a lookup for the A record when its IP is returned with > the CNAME in the first answer? > > > Using dig, I find play.google.com is a CNAME for play.l.google.com. > > > When asked to resolve it, named will first look for play.google.com. The > result > will include the CNAME and the IP of the A record. > > > Named then makes a second request to resolve the A record. Are you sure about this example? That would be the correct behavior if the target of the CNAME were delegated to different servers than the CNAME itself. But both google.com and l.google.com are served by ns[1-4].google.com. You'll see additional queries like this if you look up servers hosted by the Akamai CDN, because the CNAME points from the original domain to one of Akamai's domains. -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Why two lookups for a CNAME?
Am 22.10.2015 um 14:01 schrieb Matus UHLAR - fantomas: On 22.10.15 08:01, Mark Andrews wrote: To prevent cache poisoning via cnames. It it simpler to always lookup the target of the cname that to figure out if we would accepted the following data. server A has zones foo.example and bar.example configured server B has zone bar.example configured bar.example is only delegated to server B of the two server above. The is a cname from www.foo.example -> www.bar.example Server A return a complete answer but the www.bar.example data is from the wrong zone instance. This happens accidentally in real life. I wonder if it's not enough to verify that the first response was received from proper server. Since play.l.google.com is a subdomain of play.google.com, the lookup would go throuth google.com nameservers again... when servers for bar.example are the same as servers for foo.example, the already accepted answer for foo.example is expected to contain valid answer for bar.example too... well, it's better to keep things simple and whenever possible working the same way instead premature optimization and different behavior to keep them clear and maintainable at the end it does not matter most DNS results are coming from caches and if they are not in the cache they are not frequent enough that it would matter signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Why two lookups for a CNAME?
In message <1401468033.15948.1445459552099.javamail.vpopm...@atl4oxapp02pod1.mg t.hosting.qts.netsol.com>, Steve Arntzen writes: Why does named perform a lookup for the A record when its IP is returned with the CNAME in the first answer? On 22.10.15 08:01, Mark Andrews wrote: To prevent cache poisoning via cnames. It it simpler to always lookup the target of the cname that to figure out if we would accepted the following data. server A has zones foo.example and bar.example configured server B has zone bar.example configured bar.example is only delegated to server B of the two server above. The is a cname from www.foo.example -> www.bar.example Server A return a complete answer but the www.bar.example data is from the wrong zone instance. This happens accidentally in real life. I wonder if it's not enough to verify that the first response was received from proper server. Since play.l.google.com is a subdomain of play.google.com, the lookup would go throuth google.com nameservers again... when servers for bar.example are the same as servers for foo.example, the already accepted answer for foo.example is expected to contain valid answer for bar.example too... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Depression is merely anger without enthusiasm. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Why two lookups for a CNAME?
Makes sense. Better safe than sorry. Thanks, Steve. > > On October 21, 2015 at 4:01 PM Mark Andrews wrote: > > > > To prevent cache poisoning via cnames. It it simpler to always > lookup the target of the cname that to figure out if we would > accepted the following data. > > server A has zones foo.example and bar.example configured > server B has zone bar.example configured > > bar.example is only delegated to server B of the two server above. > > The is a cname from www.foo.example -> www.bar.example > > Server A return a complete answer but the www.bar.example data is > from the wrong zone instance. This happens accidentally in real > life. > > Mark > > In message > <1401468033.15948.1445459552099.javamail.vpopm...@atl4oxapp02pod1.mg > t.hosting.qts.netsol.com>, Steve Arntzen writes: > > > > I'm sure there's a good, simple reason for this, I just can't seem to > > find th > > e > > answer searching on the Internet. > > > > > > Why does named perform a lookup for the A record when its IP is returned > > with > > the CNAME in the first answer? > > > > > > Using dig, I find play.google.com is a CNAME for play.l.google.com. > > > > > > When asked to resolve it, named will first look for play.google.com. The > > res > > ult > > will include the CNAME and the IP of the A record. > > > > > > Named then makes a second request to resolve the A record. > > > > > > Thanks in advance, > > > > > > Steve. > > --=_Part_15947_1241356502.1445459552087 > > MIME-Version: 1.0 > > Content-Type: text/html; charset=UTF-8 > > Content-Transfer-Encoding: 7bit > > > > > "http://www.w3.org/T > > R/xhtml1/DTD/xhtml1-strict.dtd"> > > > > http://www.w3.org/1999/xhtml";> > > > > I'm sure there's a good, simple reason for this, I j > > ust can't seem to find the answer searching on the > > Internet. > p>Why does named perform a lookup for the A record when its IP is > > returned > > with the CNAME in the first answer?Using dig, I find > > play. > > google.com is a CNAME for play.l.google.com.When asked > > to r > > esolve it, named will first look for play.google.com. The result will i > > nclude the CNAME and the IP of the A record.Named then > > make > > s a second request to resolve the A record.Thanks in > > advanc > > e,Steve. > > --=_Part_15947_1241356502.1445459552087-- > > > > --===7115022951714415033== > > Content-Type: text/plain; charset="us-ascii" > > MIME-Version: 1.0 > > Content-Transfer-Encoding: 7bit > > Content-Disposition: inline > > > > ___ > > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > > unsubscribe > > from this list > > > > bind-users mailing list > > bind-users@lists.isc.org > > https://lists.isc.org/mailman/listinfo/bind-users > > --===7115022951714415033==-- > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Why two lookups for a CNAME?
On Wed, 2015-10-21 at 20:42 +, Lightner, Jeff wrote: > Because the purpose of DNS primarily is to equate a name with an IP as > applications talk to IPs not to names. When you have a CNAME you’re > equating one name with another name. That other name then has to be > looked up so the application knows what IP access. This doesn't answer the OPs question (which is a good one). He's saying that the required IP address has *already been returned* in the first response, so why is a second query made? When I use dig to do a lookup of a cname, it makes only one query: ; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> www.angihigh.com.au [...] ;; ANSWER SECTION: www.angihigh.com.au/ ... CNAME angihigh.com.au. angihigh.com.au. ... A 27.121.64.62 [...] Maybe the application mentioned by the OP is not a smart as dig. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Why two lookups for a CNAME?
To prevent cache poisoning via cnames. It it simpler to always lookup the target of the cname that to figure out if we would accepted the following data. server A has zones foo.example and bar.example configured server B has zone bar.example configured bar.example is only delegated to server B of the two server above. The is a cname from www.foo.example -> www.bar.example Server A return a complete answer but the www.bar.example data is from the wrong zone instance. This happens accidentally in real life. Mark In message <1401468033.15948.1445459552099.javamail.vpopm...@atl4oxapp02pod1.mg t.hosting.qts.netsol.com>, Steve Arntzen writes: > > I'm sure there's a good, simple reason for this, I just can't seem to find th > e > answer searching on the Internet. > > > Why does named perform a lookup for the A record when its IP is returned with > the CNAME in the first answer? > > > Using dig, I find play.google.com is a CNAME for play.l.google.com. > > > When asked to resolve it, named will first look for play.google.com. The res > ult > will include the CNAME and the IP of the A record. > > > Named then makes a second request to resolve the A record. > > > Thanks in advance, > > > Steve. > --=_Part_15947_1241356502.1445459552087 > MIME-Version: 1.0 > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: 7bit > > http://www.w3.org/T > R/xhtml1/DTD/xhtml1-strict.dtd"> > > http://www.w3.org/1999/xhtml";> > > I'm sure there's a good, simple reason for this, I j > ust can't seem to find the answer searching on the Internet. p>Why does named perform a lookup for the A record when its IP is returned > with the CNAME in the first answer?Using dig, I find play. > google.com is a CNAME for play.l.google.com.When asked to r > esolve it, named will first look for play.google.com. The result will i > nclude the CNAME and the IP of the A record.Named then make > s a second request to resolve the A record.Thanks in advanc > e,Steve. > --=_Part_15947_1241356502.1445459552087-- > > --===7115022951714415033== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > --===7115022951714415033==-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Why two lookups for a CNAME?
Thank you Jeff. I was just wondering why, when the IP comes back with the first response, does named ask again? Is it just being literal (like me) or will it not always get the IP in the first request (depending on the DNS server)? Steve. > On October 21, 2015 at 3:42 PM "Lightner, Jeff" > wrote: > > > Because the purpose of DNS primarily is to equate a name with an IP as > applications talk to IPs not to names. When you have a CNAME you’re equating > one name with another name. That other name then has to be looked up so the > application knows what IP access. > > > > This saves time if you have multiple CNAMES to the same A record in that > when you update DNS you only have to update that one A record. You don’t have > to use CNAMES to go to same IP – you could make each record an A record > pointing to the same IP. You’d then have to be sure you updated all the A > records using that IP if you decided to change it to something else later > (e.g. if you changed ISPs). > > > > Obviously there is a small performance cost in CNAMES which is why you > don’t want to have a CNAME to another CNAME because that results in 3 > lookups. For most applications the single CNAME isn’t an issue but on > occasion it is so you go the A record route instead. > > > > > > From: bind-users-boun...@lists.isc.org > [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Steve Arntzen > Sent: Wednesday, October 21, 2015 4:33 PM > To: bind-users > Subject: Why two lookups for a CNAME? > > > > I'm sure there's a good, simple reason for this, I just can't seem to find > the answer searching on the Internet. > > > > Why does named perform a lookup for the A record when its IP is returned > with the CNAME in the first answer? > > > > Using dig, I find play.google.com is a CNAME for play.l.google.com. > > > > When asked to resolve it, named will first look for play.google.com. The > result will include the CNAME and the IP of the A record. > > > > Named then makes a second request to resolve the A record. > > > > Thanks in advance, > > > > Steve. > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Why two lookups for a CNAME?
Because the purpose of DNS primarily is to equate a name with an IP as applications talk to IPs not to names. When you have a CNAME you’re equating one name with another name. That other name then has to be looked up so the application knows what IP access. This saves time if you have multiple CNAMES to the same A record in that when you update DNS you only have to update that one A record. You don’t have to use CNAMES to go to same IP – you could make each record an A record pointing to the same IP. You’d then have to be sure you updated all the A records using that IP if you decided to change it to something else later (e.g. if you changed ISPs). Obviously there is a small performance cost in CNAMES which is why you don’t want to have a CNAME to another CNAME because that results in 3 lookups. For most applications the single CNAME isn’t an issue but on occasion it is so you go the A record route instead. From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Steve Arntzen Sent: Wednesday, October 21, 2015 4:33 PM To: bind-users Subject: Why two lookups for a CNAME? I'm sure there's a good, simple reason for this, I just can't seem to find the answer searching on the Internet. Why does named perform a lookup for the A record when its IP is returned with the CNAME in the first answer? Using dig, I find play.google.com is a CNAME for play.l.google.com. When asked to resolve it, named will first look for play.google.com. The result will include the CNAME and the IP of the A record. Named then makes a second request to resolve the A record. Thanks in advance, Steve. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Why two lookups for a CNAME?
I'm sure there's a good, simple reason for this, I just can't seem to find the answer searching on the Internet. Why does named perform a lookup for the A record when its IP is returned with the CNAME in the first answer? Using dig, I find play.google.com is a CNAME for play.l.google.com. When asked to resolve it, named will first look for play.google.com. The result will include the CNAME and the IP of the A record. Named then makes a second request to resolve the A record. Thanks in advance, Steve.___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users