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

[Nathan J. Mehl]

In the immortal words of Simon Higgs ([EMAIL PROTECTED]):
> 
> SOAs with bogus.domain.names pointing to 127.0.0.1 appear to be causing 
> email to bounce (amongst other things). 

If there is actually an MTA out there so broken that it tries to
connect to the server mentioned in the SOA MNAME field instead of the
MX or A record for that domain, I'd be inclined to consider this a
benefit, not a drawback.

-n, (Let me guess...cc:SMTP?)

<[EMAIL PROTECTED]>
"We build our computers the way we build our cities -- over time, without a
plan, on top of ruins."   (--Ellen Ullman)

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

[Valdis . Kletnieks]

On Fri, 19 Apr 2002 22:14:37 PDT, Simon Higgs <[EMAIL PROTECTED]>  said:
>
> Not yet. But the common thread to this is that every domain that vanishes 
> (and causes email to bounce) has got a bogus MNAME entry (i.e. MNAME is 
> unroutable). This isn't a root specific problem as legacy root users have 
> reported this problem alongside ORSC users. The bogus MNAME may be a red 
> herring, but it's what we're looking at as a possible common cause.

Hmm... Bork-ware box boots, gets a DHCP address, tries to stick it into the
AD tree at the MNAME address, and loses.  It then tries to send mail,
and the remote end bounces it because it doesn't have a valid PTR entry?

Yes, a DHCP'ed mail server is silly, and rejecting mail entirely because
of a missing PTR is silly - but this is a world where sites reject mail
that has a 'MAIL FROM:<>' and then wonder why things dont work

Just 2AM speculation, but I've seen stupider failure modes.. ;)
-- 
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech




msg01038/pgp0.pgp
Description: PGP signature

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

[Adrian Chadd]

On Fri, Apr 19, 2002, Eric Germann wrote:
> If people set up their Win2K networks right, it wouldn't be a problem.
> Simply install the MS DNS server, point their clients at that, then all the
> updates go there.  And if that DNS server has connectivity to the 'Net at
> large, it will resolve all their other requests too by chasing the chain
> from the root down.
> 
> Best of both worlds, or at least the best you can do in the situation ...

yeah, but windows isn't really targeted at the types of people who
do things "right" .. its targeted at the types of people who want
to do things "now".

I mean, if people set up their hosts/networks right - MTU path discovery
would actually still _work_ these days, spam wouldn't be a problem ..
DDoS just Wouldn't Happen(tm) ..




adrian

-- 
Adrian Chadd"For a sucessful technology, reality must
<[EMAIL PROTECTED]>  take precedence over public relations,
for nature cannot be fooled" - Feynmann

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

[Simon Higgs]

At 06:41 PM 4/19/2002 -0700, Pete Ehlke wrote:

>On Fri, Apr 19, 2002 at 06:32:58PM -0700, Simon Higgs wrote:
> >
> > SOAs with bogus.domain.names pointing to 127.0.0.1 appear to be causing
> > email to bounce (amongst other things).
>
>Ermm... Do you have any actual evidence for this assertion?

Not yet. But the common thread to this is that every domain that vanishes 
(and causes email to bounce) has got a bogus MNAME entry (i.e. MNAME is 
unroutable). This isn't a root specific problem as legacy root users have 
reported this problem alongside ORSC users. The bogus MNAME may be a red 
herring, but it's what we're looking at as a possible common cause.

>An mta that
>examines MNAME is horribly, horribly broken. I can't imagine anything
>but the worst sort of spamware actually doing this.

Yes, but given that all software is broken by nature, and that there is a 
filing cabinet full of CERT advisories, why would you be surprised at 
either SendMail or BIND being the culprit under certain circumstances? 
Maybe even for a totally different reason.



Best Regards,

Simon

--
###

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

[Pete Ehlke]

On Fri, Apr 19, 2002 at 06:32:58PM -0700, Simon Higgs wrote:
> 
> SOAs with bogus.domain.names pointing to 127.0.0.1 appear to be causing 
> email to bounce (amongst other things). 

Ermm... Do you have any actual evidence for this assertion? An mta that
examines MNAME is horribly, horribly broken. I can't imagine anything
but the worst sort of spamware actually doing this.

-Pete
-- 
"religious fanatics are not part of my desired user base." 
- [EMAIL PROTECTED]

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

[Simon Higgs]

