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: bind-users Digest, Vol 2230, Issue 1

[Woodworth, John R]

>
> From: Harshith Mulky [mailto:harshith.mu...@outlook.com]
>
> Hello John,
>
> > 1.) Are these devices some type of VoIP device?  I've seen many novel DNS
> > based  scenarios used for VoIP before.
> [Harshith] yes, they are VOIP devices which use "lwresd" to talk to
> external DNS Servers
>

Harshith, apologies but I have not personally used lwresd.  I believe others
here may have so I can ask around but in any case I believe it is related to
bind9, at least tangentially, so the _unmodified_ version should behave as
you would expect from bind (i.e. no blacklist/ whitelist logic).

This will most likely require support from your vendor.

If by some chance you have shell access with root on the device itself there
may be other options but I recommend contacting your vendor first.


>  2.) I assume the path has been sniffed, are other records used as well, say 
> SRV?
> [Harshith] Yes we sniffed, SRV not used
>
> Is there any concept of DNS PROBE?

Not really, if the server can answer it will answer regardless of record type.


Thanks,
John

>
> I guess this wasn't a DNS question specifically and more on lwresd daemon.
>
> Sorry to have posted a wrong question
>
> Thanks
> Harshith
>
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

fetches-per-zone

[-]

I've been testing fetches-per-zone and have a couple of questions:

What is a good starting point for fetches-per-zone? I started with 200
but have no real evidence to say the number is low or high. On a
server which peaks at 1200 queries per second during the day I have
only 61 spilled due to zone quota in named.stats over a 24 hour
period. Is there any logging  available to show what zones were
spilled due to fetches-per-zone?

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