Re: Block some users with Bind9
On 7/24/2012 8:32 PM, Emiliano Vazquez wrote: Hi to everyone! I'm stuck with this! I need to do the following but i did not find the real solution. My problem: I need to block some IPs from the LAN to specific places, like Facebook.com I do this with Squid but https transport is encripted and never goes to Squid. There are some news about interception of this port (443) but this is un newers version of squid (3.2.x) I wan't know if you know some tipe of configuration of Bind9 to do something like OpenDNS who give us this solution. I need to do: IP 192.168.1.10 Block access to https://www.facebook.com http://www.facebook.com IP 192.168.1.11 Full access without limitations. IP 192.168.1.12 Block access to https://www.gmail.com http://www.gmail.com I follow the instructions from this link http://www.deer-run.com/~hal/sysadmin/dns-advert.html and get it working but the DNS act for all the machines in the network. It's possible to make what i wan't to do? Best regards and thanks for share your time. Emiliano. well on a dns level will be nice to block it but if the user will have access to some dns anywhere in the world in any way he can just use some basic browser tricks to make this dns setup stupid. i think it's better to use a proxy\fw to block these sites. you can use let say squid and use some nice and good acls to do all your the tricks you need. Regards, Eliezer -- Eliezer Croitoru https://www1.ngtech.co.il IT consulting for Nonprofit organizations eliezer at ngtech.co.il ___ 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: Filtering IPv6 AAAA records?
On Tue, Jul 24, 2012 at 07:06:09PM +0100, Paul Reilly parei...@tcd.ie wrote a message of 61 lines which said: Is it possible using the BIND resolver to filter out record replies to end clients? It's probably less work to actually enable IPv6 access... In 2012, this is not even a big achievment. ___ 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: Filtering IPv6 AAAA records?
Thanks all - the filter--on-v4 has worked well in testing. In terms of why? we do actually have native IPv6 upstream, and some parts of the network are fully IPv6 enabled, and access the internet on IPv6. But some areas are only IPv4. I need to make sure these IPv4 only parts of the network do not try and access IPv6 internet hosts - as they are blocked at the firewall. Paul ___ 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: Filtering IPv6 AAAA records?
Dne 25.7.2012 12:01, Paul Reilly napsal(a): I need to make sure these IPv4 only parts of the network do not try and access IPv6 internet hosts - as they are blocked at the firewall Then you should not send IPv6 router advertisments to v4only part of the network. Disabling responses is just workaround, you should fix your network. -- Ondřej Caletka smime.p7s Description: Elektronický podpis S/MIME ___ 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: Filtering IPv6 AAAA records?
In message CAEBgQMzfH2kvc7zYNi=edewwq_tjjf8ofm9gkrq-3m7obqi...@mail.gmail.com , Paul Reilly writes: Thanks all - the filter--on-v4 has worked well in testing. In terms of why? we do actually have native IPv6 upstream, and some parts of the network are fully IPv6 enabled, and access the internet on IPv6. But some areas are only IPv4. I need to make sure these IPv4 only parts of the network do not try and access IPv6 internet hosts - as they are blocked at the firewall. Then please make sure that the firewall returns ICMPv6 unreachables or spoofs RST for TCP. Just dropping packets is guarenteed to result in bad behaviour. Paul -- 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: Block some users with Bind9
El 24/07/12 22:38, Michael Hoskins (michoski) escribió: I would try using RPZ with a combination of views and match-clients. http://jpmens.net/2011/04/26/how-to-configure-your-bind-resolvers-to-lie-us ing-response-policy-zones-rpz/ Thanks for the link! i will read and post the results. Best regards. -- Emiliano Vazquez | PcCentro Informatica CCTV Office: +54 (11) 4951-0203 Interno 4 Movil: 011-15-6253-7165 Mail: emilianovazq...@gmail.com Web: http://www.pccentro.com.ar ___ 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: Block some users with Bind9
well on a dns level will be nice to block it but if the user will have access to some dns anywhere in the world in any way he can just use some basic browser tricks to make this dns setup stupid. i think it's better to use a proxy\fw to block these sites. you can use let say squid and use some nice and good acls to do all your the tricks you need. Regards, Eliezer My idea was block all DNS except the bind9 who has this filter. blocking port 53 will we enought? I'm using squid but in transparent mode. I'm reading about this. If i find the solution i will post. Have a lot of work to read! Best regards. -- Emiliano Vazquez | PcCentro Informatica CCTV Office: +54 (11) 4951-0203 Interno 4 Movil: 011-15-6253-7165 Mail: emilianovazq...@gmail.com Web: http://www.pccentro.com.ar ___ 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
Journal File Question
Is it possible to restore a zone file from its associated journal file? The docs seem to indicate that a restart of bind will sync the two files, but in practice I get such as this: zone foo.bar/IN: journal rollforward failed: journal out of sync with zone The problem here is that a large portion of the zone file was accidentally deleted. I'm running BIND 9.7.0-P1 Kind Regards, Chris ___ 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: Nintendo('s NSes) are asking my IP for it's rdns
On 24/07/12 14:30, Brian J. Murrell wrote: Why? I mean other than a knee-jerk reaction to that behavior not (yet) being documented in an RFC somewhere? I mean for practical purposes why is what they are (or rather, could be, assuming my suggestion about what they could be doing is correct) doing necessarily bad? The obvious implication of that behaviour is lots of DNS packets to IPs around the world that may not be (probably *are* not) running a DNS server. Based on the numbers coming in and out of my own resolvers (which aren't even that busy), suffice to say I think that traffic would be at best problematic, and at worst harmful. I can think of a bunch of ways this might cause problems, but frankly I lack the energy to get into a discussion about it. Maybe others are more interested ;o) DNS is well-specified in the RFCs. Sure. So there is no room for expansion? Absolutely. I look forward to the internet draft ;o) In all seriousness, I don't dismiss that the behaviour *could* be useful. I just think that, in general, sending unsolicited requests to unknown IP addresses, on a well-known protocol/port is sub-optimal. ___ 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: Journal File Question
Chris wrote on 07/25/2012 09:04:49 AM: Is it possible to restore a zone file from its associated journal file? No. The journal file only records updates to the zone. At best you would only recover the changes since last commit to the zone file. The docs seem to indicate that a restart of bind will sync the two files, but in practice I get such as this: It doesn't sync the files to make two equal copies. It applies all of the outstanding transactions in the journal file to the zone file and then empties the journal. zone foo.bar/IN: journal rollforward failed: journal out of sync with zone Yep, the journal is out of sync because the zone file is non-existent. The problem here is that a large portion of the zone file was accidentally deleted. Oops. That's what backups are for. Slaves are not backups. However, you might be able to extract some meaningful data from the slave's zone file. It won't be pretty though. Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ 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: Journal File Question
On Jul 25, 2012, at 7:25 AM, wbr...@e1b.org wrote: Chris wrote on 07/25/2012 09:04:49 AM: Is it possible to restore a zone file from its associated journal file? No. The journal file only records updates to the zone. At best you would only recover the changes since last commit to the zone file. The docs seem to indicate that a restart of bind will sync the two files, but in practice I get such as this: It doesn't sync the files to make two equal copies. It applies all of the outstanding transactions in the journal file to the zone file and then empties the journal. I don't believe that is entirely correct. The journal file needs to be retained to support ixfrs. My understanding is that it will be automatically trimmed to max-journal-size, if that option is set. Chris Buxton BlueCat Networks ___ 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: Journal File Question
The problem here is that a large portion of the zone file was accidentally deleted. If you have a backup of the zone file from not too long ago (maybe a copy on a slave server?), then that plus the journal file could be enough to get all the data back. The journal will usually contain records of many updates, typically back to your last rndc freeze. As long as you have a zone file that has a serial number recorded in the journal file, it'll be able to start from there and bring the file up to date. But if you have no backups, or if the backup is from before the journal file was last purged, then there's not much you can do. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: dig: Transfer failed
Check the 'allow-transfer' option in your named.conf. I don't have this option. Should I include it? Thanks ___ 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: Journal File Question
Chris Buxton chris.p.bux...@gmail.com wrote on 07/25/2012 12:07:22 PM: It doesn't sync the files to make two equal copies. It applies all of the outstanding transactions in the journal file to the zone file and then empties the journal. I don't believe that is entirely correct. The journal file needs to be retained to support ixfrs. My understanding is that it will be automatically trimmed to max-journal-size, if that option is set. Do you know how it determines what is kept? Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ 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
DNSSEC troubles (no valid NSEC) ?
I solve problem with delivering mail to address x...@br.ds.mfcr.cz.
MTA obviously isn't able resolve MX records for this domain.
dig @localhost -t MX br.ds.mfcr.cz ends with SERVFAIL error:
; DiG 9.7.4-P1-RedHat-9.7.4-2.P1.fc14 @localhost -t MX br.ds.mfcr.cz
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 43325
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;br.ds.mfcr.cz. IN MX
;; Query time: 4219 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jul 25 15:51:56 2012
;; MSG SIZE rcvd: 31
and in BIND (v9.7.4 i686) log are after this query three records:
error (no valid NSEC) resolving 'br.ds.mfcr.cz/MX/IN': 80.95.254.4#53
error (no valid NSEC) resolving 'br.ds.mfcr.cz/MX/IN': 193.86.123.22#53
error (no valid NSEC) resolving 'br.ds.mfcr.cz/MX/IN': 193.86.123.21#53
I tried find some info about this error message, but without luck.
Problem will be perhaps something with DNSSEC. What is interesting,
BIND v9.9.1, essentially with the same configuration (relevant
options paragraph part of named.conf is in both:
allow-query { localhost; };
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
bindkeys-file /etc/named.iscdlv.key;
managed-keys-directory /var/named/dynamic;
)
queried MX records solve without problems.
It is older version BIND problem?
Or it is fault at DNS server (ns1.mfcr.cz) site?
Is possible solve this issue with some BIND configuration changes
(but keeping DNSSEC validation)?
Is there some tool for a DNSSEC domain records validation?
Thanks in advance, Franta
___
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: DNSSEC troubles (no valid NSEC) ?
Frantisek Hanzlik fra...@hanzlici.cz wrote: ; DiG 9.7.4-P1-RedHat-9.7.4-2.P1.fc14 @localhost -t MX br.ds.mfcr.cz ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 43325 Problem will be perhaps something with DNSSEC. What is interesting, BIND v9.9.1, essentially with the same configuration queried MX records solve without problems. It is older version BIND problem? Either that, or RedHat's patches are broken. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Cromarty, Forth, Tyne, Dogger: Variable, becoming southeast 3 or 4, occasionally 5 in Cromarty. Smooth or slight. Mainly fair, showers and fog patches developing later. Moderate or good, occasionally very poor later. ___ 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
global forwarders - current BIND9 behaviour documentation
Hi, anybody there who can provide a definitive answer on the current BIND 9.7 (or higher) global forwarder behaviour? I did find the following info before on using multiple forwarders: https://lists.isc.org/pipermail/bind-users/2007-September/067830.html My expectation based on that is that the fastest responding forwarder will basically always be used until a timeout may occur, i.e. when specifying three forwarders one will be the prefered one based on SRTT and the others are only used if the prefered one goes down. First of all when doing 'rndc dumpdb -all' I cannot find my forwarders' IP addresses in the named_dump.db at all as explained in the posting above (BIND 9.7.3-P3 on Linux), so I cannot verify the SRTTs. 'rndc stats' / named.stats does not show any info on the forwarders as well. Also by doing a tcpdump I can see that all three forwarders I have specified are constantly used. However it is not a real round-robin but roughly a 3:2:1 ratio instead (i.e. one receives approx 3 times the number of queries compared to the third one, the other one receives 2 times the number of queries compared to the 3rd one). In fact the 3:2:1 distribution reflects the response time I can manually determine by running dig against all forwarders - the one which responds quickest gets the most queries and the one which is slowest gets the fewest queries. My server receives quite a few queries (approx 10.000 within a minute). Any idea if the DNS-Server will send every 10th query or so the slower forwarders? I also tried to set the logging level to debug 10 for category resolver but no luck at all in finding out which forwarder is used (and why). So . . . if somebody could explain what the current behaviour is supposed to be that would be helpful. Regards Tom ___ 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: global forwarders - current BIND9 behaviour documentation
All forwarders in the list will tried at least some. Every time the fastest forwarder responds the srtt of the remaining forwarders are decayed. Eventually they will be lower and get tried. If they are slower than the original fastest their srtt go back up and the original will be used again. It's the method for retrying a forwarder after it was set high due to a timeout etc. -Ben Croswell On Jul 25, 2012 2:36 PM, ip admin ipm...@googlemail.com wrote: Hi, anybody there who can provide a definitive answer on the current BIND 9.7 (or higher) global forwarder behaviour? I did find the following info before on using multiple forwarders: https://lists.isc.org/pipermail/bind-users/2007-September/067830.html My expectation based on that is that the fastest responding forwarder will basically always be used until a timeout may occur, i.e. when specifying three forwarders one will be the prefered one based on SRTT and the others are only used if the prefered one goes down. First of all when doing 'rndc dumpdb -all' I cannot find my forwarders' IP addresses in the named_dump.db at all as explained in the posting above (BIND 9.7.3-P3 on Linux), so I cannot verify the SRTTs. 'rndc stats' / named.stats does not show any info on the forwarders as well. Also by doing a tcpdump I can see that all three forwarders I have specified are constantly used. However it is not a real round-robin but roughly a 3:2:1 ratio instead (i.e. one receives approx 3 times the number of queries compared to the third one, the other one receives 2 times the number of queries compared to the 3rd one). In fact the 3:2:1 distribution reflects the response time I can manually determine by running dig against all forwarders - the one which responds quickest gets the most queries and the one which is slowest gets the fewest queries. My server receives quite a few queries (approx 10.000 within a minute). Any idea if the DNS-Server will send every 10th query or so the slower forwarders? I also tried to set the logging level to debug 10 for category resolver but no luck at all in finding out which forwarder is used (and why). So . . . if somebody could explain what the current behaviour is supposed to be that would be helpful. Regards Tom ___ 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
RHEL, Centos, Fedora rpm 9.9.1-P2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://www.five-ten-sg.com/util/bind-9.9.1-0.1.P2.fc18.src.rpm EL4: rpmbuild --rebuild --define 'dist .el4' \ bind-9.9.1-0.1.P2.fc18.src.rpm EL5: rpmbuild --rebuild --define 'dist .el5' \ bind-9.9.1-0.1.P2.fc18.src.rpm EL6: rpmbuild --rebuild --define 'dist .el6' \ bind-9.9.1-0.1.P2.fc18.src.rpm -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAlAQZx4ACgkQL6j7milTFsHnKQCfdeI8jsWzwsgpbPQCD0OMj4mp PPQAoIFLkT1DvlE09USoaefldks+yhmc =WC7K -END PGP 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: Nintendo('s NSes) are asking my IP for it's rdns
I'm assuming this greatunwashed view has recursion turned off, right?
If so, then the following approaches come to mind:
a) create a master zone for 5.37.58.216.in-addr.arpa in the
non-recursive view, putting the PTR record at the apex
b) become a stealth (unpublished) slave for 5.37.58.216.in-addr.arpa
(or its closest-enclosing zone) in the non-recursive view. Your ISP
would need to permit zone transfers to make this approach work
c) define a new view with match-recursive-only and lock it down so
that queries from external address ranges are only allowed for
5.37.58.216.in-addr.arpa (or its closest-enclosing zone), which you
would define as type stub or type forward in that view. Of course,
this method will only work if these Nintendo queries are actually RD=1
(have you verified this?). As a precaution, you might want to
double-check your query logs (or a packet capture) and see if any of the
queries currently being answered successfully from your
non-authoritative view are actually -- and superfluously -- RD=1. If
this is the case, you'll have to either fix the clients, or define the
relevant authoritative zones in *both* views in order to keep those
clients from breaking.
In other words, for approach (c), you might have:
/* our clients, allow to recurse */
view internal_clients {
match-clients { x.x.x/24; }; /* or match-destinations, depending on
your setup */
recursion yes;
...
/* implicit or explicit hints file, forwarders, whatever */
}
/* match only external RD=1 queries, deny everything except some
specific zone(s) */
view slightly_washed_Nintendoids {
match-recursive-only yes;
recursion yes;
allow-query { none; };
zone 37.58.216.in-addr.arpa {
type stub;
file 37.58.216.in-addr.arpa;
allow-query { any; }; /* override view default */
masters { y.y.y.y; }; /* ISP's nameservers */
};
...
/* might need some authoritative-zone definitions here, if you have
misconfigured clients */
...
};
/* match external RD=0 queries, answer from authoritative data only */
view greatunwashed {
recursion no;
/* allow-query-cache { any; }; /* if you prefer to return upwards
referrals rather than REFUSED for queries outside of authoritative data */
...
/* authoritative-zone definitions here */
...
};
- Kevin
On 7/24/2012 7:05 AM, Brian J. Murrell wrote:
I've come across something interesting in my named logs:
00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache)
'5.37.58.216.in-addr.arpa/PTR/IN' denied
00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache)
'5.37.58.216.in-addr.arpa/PTR/IN' denied
00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache)
'5.37.58.216.in-addr.arpa/PTR/IN' denied
00:16:37 named client 205.166.76.12#55728: view greatunwashed: query (cache)
'5.37.58.216.in-addr.arpa/PTR/IN' denied
00:16:37 named client 205.166.76.12#55728: view greatunwashed: query (cache)
'5.37.58.216.in-addr.arpa/PTR/IN' denied
00:16:38 named client 205.166.76.12#55728: view greatunwashed: query (cache)
'5.37.58.216.in-addr.arpa/PTR/IN' denied
where 216.58.37.216 is my IP address, assigned by my ISP and reverse
resolved by my ISP's name servers.
What is interesting is the fact that 205.166.76.12 are asking me
(216.58.37.216) for the PTR for my address.
Is this just broken NS software or are they (Nintendo, FWIW) doing
something interesting, like giving everyone an opportunity to provide
an rdns for their own IP address without everyone having to make
classless in-addr.arpa delegation arrangements with their ISP (which
mine refused to do)?
It's kind of a neat concept if it's not just an accident of broken NS
software.
Has anyone else seen anything like this before? Is there some
(proposed even) standard for doing this that I'm not aware of?
In any case, now to the BIND part. It seems reasonable for me to
answer that query, either with my own data or simply by allowing
that query to recurse.
I suppose I could create a zone for it and put some data in it for
that one record if I wanted to provide my own data. But what if I
just wanted to allow recursive queries on that name so that I simply
returned whatever the proper NSes for it reports? I guess I could add
a zone record for it with a forwarder(s) configured to the name's proper
NSes, yes? But that means me having to maintain those forward records
in tandem with my ISP playing musical NSes (which I don't expect but
why create a possible maintenance headache).
So how could I configure BIND to allow a query for 5.37.58.216.in-
addr.arpa to be recursive for everyone, but of course, continue to
disallow general open recursive querying for names not served here?
Cheers,
b.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this
Re: DNSSEC troubles (no valid NSEC) ?
On Wed, Jul 25, 2012 at 10:07 AM, Frantisek Hanzlik fra...@hanzlici.czwrote: I solve problem with delivering mail to address x...@br.ds.mfcr.cz. MTA obviously isn't able resolve MX records for this domain. dig @localhost -t MX br.ds.mfcr.cz ends with SERVFAIL error: ... and in BIND (v9.7.4 i686) log are after this query three records: error (no valid NSEC) resolving 'br.ds.mfcr.cz/MX/IN': 80.95.254.4#53 error (no valid NSEC) resolving 'br.ds.mfcr.cz/MX/IN': 193.86.123.22#53 error (no valid NSEC) resolving 'br.ds.mfcr.cz/MX/IN': 193.86.123.21#53 The result for br.ds.mfcr.cz/MX is an expansion of a wildcard (*. ds.mfcr.cz/MX). Signed responses that include expanded wildcards require that NSEC(3) RRs are included in the authority section to show that the QNAME (e.g., br.ds.mfcr.cz) doesn't exist, so the wildcard expansion is legitimate. The NSEC3 for the closest encloser of the QNAME is not necessary because it can be inferred from the RRSIG, so only a single NSEC3 is sufficient. However, earlier versions of BIND both served the superfluous NSEC3 and expected it. See this thread, for example: http://dnssec-deployment.org/pipermail/dnssec-deployment/2011-October/005486.html $ dig +dnssec +noall +authority @ns1.mfcr.cz br.ds.mfcr.cz mx mfcr.cz. 10800 IN NS ns1.mfcr.cz. mfcr.cz. 10800 IN NS ns3.mfcr.cz. mfcr.cz. 10800 IN NS ns2.mfcr.cz. mfcr.cz. 10800 IN RRSIG NS 7 2 10800 20120812074507 20120712074507 14339 mfcr.cz. NGNS8CkP5Gg/cvUTsTrxoDuRiGeaoixJ5+optBhK1gRYinpHZ3cx9y/i w5WOAKYy/uOpMhvAiOIzA59yDnGOhG/2ewH/S/G8+TcISBk0//KcYSuf xs7bkBm+YFzVG8YEqwESvKklAkdplraWHH2uxMX4NYBWKeOyjG+PgyW2 AdM= R9UBJMRSM8SMDHCFR97VNPPNVP6GBB2U.mfcr.cz. 3600 IN NSEC3 1 1 10 BDD515FB9B1238C4 RF50NKKASDGSBSRGBI8T72N9EEH5KBIO A RRSIG R9UBJMRSM8SMDHCFR97VNPPNVP6GBB2U.mfcr.cz. 3600 IN RRSIG NSEC3 7 3 3600 20120812074507 20120712074507 14339 mfcr.cz. 2VXv7Hudu2iHjwp75fxv9wwH5CZx35upl/iYfe8HZDHj3badkQbi6CH4 IAyJuOA9gUttoRogXtwCNJV0BwTl5iPlpl/QqEeTu1B7e2oWr829CweK +v42sHh5SuBmaB5rlJS+GhVm6MQe+nqZMe1nG48O1VV2PPGEvETYBI+V SzI= Note that only a NSEC3 RR is returned above. This is correct behavior (though an extra NSEC3 RR shouldn't matter), but the older resolver doesn't handle it well. I tried find some info about this error message, but without luck. Problem will be perhaps something with DNSSEC. What is interesting, BIND v9.9.1, essentially with the same configuration (relevant options paragraph part of named.conf is in both: I don't know what versions it has been fixed in, but I assume at least that this is the bug fix referred to in the changelog for 9.9.0: named now correctly validates DNSSEC positive wildcard responses from NSEC3 signed zones. [RT #26200] [1]. Of course, now there is some mix of older validating BIND resolvers that expect the extra NSEC3 RR and BIND (and other) authoritative server implementations that don't send it. So, this issue might show itself occasionally. Casey [1] https://kb.isc.org/article/AA-00631/0/BIND-9.9.0-Release-Notes.html ___ 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: Block some users with Bind9
On 7/25/2012 3:26 PM, Emiliano Vazquez wrote: well on a dns level will be nice to block it but if the user will have access to some dns anywhere in the world in any way he can just use some basic browser tricks to make this dns setup stupid. i think it's better to use a proxy\fw to block these sites. you can use let say squid and use some nice and good acls to do all your the tricks you need. Regards, Eliezer My idea was block all DNS except the bind9 who has this filter. blocking port 53 will we enought? I'm using squid but in transparent mode. I'm reading about this. If i find the solution i will post. Have a lot of work to read! Best regards. block udp dst port 53 is good but you must to take in account that maybe some of your services\servers needs this access for whatever reason there is. if you are using squid in transparent mode it's good enough for basic http blocking. to block HTTPS you will need to force your users to use the proxy server using some WPAD + DHCP \ Group policy. either of them can lead to some problems so you can test it first and see if it's for you. there is an option of SSL-BUMP in squid that can take a lot off but you must install the local root-ca on all the clients computers. i suggest for you to first implement the basic allow\deny acls in squid for the intercepted traffic and later see what is the effect. Regards, Eliezer -- Eliezer Croitoru https://www1.ngtech.co.il IT consulting for Nonprofit organizations eliezer at ngtech.co.il ___ 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: DNSSEC troubles (no valid NSEC) ?
In message CAEKtLiRm=opnrzatdtnhzcgjpol10o9mnjxb_mvkugmukrk...@mail.gmail.com, Casey Deccio writes: On Wed, Jul 25, 2012 at 10:07 AM, Frantisek Hanzlik fra...@hanzlici.czwrote: I solve problem with delivering mail to address x...@br.ds.mfcr.cz. MTA obviously isn't able resolve MX records for this domain. dig @localhost -t MX br.ds.mfcr.cz ends with SERVFAIL error: ... and in BIND (v9.7.4 i686) log are after this query three records: error (no valid NSEC) resolving 'br.ds.mfcr.cz/MX/IN': 80.95.254.4#53 error (no valid NSEC) resolving 'br.ds.mfcr.cz/MX/IN': 193.86.123.22#53 error (no valid NSEC) resolving 'br.ds.mfcr.cz/MX/IN': 193.86.123.21#53 The result for br.ds.mfcr.cz/MX is an expansion of a wildcard (*. ds.mfcr.cz/MX). Signed responses that include expanded wildcards require that NSEC(3) RRs are included in the authority section to show that the QNAME (e.g., br.ds.mfcr.cz) doesn't exist, so the wildcard expansion is legitimate. The NSEC3 for the closest encloser of the QNAME is not necessary because it can be inferred from the RRSIG, so only a single NSEC3 is sufficient. However, earlier versions of BIND both served the superfluous NSEC3 and expected it. See this thread, for example: http://dnssec-deployment.org/pipermail/dnssec-deployment/2011-October/005486.html $ dig +dnssec +noall +authority @ns1.mfcr.cz br.ds.mfcr.cz mx mfcr.cz. 10800 IN NS ns1.mfcr.cz. mfcr.cz. 10800 IN NS ns3.mfcr.cz. mfcr.cz. 10800 IN NS ns2.mfcr.cz. mfcr.cz. 10800 IN RRSIG NS 7 2 10800 20120812074507 20120712074507 14339 mfcr.cz. NGNS8CkP5Gg/cvUTsTrxoDuRiGeaoixJ5+optBhK1gRYinpHZ3cx9y/i w5WOAKYy/uOpMhvAiOIzA59yDnGOhG/2ewH/S/G8+TcISBk0//KcYSuf xs7bkBm+YFzVG8YEqwESvKklAkdplraWHH2uxMX4NYBWKeOyjG+PgyW2 AdM= R9UBJMRSM8SMDHCFR97VNPPNVP6GBB2U.mfcr.cz. 3600 IN NSEC3 1 1 10 BDD515FB9B1238C4 RF50NKKASDGSBSRGBI8T72N9EEH5KBIO A RRSIG R9UBJMRSM8SMDHCFR97VNPPNVP6GBB2U.mfcr.cz. 3600 IN RRSIG NSEC3 7 3 3600 20120812074507 20120712074507 14339 mfcr.cz. 2VXv7Hudu2iHjwp75fxv9wwH5CZx35upl/iYfe8HZDHj3badkQbi6CH4 IAyJuOA9gUttoRogXtwCNJV0BwTl5iPlpl/QqEeTu1B7e2oWr829CweK +v42sHh5SuBmaB5rlJS+GhVm6MQe+nqZMe1nG48O1VV2PPGEvETYBI+V SzI= Note that only a NSEC3 RR is returned above. This is correct behavior (though an extra NSEC3 RR shouldn't matter), but the older resolver doesn't handle it well. I tried find some info about this error message, but without luck. Problem will be perhaps something with DNSSEC. What is interesting, BIND v9.9.1, essentially with the same configuration (relevant options paragraph part of named.conf is in both: I don't know what versions it has been fixed in, but I assume at least that this is the bug fix referred to in the changelog for 9.9.0: And it is fixed in 9.6-ESV-R6, 9.7.5, 9.8.2 so the fix is to upgrade. named now correctly validates DNSSEC positive wildcard responses from NSEC3 signed zones. [RT #26200] [1]. Of course, now there is some mix of older validating BIND resolvers that expect the extra NSEC3 RR and BIND (and other) authoritative server implementations that don't send it. So, this issue might show itself occasionally. Casey [1] https://kb.isc.org/article/AA-00631/0/BIND-9.9.0-Release-Notes.html -- 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: Journal File Question
On Jul 25 2012, wbr...@e1b.org wrote: Chris Buxton chris.p.bux...@gmail.com wrote on 07/25/2012 12:07:22 PM: It doesn't sync the files to make two equal copies. It applies all of the outstanding transactions in the journal file to the zone file and then empties the journal. I don't believe that is entirely correct. The journal file needs to be retained to support ixfrs. My understanding is that it will be automatically trimmed to max-journal-size, if that option is set. Do you know how it determines what is kept? When the journal file reaches the max-journal-size value, roughly the first half of it is discarded. But there are other actions that can discard the whole journal file, such as rndc freeze on a type master zone, rndc retransfer on a type slave one, etc. To find out if a journal file goes back far enough for your purposes, use the named-journalprint utility distributed with BIND. Although I have to say I would hate to be dependent on this way of recovering a lost zone file: you should probably be rethinking your whole backup and recovery strategy. -- Chris Thompson Email: c...@cam.ac.uk ___ 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: Block some users with Bind9
block udp dst port 53 is good but you must to take in account that maybe some of your services\servers needs this access for whatever reason there is. That's true. if you are using squid in transparent mode it's good enough for basic http blocking. to block HTTPS you will need to force your users to use the proxy server using some WPAD + DHCP \ Group policy. either of them can lead to some problems so you can test it first and see if it's for you. there is an option of SSL-BUMP in squid that can take a lot off but you must install the local root-ca on all the clients computers. I read some articles about this but never give a try yet. i suggest for you to first implement the basic allow\deny acls in squid for the intercepted traffic and later see what is the effect. Regards, Eliezer At the moment if i send 443tcp traficc to squid i got and unknow request on access.log. Thanks for your time Eliezer Best regards. -- Emiliano Vazquez | PcCentro Informatica CCTV Office: +54 (11) 4951-0203 Interno 4 Movil: 011-15-6253-7165 Mail: emilianovazq...@gmail.com Web: http://www.pccentro.com.ar ___ 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: Journal File Question
In message prayer.1.3.5.1207260007050.11...@hermes-2.csi.cam.ac.uk, Chris Thompson writes: On Jul 25 2012, wbr...@e1b.org wrote: Chris Buxton chris.p.bux...@gmail.com wrote on 07/25/2012 12:07:22 PM: It doesn't sync the files to make two equal copies. It applies all of the outstanding transactions in the journal file to the zone file and then empties the journal. I don't believe that is entirely correct. The journal file needs to be retained to support ixfrs. My understanding is that it will be automatically trimmed to max-journal-size, if that option is set. Do you know how it determines what is kept? When the journal file reaches the max-journal-size value, roughly the first half of it is discarded. But there are other actions that can discard the whole journal file, such as rndc freeze on a type master zone, rndc retransfer on a type slave one, etc. To find out if a journal file goes back far enough for your purposes, use the named-journalprint utility distributed with BIND. Although I have to say I would hate to be dependent on this way of recovering a lost zone file: you should probably be rethinking your whole backup and recovery strategy. The slaves should have a recent copy of the zone. Just axfr it and use it as the master file. Any untransferred changes will be applied from the journal when named starts. -- Chris Thompson Email: c...@cam.ac.uk ___ 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 -- 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: DNSSEC troubles (no valid NSEC) ?
Casey Deccio wrote: On Wed, Jul 25, 2012 at 10:07 AM, Frantisek Hanzlik fra...@hanzlici.cz mailto:fra...@hanzlici.cz wrote: I solve problem with delivering mail to address x...@br.ds.mfcr.cz mailto:x...@br.ds.mfcr.cz. MTA obviously isn't able resolve MX records for this domain. dig @localhost -t MX br.ds.mfcr.cz http://br.ds.mfcr.cz ends with SERVFAIL error: ... and in BIND (v9.7.4 i686) log are after this query three records: error (no valid NSEC) resolving 'br.ds.mfcr.cz/MX/IN http://br.ds.mfcr.cz/MX/IN': 80.95.254.4#53 error (no valid NSEC) resolving 'br.ds.mfcr.cz/MX/IN http://br.ds.mfcr.cz/MX/IN': 193.86.123.22#53 error (no valid NSEC) resolving 'br.ds.mfcr.cz/MX/IN http://br.ds.mfcr.cz/MX/IN': 193.86.123.21#53 The result for br.ds.mfcr.cz/MX http://br.ds.mfcr.cz/MX is an expansion of a wildcard (*.ds.mfcr.cz/MX http://ds.mfcr.cz/MX). Signed responses that include expanded wildcards require that NSEC(3) RRs are included in the authority section to show that the QNAME (e.g., br.ds.mfcr.cz http://br.ds.mfcr.cz) doesn't exist, so the wildcard expansion is legitimate. The NSEC3 for the closest encloser of the QNAME is not necessary because it can be inferred from the RRSIG, so only a single NSEC3 is sufficient. However, earlier versions of BIND both served the superfluous NSEC3 and expected it. See this thread, for example: http://dnssec-deployment.org/pipermail/dnssec-deployment/2011-October/005486.html $ dig +dnssec +noall +authority @ns1.mfcr.cz http://ns1.mfcr.cz br.ds.mfcr.cz http://br.ds.mfcr.cz mx mfcr.cz http://mfcr.cz.10800INNSns1.mfcr.cz http://ns1.mfcr.cz. mfcr.cz http://mfcr.cz.10800INNSns3.mfcr.cz http://ns3.mfcr.cz. mfcr.cz http://mfcr.cz.10800INNSns2.mfcr.cz http://ns2.mfcr.cz. mfcr.cz http://mfcr.cz.10800INRRSIGNS 7 2 10800 20120812074507 20120712074507 14339 mfcr.cz http://mfcr.cz. NGNS8CkP5Gg/cvUTsTrxoDuRiGeaoixJ5+optBhK1gRYinpHZ3cx9y/i w5WOAKYy/uOpMhvAiOIzA59yDnGOhG/2ewH/S/G8+TcISBk0//KcYSuf xs7bkBm+YFzVG8YEqwESvKklAkdplraWHH2uxMX4NYBWKeOyjG+PgyW2 AdM= R9UBJMRSM8SMDHCFR97VNPPNVP6GBB2U.mfcr.cz http://R9UBJMRSM8SMDHCFR97VNPPNVP6GBB2U.mfcr.cz. 3600 IN NSEC31 1 10 BDD515FB9B1238C4 RF50NKKASDGSBSRGBI8T72N9EEH5KBIO A RRSIG R9UBJMRSM8SMDHCFR97VNPPNVP6GBB2U.mfcr.cz http://R9UBJMRSM8SMDHCFR97VNPPNVP6GBB2U.mfcr.cz. 3600 IN RRSIGNSEC3 7 3 3600 20120812074507 20120712074507 14339 mfcr.cz http://mfcr.cz. 2VXv7Hudu2iHjwp75fxv9wwH5CZx35upl/iYfe8HZDHj3badkQbi6CH4 IAyJuOA9gUttoRogXtwCNJV0BwTl5iPlpl/QqEeTu1B7e2oWr829CweK +v42sHh5SuBmaB5rlJS+GhVm6MQe+nqZMe1nG48O1VV2PPGEvETYBI+V SzI= Note that only a NSEC3 RR is returned above. This is correct behavior (though an extra NSEC3 RR shouldn't matter), but the older resolver doesn't handle it well. I tried find some info about this error message, but without luck. Problem will be perhaps something with DNSSEC. What is interesting, BIND v9.9.1, essentially with the same configuration (relevant options paragraph part of named.conf is in both: I don't know what versions it has been fixed in, but I assume at least that this is the bug fix referred to in the changelog for 9.9.0: named now correctly validates DNSSEC positive wildcard responses from NSEC3 signed zones. [RT #26200] [1]. Of course, now there is some mix of older validating BIND resolvers that expect the extra NSEC3 RR and BIND (and other) authoritative server implementations that don't send it. So, this issue might show itself occasionally. Casey [1] https://kb.isc.org/article/AA-00631/0/BIND-9.9.0-Release-Notes.html !DSPAM:501073e416141991854194! Many thanks for detailed explanation and references. I now compile for my Fedora box version 9.8.2 for Centos 6.3 (including 50 other RedHat patches;) and all seems be OK. Thanks to all for quick responses! ___ 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
