Re: DNS latency!!!
2010/8/16 Shiva Raman > Hi All Hi, > Which is the best method to measure dns latency ? Is there any scripts / > programs > available to measure the dns latency directly? - queryperf : /bind-9.7.1-P2/contrib/queryperf/ - dnsperf : http://www.nominum.com/services/measurement_tools.php -DNS benchmark http://www.grc.com/dns/benchmark.htm -And if you have money : http://www.spirent.com/Solutions-Directory/Avalanche.aspx Regards, Yohann > > Regards > > Shiva Raman ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
filter packets bound for company proxy server?
Hi, Can I ask if anyone has a good idea for how I could identify (filter packets) that are transiting via a company proxy server [e.g. proxy.mycompany.com]. The challenge here is that the DNS server will issue any one of a number of IP addresses back to the browser to use, associated with the range of physical separate proxy servers that you might end up on. I've tried using the filter "host <>" however this doesn't seem to work. In fact some testing I did with wireshark to provide an example of what I'm seeing is: ASSUMPTIONS: First in terms of some assumptions for the sake of this example: nslookup proxy.mycompany.com Name:proxy.xxx..yyy.mycompany.com Address: 10.10.1.10 Aliases: proxy.mycompany.com nslookup 10.1.1.10 Name:proxy3.zzz.aaa.mycompany.com Address: 10.10.1.10 WIRESHARK RESULTS FOR GIVEN CAPTURE FILTER: a) "host proxy.mycompany.com" => Does not pickup the browser traffic I created that transits the proxy. Again my goal is to find a way to filter on this. b) "host proxy3.zzz.aaa.mycompany.com" => Does pick up the traffic BUT of course I've had to manually type in the actual proxy server. I tested with the same browser straight after putting in the capture filter so the proxy I was handed back obviously didn't change in that small time (i.e. at other time I would be handed off to proxy5.zzz.aaa.mycompany.com say for example) So I'm running out of ideas re how I could identify whether, for a given packet, whether it is one that has transited via the proxy serverany ideas? Would "dig" be a reliable way to get a list of all IP's associated with the main proxy DNS name? Would this be a possible solution re identifying them all perhaps? thanks ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: filter packets bound for company proxy server?
On 8/16/2010 8:10 AM, Greg Hauptmann wrote: Hi, Can I ask if anyone has a good idea for how I could identify (filter packets) that are transiting via a company proxy server [e.g. proxy.mycompany.com]. The challenge here is that the DNS server will issue any one of a number of IP addresses back to the browser to use, associated with the range of physical separate proxy servers that you might end up on. I've tried using the filter "host<>" however this doesn't seem to work. In fact some testing I did with wireshark to provide an example of what I'm seeing is: ASSUMPTIONS: First in terms of some assumptions for the sake of this example: nslookup proxy.mycompany.com Name:proxy.xxx..yyy.mycompany.com Address: 10.10.1.10 Aliases: proxy.mycompany.com nslookup 10.1.1.10 Name:proxy3.zzz.aaa.mycompany.com Address: 10.10.1.10 WIRESHARK RESULTS FOR GIVEN CAPTURE FILTER: a) "host proxy.mycompany.com" => Does not pickup the browser traffic I created that transits the proxy. Again my goal is to find a way to filter on this. b) "host proxy3.zzz.aaa.mycompany.com" => Does pick up the traffic BUT of course I've had to manually type in the actual proxy server. I tested with the same browser straight after putting in the capture filter so the proxy I was handed back obviously didn't change in that small time (i.e. at other time I would be handed off to proxy5.zzz.aaa.mycompany.com say for example) So I'm running out of ideas re how I could identify whether, for a given packet, whether it is one that has transited via the proxy serverany ideas? Would "dig" be a reliable way to get a list of all IP's associated with the main proxy DNS name? Would this be a possible solution re identifying them all perhaps? No it would not be a reliable way, because it's likely to be a load-balancer that's actually responding to the query for proxy.mycompany.com, and it'll return whatever it considers to be the "best" proxy at any given point in time. You'd have to look at the load-balancer config to know for sure all of the *possible* answers it could give to that question. An imperfect approach would be to query that name repeatedly over time and collect all of the IPs that you get in response, but with this approach you can't really know for sure that you got *all* of them. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Recommended DNS notify method for hidden master
Hi, I have several internal DNS servers, one of which is a hidden master for external zones. The nameserver listed in the SOA RR is in a DMZ. The internal DNS servers forward all queries for non-authoritative zones to a DNS server in the DMZ that will perform recursive queries, but the internal nameservers are restricted from sending queries or notifications to outside nameservers (and even if they were, it's unlikely that a third-party slave would accept notifies from anything but the master as listed in the SOA RR). What is the recommended method to configure DNS notify for the internal hidden master? I recognize that I can specify 'notify-to-soa yes;' in the view statement (in which all of these zones are placed; or in individual zone statements), but that will still result in attempted notification to all of the other NS RRs for the zone. I'd prefer that the hidden master notify the NS listed in the SOA RR, and that nameserver issue notification to all of the other NS RRs after it has pulled the zone(s). Will 'notify-to-soa yes;' still initiate a notification even if I turn off notify via 'notify no;'? TIA! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Recommended DNS notify method for hidden master
On 16.08.10 13:48, recvf...@gmail.com wrote:
> I have several internal DNS servers, one of which is a hidden master
> for external zones. The nameserver listed in the SOA RR is in a DMZ.
> The internal DNS servers forward all queries for non-authoritative
> zones to a DNS server in the DMZ that will perform recursive queries,
> but the internal nameservers are restricted from sending queries or
> notifications to outside nameservers (and even if they were, it's
> unlikely that a third-party slave would accept notifies from anything
> but the master as listed in the SOA RR). What is the recommended
> method to configure DNS notify for the internal hidden master? I
> recognize that I can specify 'notify-to-soa yes;' in the view
> statement (in which all of these zones are placed; or in individual
> zone statements), but that will still result in attempted notification
> to all of the other NS RRs for the zone. I'd prefer that the hidden
> master notify the NS listed in the SOA RR, and that nameserver issue
> notification to all of the other NS RRs after it has pulled the
> zone(s). Will 'notify-to-soa yes;' still initiate a notification even
> if I turn off notify via 'notify no;'?
I would recommend you:
- put real (hidden) master to SOA
- put "notify explicit; also-notify { slave-1; slave-2; };" into its
configuration
so the hidden master will only send notifies to your public slaves,
abd the public slave(s) will send notifies to third party slaves.
...if you have some third-party slaves, they _must_ fetch the zone from one
of your servers, your public slaves if not the hidden master. So they can
send notifies.
And in fact there's nothing bad in your hidden master sending the notifies
to all NSs...
--
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.
WinError #9: Out of error messages.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Recommended DNS notify method for hidden master
On 8/16/2010 1:48 PM, recvf...@gmail.com wrote: Hi, I have several internal DNS servers, one of which is a hidden master for external zones. The nameserver listed in the SOA RR is in a DMZ. The internal DNS servers forward all queries for non-authoritative zones to a DNS server in the DMZ that will perform recursive queries, but the internal nameservers are restricted from sending queries or notifications to outside nameservers (and even if they were, it's unlikely that a third-party slave would accept notifies from anything but the master as listed in the SOA RR). What is the recommended method to configure DNS notify for the internal hidden master? I recognize that I can specify 'notify-to-soa yes;' in the view statement (in which all of these zones are placed; or in individual zone statements), but that will still result in attempted notification to all of the other NS RRs for the zone. I'd prefer that the hidden master notify the NS listed in the SOA RR, and that nameserver issue notification to all of the other NS RRs after it has pulled the zone(s). I think the only way to prevent sending NOTIFYs to the nameservers in the NS records is to "hardcode" your NOTIFY lists with a combination of "also-notify"/"notify explicit". Will 'notify-to-soa yes;' still initiate a notification even if I turn off notify via 'notify no;'? I'm pretty sure "notify yes/no" is a "master switch"; that if you specify "notify no" none of the other notify-related options come into play. I could be wrong on that, though, since I haven't played with the NOTIFY-related options in recent versions of BIND. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Recommended DNS notify method for hidden master
On Mon, Aug 16, 2010 at 2:24 PM, Matus UHLAR - fantomas
wrote:
> On 16.08.10 13:48, recvf...@gmail.com wrote:
>> I have several internal DNS servers, one of which is a hidden master
>> for external zones. The nameserver listed in the SOA RR is in a DMZ.
>> The internal DNS servers forward all queries for non-authoritative
>> zones to a DNS server in the DMZ that will perform recursive queries,
>> but the internal nameservers are restricted from sending queries or
>> notifications to outside nameservers (and even if they were, it's
>> unlikely that a third-party slave would accept notifies from anything
>> but the master as listed in the SOA RR). What is the recommended
>> method to configure DNS notify for the internal hidden master? I
>> recognize that I can specify 'notify-to-soa yes;' in the view
>> statement (in which all of these zones are placed; or in individual
>> zone statements), but that will still result in attempted notification
>> to all of the other NS RRs for the zone. I'd prefer that the hidden
>> master notify the NS listed in the SOA RR, and that nameserver issue
>> notification to all of the other NS RRs after it has pulled the
>> zone(s). Will 'notify-to-soa yes;' still initiate a notification even
>> if I turn off notify via 'notify no;'?
>
> I would recommend you:
> - put real (hidden) master to SOA
> - put "notify explicit; also-notify { slave-1; slave-2; };" into its
> configuration
Ahhh, I had forgotten about 'notify explicit;' -- that's exactly what I needed!
I implemented as follows:
Hidden master -- notify --> SOA MNAME -- notify --> all other slaves.
> so the hidden master will only send notifies to your public slaves,
> abd the public slave(s) will send notifies to third party slaves.
>
> ...if you have some third-party slaves, they _must_ fetch the zone from one
> of your servers, your public slaves if not the hidden master. So they can
> send notifies.
Since the hidden master is not publicly accessible, I left it out of
the SOA, but all of your other suggestions were perfect.
> And in fact there's nothing bad in your hidden master sending the notifies
> to all NSs...
Well, except that were all just dropped on the floor at the firewall,
as intended. ;-)
Many thanks!!!
-r
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
DNS Rebinding Prevention for the Weak Host Model Attacks
bind-users,
In light of Craig Heffner's recent Black Hat talk (here:
https://media.blackhat.com/bh-us-10/whitepapers/Heffner/BlackHat-USA-2010-Heffner-How-to-Hack-Millions-of-Routers-wp.pdf
and here: http://rebind.googlecode.com) I would like to propose a
possible solution in line with the 'DNS rebinding attack prevention'
provided in version 9.7.
Craig Heffner's version of the DNS Rebinding attack, similar to all
DNS Rebinding attacks, requires the DNS Servers to respond with an
Attackers IP Address as well as the Victims IP Address, in a typical
Round Robin fashion. Previous attacks would normally have the Victims
IP Address to be their Private IP.
BIND, in version 9.7, developed two new options: deny-answer-addresses
and deny-answer-aliases. Within these ranges an ISP or Corporation
could put in the list of RFC1918 Addresses or other address clients
should never be resolving to. However, Craig's attack would bypass
these rules: the Victims IP is actually the Victims WAN IP - not their
internal address. An ISP would be unable to place their entire IP pool
into the 'deny-answer-*' options, allocated to customers, because this
would break many legitimate uses.
I would like to know though, what if bind was given the option that
allowed an ISP to block and/or log DNS requests (again with a
SERVFAIL), based on if the query-source was in the response along with
at least one other address.
Basically:
if ( query.source = query.result[0] && count(query.result) > 1 ) {
return (servfail)
}
If the Source IP of the client was also at least one of the results,
log and return a SERVFAIL. The rule would permit queries with a single
response.
Craig Heffner's method is serious for ISP's that supply their
customers modems that are vulnerable. The proper protections on the
customers modems would be a logistical nightmare.
Placing these protections, along with the current DNS Rebinding
protections already in 9.7 would be a great step forward in
realistically protecting these types of attacks.
I would propose "three" parameters for this. The first mode being
completely off (and I assume the default); the second, Permissive,
would only log the attacks; the third, Enforcing, would log and block
the attacks.
This would allow ISPs to upgrade to these specific versions of bind,
turn on Permissive parameter first and Enforcing if the attacks become
well known or impact is minimal.
What are your thoughts on this ? What could these protection break the
legitimate use for ?
--
Bradley Falzon
b...@teambrad.net
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
