AW: block ddns by name
Hi
Thank you, i think this will do the trick... just have to make sure if the dhcp
uses signed updates or by ip - because it only works with signed updates. I
think it's by ip, since there's no such key config in dhcpd.conf :(
Thanks!
---
Ing. Christian Melbinger
Netzwerk & Security
WienIT EDV Dienstleistungsgesellschaft mbH & Co KG
A-1030 Wien, Thomas-Klestil-Platz 6
tel: +43 (1) 90405 47188
fax: +43 (1) 90405 88 47188
mailto:christian.melbin...@wienit.at
-Ursprüngliche Nachricht-
Von: Tony Finch [mailto:fa...@hermes.cam.ac.uk] Im Auftrag von Tony Finch
Gesendet: Donnerstag, 16. Februar 2012 14:37
An: Melbinger Christian
Cc: bind-users@lists.isc.org
Betreff: Re: block ddns by name
Melbinger Christian wrote:
>
> Does anyone know if there is a way to prevent the creation of certain
> records - by name?
http://ftp.isc.org/isc/bind9/cur/9.7/doc/arm/Bv9ARM.ch06.html#dynamic_update_policies
Based on that, something the following should do what you want:
update-policy {
deny "*" name "internal.example.com";
# ...
};
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Shannon: Westerly or southwesterly 5 or 6, but 4 until later in far south.
Moderate or rough. Occasional rain or drizzle. Moderate or good.
WienIT EDV Dienstleistungsgesellschaft mbH & Co KG, A-1030 Wien,
Thomas-Klestil-Platz 6,
FN 255974h, Handelsgericht Wien, DVR: 2109667, UID-Nr. ATU61260824
Persönlich haftender Gesellschafter:
WienIT EDV Dienstleistungsgesellschaft mbH, A-1030 Wien, Thomas-Klestil-Platz 6,
FN 255649f, Handelsgericht Wien, UID-Nr. ATU61296118
___
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
lists.isc.org rDNS failed, DNSSEC?
Yesterday I looked in mail logs for something else and stumbled upon this (times are UTC): rob0@harrier:~$ grep 'unknown\[149\.20\.64\.75\]' /var/log/maillog | wc 2713607 44087 rob0@harrier:~$ grep 'unknown\[149\.20\.64\.75\]' /var/log/maillog | head -1 Feb 21 05:28:25 harrier postfix/smtpd[4653]: connect from unknown[149.20.64.75] rob0@harrier:~$ grep 'unknown\[149\.20\.64\.75\]' /var/log/maillog | tail -1 Feb 21 21:32:06 harrier postfix/smtpd[3575]: disconnect from unknown[149.20.64.75] During that time I tried a "dig 75.64.20.149.in-addr.arpa. any" and got SERVFAIL. I checked 64.20.149.in-addr.arpa at Sandia's DNSViz, and it was fine. I was in a hurry so I didn't think to check 75.64.20.149.in-addr.arpa. I whitelisted 149.20.64.75 so this list's mail would come through; went on with other things. I was thinking that the problem might have been on my end, but I changed nothing before nor since; 75.64.20.149.in-addr.arpa/IN/PTR since 21:32 UTC yesterday has been returning "lists.isc.org." Any idea (especially from ISC folks) what might have caused this? This is the scary thing about DNSSEC: a lot of valid zones might suffer from temporary glitches wherein signatures fail. I know one of my own zones had expired signatures awhile, and I have seen it with subscribers on my own Mailman lists. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: ___ 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
bind9.9.0rc4 rndc retransfer appears to be fixed
> With the properly patched bind 9.9.0rc3 running, 'rndc retransfer > jaspain.biz' generated no output, presumably indicating success. > The log showed some related error messages, however... > Seems like it is confusing the serial numbers of the signed and unsigned > zones. I installed the bind9.9.0rc4 early release code. I retested a bind10 zone update followed by 'rndc retransfer' on the bind9.9.0rc4 inline signing server. The command executed successfully, there were no errors reported in the log, and the unsigned and signed zone contents as displayed by named-checkzone look as they should. Thanks. Jeff. Jeffry A. Spain Network Administrator Cincinnati Country Day School ___ 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: lists.isc.org rDNS failed, DNSSEC?
There was a issues with the delegation of some zones. NS records were not added to the parent zone when they should have been but the scripts which sign the zones added DS records which caused the parent zone not to be resigned. The signatures for the parent zone eventually expired which caused resolution failures for all the children of the parent zone rather than just the zones with a broken delegation. The scripts that sign the zones did report the error but those reports were overlooked. Operations is looking at their proceedures and what additional checking can be done to prevent a repeat. Mark -- 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: lists.isc.org rDNS failed, DNSSEC?
On Thu, Feb 23, 2012 at 2:47 PM, Mark Andrews wrote: > > There was a issues with the delegation of some zones. NS records > were not added to the parent zone when they should have been but > the scripts which sign the zones added DS records which caused the > parent zone not to be resigned. The signatures for the parent zone > eventually expired which caused resolution failures for all the > children of the parent zone rather than just the zones with a broken > delegation. > > The scripts that sign the zones did report the error but those > reports were overlooked. > > Operations is looking at their proceedures and what additional > checking can be done to prevent a repeat. I've seen several places, mostly in .gov bitten by this one and I'll admit that it almost caught me, but the fact that the ISC tripped over this says volumes about how careful people have to be about handling details when DNSSEC is added. It simply can't be the "set and forget" DNS of the past, at least not until and unless tools become far more bullet-proof. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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: lists.isc.org rDNS failed, DNSSEC?
I kind of had the same thought... If ISC had a DNS outage due to expired signatures of a zone, what chance do I have in successfully deploying and maintaining DNSSEC for my zones? Sure, everyone makes mistakes, but I think it speaks volumes to the inherent complexity and the further need for simplifying the maintenance of signed zones. I know that progress is continually being made on this front and I think others agree... Just pointing it out again. I have nothing against DNSSEC, personally. I'd love to deploy it. I just don't have the time to maintain it or worry about maintaining it right now. -Vinny -Original Message- From: bind-users-bounces+vinny_abello=dell@lists.isc.org [mailto:bind-users-bounces+vinny_abello=dell@lists.isc.org] On Behalf Of Kevin Oberman Sent: Thursday, February 23, 2012 6:21 PM To: Mark Andrews Cc: bind-us...@isc.org Subject: Re: lists.isc.org rDNS failed, DNSSEC? On Thu, Feb 23, 2012 at 2:47 PM, Mark Andrews wrote: > > There was a issues with the delegation of some zones. NS records > were not added to the parent zone when they should have been but > the scripts which sign the zones added DS records which caused the > parent zone not to be resigned. The signatures for the parent zone > eventually expired which caused resolution failures for all the > children of the parent zone rather than just the zones with a broken > delegation. > > The scripts that sign the zones did report the error but those > reports were overlooked. > > Operations is looking at their proceedures and what additional > checking can be done to prevent a repeat. I've seen several places, mostly in .gov bitten by this one and I'll admit that it almost caught me, but the fact that the ISC tripped over this says volumes about how careful people have to be about handling details when DNSSEC is added. It simply can't be the "set and forget" DNS of the past, at least not until and unless tools become far more bullet-proof. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: lists.isc.org rDNS failed, DNSSEC?
On 2/23/12 8:48 PM, "vinny_abe...@dell.com" wrote: > I kind of had the same thought... If ISC had a DNS outage due to expired > signatures of a zone, what chance do I have in successfully deploying and > maintaining DNSSEC for my zones? Sure, everyone makes mistakes, but I think it > speaks volumes to the inherent complexity and the further need for simplifying > the maintenance of signed zones. I know that progress is continually being > made on this front and I think others agree... Just pointing it out again. I > have nothing against DNSSEC, personally. I'd love to deploy it. I just don't > have the time to maintain it or worry about maintaining it right now. Much agreed, though I want to point out that you should only generally deploy DNSSEC (or any new technology?) if the benefit outweighs the cost. Adopting new technology "just because" usually leads to trouble (or overworked admins that give up and go elsewhere). What's the potential risk to your organization if the mythical "determined attacker" is able to negatively or positively spoof resource records under your control? Maybe not much for you, maybe millions for financial orgs. If the potential cost to the organization is high enough... It will justify paying a team of folks to maintain DNSSEC. :-) That said, I too look forward to a day when security is easier and more automatic. Much progress has been made, and I have high hopes and faith in ISC and the DNS community at large. http://www.jnd.org/books.html -- Time is the coin of your life. It is the only coin you have, and only you can determine how it will be spent. Be careful lest you let other people spend it for you. -- Carl Sandburg ___ 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: lists.isc.org rDNS failed, DNSSEC?
On Thu, Feb 23, 2012 at 9:00 PM, michoski wrote: > On 2/23/12 8:48 PM, "vinny_abe...@dell.com" wrote: > >> I kind of had the same thought... If ISC had a DNS outage due to expired >> signatures of a zone, what chance do I have in successfully deploying and >> maintaining DNSSEC for my zones? Sure, everyone makes mistakes, but I think >> it >> speaks volumes to the inherent complexity and the further need for >> simplifying >> the maintenance of signed zones. I know that progress is continually being >> made on this front and I think others agree... Just pointing it out again. I >> have nothing against DNSSEC, personally. I'd love to deploy it. I just don't >> have the time to maintain it or worry about maintaining it right now. > > Much agreed, though I want to point out that you should only generally > deploy DNSSEC (or any new technology?) if the benefit outweighs the cost. > Adopting new technology "just because" usually leads to trouble (or > overworked admins that give up and go elsewhere). > > What's the potential risk to your organization if the mythical "determined > attacker" is able to negatively or positively spoof resource records under > your control? Maybe not much for you, maybe millions for financial orgs. > > If the potential cost to the organization is high enough... It will justify > paying a team of folks to maintain DNSSEC. :-) > > That said, I too look forward to a day when security is easier and more > automatic. Much progress has been made, and I have high hopes and faith in > ISC and the DNS community at large. > > http://www.jnd.org/books.html FWIW, we have been signing daily and rolling ZSKs every 2 weeks for over a year with no glitches at all, though we are using a non-BIND solution (Secure64) to do the signing. Still, it tells me that it is possible and I suspect that BIND 10 will move closer to that point. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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
BIND 9.9.0rc4 is now available
Introduction BIND 9.9.0rc4 is the fourth release candidate for BIND 9.9.0 This document summarizes changes from BIND 9.8 to BIND 9.9. Please see the CHANGES file in the source code release for a complete list of all changes. Download The latest versions of BIND 9 software can always be found on our web site at http://www.isc.org/downloads/all. There you will find additional information about each release, source code, and pre-compiled versions for Microsoft Windows operating systems. Support Product support information is available on http://www.isc.org/services/support for paid support options. Free support is provided by our user community via a mailing list. Information on all public email lists is available at https://lists.isc.org/mailman/listinfo. Security Fixes new in 9.9.0rc4 no new security fixes have been added New Features new in 9.9.0rc4 no new features have been added previously included in 9.9.0rc3 NXDOMAIN redirection is now possible. This enables a resolver to respond to a client with locally-configured information when a query would otherwise have gotten an answer of "no such domain". This allows a recursive nameserver to provide alternate suggestions for misspelled domain names. Note that names that are in DNSSEC-signed domains are exempted from this when validation is in use. [RT #23146] Improved scalability by using multiple threads to listen for and process queries. Previously named only listened for queries on one thread regardless of the number of overall threads used. [RT #22992] Improves startup and reconfiguration time by allowing zones to load in multiple threads. [RT #25333] Improves initial start-up and server reload time by increasing the default size of the hash table the configuration parser uses to keep track of loaded zones and allowing it to grow dynamically to better handle systems with large numbers of zones. [RT #26523] Improves the startup time for an authoritative server with a large number of zones by making the zone task table of variable size rather than fixed size. This means that authoritative servers with many zones will be serving that zone data much sooner. [RT #24406] The new "inline-signing" option, in combination with the "auto-dnssec" option that was introduced in BIND 9.7, allows named to sign zones completely transparently. Previously automatic zone signing only worked on master zones that were configured to be dynamic; now, it works on any master or slave zone. In a master zone with inline signing, the zone is loaded from disk as usual, and a second copy of the zone is created to hold the signed version. The original zone file is not touched; all comments remain intact. When you edit the zone file and reload, named detects the incremental changes that have been made to the raw version of the zone, and applies those changes to the signed version, adding signatures as needed. A slave zone with inline signing works similarly, except that instead of loading the zone from disk and then signing it, the slave transfers the zone from a master server and then signs it. This enables "bump in the wire" signing: a dedicated signing server acting as an intermediary between a hidden master server (which provides the raw zone data) and a set of publicly accessible slave servers (which only serve the signed data). [RT #26224/23657] "rndc flushtree " command removes the specified name and all names under it from the cache. [RT #19970] "rndc sync" command dumps pending changes in a dynamic zone to disk without a freeze/thaw cycle. "rndc sync -clean" removes the journal file after syncing. "rndc freeze" no longer removes journal files. [RT #22473] The new "rndc signing" command provides greater visibility and control of the automatic DNSSEC signing process. Options to this new command include "-list " which will show the current state of signing operations overall or per specified zone. [RT #23729] The "also-notify" option now takes the same syntax as "masters", thus it can use named master lists and TSIG keys. [RT #23508] "auto-dnssec" zones can now have NSEC3 parameters set prior to signing. [RT #23684] The "dnssec-signzone -D" option causes dnssec-signzone to write DNSSEC data to a separate output file. This allows you to put "$INCLUDE example.com.signed" into the zonefile for example.com, run "dnssec-signzone -SD example.com", and the result is a fully signed zone which did *not* overwrite your original zone file. Running the same command again will incrementally re-sign the zone, replacing only those signatures that need updating, rather than signing the entire zone from scratch. [RT #22896] "dnssec-signzone -R" forces removal of signatures that are not expired but were created by