At 08:31 AM 4/19/2002 -0700, Paul A Vixie wrote:

>this was sent personally, but i'm answering to the list.
>
> > It might help the A Root, at least, if the SOA record listed
> > bogus.root-servers.net instead of A.root-servers.net, and then a record
> > mapped bogus.root-servers.net to 127.0.0.1. That should keep Win2K and
> > follow-ons from sending dynamic updates to the root zone.

SOAs with bogus.domain.names pointing to 127.0.0.1 appear to be causing 
email to bounce (amongst other things). Is there something out there 
specifically describing putting [your.domain].local in the SOA to achieve 
this? What is the rational behind this?


Best Regards,

Simon

--
###

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

[Daniel Senie]

At 03:08 PM 4/19/02, you wrote:
>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.

Explain how to fix everyone else's machines in the world. I host the 
domains owl.com and jove.com, among others, for clients. Apparently many 
people around the world would LIKE to own one or the other of these, and so 
program owl.com or jove.com into their Win2K machine setups. Those machines 
then bash the crap out of my name servers with dynamic updates.

We changed the MNAME in the SOA for those two domains to something that 
resolves to 127.0.0.1, and that took care of our load issue.

PLEASE understand the problem is NOT something people running the name 
servers have control over!

This is a totally irresponsible implementation on the part of Microsoft. It 
really reminds me of SNMP Management stations which would do network 
discovery by walking the entire IPv4 address space. Implementers of the 
products did not think through their designs, and many other people suffer 
for it.


-
Daniel Senie[EMAIL PROTECTED]
Amaranth Networks Inc.http://www.amaranth.com

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

[Mike Parson]

On Thu, Apr 18, 2002 at 04:57:59PM -0700, Paul Vixie wrote:



> what these files are is a whole lot of lines that look like (broken by me):
> 
> 18-Apr-2002 16:16:05.491 security: notice: \
>   denied update from [63.198.141.30].2323 for "168.192.in-addr.arpa" IN
> 
> by "a whole lot" i mean we've logged 3.3M of these in the last four hours.

I saw similar behavior on my little box (ns.bl.org) about a year or so ago,
logs have long since rotated out, so I don't recall exactly when, but there
was an IP somewhere in S. America trying to do a dyn update, something like
one attempt every two seconds.

I emailed the ISP, didn't get anything back, so I set up a black-hole
in BIND and stuck that /24 in it.  A few days later, it was back,
from a different /24, but in the same /16, so I blackholed the /16.
Then again, from another /16, but the same ISP, so I blackholed it.

Haven't seen anything in a long time.

-- 
Michael Parson
[EMAIL PROTECTED]

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

[Jeroen Massar]

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
;
$TTL604800
@   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<---
jeroe

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

[bert hubert]

On Fri, Apr 19, 2002 at 10:06:19AM -0700, Randy Bush wrote:
> > according to our border flow stats, not all of them get nat'd on the way
> > here.
> 
> we already knew nats were broken.
> 
> but i still believe that win2k behind nats probably explain most of the
> data behind the updates for 1918 space from non-1918 ip source addresses.

We find that updates in the forward zones are a great way of tracking
laptops, btw, as nobody ever changes the 'domain' or whatever it is called
in Windows.
 
So you see these updates coming in from everywhere the laptop goes.

Regards,

bert hubert

-- 
http://www.PowerDNS.com  Versatile DNS Software & Services
http://www.tk  the dot in .tk
http://lartc.org   Linux Advanced Routing & Traffic Control HOWTO

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

[Randy Bush]

