Re: Why two lookups for a CNAME?

[Reindl Harald]

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?

[Woodworth, John R]

> 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?

[Woodworth, John R]

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?

[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.

(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?

[Reindl Harald]

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?

[Matus UHLAR - fantomas]

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?

[Barry Margolin]

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?

[Reindl Harald]

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?

[Reindl Harald]

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?

[John Miller]

>>
>> 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?

[Steve Arntzen]

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?

[Phil Mayers]

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?

[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?

___
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?

[Steve Arntzen]

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?

[Steve Arntzen]

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?

[Mark Andrews]

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;>
> 
>  Im sure theres a good, simple reason for this, I j
> ust cant 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?

[Lightner, Jeff]

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?

[Karl Auer]

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?

[Steve Arntzen]

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