[AusNOG] IPv6 reverse DNS and Mail ...

[Mick O'Rourke]

Hi Mark,

Has much changed with BIND since your Aug 2009 (link below) regarding
dynamic and not pre-generation of these types of records? I've found a
mention in the Bind10 wiki IdeaDump yet haven't been able to find any
references beyond that.

https://lists.isc.org/pipermail/bind-users/2009-August/077526.html

Kind Regards,

Mick

-


On Mon, May 20, 2013 at 5:26 PM, Mark Andrews <marka at isc.org> wrote:

>
> 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
> _______________________________________________
> 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/a3acd989/attachment.html>