How Do I block DNS Update Attempts

I keep having somebody attempting to Update our DNS Records. We do not know
who this is and an NSLOOKUP tells us they are from a DHCP Pool owned by
verizon.net. Calling Verszon is useless.

Periodically our Linux Box needs to be rebooted due to lockups probably
caused by these failed update attempts.

Question: How do I block these update attempts.

Non-authoritative answer:
29.236.156.141.in-addr.arpa name =
pool-141-156-236-29.res.east.verizon.net.


-Thank You
-tom




May 14 14:41:03 smtp2 named[967]: client 141.156.236.29#3114: updating zone
'mydomain.com/IN': update failed: 'RRset exists (value dependent)'
prerequisite not satisfied (NXRRSET)

May 14 14:41:03 smtp2 named[967]: client 141.156.236.29#3117: update
'mydomain.com/IN' denied

May 14 14:41:47 smtp2 named[966]: client 141.156.236.29#3120: updating zone
'mydomain.com/IN': update failed: 'RRset exists (value dependent)'
prerequisite not satisfied (NXRRSET)

May 14 14:41:47 smtp2 named[967]: client 141.156.236.29#3123: update
'mydomain.com/IN' denied

May 14 14:43:05 smtp2 sshd(pam_unix)[2074]: session closed for user root

May 14 14:46:03 smtp2 named[966]: client 141.156.236.29#3126: updating zone
'mydomain.com/IN': update failed: 'RRset exists (value dependent)'
prerequisite not satisfied (NXRRSET)

May 14 14:46:03 smtp2 named[966]: client 141.156.236.29#3129: update
'mydomain.com/IN' denied

May 14 14:46:47 smtp2 named[966]: client 141.156.236.29#3132: updating zone
'mydomain.com/IN': update failed: 'RRset exists (value dependent)'
prerequisite not satisfied (NXRRSET)

May 14 14:46:47 smtp2 named[966]: client 141.156.236.29#3135: update
'mydomain.com/IN' denied

May 14 14:48:26 smtp2 sshd(pam_unix)[2153]: session opened for user root by
(uid=0)

[root@smtp2 root]#

"Tom Celica" <tom@dontreply.com> writes:

> I keep having somebody attempting to Update our DNS Records. We do not
> know who this is and an NSLOOKUP tells us they are from a DHCP Pool owned
> by verizon.net. Calling Verszon is useless.

What relationship does your organization have with verizon? Any
Windoze-lusing employees dialling-up from home accessing work, for example?

Why does this worry you, anyway? As long as you've configured your
nameserver properly (you don't say what named you're using, so RTFM for
whatever it is), it's not as they'll be able to do anything, anyway, right?

> Periodically our Linux Box needs to be rebooted due to lockups probably
> caused by these failed update attempts.

Highly unlikely. There are proper ways to diagnose machines hanging
starting with correlating console output, logfiles (two events at 03 and
47s past the minute, 5mins apart - have you noticed this pattern?), system
load, CPU and ambient temperature, whether motherboard components are well
seated or not, quality of PSU and smoothness of input voltage etc, without
resorting to voodoo guesswork.

[snip]

~Tim
--
There's a sadness, there's a joy |piglet@stirfried.vegetable.org.uk
There's a place, |http://spodzone.org.uk/cesspit/
There's a song that will never die |
Forever |

Tom Celica wrote:
> I keep having somebody attempting to Update our DNS Records. We do not know
> who this is and an NSLOOKUP tells us they are from a DHCP Pool owned by
> verizon.net. Calling Verszon is useless.
>
> Periodically our Linux Box needs to be rebooted due to lockups probably
> caused by these failed update attempts.
>
> Question: How do I block these update attempts.
>
> Non-authoritative answer:
> 29.236.156.141.in-addr.arpa name =
> pool-141-156-236-29.res.east.verizon.net.
>
>

You block them by configuring bind to ignore them. If you have bind
configured properly, then no harm done.

You could IPTABLE DNS requests from that IP range. Since it's dial-up,
it's a fair bet that they use Verizon's RADIUS-supplied DNS settings and
those DNS machines are probably not even close in address space (or one
would hope). The concept being that since they are dial-up, the
supplied DNS will do the look-up and isn't blocked.

However, I doubt that these requests are causing your machine to
lock-up. If they are, then something is very very wrong with your
version of bind. I'd suspect that something else is causing your
machine to behave this way.




--

WWJD? JWRTFM
Rot13 for email address: yvfgf @ ehqa.pbz

Brad Olin wrote:
> On Sat, 15 May 2004 19:07:06 -0400, Jeff Breitner <usenet@rudn.com>
> wrote:

> Ummm... Except that it is valid for those same verizon users to look up
> a domain that his dns server is authoritative of. So you can't just
> blindly drop them by address range and port. Well, unless the op has a
> caching only dns server.


If they are dial-up, then it's a safe bet that the radius auth session
gave them Verizon DNS servers to use. They wouldn't be looking anything
up at his nameservers, Verizon's nameservers would be doing that and
passing the look-up along to their clients. I'd be really surprised if
Verizon has those nameservers even remotely close in IP space to the
radius assigned nameserver. Therefore, and as I indicated in my
previous post, he could IPTABLE them with the only bad effects limited
to the Verizon users within the IP space he blocked. And even then, it
would be those that are running their own nameservers (assuming Verizon
didn't have the radius assigned nameservers within the blocked space --
so he wouldn't want to block an entire /16). And really, the only
people capable of trying to send bad update information would be those
running their own nameservers.

Unfortunately, the offending single user probably would shift around the
assigned address, so IPTABLE would be an action of last resort.

--

WWJD? JWRTFM
Rot13 for email address: yvfgf @ ehqa.pbz

Brad Olin wrote:

> Not true if he is authoritative on one or more domains on the lookup of
> those domains. To paraphrase the process... The process starts by the
> client contacting the tld server, then based on that reply, the client
> contacts the authoritative dns server(s). If his dns server is the
> authoritative server, and he blocks the requesting IP, then the
> domain(s) he serves would be broken for that IP/address range.

You are correct, *if* this particular client is running their own
nameserver. And that right there is part of the problem; some Verizon
client is running their own nameserver and is running amok with update
requests and he'd like to block it.

>
> Your assumption is fine if he has a caching only server.

As well the scads of other clients that are just ordinary dial-up users.

>
>
>>Unfortunately, the offending single user probably would shift around the
>>assigned address, so IPTABLE would be an action of last resort.
>
>
> True if it's a malicious intent. It could be just a poorly configured
> box.


I lean toward the latter. The only malicious update intent I've seen
was toward Windows DNS machines that allowed people to poison the cache
and do such nasties as point all requests to some porn site.


--

WWJD? JWRTFM
Rot13 for email address: yvfgf @ ehqa.pbz

Brad Olin wrote:

> I have setup several caching only dns servers for dhcp customers
> (dsl/cable/dialup) because the provider's dns servers are so slow or
> overloaded. I don't know that there is any foul with that if it's done
> correctly. I do it myself with my cable connection at home.
>

My cable ISP is the same way. DHCP assigned nameservers are slower than
tax refund checks.

--

WWJD? JWRTFM
Rot13 for email address: yvfgf @ ehqa.pbz