is your host or dhcp server sending dns dynamic updates for rfc1918?

here's another one that was sent personally but that i'm answering to the list:

> i apologize for indicating that an AS owner ought to have been capturing
> DNS updates for rfc1918 PTR's, since up until we put the servers into an
> anycast block, this wasn't possible. now that it's possible, you should
> all start doing it.

Wasn't it possible before the anycast trick was instituted as well?
The only reason I see for it not being possible is if the servers
weren't dedicated, but they needn't be on anycast addresses for that.

the old server addresses were not intended by their registrants to be
anycast by third parties. capturing traffic to such addresses would
have been either a configuration error or electronic fraud, depending
on whether the person trying to fix it was a sysadmin, or a lawyer.

Maybe I'm misreading your wording, but it seems to me that in order to
capture traffic one doesn't need anycast addressing for the target, the
servers just need to not have any other purpose besides DNS for RFC1918
space...

that's an alternative, sure. but anycast isn't just a global routing
activity. any AS owner could advertise this /24 within their own border
and collect all this "spurious" traffic from their own downstreams without
also collecting it from anybody else's downstreams. that seems easier
than installing null routes on every host in your AS.

I've added the following to /etc/rc.conf on the FreeBSD machine acting
as router at the office:

---
# Blackholed servers - these are configured here to capture RFC1918
# dynamic DNS update requests instead of burdening IANA with them.
ifconfig_fxp0_alias3="192.175.48.6 netmask 255.255.255.255"
ifconfig_fxp0_alias4="192.175.48.42 netmask 255.255.255.255"
---

you really want .1, since that's where microsoft's products send the updates.

and by the way, it's not exactly a burden, from IANA's point of view,
but it is indeed traffic that's kind of silly, from my own point of view.