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,
>
At 4:57 PM -0700 4/18/02, 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 th
On Thu, 18 Apr 2002, Paul Vixie wrote:
[snip]
> 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
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
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 a
>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 the
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
> broadb
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
> > 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 addr
> > 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
On 4/19/02 4:19 AM, "bert hubert" <[EMAIL PROTECTED]> wrote:
> 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.
A) not all failed update attempts should be ignored
B) putting your head in the sand typ
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 possib
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.mic
(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
> Why do we bother having "public" nameservers answering for this space at all?
>
> Why don't we have "blackhole-[12].iana.org" have A records of "127.0.0.1"?
127.0.0.1 is a convention, not a standard. and to the extent that it is ever
upgraded to a standard, i don't think putting A RR's point
>>> 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 addre
On 19 Apr 2002, Paul Vixie wrote:
> > Why do we bother having "public" nameservers answering for this space at all?
> > Why don't we have "blackhole-[12].iana.org" have A records of "127.0.0.1"?
>
> 127.0.0.1 is a convention, not a standard. and to the extent that it is eve
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
"Martin J. Levy" wrote:
> 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 have a very simple patch to BIND 8.3.1 to create a category just
for these requests so that they can easily be sent to th
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 eventua
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
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 poli
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
> Behalf Of Doug Barton
> Sent: April 19, 2002 2:56 PM
> To: [EMAIL PROTECTED]
> Subject: Re: is your host or dhcp server sending dns dynamic
> updatesfor rfc1918?
>
> Also, since I operate authoritative
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> [EMAIL PROTECTED]
> Sent: Friday, April 19, 2002 6:39 AM
> To: Greg Maxwell
> Cc: [EMAIL PROTECTED]
> Subject: Re: is your host or dhcp server sending dns dynamic
> updates for
> rfc1918?
>
>
> On Fr
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
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 broke
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?
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
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
29 matches
Mail list logo
