>
> Hello! This is [EMAIL PROTECTED],
>
> I am taking a proactive approach to screening my emails so that I don't get
> junk mail.
>
> Please just click on the link below so I can get your message, and all your
> future messages. You only have to do this ONCE!
Kurt, and our friends at CNW,
>
>
>
> On Fri, 13 Jan 2006, Jeffrey I. Schiller wrote:
>
> >
> > Let me attempt to bring this back to the policy question.
> >
> > Does someone have the *right* to put one of your IP addresses as an NS
> > record for their domain even if you do not agree?
>
> Probably this is a multifaceted
>
>
>
> On Fri, 13 Jan 2006, Joe Abley wrote:
>
> > It seems to me that if someone else chooses to insert 32- or 128-bit
> > integers
> > of their choice into their zone files, then there's properly very little I
> > can or should be able to do about it. But that's just me.
>
> So I'm sure
On Fri, 13 Jan 2006, Joe Abley wrote:
It seems to me that if someone else chooses to insert 32- or 128-bit integers
of their choice into their zone files, then there's properly very little I
can or should be able to do about it. But that's just me.
So I'm sure you would not mind (and would
On Fri, 13 Jan 2006, Randy Bush wrote:
> > it is a best practice to separate authoritative and recursive servers.
> e.g. a small isp has a hundred auth zones (secondaried far
> away and off-net, of course) and runs cache. why should
> they separate auth from cache?
and it means that you can use
On Fri, 13 Jan 2006, Randy Bush wrote:
> > it is a best practice to separate authoritative and recursive servers.
>
> why?
>
> e.g. a small isp has a hundred auth zones (secondaried far away and
> off-net, of course) and runs cache. why should they separate auth from
> cache?
I absolutely hate
On Fri, 13 Jan 2006, Jeffrey I. Schiller wrote:
>
> Let me attempt to bring this back to the policy question.
>
> Does someone have the *right* to put one of your IP addresses as an NS
> record for their domain even if you do not agree?
Probably this is a multifaceted question :( So.. If I unde
On Fri, 13 Jan 2006, Martin Hannigan wrote:
> I heard something nasty about goatse.cx, but I checked www and I got:
>
> The registrar name servers have not been configured properly
>
> ..and nothing bad. I do think it's better to put up the page locally
> though.
>
> >
> > Granted that what your
>
>
> On Fri, 13 Jan 2006, Jeffrey I. Schiller wrote:
> > Let me attempt to bring this back to the policy question.
> >
> > Does someone have the *right* to put one of your IP addresses as an NS
> > record for their domain even if you do not agree?
> >
> > Registrar policies imply that this is s
On 13-Jan-2006, at 19:20, Sean Donelan wrote:
On Fri, 13 Jan 2006, Jeffrey I. Schiller wrote:
Let me attempt to bring this back to the policy question.
Does someone have the *right* to put one of your IP addresses as
an NS
record for their domain even if you do not agree?
Registrar polic
On Fri, 13 Jan 2006, Jeffrey I. Schiller wrote:
> Let me attempt to bring this back to the policy question.
>
> Does someone have the *right* to put one of your IP addresses as an NS
> record for their domain even if you do not agree?
>
> Registrar policies imply that this is so, and has been this
Let me attempt to bring this back to the policy question.
Does someone have the *right* to put one of your IP addresses as an NS
record for their domain even if you do not agree?
Registrar policies imply that this is so, and has been this way for a
long time.
A number of years ago (like 8-10 or
On Fri, Jan 13, 2006 at 12:57:22PM -1000, Randy Bush wrote:
> at root, i am a naggumite. erik nagum was good at describing
> why broken things should not be patched over. it's better to
> amplify breakage if that's what it takes to get it fixed asap.
In this case, the 'break' is only damaging if
at root, i am a naggumite. erik nagum was good at describing
why broken things should not be patched over. it's better to
amplify breakage if that's what it takes to get it fixed asap.
yes, this goes against "be liberal in what you accept." tough
patooties, that way lies entropic death.
an ana
On Fri, Jan 13, 2006 at 12:09:51PM -1000, Randy Bush wrote:
>
> > Well, RFC2010 section 2.12 hints at cache pollution attacks, and that's
> > been discussed already. Note that I can't seem to find the same claim
> > in RFC2870, which obsoletes 2010 (and the direction against recursive
> > servic
On Fri, Jan 13, 2006 at 12:07:11PM -1000, Randy Bush wrote:
> and thereby hiding the fact that someone has either lame delegated
> or i have forgotten to remove an auth zone, both cases i want to
> catch. not a win here.
Responding with stale data is, arguably, more damaging than failing
to respo
> I'm curious if the rest of my response was lost on you due to its
> verbosity?
no. it seemed to apply in some cases, and not in others. so
it was useful info, but did not seem to be completely relevant
to the more unconditional original position "it is a best
practice to separate authoritativ
On Fri, Jan 13, 2006 at 12:09:51PM -1000, Randy Bush wrote:
> > Well, RFC2010 section 2.12 hints at cache pollution attacks, and that's
> > been discussed already. Note that I can't seem to find the same claim
> > in RFC2870, which obsoletes 2010 (and the direction against recursive
> > service is
On 13-Jan-2006, at 17:07, Randy Bush wrote:
it is a best practice to separate authoritative and recursive
servers.
why?
Because it prevents stale, authoritative data on your nameservers
being returned to intermediate-mode resolvers in the form of
apparently authoritative answers, bypassing
> Well, RFC2010 section 2.12 hints at cache pollution attacks, and that's
> been discussed already. Note that I can't seem to find the same claim
> in RFC2870, which obsoletes 2010 (and the direction against recursive
> service is still there).
despite others saying that 2870 should apply to ser
>>> it is a best practice to separate authoritative and recursive
>>> servers.
>> why?
> Because it prevents stale, authoritative data on your nameservers
> being returned to intermediate-mode resolvers in the form of
> apparently authoritative answers, bypassing a valid delegation chain
>
On Fri, Jan 13, 2006 at 03:29:15AM +, Christopher L. Morrow wrote:
...
> Some vendors have asked and received this sort of thing, does huwei (which
> I butchered the spelling of) want one? (or need one?) how about netgear
> and their lovely NTP issue? or checkpoint or ... there are quite a few
On Fri, Jan 13, 2006 at 01:47:48PM -0800, David W. Hankins wrote:
> On Fri, Jan 13, 2006 at 10:09:51AM -1000, Randy Bush wrote:
> > > it is a best practice to separate authoritative and recursive
> > > servers.
> > why?
> I'm not sure anyone can answer that question. I certainly can't.
> Not
Title: Worm?
Anyone know about a new worm going around? Our IPS vendor says that they have a number of customers affected by traffic volume, but I don’t know any details.
Thanks,
David Byrne
Corporate IT Security
EchoStar Satellite L.L.C.
720-514-5675
[EMAIL PROTECTED]
On Fri, Jan 13, 2006 at 10:09:51AM -1000, Randy Bush wrote:
> > it is a best practice to separate authoritative and recursive servers.
>
> why?
I'm not sure anyone can answer that question. I certainly can't.
Not completely, anyway. There are too many variables and motivations.
Some remember t
On 13-Jan-2006, at 15:09, Randy Bush wrote:
it is a best practice to separate authoritative and recursive
servers.
why?
Because it prevents stale, authoritative data on your nameservers
being returned to intermediate-mode resolvers in the form of
apparently authoritative answers, bypa
in named.conf
zone "2.96.192.in-addr.arpa"{ type master; file "primary/bogus.ia";
};
in the zone file
* PTR
some.schmuck.lame.delegated.to.RAIN.PSG.COM.
or
zone "someschmuck.com" { type master; file "primary/bogus.fwd";
};
and
@ MX
In message <[EMAIL PROTECTED]>, Michael Loftis writ
es:
>
>
>
>--On January 13, 2006 10:09:51 AM -1000 Randy Bush <[EMAIL PROTECTED]> wrote:
>
>>
>>> it is a best practice to separate authoritative and recursive servers.
>>
>> why?
>
>Cache poisoning (though this is less likely with more modern bi
> Cache poisoning
let's assume that we're not dealing with the bugs of old
versions of server software
randy
--On January 13, 2006 10:09:51 AM -1000 Randy Bush <[EMAIL PROTECTED]> wrote:
it is a best practice to separate authoritative and recursive servers.
why?
Cache poisoning (though this is less likely with more modern bind's and
other resolvers) and the age old your view is NOT the same a
>
>
> On Fri, 2006-01-13 at 08:32 -1000, Randy Bush wrote:
> > > Don't forget:
> > > wwwIN CNAME goatse.cx
> >
> > and don't forget the terminating dot on goatse.cx.
> >
> > but this did cause me to update those trapper zone files and
> > bump the serials.
> it is a best practice to separate authoritative and recursive servers.
why?
e.g. a small isp has a hundred auth zones (secondaried far
away and off-net, of course) and runs cache. why should
they separate auth from cache?
randy
Assuming that you are running separate authoritative and recursive servers this
would only be a problem when someone goes to a lame-delegated domain.
It is probably also good to note that it is a best practice to separate
authoritative and recursive servers.
john
-Ursprüngliche Nachric
On Fri, 2006-01-13 at 08:32 -1000, Randy Bush wrote:
> > Don't forget:
> > wwwIN CNAME goatse.cx
>
> and don't forget the terminating dot on goatse.cx.
>
> but this did cause me to update those trapper zone files and
> bump the serials. last time the serials
> Don't forget:
> wwwIN CNAME goatse.cx
and don't forget the terminating dot on goatse.cx.
but this did cause me to update those trapper zone files and
bump the serials. last time the serials had been bumped since
1995. so you had the suggestion of a decade.
On Fri, 13 Jan 2006, Randy Bush wrote:
>
> > Maybe not such an odd question; Anywhoo, we have quite a few
> > people who register our IP addresses as nameservers, and then never
> > delete the records. I don't suppose there is any way that we can delete
> > these old records, we have appealed
This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.
Daily listings are sent to [EMAIL PROTECTED]
If you have any comments please contact Philip Smith <[EMAIL PROTECTED]>.
Routing Table Report 04:00 +10GMT Sat 14 Jan, 2006
> Maybe not such an odd question; Anywhoo, we have quite a few
> people who register our IP addresses as nameservers, and then never
> delete the records. I don't suppose there is any way that we can delete
> these old records, we have appealed to multiple registrars such as
> godaddy, enom,
Maybe not such an odd question; Anywhoo, we have quite a few
people who register our IP addresses as nameservers, and then never
delete the records. I don't suppose there is any way that we can delete
these old records, we have appealed to multiple registrars such as
godaddy, enom, and the
This report has been generated at Fri Jan 13 21:46:55 2006 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table Hist
40 matches
Mail list logo
