[AusNOG] IPv6 reverse DNS and Mail ...

[Mark Andrews]

In message <CAHgLLqbr86L2zOndvb-MtkQjYi_PVH8p-PTa9LO2qWPSPrsCYg at mail.gmail.com>, Peter Tiggerdine writes:
> 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.

No it doesn't.  You can host your own nameservers.  Been doing that for
the last 20 years.  If you choose to outsource your DNS management then
you need to talk to whomever you outsourced it to.
 
> 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"

If you care about security you would all run MTA's at home and force
STARTTLS for all connections.  It is total BS to require a residential
user to pay commercial rates because they want to run a MTA at home.

> > For seconds, nothing stops working if the reverses are missing or
> > wrong.
> 
> 
> Email and DNS (every tried to remove PTR for a name server?)

DNS doesn't give a whoot about PTR records existing or not.  The
only part of DNS that ever cared about PTR records was nslookup and
those checks where removed over a decade ago.

> > 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
> >
> 
> --001a11c23f64cc3a7904dd20e328
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <br><br><div class=3D"gmail_quote">On Mon, May 20, 2013 at 4:25 PM, Mark De=
> lany <span dir=3D"ltr"><<a href=3D"mailto:g2x at juliet.emu.st" target=3D"_=
> blank">g2x at juliet.emu.st</a>></span> wrote:<br><blockquote class=3D"gmai=
> l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
> :1ex">
> <div class=3D"im">On 20May13, Peter Tiggerdine allegedly wrote:<br>
> <br>
> > So we should all just ignore RFC's because our largest trading par=
> tner<br>
> > decide they don't to play by the same rules as the rest of the wor=
> ld.. WTF?.<br>
> <br>
> </div>For some reason you think that all RFCs are perfect and are always<br=
> >
> pragmatically based. Where did you get that idea from?<br>
> <br></blockquote><div><br></div><div>"Rules are rules Jacko" RFC&=
> #39;s allow us to all have a common understanding of what to expect. If you=
> r software and implementation can't pass RFC compliance then you should=
>  find a better vendor and implementation engineer.</div>
> <div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
> ex;border-left:1px #ccc solid;padding-left:1ex">
> Geeks have been banging the "must have a reverse" drum for, what,=
>  20<br>
> years now? The evidence is in, it's a lost cause because time-pressed<b=
> r>
> admins rarely waste their time on useless fluff that is a maintenance<br>
> headache.<br>
> <div class=3D"im"><br></div></blockquote><div><br></div><div>I'd like t=
> o see how you come up with that "evidence" sounds more hearsay an=
> d=C2=A0circumstantial=C2=A0than anything else. =C2=A0Real network admin and=
>  email admin know PTR is mandatory.</div>
> <div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
> ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im">
> > How exactly is it more difficult than forward records?<br>
> <br>
> </div>Well, for a start arranging the delegation of reverse can be a lot<br=
> >
> more difficult. If your ISP doesn't do a good job, </blockquote><div><b=
> r>Find a new ISP. Simple resolution. Real ISP with business customers know =
> the story an have systems in place.</div><div>=C2=A0</div><blockquote class=
> =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
> ing-left:1ex">
> or doesn't want to<br>
> delegate you have zero recourse. Managing your forwards is completely<br>
> under your control and does not require co-operation from any upstream<br>
> delegation.<br></blockquote><div><br></div><div>Disgree entirely. Managing =
> forward requires the co-operation of the DNS hosting provider, not mention =
> your ISP to correctly route traffic.</div><div>=C2=A0</div><div>Sounds more=
>  like "WAA" I tried to run a mail server off a residental link be=
> cause I didn't want to pay for system and SLA WAA"</div>
> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
> ;border-left:1px #ccc solid;padding-left:1ex">
> <br>
> For seconds, nothing stops working if the reverses are missing or<br>
> wrong. </blockquote><div><br></div><div>Email and DNS (every tried to remov=
> e PTR for a name server?)</div><div>=C2=A0</div><blockquote class=3D"gmail_=
> quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
> ex">
> Third, if they get out-of-date nothing knows or cares. </blockquote><div><b=
> r></div><div>span filters care as do your customers when there email starts=
>  to get blocked.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
> yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Forth,<br>
> if you make completely bogus entries in your reverses, you make the<br>
> RFC Police happy, but what is that really achieving apart from<br>
> demonstrating basic scripting skills?<br></blockquote><div><br></div><div>I=
> t demonstrates that the IP owner knows your running a mail server as they&#=
> 39;ve put records in or you've setup=C2=A0sufficient=C2=A0infrastructur=
> e to handle PTR as the owner of the IP space.</div>
> <div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
> ex;border-left:1px #ccc solid;padding-left:1ex">
> <br>
> In any event, it's not a question of difficulty, it's a question of=
> <br>
> cost/benefit. And as we see all the time, a lot of places don't<br>
> believe that one exists.<br></blockquote><div><br></div><div>Cost of you do=
> n't do it, YMMV on email reachability.</div><div><br></div><div>Cost if=
>  you do, everything works include SPF records.</div><div>=C2=A0</div><block=
> quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
>  solid;padding-left:1ex">
> 
> <br>
> When you block on a missing reverse, you're mostly using that as a<br>
> proxy to recognize an overworked or under-trained admin or a<br>
> recalcitrant upstream provider. None of these have much bearing on<br>
> what is being run on that IP.<br></blockquote><div><br></div><div>Refer to =
> find another ISP or hire more admins. Not a technical problem.</div><div>=
> =C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
> rder-left:1px #ccc solid;padding-left:1ex">
> 
> <br>
> So I guess if your goal is to punish an overworked admin, continue to<br>
> block away.<br>
> <br></blockquote><div>My goal is to reduce spam and protect my users and th=
> e=C2=A0infrastructure. OH&S issue there also. =C2=A0=C2=A0</div><div>=
> =C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
> rder-left:1px #ccc solid;padding-left:1ex">
> 
> <br>
> The other problem is that spammers are well aware that a lack of<br>
> reverse is used by some naive filters, so guess what? They retry the<br>
> same payload to you from another IP if the first IP fails. They will<br>
> keep going until one of their IPs is accepted by you.<br>
> <br>
> You may smugly think you've blocked them, and they smugly know that<br>
> they got to you via another route.<br></blockquote><div><br></div><div>doub=
> t it. It's call perimeter audits. Do it.</div><div>=C2=A0</div><blockqu=
> ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
> olid;padding-left:1ex">
> 
> <br>
> For those who believe that blocking an a lack of reverse truly stops<br>
> spam, how do you know it didn't show up some time later on an IP that<b=
> r>
> happens to have a reverse?<br></blockquote><div><br></div><div>Strawman arg=
> uement - ignoring.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
> style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> <div class=3D"HOEnZb"><div class=3D"h5"><br>
> <br>
> Mark.<br>
> _______________________________________________<br>
> AusNOG mailing list<br>
> <a href=3D"mailto:AusNOG at lists.ausnog.net">AusNOG at lists.ausnog.net</a><br>
> <a href=3D"http://lists.ausnog.net/mailman/listinfo/ausnog" target=3D"_blan=
> k">http://lists.ausnog.net/mailman/listinfo/ausnog</a><br>
> </div></div></blockquote></div><br>
> 
> --001a11c23f64cc3a7904dd20e328--
> 
> --===============8798412078928498372==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
> 
> --===============8798412078928498372==--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org