bert hubert wrote:
On Thu, Apr 18, 2002 at 04:57:59PM -0700, Paul Vixie wrote:
according to http://root-servers.org/, dns transactions concerning
rfc1918
address space are now being served by an anycast device near you (no matter who you might be, or where.) there will eventually be official statistics, but i thought i'd give everybody a chance to clean up their houses first.
And right you are. However, pray tell, why doesn't bind feature a simple way to not log these spurious updates? As far as I can tell lots of people want to just ignore these messages but can only do so by turning off all security logging.
Both bind8 & 9 can do seperate update logging: http://www.crt.se/dnssec/bind9/Bv9ARM.ch06.html#AEN1548 "Logging Statement Grammar" The category 'update' is meant for Dynamic updates, one could either log that to /dev/null or to a seperate file. Which one could then filter for fails etc. If one chooses to log to /dev/null succeeded updates won't be logged either. But I'd rather see failed updates in my own reverse zones than all the other crap, which makes the filter the best way. Which is also most probably what Bert meant. It would be nice to be able to ignore certain failures though and actually have a more fine grained control of it all. One could always opt to use the source and modify it ofcourse ;) As for the Win2k/XP dyndns updates; it's a great thing when one uses it, if you don't simply either ignore all updates from these boxes, fix them with that simple clickety click option, some nice registry script on user-login and never forget the power of policies. Also those 10.in-addr.arpa. DNS servers should simply be 'deployed' by the ISP's to block them off. But then again I also think it's a good idea to block port 25 outgoing on ISP's and force clueless users to use the ISP's relay which would save us of many spams from around this world. Btw... 'a' way to catch these things ;) I have these in place, but this host does apparently pop-up 48 times in the /32 list, so Paul if you can pass me the entries in the logs for my host (purgatory.unfix.org / 195.64.92.136). I will be figuring it out as there are only 2 win2k here and both have the dynamic dns stuff disabled, so they really shouldn't be poppin up in yours... Thou named.conf: 8<------- // RFC1918 Catches // 10.0.0.0/8 zone "10.in-addr.arpa" { type master; file "/etc/namedb/pz/rev/catch/10"; }; // 192.168.0.0/16 zone "168.192.in-addr.arpa" { type master; file "/etc/namedb/pz/rev/catch/empty"; }; // 172.16.0.0/12 zone "16.172.in-addr.arpa" { type master; file "/etc/namedb/pz/rev/catch/empty"; }; zone "17.172.in-addr.arpa" { type master; file "/etc/namedb/pz/rev/catch/empty"; }; zone "18.172.in-addr.arpa" { type master; file "/etc/namedb/pz/rev/catch/empty"; }; zone "19.172.in-addr.arpa" { type master; file "/etc/namedb/pz/rev/catch/empty"; }; zone "20.172.in-addr.arpa" { type master; file "/etc/namedb/pz/rev/catch/empty"; }; zone "21.172.in-addr.arpa" { type master; file "/etc/namedb/pz/rev/catch/empty"; }; zone "22.172.in-addr.arpa" { type master; file "/etc/namedb/pz/rev/catch/empty"; }; zone "23.172.in-addr.arpa" { type master; file "/etc/namedb/pz/rev/catch/empty"; }; zone "24.172.in-addr.arpa" { type master; file "/etc/namedb/pz/rev/catch/empty"; }; zone "25.172.in-addr.arpa" { type master; file "/etc/namedb/pz/rev/catch/empty"; }; zone "26.172.in-addr.arpa" { type master; file "/etc/namedb/pz/rev/catch/empty"; }; zone "27.172.in-addr.arpa" { type master; file "/etc/namedb/pz/rev/catch/empty"; }; zone "28.172.in-addr.arpa" { type master; file "/etc/namedb/pz/rev/catch/empty"; }; zone "29.172.in-addr.arpa" { type master; file "/etc/namedb/pz/rev/catch/empty"; }; zone "30.172.in-addr.arpa" { type master; file "/etc/namedb/pz/rev/catch/empty"; }; zone "31.172.in-addr.arpa" { type master; file "/etc/namedb/pz/rev/catch/empty"; }; // 169.254.0.0/16 - Autoconfig zone Catch zone "254.169.in-addr.arpa" { type master; file "/etc/namedb/pz/rev/catch/empty"; }; --------->8 As you see I defined the 10.0.0.0/24 seperatly as I have some lines with 'downstream' (read my local) NS's in there... 8<---------------- ; BIND reverse data file for *.in-addr.arpa ; Reverse-Lookup zones for subnets: ; Empty - Catch ; $TTL 604800 @ IN SOA purgatory.unfix.org. dnsadmin.purgatory.unfix.org. ( 2000122901 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Default TTL NS purgatory.unfix.org. -------------->8 And use something like this for the empty, the $ORIGIN can be irritating, otherwise generate seperate ones. At least one can't lookup 'outside' dns's anymore and send updates there unless they are specifically instructed too. 8<------- jeroen@heaven:~$ host -t ns 13.100.10.in-addr.arpa. 13.100.10.in-addr.arpa NS purgatory.unfix.org jeroen@heaven:~$ host -t ns 100.10.in-addr.arpa. 100.10.in-addr.arpa does not exist, try again jeroen@heaven:~$ host -t ns 10.in-addr.arpa. 10.in-addr.arpa NS purgatory.unfix.org jeroen@heaven:~$ host -t ns 18.172.in-addr.arpa. 18.172.in-addr.arpa NS purgatory.unfix.org ------->8 And ofcourse that box doesn't allow updates but does nicely deny them, so no delay. Someone prolly has a cleaner solution for filtering it... On another note..... IPv6 has the fec0::/10 addresses and we also got two reverses for that: 0.c.e.f.ip6.int & 0.c.e.f.ip6.arpa. And we will probably be updating those soon too, so people better start implementing their filters there and at some other addresses too ;) Fortunatly one can easily catch the f.ip6.int/arpa and is done then, nibble reverses hooray. Greets, Jeroen PS: for snoopy people, the above config is only the inside view, not the outside, which doesn't recurse.