Re: «tsig verify failure» only on some zones
First thing. Ensure that the nameservers are properly ntp synced. This should get rid of mosr timing issues. Secondly, for the failing zone run tcpdump on both ends and compare the TCP payload of the packets. They should be byte for byte identical. If they differ then the NAT box is fiddling with the contents. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind as cache DNS and firewall
On 08/18/2010 02:42 PM, Ulrich David wrote: > Hi, > > I'm using Bind as a cache (absolutely not authoritative) DNS for a public > network. I have put a firewall in order to refuse incoming packets from > people not on my network. > > Today, inspecting logs, I see this : > > Aug 18 17:31:44 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=195.176.219.26 > DST=MY.CACHE.DNS LEN=69 TOS=00 PREC=0x00 TTL=120 ID=50785 CE PROTO=UDP > SPT=56592 DPT=53 LEN=49 > Aug 18 17:31:48 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=195.176.219.26 > DST=MY.CACHE.DNS LEN=59 TOS=00 PREC=0x00 TTL=120 ID=23374 PROTO=UDP SPT=57527 > DPT=53 LEN=39 > Aug 18 17:31:51 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=207.38.104.93 > DST=MY.CACHE.DNS LEN=47 TOS=00 PREC=0x00 TTL=48 ID=48457 CE PROTO=UDP > SPT=32779 DPT=53 LEN=27 > Aug 18 17:31:56 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=195.176.219.26 > DST=MY.CACHE.DNS LEN=72 TOS=00 PREC=0x00 TTL=120 ID=38433 CE PROTO=UDP > SPT=53494 DPT=53 LEN=52 > Aug 18 17:32:00 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=109.164.132.64 > DST=MY.CACHE.DNS LEN=60 TOS=00 PREC=0x00 TTL=112 ID=24658 PROTO=UDP SPT=51908 > DPT=53 LEN=40 > Aug 18 17:32:04 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=195.176.219.26 > DST=MY.CACHE.DNS LEN=69 TOS=00 PREC=0x00 TTL=120 ID=40178 CE PROTO=UDP > SPT=48147 DPT=53 LEN=49 > Aug 18 17:32:08 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=213.3.5.3 > DST=MY.CACHE.DNS LEN=68 TOS=00 PREC=0x00 TTL=53 ID=15544 PROTO=UDP SPT=18967 > DPT=53 LEN=48 > > This traffic came from other DNS server in the world. As it's UDP I think of > UDP queries going from my cache server to other DNS server, and I catch their > UDP responses in the firewall. Is it possible? > > So I should open my firewall for UDP on port 53 for all the world? > > Regards, > > David David, First, double-check that you're on a current BIND release. Second, check that your named.conf doesn't have "query-source" bound to port 53. It's bad to always source your queries from port 53, as it allows your cache to get bogus spoofed replies from systems you aren't asking queries of. Provided that you are running a recent version of BIND, and that you are configuring your named.conf to query from port 53, your DNS server should be sending out UDP queries from random, high-numbered ephemeral ports. See the Wikipedia article on this, which discusses Linux port defaults vs. IANA recommended port range, etc. (as I'm typing this while offline). Your server should be sourcing from those random, high-numbered ephemeral ports to remote DNS servers' udp/53. Their queries should come back from their same udp/53 source to your same original high-numbered ephemeral port. As you should be sending UDP queries from high-numbered ports, and your queries are never going to originate from udp/53, so you should never get replies destined for your udp/53. You should absolutely not open your firewall to queries from UDP/53 as it is not authoritative and is not an open dns resolving server for the Internet (or if it was, you shouldn't be asking questions on here how to secure it). I would configure your firewall to -j DROP and not first -j LOG these packets. No need filling up your syslog with bogus queries. My guess is that there are some poorly configured remote firewalls. Jason Roysdon http://jason.roysdon.net/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind as cache DNS and firewall
On Wednesday 18 August 2010 17:42, Ulrich David wrote: > Hi, > > I'm using Bind as a cache (absolutely not authoritative) DNS for a public > network. I have put a firewall in order to refuse incoming packets from > people not on my network. > > This traffic came from other DNS server in the world. As it's UDP I think > of UDP queries going from my cache server to other DNS server, and I catch > their UDP responses in the firewall. Is it possible? > > So I should open my firewall for UDP on port 53 for all the world? It would really depend on how you have your firewall setup. You should have it setup to do STATEFUL inspection and allow ESTABLISHED,RELATED connection inbound that way your responses are allowed through. Also ensure that connection tracking is turned on. A simple firewall could be; eth0 = Internet eth1 = LAN iptables -A FORWARD -i eth1 -m state --state NEW --dport 53 -j ACCEPT iptables -A FORWARD -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT The reason I use just the port is so that both TCP and UDP are captured. But not knowing your setup it is hard to give you a complete answer. -- Regards Robert Linux The adventure of a life time. Linux User #296285 Get Counted http://counter.li.org/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: www.ncbi.nlm.nih.gov / pubmed
On 08/18/2010 06:55 PM, Dave Sparro wrote: On 8/18/2010 1:12 PM, Casey Deccio wrote: On Wed, Aug 18, 2010 at 9:48 AM, Dave Sparro wrote: On 8/18/2010 8:30 AM, Phil Mayers wrote: ...since the "ncbi" zone is an unsigned child zone, there needs to be an NSEC/NSEC3 record to prove the absence of the DS record, and have a secure delegation to an unsigned child zone. It sounds to me like DNSSEC validation is working as designed. If your DNS server's users are complaining about not being able to resolve something that fails validation, the question you need to ask is do your end-users really want you to do DNSSEC validation for them? If you're asking for a workaround for when validation fails, there's not much point to doing the validation. Insecure delegations are not a work-around, but are rather a provision for delegated child zones that have not implemented DNSSEC. The parent zone (and its authoritative servers) must be properly configured to handle authenticated denial of existence using NSEC or NSEC3. Specifically, they must use these RRs to prove the non-existence of a DS RR for an unsigned child zone, whose existence would otherwise indicate a secure delegation. If the proper NSEC/NSEC3 RRs are not returned, or are not thought to be authentic, then there is a broken chain because the resolver cannot prove that the delegation is insecure. In the following diagram, note the diamond-shaped NSEC3 node, whose presence (when properly authenticated) proves the insecure delegation to ncbi.nlm.nih.gov: http://dnsviz.net/d/www.ncbi.nlm.nih.gov/dnssec/ It seems to me that the OP wanted a work-around to the fact that his end users couldn't use the website due to a validation failure. It still seems to me that working around that situation misses the point of using DNSSEC. I did, and I disagree that it misses the point. I wanted a *short term* workaround for that zone, while the site fixed their DNSSEC. I had satisfied myself that it was a DNSSEC signing mistake, and faced an unpalatable choice - disable validation globally for the duration of a single site repair period (sacrificing the benefits of DNSSEC) or lose connectivity to that site. Had the site been more "important" to us, it would have been no "choice" at all - I would have been instructed to disable validation. I think DNSSEC is very important, but I also think mistakes will happen, and that sites will want the ability to be forgiving for a grace period. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind as cache DNS and firewall
Hi Jason and Robert,
Sorry for my lack of details.
My firewall has stateful inspection enabled for all port :
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
I permit all outgoing packet. The opened incoming ports are 22 tcp (for all
IP), 53 tcp and udp (filtered for my clients IP - they have public IPs... so...
-).
I enable LOG for iptables but protect it against DoS. Doing this permit me to
do some "inspection" :) .
I have a BIND 9.4.3-P5 (running on a linux). It's last stable release on my
distribution. query-source is not enabled. My configuration is very simple :
options {
directory "/var/bind";
listen-on-v6 { none; };
listen-on { any; };
allow-query {
local;
my-clients;
my-servers;
my-private-network;
};
statistics-file "/var/bind/stats/named.stats";
version "None of your business";
blackhole { blacklist; };
max-cache-size 0;
recursive-clients 1;
pid-file "/var/run/named/named.pid";
};
I have some zone (in-addr.arpa, . , localhost). I have logging and controls
block too.
I can go up to 4000 queries/seconds (a lot of mailservers on my network).
named is running well. But I have some problems with some perharps "bogus"
authoritative dns (ns51.domaincontrol.com andns52.domaincontrol.com for
example)... so I decided to see if it's not my configuration which has a
problem.
Regards,
David
Le 19 août 2010 à 04:23, Jason Roysdon a écrit :
>
> On 08/18/2010 02:42 PM, Ulrich David wrote:
>> Hi,
>>
>> I'm using Bind as a cache (absolutely not authoritative) DNS for a public
>> network. I have put a firewall in order to refuse incoming packets from
>> people not on my network.
>>
>> Today, inspecting logs, I see this :
>>
>> Aug 18 17:31:44 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=195.176.219.26
>> DST=MY.CACHE.DNS LEN=69 TOS=00 PREC=0x00 TTL=120 ID=50785 CE PROTO=UDP
>> SPT=56592 DPT=53 LEN=49
>> Aug 18 17:31:48 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=195.176.219.26
>> DST=MY.CACHE.DNS LEN=59 TOS=00 PREC=0x00 TTL=120 ID=23374 PROTO=UDP
>> SPT=57527 DPT=53 LEN=39
>> Aug 18 17:31:51 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=207.38.104.93
>> DST=MY.CACHE.DNS LEN=47 TOS=00 PREC=0x00 TTL=48 ID=48457 CE PROTO=UDP
>> SPT=32779 DPT=53 LEN=27
>> Aug 18 17:31:56 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=195.176.219.26
>> DST=MY.CACHE.DNS LEN=72 TOS=00 PREC=0x00 TTL=120 ID=38433 CE PROTO=UDP
>> SPT=53494 DPT=53 LEN=52
>> Aug 18 17:32:00 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=109.164.132.64
>> DST=MY.CACHE.DNS LEN=60 TOS=00 PREC=0x00 TTL=112 ID=24658 PROTO=UDP
>> SPT=51908 DPT=53 LEN=40
>> Aug 18 17:32:04 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=195.176.219.26
>> DST=MY.CACHE.DNS LEN=69 TOS=00 PREC=0x00 TTL=120 ID=40178 CE PROTO=UDP
>> SPT=48147 DPT=53 LEN=49
>> Aug 18 17:32:08 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=213.3.5.3
>> DST=MY.CACHE.DNS LEN=68 TOS=00 PREC=0x00 TTL=53 ID=15544 PROTO=UDP SPT=18967
>> DPT=53 LEN=48
>>
>> This traffic came from other DNS server in the world. As it's UDP I think of
>> UDP queries going from my cache server to other DNS server, and I catch
>> their UDP responses in the firewall. Is it possible?
>>
>> So I should open my firewall for UDP on port 53 for all the world?
>>
>> Regards,
>>
>> David
>
>
> David,
>
> First, double-check that you're on a current BIND release. Second,
> check that your named.conf doesn't have "query-source" bound to port 53.
> It's bad to always source your queries from port 53, as it allows your
> cache to get bogus spoofed replies from systems you aren't asking
> queries of.
>
> Provided that you are running a recent version of BIND, and that you are
> configuring your named.conf to query from port 53, your DNS server
> should be sending out UDP queries from random, high-numbered ephemeral
> ports. See the Wikipedia article on this, which discusses Linux port
> defaults vs. IANA recommended port range, etc. (as I'm typing this while
> offline). Your server should be sourcing from those random,
> high-numbered ephemeral ports to remote DNS servers' udp/53. Their
> queries should come back from their same udp/53 source to your same
> original high-numbered ephemeral port.
>
> As you should be sending UDP queries from high-numbered ports, and your
> queries are never going to originate from udp/53, so you should never
> get replies destined for your udp/53.
>
> You should absolutely not open your firewall to queries from UDP/53 as
> it is not authoritative and is not an open dns resolving server for the
> Internet (or if it was, you shouldn't be asking questions on here how to
> secure it).
>
> I would configure your firewall to -j DROP and not first -j LOG these
> packets. No need filling up your syslog with bogus queries.
>
> My guess is that there are some poorly configured remote firewal
Re: Bind as cache DNS and firewall
Hi,
I have some more information. I do a tcpdump of incoming packets of the sources
of request on udp 53 from external IPs :
08:29:32.482475 IP 195.176.219.26.62511 > MY.CACHE.DNS.domain: 12614+ PTR?
167.72.97.76.IN-ADDR.ARPA. (43)
08:29:34.333751 IP 195.176.219.26.25840 > MY.CACHE.DNS.domain: 1116+ PTR?
37.146.254.169.IN-ADDR.ARPA. (45)
08:29:42.699256 IP 195.176.219.26.31381 > MY.CACHE.DNS.domain: 21474+ PTR?
125.110.0.10.IN-ADDR.ARPA. (43)
08:29:53.516726 IP 195.176.219.26.57195 > MY.CACHE.DNS.domain: 24503+ PTR?
110.147.178.193.IN-ADDR.ARPA. (46)
08:29:53.915886 IP 195.176.219.26.45779 > MY.CACHE.DNS.domain: 2807+ PTR?
207.45.20.201.IN-ADDR.ARPA. (44)
08:29:54.232617 IP 195.176.219.26.38890 > MY.CACHE.DNS.domain: 6981+ PTR?
1.180.209.163.IN-ADDR.ARPA. (44)
Regards,
David Ulrich
---
e-mail: david.ulr...@siesa.ch
Phone: +41274511962
Sierre-Énergie SA
Rte de l'Industrie 29
CH-3960 Sierre
Le 19 août 2010 à 08:21, Ulrich David a écrit :
> Hi Jason and Robert,
>
> Sorry for my lack of details.
>
> My firewall has stateful inspection enabled for all port :
> iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> I permit all outgoing packet. The opened incoming ports are 22 tcp (for all
> IP), 53 tcp and udp (filtered for my clients IP - they have public IPs...
> so... -).
> I enable LOG for iptables but protect it against DoS. Doing this permit me to
> do some "inspection" :) .
>
> I have a BIND 9.4.3-P5 (running on a linux). It's last stable release on my
> distribution. query-source is not enabled. My configuration is very simple :
> options {
> directory "/var/bind";
> listen-on-v6 { none; };
> listen-on { any; };
>
> allow-query {
> local;
> my-clients;
> my-servers;
> my-private-network;
> };
>
> statistics-file "/var/bind/stats/named.stats";
> version "None of your business";
> blackhole { blacklist; };
> max-cache-size 0;
> recursive-clients 1;
> pid-file "/var/run/named/named.pid";
> };
> I have some zone (in-addr.arpa, . , localhost). I have logging and controls
> block too.
> I can go up to 4000 queries/seconds (a lot of mailservers on my network).
>
> named is running well. But I have some problems with some perharps "bogus"
> authoritative dns (ns51.domaincontrol.com andns52.domaincontrol.com for
> example)... so I decided to see if it's not my configuration which has a
> problem.
>
> Regards,
>
> David
>
>
>
>
> Le 19 août 2010 à 04:23, Jason Roysdon a écrit :
>
>>
>> On 08/18/2010 02:42 PM, Ulrich David wrote:
>>> Hi,
>>>
>>> I'm using Bind as a cache (absolutely not authoritative) DNS for a public
>>> network. I have put a firewall in order to refuse incoming packets from
>>> people not on my network.
>>>
>>> Today, inspecting logs, I see this :
>>>
>>> Aug 18 17:31:44 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=195.176.219.26
>>> DST=MY.CACHE.DNS LEN=69 TOS=00 PREC=0x00 TTL=120 ID=50785 CE PROTO=UDP
>>> SPT=56592 DPT=53 LEN=49
>>> Aug 18 17:31:48 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=195.176.219.26
>>> DST=MY.CACHE.DNS LEN=59 TOS=00 PREC=0x00 TTL=120 ID=23374 PROTO=UDP
>>> SPT=57527 DPT=53 LEN=39
>>> Aug 18 17:31:51 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=207.38.104.93
>>> DST=MY.CACHE.DNS LEN=47 TOS=00 PREC=0x00 TTL=48 ID=48457 CE PROTO=UDP
>>> SPT=32779 DPT=53 LEN=27
>>> Aug 18 17:31:56 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=195.176.219.26
>>> DST=MY.CACHE.DNS LEN=72 TOS=00 PREC=0x00 TTL=120 ID=38433 CE PROTO=UDP
>>> SPT=53494 DPT=53 LEN=52
>>> Aug 18 17:32:00 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=109.164.132.64
>>> DST=MY.CACHE.DNS LEN=60 TOS=00 PREC=0x00 TTL=112 ID=24658 PROTO=UDP
>>> SPT=51908 DPT=53 LEN=40
>>> Aug 18 17:32:04 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=195.176.219.26
>>> DST=MY.CACHE.DNS LEN=69 TOS=00 PREC=0x00 TTL=120 ID=40178 CE PROTO=UDP
>>> SPT=48147 DPT=53 LEN=49
>>> Aug 18 17:32:08 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=213.3.5.3
>>> DST=MY.CACHE.DNS LEN=68 TOS=00 PREC=0x00 TTL=53 ID=15544 PROTO=UDP
>>> SPT=18967 DPT=53 LEN=48
>>>
>>> This traffic came from other DNS server in the world. As it's UDP I think
>>> of UDP queries going from my cache server to other DNS server, and I catch
>>> their UDP responses in the firewall. Is it possible?
>>>
>>> So I should open my firewall for UDP on port 53 for all the world?
>>>
>>> Regards,
>>>
>>> David
>>
>>
>> David,
>>
>> First, double-check that you're on a current BIND release. Second,
>> check that your named.conf doesn't have "query-source" bound to port 53.
>> It's bad to always source your queries from port 53, as it allows your
>> cache to get bogus spoofed replies from systems you aren't asking
>> queries of.
>>
>> Provided that you are running a recent version of BIND, and that you are
>> configuring your named.conf to query from port 53, your DNS server
>> sh
Re: DNS latency!!!
On Aug 16, 2010, at 11:55 , Yohann Lepage wrote: > 2010/8/16 Shiva Raman >> Which is the best method to measure dns latency ? Is there any scripts / >> programs >> available to measure the dns latency directly? I would like to remind people of the most obvious one: dig sh-4.1$ dig localhost ; <<>> DiG 9.7.1-P2 <<>> localhost ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23311 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;localhost. IN A ;; ANSWER SECTION: localhost. 86400 IN A 127.0.0.1 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Aug 18 11:30:12 2010 ;; MSG SIZE rcvd: 43 See the Query time column. Stefan ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
www.ncbi.nlm.nih.gov / pubmed
All, It seems this zone is broken as of a couple of days ago. Is anyone else seeing it? Is there an appropriate bind workaround? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: www.ncbi.nlm.nih.gov / pubmed
It comes right up in Firefox but prompts for a username and password. Dig shows: dig www.ncbi.nlm.nih.gov ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> www.ncbi.nlm.nih.gov ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22983 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.ncbi.nlm.nih.gov. IN A ;; ANSWER SECTION: www.ncbi.nlm.nih.gov. 600 IN CNAME www.wip.ncbi.nlm.nih.gov. www.wip.ncbi.nlm.nih.gov. 30IN A 130.14.29.110 ;; AUTHORITY SECTION: wip.ncbi.nlm.nih.gov. 3600IN NS gslb03.nlm.nih.gov. wip.ncbi.nlm.nih.gov. 3600IN NS gslb01.nlm.nih.gov. wip.ncbi.nlm.nih.gov. 3600IN NS gslb02.nlm.nih.gov. ;; Query time: 84 msec ;; SERVER: 10.0.4.99#53(10.0.4.99) ;; WHEN: Wed Aug 18 08:14:44 2010 ;; MSG SIZE rcvd: 139 -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of Phil Mayers Sent: Wednesday, August 18, 2010 6:49 AM To: bind-users@lists.isc.org Subject: www.ncbi.nlm.nih.gov / pubmed All, It seems this zone is broken as of a couple of days ago. Is anyone else seeing it? Is there an appropriate bind workaround? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users Proud partner. Susan G. Komen for the Cure. Please consider our environment before printing this e-mail or attachments. -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: www.ncbi.nlm.nih.gov / pubmed
On 18/08/10 13:30, Phil Mayers wrote: On 18/08/10 13:15, Lightner, Jeff wrote: It comes right up in Firefox but prompts for a username and password. Do you have DNSSEC validation enabled? Because as per my email, it's a DNSSEC problem. Damn - in fact sorry, scratch that. I realise my original email said nothing of the sort! I blame the stress of moving house ;o) After a bit of investigation, it seems that the problem is a missing NSEC/NSEC3 record in the empty reply for: $ dig +dnssec @165.112.4.230 ncbi.nlm.nih.gov ds ...since the "ncbi" zone is an unsigned child zone, there needs to be an NSEC/NSEC3 record to prove the absence of the DS record, and have a secure delegation to an unsigned child zone. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: www.ncbi.nlm.nih.gov / pubmed
On 18/08/10 13:15, Lightner, Jeff wrote: It comes right up in Firefox but prompts for a username and password. Do you have DNSSEC validation enabled? Because as per my email, it's a DNSSEC problem. After a bit of investigation, it seems that the problem is a missing NSEC/NSEC3 record in the empty reply for: $ dig +dnssec @165.112.4.230 ncbi.nlm.nih.gov ds ...since the "ncbi" zone is an unsigned child zone, there needs to be an NSEC/NSEC3 record to prove the absence of the DS record, and have a secure delegation to an unsigned child zone. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: www.ncbi.nlm.nih.gov / pubmed
On 18.08.2010 14:31, Phil Mayers wrote: > After a bit of investigation, it seems that the problem is a missing > NSEC/NSEC3 record in the empty reply for: > > $ dig +dnssec @165.112.4.230 ncbi.nlm.nih.gov ds > > ...since the "ncbi" zone is an unsigned child zone, there needs to be an > NSEC/NSEC3 record to prove the absence of the DS record, and have a > secure delegation to an unsigned child zone. I think the problem is already in the nlm.nih.gov zone. nih.gov contains DS records for nlm.nih.gov, but the zone itself is not signed. dig +dnssec nlm.nih.gov ds @ns.nih.gov. -> signed DS records dig +dnssec nlm.nih.gov soa @ns.nih.gov. -> unsigned response Validating resolvers thus reject the unsigned answer: "nlm.nih.gov SOA: got insecure response; parent indicates it should be secure" According to the SOA, nlmdnshostmas...@mail.nih.gov is the appropriate contact address. I'll put them in Cc. Hauke. signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: www.ncbi.nlm.nih.gov / pubmed
No problem. We haven't enabled DNSSEC here yet. Man for dig says: "+[no]cdflag Set [do not set] the CD (checking disabled) bit in the query. This requests the server to not perform DNSSEC validation of responses." Below are the digs with the +cdflag and +nocdflag: dig +cdflag www.ncbi.nlm.nih.gov ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> +cdflag www.ncbi.nlm.nih.gov ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13903 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.ncbi.nlm.nih.gov. IN A ;; ANSWER SECTION: www.ncbi.nlm.nih.gov. 600 IN CNAME www.wip.ncbi.nlm.nih.gov. www.wip.ncbi.nlm.nih.gov. 30IN A 130.14.29.110 ;; AUTHORITY SECTION: wip.ncbi.nlm.nih.gov. 2059IN NS gslb01.nlm.nih.gov. wip.ncbi.nlm.nih.gov. 2059IN NS gslb02.nlm.nih.gov. wip.ncbi.nlm.nih.gov. 2059IN NS gslb03.nlm.nih.gov. ;; Query time: 48 msec ;; SERVER: 10.0.4.99#53(10.0.4.99) ;; WHEN: Wed Aug 18 08:40:25 2010 ;; MSG SIZE rcvd: 139 dig +nocdflag www.ncbi.nlm.nih.gov ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> +nocdflag www.ncbi.nlm.nih.gov ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30098 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.ncbi.nlm.nih.gov. IN A ;; ANSWER SECTION: www.ncbi.nlm.nih.gov. 597 IN CNAME www.wip.ncbi.nlm.nih.gov. www.wip.ncbi.nlm.nih.gov. 27IN A 130.14.29.110 ;; Query time: 5 msec ;; SERVER: 10.0.4.99#53(10.0.4.99) ;; WHEN: Wed Aug 18 08:40:29 2010 ;; MSG SIZE rcvd: 76 -Original Message- From: Phil Mayers [mailto:p.may...@imperial.ac.uk] Sent: Wednesday, August 18, 2010 8:31 AM To: Lightner, Jeff Cc: bind-users@lists.isc.org Subject: Re: www.ncbi.nlm.nih.gov / pubmed On 18/08/10 13:30, Phil Mayers wrote: > On 18/08/10 13:15, Lightner, Jeff wrote: >> It comes right up in Firefox but prompts for a username and password. > > Do you have DNSSEC validation enabled? Because as per my email, it's a > DNSSEC problem. Damn - in fact sorry, scratch that. I realise my original email said nothing of the sort! I blame the stress of moving house ;o) > > After a bit of investigation, it seems that the problem is a missing > NSEC/NSEC3 record in the empty reply for: > > $ dig +dnssec @165.112.4.230 ncbi.nlm.nih.gov ds > > ...since the "ncbi" zone is an unsigned child zone, there needs to be an > NSEC/NSEC3 record to prove the absence of the DS record, and have a > secure delegation to an unsigned child zone. Proud partner. Susan G. Komen for the Cure. Please consider our environment before printing this e-mail or attachments. -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: www.ncbi.nlm.nih.gov / pubmed
On Wed, Aug 18, 2010 at 5:30 AM, Phil Mayers wrote: > > After a bit of investigation, it seems that the problem is a missing > NSEC/NSEC3 record in the empty reply for: > > $ dig +dnssec @165.112.4.230 ncbi.nlm.nih.gov ds > > ...since the "ncbi" zone is an unsigned child zone, there needs to be an > NSEC/NSEC3 record to prove the absence of the DS record, and have a secure > delegation to an unsigned child zone. > The problem was that three out of the five servers authoritative for nlm.nih.gov were serving a version of the zone that did not include DNSKEY RRs or any other DNSSEC-required RRs (RRSIG, NSEC3, etc). If your resolver queried any of those three it got a response, but it was incomplete. This has been a fairly common problem among new DNSSEC deployments. Sometimes the problem is a slave that is not DNSSEC capable. Sometimes it's a slave not NSEC3-capable serving a zone signed with NSEC3 (which creates the issue for insecure delegations). In this case, I'm pretty sure the servers are capable of DNSSEC because they are serving the signed nih.gov zone just fine, so perhaps they got their nlm.nih.gov zone data from the wrong place. Often, BIND users don't notice these types of errors because BIND makes a special effort to find a valid response, if validation is enabled. However, if your validating server is behind an upstream proxy DNS recursive server, you may not have that choice. Likewise, a zone may not have the redundancy administrators think it has if you're only getting valid DNSSEC responses from a fraction of your authoritative servers. Regards, Casey ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: «tsig verify failure» only on some zones
On Wed, Aug 18, 2010, at 00:42:40AM GMT+02:00, Hauke Lampe wrote: What TSIG algorithms do you use and how long are the keys? HMAC-MD5, 128 bit. The keys are 24 chars long. I'll try to test with another algorithm, however I find it quite strange; if it works for some zones, why doesn't it work for the others? It could be that you hit an interoperability bug in BIND that was fixed in 9.7.0, although it doesn't fit the symptoms exactly: I see. No, it doesn't seem like the same symptoms. I could of course try to downgrade NS3, or upgrade the two other, but I'd consider that as a last-resort solution. -- Joachim ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Rebinding Prevention for the Weak Host Model Attacks
deny-answer-addresses { %source%; };
deny-answer-aliases { %source%; };
Maybe?
- Kevin
On 8/17/2010 12:22 AM, Bradley Falzon wrote:
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 ?
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: www.ncbi.nlm.nih.gov / pubmed
On 8/18/2010 8:30 AM, Phil Mayers wrote: On 18/08/10 13:15, Lightner, Jeff wrote: It comes right up in Firefox but prompts for a username and password. Do you have DNSSEC validation enabled? Because as per my email, it's a DNSSEC problem. After a bit of investigation, it seems that the problem is a missing NSEC/NSEC3 record in the empty reply for: $ dig +dnssec @165.112.4.230 ncbi.nlm.nih.gov ds ...since the "ncbi" zone is an unsigned child zone, there needs to be an NSEC/NSEC3 record to prove the absence of the DS record, and have a secure delegation to an unsigned child zone. It sounds to me like DNSSEC validation is working as designed. If your DNS server's users are complaining about not being able to resolve something that fails validation, the question you need to ask is do your end-users really want you to do DNSSEC validation for them? If you're asking for a workaround for when validation fails, there's not much point to doing the validation. -- Dave ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: www.ncbi.nlm.nih.gov / pubmed
On Wed, Aug 18, 2010 at 9:48 AM, Dave Sparro wrote: > On 8/18/2010 8:30 AM, Phil Mayers wrote: >> >> ...since the "ncbi" zone is an unsigned child zone, there needs to be an >> NSEC/NSEC3 record to prove the absence of the DS record, and have a >> secure delegation to an unsigned child zone. > > > It sounds to me like DNSSEC validation is working as designed. If your DNS > server's users are complaining about not being able to resolve something > that fails validation, the question you need to ask is do your end-users > really want you to do DNSSEC validation for them? > > If you're asking for a workaround for when validation fails, there's not > much point to doing the validation. > Insecure delegations are not a work-around, but are rather a provision for delegated child zones that have not implemented DNSSEC. The parent zone (and its authoritative servers) must be properly configured to handle authenticated denial of existence using NSEC or NSEC3. Specifically, they must use these RRs to prove the non-existence of a DS RR for an unsigned child zone, whose existence would otherwise indicate a secure delegation. If the proper NSEC/NSEC3 RRs are not returned, or are not thought to be authentic, then there is a broken chain because the resolver cannot prove that the delegation is insecure. In the following diagram, note the diamond-shaped NSEC3 node, whose presence (when properly authenticated) proves the insecure delegation to ncbi.nlm.nih.gov: http://dnsviz.net/d/www.ncbi.nlm.nih.gov/dnssec/ Regards, Casey ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: www.ncbi.nlm.nih.gov / pubmed
On 8/18/2010 1:12 PM, Casey Deccio wrote: On Wed, Aug 18, 2010 at 9:48 AM, Dave Sparro wrote: On 8/18/2010 8:30 AM, Phil Mayers wrote: ...since the "ncbi" zone is an unsigned child zone, there needs to be an NSEC/NSEC3 record to prove the absence of the DS record, and have a secure delegation to an unsigned child zone. It sounds to me like DNSSEC validation is working as designed. If your DNS server's users are complaining about not being able to resolve something that fails validation, the question you need to ask is do your end-users really want you to do DNSSEC validation for them? If you're asking for a workaround for when validation fails, there's not much point to doing the validation. Insecure delegations are not a work-around, but are rather a provision for delegated child zones that have not implemented DNSSEC. The parent zone (and its authoritative servers) must be properly configured to handle authenticated denial of existence using NSEC or NSEC3. Specifically, they must use these RRs to prove the non-existence of a DS RR for an unsigned child zone, whose existence would otherwise indicate a secure delegation. If the proper NSEC/NSEC3 RRs are not returned, or are not thought to be authentic, then there is a broken chain because the resolver cannot prove that the delegation is insecure. In the following diagram, note the diamond-shaped NSEC3 node, whose presence (when properly authenticated) proves the insecure delegation to ncbi.nlm.nih.gov: http://dnsviz.net/d/www.ncbi.nlm.nih.gov/dnssec/ It seems to me that the OP wanted a work-around to the fact that his end users couldn't use the website due to a validation failure. It still seems to me that working around that situation misses the point of using DNSSEC. -- Dave ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: www.ncbi.nlm.nih.gov / pubmed
On Wed, Aug 18, 2010 at 10:55 AM, Dave Sparro wrote: > It seems to me that the OP wanted a work-around to the fact that his end > users couldn't use the website due to a validation failure. > It still seems to me that working around that situation misses the point of > using DNSSEC. > I read your response only in the context of the quoted text and didn't notice the text from the original post asking if there was a BIND work-around. Hence my lengthy discourse on insecure delegation... Regarding the "work-around", I'm not sure how BIND's "keep trying" algorithm is currently implemented and if it induces queries to other servers to find NSEC/NSEC3 RRs if they aren't present in the first response accompanying an NXDOMAIN or authoritative response with empty answer section. Regards, Casey ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Bind as cache DNS and firewall
Hi, I'm using Bind as a cache (absolutely not authoritative) DNS for a public network. I have put a firewall in order to refuse incoming packets from people not on my network. Today, inspecting logs, I see this : Aug 18 17:31:44 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=195.176.219.26 DST=MY.CACHE.DNS LEN=69 TOS=00 PREC=0x00 TTL=120 ID=50785 CE PROTO=UDP SPT=56592 DPT=53 LEN=49 Aug 18 17:31:48 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=195.176.219.26 DST=MY.CACHE.DNS LEN=59 TOS=00 PREC=0x00 TTL=120 ID=23374 PROTO=UDP SPT=57527 DPT=53 LEN=39 Aug 18 17:31:51 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=207.38.104.93 DST=MY.CACHE.DNS LEN=47 TOS=00 PREC=0x00 TTL=48 ID=48457 CE PROTO=UDP SPT=32779 DPT=53 LEN=27 Aug 18 17:31:56 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=195.176.219.26 DST=MY.CACHE.DNS LEN=72 TOS=00 PREC=0x00 TTL=120 ID=38433 CE PROTO=UDP SPT=53494 DPT=53 LEN=52 Aug 18 17:32:00 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=109.164.132.64 DST=MY.CACHE.DNS LEN=60 TOS=00 PREC=0x00 TTL=112 ID=24658 PROTO=UDP SPT=51908 DPT=53 LEN=40 Aug 18 17:32:04 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=195.176.219.26 DST=MY.CACHE.DNS LEN=69 TOS=00 PREC=0x00 TTL=120 ID=40178 CE PROTO=UDP SPT=48147 DPT=53 LEN=49 Aug 18 17:32:08 cns1 [IPT DROP] : IN=eth0 OUT= MAC=00 SRC=213.3.5.3 DST=MY.CACHE.DNS LEN=68 TOS=00 PREC=0x00 TTL=53 ID=15544 PROTO=UDP SPT=18967 DPT=53 LEN=48 This traffic came from other DNS server in the world. As it's UDP I think of UDP queries going from my cache server to other DNS server, and I catch their UDP responses in the firewall. Is it possible? So I should open my firewall for UDP on port 53 for all the world? Regards, David ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RRSIGs without DNSKEYs in insecure zone
Using BIND 9.6.2-P2 and 9.7.1.P2 configured for DNSSEC validation with DLV I experience the following issue. When I attempt to resolve www.jobcorps.govI get a SERVFAIL message. The authoritative servers return an RRSIG covering the A RR, but the resolver is unable to validate it because it cannot retrieve the DNSKEYs. The servers are attempting to send packets exceeding their PMTU and they apparently don't accept TCP connections, which means that a resolver can't get a complete response for DNSKEYs. Despite the server misconfigurations, the delegation from .GOV is insecure, so ultimately the result should return a insecure data, rather than failure. Thoughts? Regards, Casey ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RRSIGs without DNSKEYs in insecure zone
On Wed, 18 Aug 2010, Casey Deccio wrote: Using BIND 9.6.2-P2 and 9.7.1.P2 configured for DNSSEC validation with DLV I experience the following issue. When I attempt to resolve www.jobcorps.gov I get a SERVFAIL message. The authoritative servers return an RRSIG covering the A RR, but the resolver is unable to validate it because it cannot retrieve the DNSKEYs. The servers are attempting to send packets exceeding their PMTU and they apparently don't accept TCP connections, which means that a resolver can't get a complete response for DNSKEYs. Despite the server misconfigurations, the delegation from .GOV is insecure, so ultimately the result should return a insecure data, rather than failure. Thoughts? If the domain is in the DLV, then it is treated as having a secure entry point just as if the parent had a DS record, and any missing DNSKEY's is considered a downgrade attack to lure you into spoofed faked data. Paul ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RRSIGs without DNSKEYs in insecure zone
On Wed, Aug 18, 2010 at 4:33 PM, Paul Wouters wrote: > On Wed, 18 Aug 2010, Casey Deccio wrote: > > Using BIND 9.6.2-P2 and 9.7.1.P2 configured for DNSSEC validation with DLV >> I experience the following issue. When I >> attempt to resolve www.jobcorps.gov I get a SERVFAIL message. The >> authoritative servers return an RRSIG covering the >> A RR, but the resolver is unable to validate it because it cannot retrieve >> the DNSKEYs. The servers are attempting to >> send packets exceeding their PMTU and they apparently don't accept TCP >> connections, which means that a resolver can't >> get a complete response for DNSKEYs. >> >> Despite the server misconfigurations, the delegation from .GOV is >> insecure, so ultimately the result should return a >> insecure data, rather than failure. Thoughts? >> > > If the domain is in the DLV, then it is treated as having a secure entry > point just as if the parent had a DS record, and any missing DNSKEY's > is considered a downgrade attack to lure you into spoofed faked data. > > True, but only .GOV is registered in the DLV, jobcorps.gov is not. Incidentally, unbound returns an insecure response for this. Regards, Casey ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Rebinding Prevention for the Weak Host Model Attacks
I am looking at the deny-answer-* section for this, but we just need
to ensure we minimally affect legitimate applications. This is why I
was proposing we only action when the source is apart of the answer AS
WELL as another answer. Blocking based on just the source would affect
dyn-dns type applications when resolving from the source network - as
well as other applications, such as domain controllers, that maybe
querying then finding out it is themselves.
My concern is breaking current applications, for example, let's assume
example.com has dc1.example.com and dc2.example.com. Both of these
being Windows Domain Controllers. If dc1.example.com queries for the
round-robin address dc.example.com it may result in dc1.example.com
and dc2.example.com being in the answer - my proposed logic would
SERVFAIL that.
>From my understanding though, Windows DC's are usually deployed
managing their own DNS, so I don't think this would normally happen -
but - is there an example where this is widely deployed and possible
to impact applications ?
If it can impact applications, but it's very small, an opt-out service
could be possible. Alternatively, simply logging maybe good enough.
But I still feel within bind would be a great place for this checking
to occur.
On Thu, Aug 19, 2010 at 1:51 AM, Kevin Darcy wrote:
> deny-answer-addresses { %source%; };
> deny-answer-aliases { %source%; };
>
> Maybe?
>
> - Kevin
>
> On 8/17/2010 12:22 AM, Bradley Falzon wrote:
>>
>> 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 ?
>>
>>
>
>
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
--
Bradley Falzon
b...@teambrad.net
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