>>> now as to who's responsible, first off you have to understand that we
>>> block rfc1918-sourced packets at our AS boundary.  (otherwise these
>>> numbers would be Much Higher
>> are you sure?  i suspect they are windows 2000 systems behind NATs.  so
>> the dynamic update is for the 1918 address, but the packet source address
>> has been natted into real space.
> according to our border flow stats, not all of them get nat'd on the way
> here.

we already knew nats were broken.

but i still believe that win2k behind nats probably explain most of the
data behind the updates for 1918 space from non-1918 ip source addresses.

randy

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

[Paul Vixie]

(received privately, answering publically)

> > any AS owner who wants to localize these updates can do so by simply
> > anycasting the 192.175.48/24 netblock and serving dns on .1,=20
> > .6, and .42.
> 
> Will it be a _bad_ thing if I just null-route those addresses in a
> controlled/documented/restorable manner in the ASes and other sub-AS
> networks that I administer?

not at all.

> Will it break anything valuable to you or to end-users inside those ASes?

nope.

> Is there is a certain reason I should run a real DNS server on 1, 6 and
> 42 (besides, of course, collecting statistics and chasing ab|users) ?

nope.

> Is there a centralised place with information on the blackhole-X anycast
> addresses and AS112 or a document with the proposal and implementation
> besides www.root-servers.org ?

um, nope.  if you think it should say more than it does, let us know and
we'll plump it up.

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

[Eric Germann]

The point wasn't to get everyone to convert to MS DNS.  The point was if you
ALREADY HAVE Win2K server running on your network, set it up right and you
can short circuit the problem.  Its not a great conspiracy 

Also, you can follow these directions from the client end ...

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q259922


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Ukyo Kuonji
> Sent: Friday, April 19, 2002 10:35 AM
> To: [EMAIL PROTECTED]
> Subject: RE: is your host or dhcp server sending dns dynamic updates for
> rfc1918?
>
>
>
> >From: Eric Germann <[EMAIL PROTECTED]>
> >
> >If people set up their Win2K networks right, it wouldn't be a problem.
> >Simply install the MS DNS server, point their clients at that,
> then all the
> >updates go there.  And if that DNS server has connectivity to the 'Net at
> >large, it will resolve all their other requests too by chasing the chain
> >from the root down.
>
> Great, just what Microsoft would like to see happen.  In order to
> do this,
> EVERY DNS server that answers queries from end users (or servers)
> would have
> to be a MS DNS server.  Might as well just replace the Internet
> with MSN, no
> offence to those that drive the deathstar.
>
> What I AM trying to figure out is why some win2K systems do this,
> and some
> don't.  Did MS fix/break something with SP2?
>
> _
> Get your FREE download of MSN Explorer at
> http://explorer.msn.com/intl.asp.
>
>


BEGIN:VCARD
VERSION:2.1
N:Germann;Eric
FN:Eric Germann
ORG:CCTec
TEL;WORK;VOICE:(419) 968-2640
TEL;WORK;FAX:(603) 825-5893
ADR;WORK:;;17780 Middle Point Road;Van Wert;OH;45891;United States of America
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:17780 Middle Point Road=0D=0AVan Wert, OH 45891=0D=0AUnited States of Americ=
a
URL:
URL:http://www.cctec.com
EMAIL;PREF;INTERNET:[EMAIL PROTECTED]
REV:20010529T013421Z
END:VCARD

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

[Paul Vixie]

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.

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

[Paul Vixie]

> > according to http://root-servers.org/, dns transactions concerning rfc1918
> > address space are now being served by an anycast device near you ...
> 
> 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.

that question belongs on [EMAIL PROTECTED], i suspect.  but i'll answer: if
you redirect the "update" and "security" categories to channel "null" then it
works like you want.  if there was demand, ISC would make a specific category
called "failed-updates" so that other security related events wouldn't have
to be nulled at the same time.

> Please note that PowerDNS is just as silly in this respect up to 1.99.9. The
> next version features --log-failed-updates which defaults to off.

not all failed updates are spurious.  i recommend against this as a default.

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

[Paul Vixie]

> > now as to who's responsible, first off you have to understand that we block
> > rfc1918-sourced packets at our AS boundary.  (otherwise these numbers would
> > be Much Higher
> 
> are you sure?  i suspect they are windows 2000 systems behind NATs.  so
> the dynamic update is for the 1918 address, but the packet source address
> has been natted into real space.

according to our border flow stats, not all of them get nat'd on the way here.

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

[Paul A Vixie]

this was sent personally, but i'm answering to the list.

> It might help the A Root, at least, if the SOA record listed 
> bogus.root-servers.net instead of A.root-servers.net, and then a record 
> mapped bogus.root-servers.net to 127.0.0.1. That should keep Win2K and 
> follow-ons from sending dynamic updates to the root zone.

now that we have separate servers for the rfc1918 ptr zones, these updates
are not going to the root servers and indeed cannot affect the root servers.

since ddos attack backscatter shows up in these log files, it's darn useful
to centralize the logging for it.

any AS owner who wants to localize these updates can do so by simply
anycasting the 192.175.48/24 netblock and serving dns on .1, .6, and .42.

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

[Paul A Vixie]

this was sent personally, but i'm responding to the list:

>   I noticed ~550 addresses from several /16's the I manage on the list.  The
> majority of the addresses were commercial broadband customers that have
> static IP address assignments and appear to be running linksys/netgear/smc
> broadband routers doing NAT (likely running internal DHCP servers).

a common enough configuration.

>   I believe I understand what's happening, but how can I go about fixing
> this?  Is this Win2k/XP's fault, Linksys' fault, my fault?  Real
> question:  How do I go about preventing customer Windows machines behind
> customer nat boxes from DDoSing root servers with Windoze "Dynamic Updates"?
> You mentioned capturing this request, but I'm (perhaps blindly) missing the
> "how" part of that concept.

if rfc1918 addressing is in use inside your AS (a foregone conclusion),
then it's your responsibility to install "covering routes" at the IP layer
so that any traffic with that destination will die at your border.  if you
can also run URPF on your border routers so that packets with that _source_
will die at your border, so much the better.  (i mention this not because
it answers your question but because our flow stats here tell me that most
other AS's don't handle their own rfc1918 traffic at their own border.)

since rfc1918 addressing is in use inside your AS, i recommend that you
install a route for 192.175.48.0/24, put some kind of dns servers on the
.1, .6, and .42 addresses in that block, and watch the syslog file, and
have your customer service (or abuse desk) folks work on educating your
customers.

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.

> BTW, what was the time frame on that list?  Hours, days, weeks?

four hours.

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

[Ukyo Kuonji]

>From: Eric Germann <[EMAIL PROTECTED]>
>
>If people set up their Win2K networks right, it wouldn't be a problem.
>Simply install the MS DNS server, point their clients at that, then all the
>updates go there.  And if that DNS server has connectivity to the 'Net at
>large, it will resolve all their other requests too by chasing the chain
>from the root down.

Great, just what Microsoft would like to see happen.  In order to do this, 
EVERY DNS server that answers queries from end users (or servers) would have 
to be a MS DNS server.  Might as well just replace the Internet with MSN, no 
offence to those that drive the deathstar.

What I AM trying to figure out is why some win2K systems do this, and some 
don't.  Did MS fix/break something with SP2?

_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

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

[Valdis . Kletnieks]

On Fri, 19 Apr 2002 09:03:51 EDT, Greg Maxwell <[EMAIL PROTECTED]>  said:

> Does anyone already have a SNORT signature to match on these updates to
> aid in tracking down which hosts behind a NAT are guilty for generating
> this garbage?

The problem is that the sites that are the big offenders are probably not
the sort of sites that would run Snort.

Now, think about it - one /32 popped of *30K* of these in 4 hours -
and a 'dig -x' shows it to apparently be a DSL line.  So we're seeing
2 or 3 DCHP events *PER SECOND* behind that NAT.  Either they've got
a bunch of machines doing the Reboot Shuffle and have bigger problems,
or they're big enough that 2-3 DHCP per second is reasonable (at which
point you have to wonder how they're THAT big, and depending on a DSL
line.. ;)

-- 
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech




msg01014/pgp0.pgp
Description: PGP signature

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

[Eric Germann]

If people set up their Win2K networks right, it wouldn't be a problem.
Simply install the MS DNS server, point their clients at that, then all the
updates go there.  And if that DNS server has connectivity to the 'Net at
large, it will resolve all their other requests too by chasing the chain
from the root down.

Best of both worlds, or at least the best you can do in the situation ...


==
  Eric GermannCCTec
  [EMAIL PROTECTED] Van Wert OH 45801
  http://www.cctec.comPh:  419 968 2640
  Fax: 603 825 5893

"The fact that there are actually ways of knowing and characterizing the
extent of one’s ignorance, while still remaining ignorant, may ultimately be
more interesting and useful to people than Yarkovsky"

  -- Jon Giorgini of NASA’s Jet Propulsion Laboratory

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Adrian Chadd
> Sent: Friday, April 19, 2002 2:35 AM
> To: [EMAIL PROTECTED]
> Subject: Re: is your host or dhcp server sending dns dynamic updates for
> rfc1918?
>
>
>
> On Thu, Apr 18, 2002, Martin J. Levy wrote:
> >
> > Paul,
> >
> > > now as to who's responsible, ...
> >
> > I hate to say it, but "Microsoft".  This is the default for w2k
> and the like.  The interesting thing is that it's got a very
> short timer for retries and hence why your logs are so big.  I
> found this...
> >
> >  http://www.isc.org/ml-archives/bind-users/2001/02/msg01806.html
> >
> >  http://www.domainregistry.ie/tech/dynamic-dns.html
>
> . time for a BCP, perhaps?
>
> >
> > I also thought that w2k and the like should not do a dynamic
> dns update if it's on private IP space, but that's not a valid
> test either, as the "enterprise" may well only exist in private
> IP space.  (Yes... they should run their own zone for the reverse dns).
>
> What _should_ happen IMHO is that this becomes an option thats off
> by default, rather than on by default. The amount of time saved by admins
> having this turned on is probably negated by the load placed on
> bind servers all over the planet - perhaps someone should send M$ an
> invoice.. :P
>
>
>
>
> Adrian
>
> --
> Adrian Chadd  "For a sucessful technology, reality must
> <[EMAIL PROTECTED]>take precedence over public relations,
>   for nature cannot be fooled" - Feynmann
>


BEGIN:VCARD
VERSION:2.1
N:Germann;Eric
FN:Eric Germann
ORG:CCTec
TEL;WORK;VOICE:(419) 968-2640
TEL;WORK;FAX:(603) 825-5893
ADR;WORK:;;17780 Middle Point Road;Van Wert;OH;45891;United States of America
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:17780 Middle Point Road=0D=0AVan Wert, OH 45891=0D=0AUnited States of Americ=
a
URL:
URL:http://www.cctec.com
EMAIL;PREF;INTERNET:[EMAIL PROTECTED]
REV:20010529T013421Z
END:VCARD

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

[bert hubert]

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.

Please note that PowerDNS is just as silly in this respect up to 1.99.9. The
next version features --log-failed-updates which defaults to off.

Regards,

bert

-- 
http://www.PowerDNS.com  Versatile DNS Software & Services
http://www.tk  the dot in .tk
http://lartc.org   Linux Advanced Routing & Traffic Control HOWTO

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

[Adrian Chadd]

On Thu, Apr 18, 2002, Martin J. Levy wrote:
> 
> Paul,
> 
> > now as to who's responsible, ...
> 
> I hate to say it, but "Microsoft".  This is the default for w2k and the like.  The 
>interesting thing is that it's got a very short timer for retries and hence why your 
>logs are so big.  I found this...
> 
>  http://www.isc.org/ml-archives/bind-users/2001/02/msg01806.html
> 
>  http://www.domainregistry.ie/tech/dynamic-dns.html

.. time for a BCP, perhaps? 

> 
> I also thought that w2k and the like should not do a dynamic dns update if it's on 
>private IP space, but that's not a valid test either, as the "enterprise" may well 
>only exist in private IP space.  (Yes... they should run their own zone for the 
>reverse dns).

What _should_ happen IMHO is that this becomes an option thats off
by default, rather than on by default. The amount of time saved by admins
having this turned on is probably negated by the load placed on
bind servers all over the planet - perhaps someone should send M$ an
invoice.. :P




Adrian

-- 
Adrian Chadd"For a sucessful technology, reality must
<[EMAIL PROTECTED]>  take precedence over public relations,
for nature cannot be fooled" - Feynmann

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

[Randy Bush]

> now as to who's responsible, first off you have to understand that we block
> rfc1918-sourced packets at our AS boundary.  (otherwise these numbers would
> be Much Higher

are you sure?  i suspect they are windows 2000 systems behind NATs.  so
the dynamic update is for the 1918 address, but the packet source address
has been natted into real space.

randy

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

[Martin J. Levy]

Paul,

> now as to who's responsible, ...

I hate to say it, but "Microsoft".  This is the default for w2k and the like.  The 
interesting thing is that it's got a very short timer for retries and hence why your 
logs are so big.  I found this...

 http://www.isc.org/ml-archives/bind-users/2001/02/msg01806.html

 http://www.domainregistry.ie/tech/dynamic-dns.html

>Windows 2000
>The option can be found from:
>Click Start -> Settings -> Network and Dialup
>View the Properties of Local Area
>Select Adapter -> Protocols -> TCP/IP -> Advanced -> DNS
>The "Register this name" option box should be clear.

...the later would have to be done on millions of boxes around the world.

I wanted to add a flag to bind to "silently ignore" these requests, but alas this is 
not a good solution for reverse-dns private space.

I also thought that w2k and the like should not do a dynamic dns update if it's on 
private IP space, but that's not a valid test either, as the "enterprise" may well 
only exist in private IP space.  (Yes... they should run their own zone for the 
reverse dns).

Martin

---

At 04:57 PM 4/18/2002 -0700, you 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.
>
>on the instance ISC runs, i noticed that the log files were turning over
>really fast.  that is to say, really, really, really fast.  see below.
>
>-rw-r--r--   1 root   sys10485795 Apr 18 12:11 update-1.log.33
>-rw-r--r--   1 root   sys10485850 Apr 18 12:19 update-1.log.32
>-rw-r--r--   1 root   sys10485794 Apr 18 12:26 update-1.log.31
>-rw-r--r--   1 root   sys10485846 Apr 18 12:33 update-1.log.30
>-rw-r--r--   1 root   sys10485787 Apr 18 12:41 update-1.log.29
>-rw-r--r--   1 root   sys10485830 Apr 18 12:48 update-1.log.28
>-rw-r--r--   1 root   sys10485776 Apr 18 12:55 update-1.log.27
>-rw-r--r--   1 root   sys10485873 Apr 18 13:02 update-1.log.26
>-rw-r--r--   1 root   sys10485847 Apr 18 13:09 update-1.log.25
>-rw-r--r--   1 root   sys10485830 Apr 18 13:17 update-1.log.24
>-rw-r--r--   1 root   sys10485783 Apr 18 13:24 update-1.log.23
>-rw-r--r--   1 root   sys10485871 Apr 18 13:31 update-1.log.22
>-rw-r--r--   1 root   sys10485794 Apr 18 13:39 update-1.log.21
>-rw-r--r--   1 root   sys10485866 Apr 18 13:46 update-1.log.20
>-rw-r--r--   1 root   sys10485821 Apr 18 13:54 update-1.log.19
>-rw-r--r--   1 root   sys10485843 Apr 18 14:01 update-1.log.18
>-rw-r--r--   1 root   sys10485831 Apr 18 14:08 update-1.log.17
>-rw-r--r--   1 root   sys10485809 Apr 18 14:16 update-1.log.16
>-rw-r--r--   1 root   sys10485765 Apr 18 14:23 update-1.log.15
>-rw-r--r--   1 root   sys10485802 Apr 18 14:31 update-1.log.14
>-rw-r--r--   1 root   sys10485853 Apr 18 14:39 update-1.log.13
>-rw-r--r--   1 root   sys10485779 Apr 18 14:46 update-1.log.12
>-rw-r--r--   1 root   sys10485822 Apr 18 14:54 update-1.log.11
>-rw-r--r--   1 root   sys10485864 Apr 18 14:59 update-1.log.10
>-rw-r--r--   1 root   sys10485770 Apr 18 15:03 update-1.log.9
>-rw-r--r--   1 root   sys10485801 Apr 18 15:07 update-1.log.8
>-rw-r--r--   1 root   sys10485795 Apr 18 15:14 update-1.log.7
>-rw-r--r--   1 root   sys10485810 Apr 18 15:22 update-1.log.6
>-rw-r--r--   1 root   sys10485762 Apr 18 15:29 update-1.log.5
>-rw-r--r--   1 root   sys10485844 Apr 18 15:37 update-1.log.4
>-rw-r--r--   1 root   sys10485813 Apr 18 15:45 update-1.log.3
>-rw-r--r--   1 root   sys10485806 Apr 18 15:53 update-1.log.2
>-rw-r--r--   1 root   sys10485769 Apr 18 16:00 update-1.log.1
>-rw-r--r--   1 root   sys10485853 Apr 18 16:07 update-1.log.0
>-rw-r--r--   1 root   sys8108342 Apr 18 16:13 update-1.log
>
>what these files are is a whole lot of lines that look like (broken by me):
>
>18-Apr-2002 16:16:05.491 security: notice: \
>denied update from [63.198.141.30].2323 for "168.192.in-addr.arpa" IN
>
>by "a whole lot" i mean we've logged 3.3M of these in the last four hours.
>
>so who are these people and why are they sending dynamic updates for rfc1918
>address space PTR's?  second answer first: it's probably Windows' fault.
>after a successful DHCP transaction, the corresponding A RR and PTR RR have
>to be updated.  if rfc1918 is in use, dns transactions about these PTR's
>ought to be caught and directed toward some local server, who can do something
>useful with them.  this loca