Re: [DNSOP] Possible slower response with minimization

In message <545b54d3.50...@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: > Paul Vixie wrote: > > >>> Right, NXDOMAIN returned by some broken implementation to empty > >>> non-terminals MUST NOT be interpreted that the terminals does not > >>> exist. > > > > i disagree with this. broken impl

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

In message <20141106152435.7ad4caa0...@fafnir.remote.dragon.net>, Paul Ebersman writes: > > marka> For in-addr.arpa you already have a PTR records. Allowing the > marka> end user to set its content does not increase the amount of data > marka> you are serving. It does increase the amount of ch

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

phoffman> Do we know whether typical PTR checks look for existence or phoffman> matching? johnl> The ones I know all look for matching. For MX/spam and for VPNs, seems to want matching. For more "fringe" uses like NYT web, seems to just want a non-NXDOMAIN response. I'd be nervous about wildc

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

On Thu, Nov 06, 2014 at 09:41:57AM -0800, Paul Hoffman wrote: > Do we know whether typical PTR checks look for existence or matching? It depends. (We covered this to some extent in that failed reverse-tree draft.) A -- Andrew Sullivan a...@anvilwalrusden.com __

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

> Evan Hunt > Thursday, November 06, 2014 9:46 AM > > I see. Too bad. Is it any more feasible to adjust expectations for v6 in > this respect than it was when we were talking about not providing PTR for > v6 in the first place? sadly, ipv6 isn't deployed enough that a v6-on

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

>> Most PTR checks look up the name to be sure there's a matching forward >> ( in this case) record, and ignore them if there isn't. > >I see. Too bad. Is it any more feasible to adjust expectations for v6 in >this respect than it was when we were talking about not providing PTR for >v6 in th

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

On Thu, Nov 06, 2014 at 09:41:57AM -0800, Paul Hoffman wrote: > I think Evan was proposing that home-ipv6-customer.isp.net would also exist, > so a PTR check that looked for *existence* would succeed, but one that looked > for *matching* would fail for most of those addresses. > > Do we know whe

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

> Paul Hoffman > Thursday, November 06, 2014 9:41 AM > > ... > > Do we know whether typical PTR checks look for existence or matching? in postfix, it's matching. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

>I think Evan was proposing that home-ipv6-customer.isp.net would also exist, >so a PTR check that looked for >*existence* would succeed, but one that looked for *matching* would fail for >most of those addresses. > >Do we know whether typical PTR checks look for existence or matching? The ones

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

On Thu, Nov 06, 2014 at 05:33:10PM -, John Levine wrote: > This turns out to be a Well Known Bad Idea (WKBI). > > Most PTR checks look up the name to be sure there's a matching forward > ( in this case) record, and ignore them if there isn't. I see. Too bad. Is it any more feasible to a

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

On Nov 6, 2014, at 9:33 AM, John Levine wrote: > >> stupid thing I've been wondering: Is there a reason not to use wildcard >> PTRs? >> >> $ORIGIN 6.7.6.2.7.6.7.0.1.0.0.2.ip6.arpa. >> * 604800 IN PTR home-ipv6-customer.isp.net. > > This turns out to be a Well Known

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

>stupid thing I've been wondering: Is there a reason not to use wildcard >PTRs? > >$ORIGIN 6.7.6.2.7.6.7.0.1.0.0.2.ip6.arpa. >* 604800 IN PTR home-ipv6-customer.isp.net. This turns out to be a Well Known Bad Idea (WKBI). Most PTR checks look up the name to be sure

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

On 11/5/14 12:50 PM, Paul Vixie wrote: > > >> Andrew Sullivan >> Wednesday, November 05, 2014 10:50 AM >> On Wed, Nov 05, 2014 at 10:19:59AM -0800, 神明達哉 wrote: >>> https://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06 >> ... >> ... I belie

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

On Thu, Nov 06, 2014 at 08:24:35AM -0700, Paul Ebersman wrote: > marka> Which won't work in IPv6 unless you syntesize the records on > marka> demand. > > And that's the plan, at least for $DAYJOB. And sign on the fly for those > of us signing our zones. I'm going to take the risk of embarrassing

Re: [DNSOP] Possible slower response with minimization

> Nicholas Weaver > Thursday, November 06, 2014 7:55 AM > > > ... > > Short of setting deliberate viral brush fires designed to brick old > devices, we're stuck with them and need to plan around them. BIND once had a 100% market share, and did a number of thing

Re: [DNSOP] Possible slower response with minimization

Paul Vixie wrote: > the internet has > hundreds of years to run yet, and these broken implementations are > (a) shrinking not growing, and (b) subject to rapid replacement when > they start to encounter problems with correct enhancements to their > habitat. Hh. Hahahah. HAHAHA. MUHAAHHAHAHAHAH

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

marka> For in-addr.arpa you already have a PTR records. Allowing the marka> end user to set its content does not increase the amount of data marka> you are serving. It does increase the amount of churn in the marka> zone. This draft isn't talking about v4. And $GENERATE or equiv already works i

Re: [DNSOP] Possible slower response with minimization

Paul Vixie wrote: >>> Right, NXDOMAIN returned by some broken implementation to empty >>> non-terminals MUST NOT be interpreted that the terminals does not >>> exist. > > i disagree with this. broken implementations who emit NXDOMAIN for > empty non-terminals cannot be used as an excuse not to de

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

sth...@nethelp.no wrote: > For our residential customers, we provide IPv4 PTRs which indicate > that this is a dynamic address. We *don't* plan to provide IPv6 PTRs > for those same customers. That's fine. But, what we need is opinions of ISPs which are allowing customers supply PTRs for IPv4, d

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

> > Putting my ISP hat on, I'd have to agree with the security/stability > > reasons (and several others I can think of). As of today, I have zero > > incentive to let my residential customers create their own PTR records. > > Better tools and systems may change this, but it would in any case be >

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

Mark Andrews wrote: > For in-addr.arpa you already have a PTR records. Allowing the end > user to set its content does not increase the amount of data you > are serving. It does increase the amount of churn in the zone. A > matching TCP source address is a good enough authenticator to permit >

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

Andrew Sullivan wrote: > Especially in the absence of strong anti-spoofing mechanisms, like > the DNS Security Extensions, a check for matching reverse DNS mapping > should be regarded as an extremely weak form of authentication. Considering that DNS Security Extension provides weak s