re: .prod issues
I have a subdomain prod.mydomain.com today all of our internal resources that use this prod subdomain stopped being able to reach eachother. I believe the issue is related to the release of .prod as a TLD. Is there a way I can block this TLD or point it back to my environment? Currently, I have added mdots:2 to resolv.conf as a workaround. i think you probably mean ndots not mdots. that's a fine workaround as long as you control all your stub resolvers (which is where the ndots logic runs) and they are all running the BIND stub resolver (for which ndots is a unique feature; see RFC 1535 for the history). a likely better workaround is to use DNS RPZ (so, you'll need BIND 9.9 or later on your recursive servers) and put in a local rule like *.PROD CNAME . to cause all of the search-path logic of all your stub resolvers (whether they have ndots logic, or not) to never see the PROD TLD, and thus, fall through to your local PROD.EXAMPLE.COM names. sadly, i think a lot of people in a lot of places are going to do this to a lot of the new GTLD's. but the new GTLD's have been on greased rails since inception, and no amount of warnings about this kind of damage did more than slow things down briefly. so, the hounds of DNS hell are now loose. good thing we have RPZ i guess. vixie ___ 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: RPZ configuration examples
noting, first: there is documentation online for DNS RPZ, see the following:
https://deepthought.isc.org/article/AA-00525/0/Building-DNS-Firewalls-with-Response-Policy-Zones-RPZ.html
second, as to the particulars:
babu dheen babudh...@yahoo.co.in writes:
We are new to BIND and would like to implement RPZ in BIND. I have a
following queries with respect to RPZ in BIND.
1. Do you have basic example/steps to configure RPZ in Bind? ( I need
couple of examples like /etc/named.conf file and zone files for rpz
in my recursive server's named.conf file, in the options{} block, i have:
response-policy {
zone dns-policy.vix.com;
zone rpz.surbl.org;
zone rpz.spamhaus.org;
zone block.c2.rpz.umbradata.com;
zone hh.c2.rpz.umbradata.com;
zone active.nx.rpz.iidrpz.net;
zone dga.nx.rpz.iidrpz.net;
};
all but the first of these is a slave zone that i subscribe to. the first
one is my local policy, and that zone looks like:
$TTL 30
@ SOA nsa.vix.com. hostmaster.vix.com. 29 3600 1800 604800 30
NS localhost.
; eric ziegast suggestions
11.156.21.46.32.rpz-ip CNAME *.
96.177.58.207.32.rpz-ip CNAME *.
; pedro bueno suggestions
14.53.199.94.32.rpz-ip CNAME *.
; android market scammer
softthrifty.com CNAME .
*.softthrifty.com CNAME .
; spam houses
*.verticalresponse.com CNAME .
; imports
$INCLUDE drop/drop.inc
$INCLUDE drop/bogons.inc
the two $INCLUDE files are generated by a perl script using data imported
from Team Cymru and Spamhaus. that method is described at in blog post at:
http://www.circleid.com/posts/using_domain_filtering_to_effect_ip_address_filtering/
drop.inc begins as follows:
24.0.140.196.109.rpz-ip CNAME .
*.140.196.109.in-addr.arpa CNAME .
22.0.212.94.109.rpz-ip CNAME .
*.212.94.109.in-addr.arpa CNAME .
*.213.94.109.in-addr.arpa CNAME .
*.214.94.109.in-addr.arpa CNAME .
*.215.94.109.in-addr.arpa CNAME .
bogons.inc begins as follows:
8.0.0.0.0.rpz-ip CNAME .
*.0.in-addr.arpa CNAME .
10.0.0.64.5.rpz-ip CNAME .
*.64.5.in-addr.arpa CNAME .
*.65.5.in-addr.arpa CNAME .
*.66.5.in-addr.arpa CNAME .
*.67.5.in-addr.arpa CNAME .
*.68.5.in-addr.arpa CNAME .
*.69.5.in-addr.arpa CNAME .
a copy of the perl script that generates these is online at:
http://nsa.vix.com/~vixie/lasso2rpz.pl
2. If I use RPZ, recursive DNS will contact remote RBL database for
every DNS query?
no. all RPZ control plane information is held locally in the recursive
server. per the specification at:
https://deepthought.isc.org/article/AA-00512/0
we see this text:
A DNS Response Policy Zone (RPZ) is a DNS zone, and as such its
contents can be transferred between servers (DNS AXFR/IXFR),
protected by transaction signatures (DNS TSIG), and expedited by
real time change notifications (DNS NOTIFY), all subject to
familiar DNS access controls. An RPZ usually does not support query
access since it is never required for correct operation. Rather it
is the zone transfer of RPZ content from producers to subscribers
which effectively publishes the policy data, and it is the
transferee's server configuration which promotes RPZ payload data
into DNS control plane data.
3. Is it possible to download DNS RBLs locally on the DNS server
automatically daily and then allow RPZ query locally to give malware
domain lookup response?
yes. that is one of the intended uses of DNS RPZ.
If you can help on this, it will be very much helpful to understand
and implement RPZ in our enterprise.
while this discussion is on-topic for bind-us...@isc.org (here), there
is also a mailing list specific to DNS RPZ. to subscribe, visit:
https://lists.isc.org/mailman/listinfo/dnsrpz-interest
noting, again: there is documentation online for DNS RPZ, see the following:
https://deepthought.isc.org/article/AA-00525/0/Building-DNS-Firewalls-with-Response-Policy-Zones-RPZ.html
thank you for your interest in DNS RPZ.
--
Paul Vixie
KI6YSY
___
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: disable dnssec in bind resolver
Doug Barton do...@dougbarton.us writes: I have a guess at why ISC would want to enable it by default, and even in the presence of an option to turn it off I'm still Ok with that default. But if it's not a standards requirement to have it on, giving the admin a choice would be a welcome thing. this was, as you pointed out, a controversial decision. BIND implements the DO bit as this requestor will not vomit or crash if you include DNSSEC metadata in the response. we believe that this supports the eventual goal of near-universal DNSSEC deployment, in which it's foolish to treat DO as this requestor is explicitly interested in DNSSEC metadata on this answer. the earlier we face the UDP fragmentation pain, the smaller that pain will have been by the time we overcome it. same thing for validator bugs, zone signing/resigning errors/expirations, and everything else that makes always set DO seem unattractive today, to today's sysadmins, who aren't involved in any DNSSEC deployment crusade and don't appreciate being co-opted for it. unless a new IETF RFC comes along and disambiguates the meaning of DO such that it's only to be set if the requestor thinks it has a reasonable shot at validating the resulting metadata, i expect BIND to keep setting DO on all EDNS requests it generates. and i don't think you can make a _public benefit_ argument that this is wrong even though there are _private benefit_ arguments. -- Paul Vixie KI6YSY ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: disable dnssec in bind resolver
Doug Barton do...@dougbarton.us writes: On 06/04/10 19:40, Paul Vixie wrote: ... unless a new IETF RFC comes along and disambiguates the meaning of DO such that it's only to be set if the requestor thinks it has a reasonable shot at validating the resulting metadata, i expect BIND to keep setting DO on all EDNS requests it generates. and i don't think you can make a _public benefit_ argument that this is wrong even though there are _private benefit_ arguments. ... With my business hat on though I can see at least 2 possible use cases for DO=0. The first being related to this thread, I can't/won't fix/remove the firewall today, I just want my resolver to work. it works. it's just slower because it has to fall back. this is one of the reasons we fall back to BUFSIZE=512 before falling all the way back to DNS (that is, turning EDNS off all together.) The hapless user in that spot is either going to use another vendor, or go back to the old version of BIND that works. I know market share isn't a _primary_ concern for BIND, but I would argue that the go back to old version answer to this dilemma is something that we should all be concerned about. that's been *very* rare on this point. ISC is concerned about relevance, since we don't want to develop stuff that folks don't want to use. that's *not* happening en masse in this case. ... In all fairness, I don't have any actual clients telling me that DO=1 is a problem for them, this is pure speculation on my part; ... yes, i know that, because i'd see the other side of it if it was going on. -- Paul Vixie KI6YSY ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
[no subject]
Chris Thompson c...@cam.ac.uk writes: Nothing that I can see. Maybe dnsviz can't cope with multiple PTR records in an RRset, as your first case has? (On the other hand it handles multiple A records in forward zones OK.) to be fair, multiple PTR RRs is something we added in BIND gethostbyaddr() in more or less direct contravention to RFC 1034. if dnsviz doesn't handle it (and i don't know if it doesn't) then it's not dnsviz's fault at all since the DNS RFC's say that there will only be one PTR RR at an in-addr. -- Paul Vixie KI6YSY ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
