[AusNOG] IPv6 reverse DNS and Mail ...

[Peter Tiggerdine]

On Mon, May 20, 2013 at 4:25 PM, Mark Delany <g2x at juliet.emu.st> wrote:

> On 20May13, Peter Tiggerdine allegedly wrote:
>
> > So we should all just ignore RFC's because our largest trading partner
> > decide they don't to play by the same rules as the rest of the world..
> WTF?.
>
> For some reason you think that all RFCs are perfect and are always
> pragmatically based. Where did you get that idea from?
>
>
"Rules are rules Jacko" RFC's allow us to all have a common understanding
of what to expect. If your software and implementation can't pass RFC
compliance then you should find a better vendor and implementation engineer.


> Geeks have been banging the "must have a reverse" drum for, what, 20
> years now? The evidence is in, it's a lost cause because time-pressed
> admins rarely waste their time on useless fluff that is a maintenance
> headache.
>
>
I'd like to see how you come up with that "evidence" sounds more hearsay
and circumstantial than anything else.  Real network admin and email admin
know PTR is mandatory.


> > How exactly is it more difficult than forward records?
>
> Well, for a start arranging the delegation of reverse can be a lot
> more difficult. If your ISP doesn't do a good job,


Find a new ISP. Simple resolution. Real ISP with business customers know
the story an have systems in place.


> or doesn't want to
> delegate you have zero recourse. Managing your forwards is completely
> under your control and does not require co-operation from any upstream
> delegation.
>

Disgree entirely. Managing forward requires the co-operation of the DNS
hosting provider, not mention your ISP to correctly route traffic.

Sounds more like "WAA" I tried to run a mail server off a residental link
because I didn't want to pay for system and SLA WAA"


> For seconds, nothing stops working if the reverses are missing or
> wrong.


Email and DNS (every tried to remove PTR for a name server?)


> Third, if they get out-of-date nothing knows or cares.


span filters care as do your customers when there email starts to get
blocked.


> Forth,
> if you make completely bogus entries in your reverses, you make the
> RFC Police happy, but what is that really achieving apart from
> demonstrating basic scripting skills?
>

It demonstrates that the IP owner knows your running a mail server as
they've put records in or you've setup sufficient infrastructure to handle
PTR as the owner of the IP space.


>
> In any event, it's not a question of difficulty, it's a question of
> cost/benefit. And as we see all the time, a lot of places don't
> believe that one exists.
>

Cost of you don't do it, YMMV on email reachability.

Cost if you do, everything works include SPF records.


>
> When you block on a missing reverse, you're mostly using that as a
> proxy to recognize an overworked or under-trained admin or a
> recalcitrant upstream provider. None of these have much bearing on
> what is being run on that IP.
>

Refer to find another ISP or hire more admins. Not a technical problem.


>
> So I guess if your goal is to punish an overworked admin, continue to
> block away.
>
> My goal is to reduce spam and protect my users and the infrastructure.
OH&S issue there also.


>
> The other problem is that spammers are well aware that a lack of
> reverse is used by some naive filters, so guess what? They retry the
> same payload to you from another IP if the first IP fails. They will
> keep going until one of their IPs is accepted by you.
>
> You may smugly think you've blocked them, and they smugly know that
> they got to you via another route.
>

doubt it. It's call perimeter audits. Do it.


>
> For those who believe that blocking an a lack of reverse truly stops
> spam, how do you know it didn't show up some time later on an IP that
> happens to have a reverse?
>

Strawman arguement - ignoring.


>
>
> Mark.
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20130520/e0aec182/attachment.html>