Larry Blunk wrote the following on 11/3/2011 12:47 PM:
On 11/02/2011 05:57 PM, Matt Chung wrote:
I work for a regional ISP and very recently there has been an influx of
calls reporting "slowness" when accessing certain websites (i.e
google.com/voice/b) via HTTP. After performing a tcpdump and
In message <41f6c547ea49ec46b4ee1eb2bc2f341849f82d4...@exvpmbx100-1.exc.icann.o
rg>, Leo Vegoda writes:
> Mark Andrew wrote:
>
> [...]
>
> > > That said though the PTR->forward->PTR check is a proper check and a
> > > really great way to figure out if the source SMTP host was actually set
> > >
Mark Andrew wrote:
[...]
> > That said though the PTR->forward->PTR check is a proper check and a
> > really great way to figure out if the source SMTP host was actually set
> > up with at least some admin doing it the right way. If they can't be
> > bothered to set that up, why should you bother
On 2011-11-08 13:27 , Mark Andrews wrote:
> In message <4eb90ef2.3030...@unfix.org>, Jeroen Massar writes:
>> On 2011-11-08 12:05 , Mark Andrews wrote:
>>> In message <4eb8f028.8040...@dds.nl>, Seth Mos writes:
>> [..]
>>> Sounds like FUD. Who has trusted the contents of a PTR record in the
>>> la
In message <4eb90ef2.3030...@unfix.org>, Jeroen Massar writes:
> On 2011-11-08 12:05 , Mark Andrews wrote:
> > In message <4eb8f028.8040...@dds.nl>, Seth Mos writes:
> [..]
> > Sounds like FUD. Who has trusted the contents of a PTR record in the
> > last 2 decades?
>
> Lots of tools (read: SSH,
On 2011-11-08 12:05 , Mark Andrews wrote:
> In message <4eb8f028.8040...@dds.nl>, Seth Mos writes:
[..]
> Sounds like FUD. Who has trusted the contents of a PTR record in the
> last 2 decades?
Lots of tools (read: SSH, Spam-checks, oh and IRCd's ;) trust PTR, but
only if the reverse => forward =>
On Tue, Nov 08, 2011 at 10:05:12PM +1100, Mark Andrews wrote:
>
> In message <4eb8f028.8040...@dds.nl>, Seth Mos writes:
> > On 7-11-2011 14:46, sth...@nethelp.no wrote:
> > >>> The practice of filling out the reverse zone with fake PTR record
> > >>> started before there was wide spread support f
In message <4eb8f028.8040...@dds.nl>, Seth Mos writes:
> On 7-11-2011 14:46, sth...@nethelp.no wrote:
> >>> The practice of filling out the reverse zone with fake PTR record
> >>> started before there was wide spread support for UPDATE/DNS. There
> >>> isn't any need for this to be done anymore.
On 7-11-2011 14:46, sth...@nethelp.no wrote:
>>> The practice of filling out the reverse zone with fake PTR record
>>> started before there was wide spread support for UPDATE/DNS. There
>>> isn't any need for this to be done anymore. Machines are capable
>>> of adding records for themselves.
>>
>
On 7 Nov 2011, at 14:03, "Bjørn Mork" wrote:
> Leigh Porter writes:
>
>> Indeed, there is no way I would allow that either. But really,
>> providing a reverse zone and forward zone to match is a case of five
>> minutes and a shell script or a DNS that as Steinar said, will
>> synthesise resul
Leigh Porter writes:
> Indeed, there is no way I would allow that either. But really,
> providing a reverse zone and forward zone to match is a case of five
> minutes and a shell script or a DNS that as Steinar said, will
> synthesise results.
>
> It's really not all that difficult..
No, not at
On 7 Nov 2011, at 13:48, "sth...@nethelp.no" wrote:
>>> The practice of filling out the reverse zone with fake PTR record
>>> started before there was wide spread support for UPDATE/DNS. There
>>> isn't any need for this to be done anymore. Machines are capable
>>> of adding records for thems
> > The practice of filling out the reverse zone with fake PTR record
> > started before there was wide spread support for UPDATE/DNS. There
> > isn't any need for this to be done anymore. Machines are capable
> > of adding records for themselves.
>
> How do I setup this for DHCPv6-PD? Say, I d
On 2 November 2011 17:57, Matt Chung wrote:
> I work for a regional ISP and very recently there has been an influx of
> calls reporting "slowness" when accessing certain websites (i.e
> google.com/voice/b) via HTTP. *snip*
>
I have been experiencing this same issue as an end user, my ISP does n
On Mon, Nov 7, 2011 at 1:34 AM, wrote:
> On Mon, 07 Nov 2011 01:09:19 CST, Robert Bonomi said:
>> You're missing some 'obvious' considerations. Consider a spam complaint
>> sent with 'full headers' included. The rDNS _at_the_time_of_the_crime_
>> is present in the complaint.
> And if the rDNS i
On Mon, 07 Nov 2011 01:09:19 CST, Robert Bonomi said:
> You're missing some 'obvious' considerations. Consider a spam complaint
> sent with 'full headers' included. The rDNS _at_the_time_of_the_crime_
> is present in the complaint.
And if the rDNS isn't provided, any sane MTA will have included
Tom Lanyon opined:
> >> OK.. let's say you're a DSL provider. Are you going to have your
> >> DHCP server populating the forward and reverse DNS? With what, the
> >> account holder's name?somename.example.com ?
> >
> > I'll suggest that (a) IF the addresses do migrate among different c
Mark Andrews writes:
> The practice of filling out the reverse zone with fake PTR record
> started before there was wide spread support for UPDATE/DNS. There
> isn't any need for this to be done anymore. Machines are capable
> of adding records for themselves.
How do I setup this for DHCPv6-PD
On Nov 6, 2011, at 6:57 PM, Jimmy Hess wrote:
> On Sun, Nov 6, 2011 at 7:10 PM, Mark Andrews wrote:
>> MacOS and Windows can both populate the reverse zone for you as can
>> dhcp servers.
>> The practice of filling out the reverse zone with fake PTR record [...]
>
> OK.. let's say you're a DSL
In message
, Jimmy Hess writes:
> On Sun, Nov 6, 2011 at 7:10 PM, Mark Andrews wrote:
> > MacOS and Windows can both populate the reverse zone for you as can
> > dhcp servers.
> > The practice of filling out the reverse zone with fake PTR record [...]
>
> OK.. let's say you're a DSL provider.
On 07/11/2011, at 12:46 PM, Robert Bonomi wrote:
>> OK.. let's say you're a DSL provider. Are you going to have your
>> DHCP server populating the forward and reverse DNS? With what, the
>> account holder's name?somename.example.com ?
>
> I'll suggest that (a) IF the addresses do migrate
Once upon a time, Robert Bonomi said:
> I'll suggest that (a) IF the addresses do migrate among different customers
> of the ISP, (b) the addresses handed out are publicly routable, AND (c) the
> CPE has to 'authenticate' itself to the head-end, then it is _very_ useful
> *to*the*ISP* to have dyn
> From nanog-bounces+bonomi=mail.r-bonomi@nanog.org Sun Nov 6 19:58:58
> 2011
> Date: Sun, 6 Nov 2011 19:57:51 -0600
> Subject: Re: Performance Issues - PTR Records
> From: Jimmy Hess
> To: Mark Andrews
> Cc: nanog@nanog.org
>
> On Sun, Nov 6, 2011 at 7
On Sun, Nov 6, 2011 at 7:10 PM, Mark Andrews wrote:
> MacOS and Windows can both populate the reverse zone for you as can
> dhcp servers.
> The practice of filling out the reverse zone with fake PTR record [...]
OK.. let's say you're a DSL provider. Are you going to have your
DHCP server popul
In message , Tom Lanyon wri
tes:
> On 05/11/2011, at 1:14 PM, Paul Ebersman wrote:
> > tim> If PTR exists in zone file, serve it. Else, synthesize generic
> > tim> reverse. Jobsagoodun.
> >=20
> > If all we're doing is lying with some generic answer that we hack our
> > server to produce, why ar
On 05/11/2011, at 1:14 PM, Paul Ebersman wrote:
> tim> If PTR exists in zone file, serve it. Else, synthesize generic
> tim> reverse. Jobsagoodun.
>
> If all we're doing is lying with some generic answer that we hack our
> server to produce, why are we bothering?
Because some applications rely
- Original Message -
> From: "Jimmy Hess"
> There is no need for me to physically create 64k*4bil*4bil on a disk or
> memory area
> somewhere. I can make a plugin for my DNS server to hand you the generic
> result
> when you ask my DNS server what something reverses to...
>
> That is,
tim> If PTR exists in zone file, serve it. Else, synthesize generic
tim> reverse. Jobsagoodun.
If all we're doing is lying with some generic answer that we hack our
server to produce, why are we bothering?
At that point, you're not proving clue. You're proving you at least
bought a solution fr
On Fri, Nov 4, 2011 at 11:28 AM, Paul Ebersman wrote:
> It's already been pointed out that lame delegations are more likely
> problems for many. But the "we'll just pre-fill in-addr to avoid
> problems" isn't going to work for ip6.arpa. If anyone has enough
> hardware to serve the zone for a /48 (
> It's already been pointed out that lame delegations are more likely
> problems for many. But the "we'll just pre-fill in-addr to avoid
> problems" isn't going to work for ip6.arpa. If anyone has enough
> hardware to serve the zone for a /48 (64k * 4bil * 4bil *
> bytes-in-record), I'd love to see
paul4004> It is entirely possible they have it pointed to their
paul4004> non-existent or broken DNS. Given current best practices, I
paul4004> see no reason not to assign a generic
paul4004> x.x.x.x-dynamic.customer.isp.com DNS across their netblock.
It's already been pointed out that lame dele
On 11/02/2011 05:57 PM, Matt Chung wrote:
I work for a regional ISP and very recently there has been an influx of
calls reporting "slowness" when accessing certain websites (i.e
google.com/voice/b) via HTTP. After performing a tcpdump and analyzing the
session, I have been able to pinpoint the l
On Wed, Nov 2, 2011 at 8:33 PM, Larry Smith wrote:
> On Wed November 2 2011 20:27, Matt Chung wrote:
>> I assumed that the applications would take absent records into
> When you mis-place your keys do you only look in one place and then give
> up? The calling server does not know there is "no" re
On Wed November 2 2011 20:27, Matt Chung wrote:
> I assumed that the applications would take absent records into
> consideration instead of waiting and timing out before responding with
> data. Trying to troubleshoot this issue from the limited visibility is
> difficult ; the latency the applicatio
We really have no objections to creating records for our IPs however there was
no compelling reason previously. With the manifestation of performance issues,
we are currently creating a generic record for our addresses.
I assumed that the applications would take absent records into consideratio
PC wrote:
> What happens if the ISP never defines a name server with their RIR for
> their provider-independent address space? Does ARIN point to somewhere
> which supplies NXDOMAIN? Just a thought -- I don't have a clue.
>
> It is entirely possible they have it pointed to their non-existent or
What happens if the ISP never defines a name server with their RIR for
their provider-independent address space? Does ARIN point to somewhere
which supplies NXDOMAIN? Just a thought -- I don't have a clue.
It is entirely possible they have it pointed to their non-existent or
broken DNS. Given c
On Wed, Nov 2, 2011 at 6:08 PM, Barry Shein wrote:
> Another practical problem with this approach is that .IN is India but
> hey, at least it blocks something :-)
There are also some services out there that block connections
entirely, if the user doesn't have a PTR record.
I'm thinking IRC server
On Nov 2, 2011, at 5:57 PM, Matt Chung wrote:
> I work for a regional ISP and very recently there has been an influx of
> calls reporting "slowness" when accessing certain websites (i.e
> google.com/voice/b) via HTTP. After performing a tcpdump and analyzing the
> session, I have been able to pin
> As a web host, we frequently find customers who have
> added Apache rules to their ecommerce sites to block
> undesirable traffic, such as credit card scammers, etc.
> Not knowing any better, they often do this by just
> blocking anything that ends in .in to block Indonesia
> for example.
From: Matthew Palmer [mailto:mpal...@hezmatt.org]
>
> That's even less effective than you'd naively expect, given
> that Indonesia's
> TLD is .id...
>
Umm yeah, simple typo, but I appreciate the help.
On Wed, Nov 02, 2011 at 06:12:21PM -0400, David Hubbard wrote:
> From: Matt Chung [mailto:itsmemattch...@gmail.com]
> > Historically, there was no compelling reason to create PTR
> > records for our CPE however more and more applications seem
> > to be dependent on it. Although we will be assign
From: Matt Chung [mailto:itsmemattch...@gmail.com]
>
> Historically, there was no compelling reason to create PTR
> records for our CPE however more and more applications seem
> to be dependent on it. Although we will be assigning a
> record for each address, my question is why
> is the appli
On 11/2/2011 2:57 PM, Matt Chung wrote:
Although we will be assigning a record for each address, my question is why
is the application (specifically HTTP) dependent on a reverse record ?
What is the purpose?
HTTP has no requirement that the connecting client have reverse DNS
setup. Some serv
I work for a regional ISP and very recently there has been an influx of
calls reporting "slowness" when accessing certain websites (i.e
google.com/voice/b) via HTTP. After performing a tcpdump and analyzing the
session, I have been able to pinpoint the latency at the application
layer. After the
45 matches
Mail list logo
