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