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 security only blindly relying on untrustworthy TTPs, it is better to say; Especially in the absence of strong anti-spoofing mechanisms, a check for matching reverse DNS mapping should be regarded as a weak form of authentication. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 *way* down on the priority list. Considering that PTRs generated by ISPs are too often useless, are you saying you won't provide PTRs? 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. Steinar Haug, AS 2116 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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, doesn't it? Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 develop and deploy correct protocol and software enhancements. My suggestion is just for robust minimization without sacrificing the correctness as NXDOMAIN for full domain name is interpreted as is. 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. How widely is EDNS deployed? IIRC, about 20 years ago, you said 2KB DNS message of DNSSEC was not a problem because EDNS takes care of it. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 in that most customers don't scream. I have no incentive to change to a more risky and complicated and hard to maintain system for v4. I'd contend that the folks who check v4 PTRs will have the same level of trust with auto-gen'ed v6 that they do with v4. Folks that don't trust it now still won't and those that find it acceptible in v4 will accept it in v6. marka The occasional customer will add a offensive PTR record which marka won't be seen by 99.9% of the world. [...] marka If we recommend that this is only done when a forward record is marka also successfully added UPDATE + TSIG (yes, this does scale for marka this use) you get rid of the PTR/A mis-match issues. And we're definitely not talking about allowing customers to do dynamic updates of forward records in this draft. If you want that currently, you get a business account or use one of the many services that allows that. Yes, it costs money. But most folks don't seem to miss it in the consumer world and those that do find someone willing to do it. marka For ip6.arpa you delegate to the customer along with the prefix marka delegation. The customer has to deal with the space issues but marka uses the same mechanisms to add the PTR records and cleanup. Because the mythical grandmother wants to deal with their own address space. Right... Most customers don't even know what DNS is, much less PTRs. They want to get content, send emails and pictures of cats. As an ISP, it's our job to make sure this works. $GENERATE in v4 does work. Auto-gen'ed PTRs in v6 works as well as $GENERATE, no better, no worse. marka You get the equivalent of $GENERATE with customer settable marka overrides using UPDATE over TCP. And I want 10s of millions of users doing TCP to my auth servers? I think not. Certainly not for something of so little gain to my customers. ebersman Anti-spam folks *like* it that it's not trivial to get ebersman correct rDNS/PTRs. It's easy to find consumer connections ebersman based on the ISP doing bulk/lazy PTR generation and just ebersman reject SMTP traffic from them. 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. ebersman Large ISPs don't care about clean PTRs as long as no customers ebersman complain and they don't care if end customers can't do SMTP ebersman without having to ask for it in some special way. marka Except autogenerated PTR records don't solve the problem. How not? Works fine for v4 right now. Customers that want to do their own email usually have to make a special request to their ISP but can do it. Biz connections are allowed to do their own PTRs at most ISPs, assuming the customers want and need it. And if they do clean PTRs as part of this, the anti-spam folks are happy. ebersman What else in the way of tradeoffs is missing? marka That people want IP to name mappings for their internal networks. Get a biz connection or a service to allow this. marka With things like DNSSEC you need break DNSSEC trust chains at the marka ISP level for this to work. Even our biz customers mostly don't do or want DNSSEC on PTRs. As this changes, we'll figure out how to do this as a service. But all the work of getting in DS and doing clean zone cut and delegation has nothing to do with this draft either. marka We also don't know what else will come along to use the reverse marka namespace. It is a good place to hang keying material which is marka tied to IP address. So you're volunteering to work on a draft mentioned documenting how folks are using PTR space? Thanks! marka Having a well defined method to update this name space will be marka useful. Another draft. But not this one. If such a method did already exist, worked and had at least reference implementations, it would certainly be worth mentioning in this draft. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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. MUHAAHHAHAHAHAHAHAHA. Sorry, where was I. Oh yeah. There is far too much bad undergrowth on the Internet, of old code and old systems that it still works and is never upgraded. For example, we see plenty of instances of dnsmasq which are so old that the version date is before the developer started keeping a changelog. Short of setting deliberate viral brush fires designed to brick old devices, we're stuck with them and need to plan around them. -- Nicholas Weaver it is a tale, told by an idiot, nwea...@icsi.berkeley.edufull of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
Nicholas Weaver mailto:nwea...@icsi.berkeley.edu 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 things wrong, which Win/NT's DNS implementation had to work around. rather than documenting the current behaviour and telling others to plan around it, we fixed BIND. similarly, many DNS servers are behind low-grade IP firewalls who pass udp/53 but not frags, thus keeping EDNS from working. so, every EDNS implementation has complicated fallback, and DNSSEC won't work on many data paths. nevertheless we call those firewalls wrong and keep trying to get DNSSEC (and therefore EDNS) working. so, there are cases where you have to plan for an extremely long tail, and other cases where you plan for a rapid transition. implementations who think NXDOMAIN is valid for empty-nonterminal nodes are known-broken, and they are on our short list to fix, and we're going to ignore them and let their operators feel the pain. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 myself in public and ask the 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 way, a PTR would exist for every address, so broken sshd and similar daemons will work. It's easy to grep for, so antispam folks should be content. The wildcard record can be signed, which is trickier to do with on-demand PTR synthesis. If you want to sell a customer their own PTR or delegated reverse zone, you still can. You don't end up with a unique PTR for each address, and you'll get answers for addresses that aren't in use... but those kind of seem like features, not bugs. Also, it's cheap. So, are there technical reasons not to do this, or is it just conceptual inertia from the use of $GENERATE for v4? -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
On 11/5/14 12:50 PM, Paul Vixie wrote: Andrew Sullivan mailto:a...@anvilwalrusden.com 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 believed I had watered down the draft so thoroughly that it would be impossible for anyone to disagree with it. I was evidently wrong. If we're going to bring that thing back up (in any sense you like), then I think it needs to get a spine. Perhaps also my willingness to try to find consensus has declined in the intervening years: I just don't think there _is_ a consensus on this. the lack of consensus means it can't be a proposed standard, not that it can't be an FYI, BCP or similar, right? BCP requires consensus after a fashion very similar to a standards track document. something with no-consensus basis would probably go to the ISE. Some that people do not oppose publication of even if they disagree with it might be informational. but this is all jail-house lawyering, if the w.g. can't build a consensus then it doesn't advance as a w.g. document. the fact of the network is, without a PTR you will have a hard time originating TCP/25. we should say that. another fact is, not everyone who should be able to (non-maliciously) access your web service will have a PTR. we should say that, too. those aren't opinions and they shouldn't be controversial. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 there's a matching forward ( in this case) record, and ignore them if there isn't. You can't do that with wildcard PTRs unless you have some way of serving 2^64 records in a single response. R's, John PS to the literal minded: yes, I know that's impossible. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
On Nov 6, 2014, at 9:33 AM, John Levine jo...@taugh.com 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 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 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? --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 adjust expectations for v6 in this respect than it was when we were talking about not providing PTR for v6 in the first place? For whatever it's worth I've been running with a wildcard PTR for my hurricane-tunnel v6 network at home for more than four years. It's only a dozen or so addresses, but I haven't hit any obvious problems. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 I know all look for matching. It's too easy for a malicious or negligent provider (typically in eastern Europe or Asia) to stick in PTRs like mail.google.com. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Paul Hoffman mailto:paul.hoff...@vpnc.org 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://www.ietf.org/mailman/listinfo/dnsop
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 whether typical PTR checks look for existence or matching? Matching could work, too, if they were able to compare prefixes rather than full addresses, but that's obviously a bigger leap. I suspect John is correct and the idea isn't practical. Alas. Thanks for the education, carry on. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 the first place? Considering the security issues involved, I sure hope not. For whatever it's worth I've been running with a wildcard PTR for my hurricane-tunnel v6 network at home for more than four years. It's only a dozen or so addresses, but I haven't hit any obvious problems. I see a lot of v4 PTRs that don't forward resolve when doing header analysis for spam reports. The majority just seem sloppy, but a fair number are malicious and try to impersonate someone. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Evan Hunt mailto:e...@isc.org 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-only end host can get real work done, but ipv6 is however deployed just well enough that we can't change what PTR means at this point. see also: http://www.circleid.com/posts/20110607_two_stage_filtering_for_ipv6_electronic_mail/ noting that in 2011 it was already too late for foundational recommendations on ipv6. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 wildcard more because there seems to be a fair amount of variation in implementations (or folks who don't read RFCs but play with DNS...). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 churn in the
marka zone.
This draft isn't talking about v4. And $GENERATE or equiv already works
in that most customers don't scream. I have no incentive to change to a
more risky and complicated and hard to maintain system for v4.
I'd contend that the folks who check v4 PTRs will have the same level of
trust with auto-gen'ed v6 that they do with v4. Folks that don't trust
it now still won't and those that find it acceptible in v4 will accept
it in v6.
And why can't we improve IPv4 at the same time using the same
mechanisms?
Also the examples are easier to type into a 80 column window. The
only difference between IPv4 and IPv6 on the client node is the
name of the PTR record.
marka The occasional customer will add a offensive PTR record which
marka won't be seen by 99.9% of the world.
[...]
marka If we recommend that this is only done when a forward record is
marka also successfully added UPDATE + TSIG (yes, this does scale for
marka this use) you get rid of the PTR/A mis-match issues.
And we're definitely not talking about allowing customers to do dynamic
updates of forward records in this draft.
With IPv4 most ISPs supply both fake/generic forward and reverse
zones for those that check PTR records with A lookups.
If you want that currently, you get a business account or use one of the
many services that allows that. Yes, it costs money. But most folks
don't seem to miss it in the consumer world and those that do find
someone willing to do it.
Actually it is often impossible to find a ISP willing + same or
better speed let alone for a reasonable price. Sometimes you can't
get it for any price at any speed because the end point of the
connection is in a residence and the only ISP's servicing the area
won't sell a business class connection to the address.
So no, get a business account is *not* a viable alternative.
I'm and sick and tired of Were the phone company and you just have to
lump it which is all this alternative is.
marka For ip6.arpa you delegate to the customer along with the prefix
marka delegation. The customer has to deal with the space issues but
marka uses the same mechanisms to add the PTR records and cleanup.
Because the mythical grandmother wants to deal with their own address
space. Right...
Most customers don't even know what DNS is, much less PTRs. They want to
get content, send emails and pictures of cats. As an ISP, it's our job
to make sure this works. $GENERATE in v4 does work. Auto-gen'ed PTRs in
v6 works as well as $GENERATE, no better, no worse.
marka You get the equivalent of $GENERATE with customer settable
marka overrides using UPDATE over TCP.
And I want 10s of millions of users doing TCP to my auth servers? I
think not. Certainly not for something of so little gain to my
customers.
Well I can also do a solution which uses KEY's submitted via DHCP and
works over UDP.
TCP happens to work well for SLAAC in the home but it is conceptually
trivial to send KEY rdata via DHCP and have the DHCP server add the
record so that the DNS update can be done over UDP for those using
DHCP. Yes, I have written a draft on how to do this with PD but
similar logic works for a single address.
DHCP servers already do dynamic updates of reverse zones so this
is just adding a different record compared to the PTR record they
currently do. I would expect it would take about a day to add the
logic to do this once a code point for the DHCP option is assigned.
Nameservers already support updating of records based on self
referential KEY records for the name alone or the name and subzone
beneath it. We have shipped one which does this for over a decade
now.
update-policy {
grant dhcp-server-key subzone * ANY;
grant * self * PTR KEY; // explict list of type updatable
// grant * self * ANY; // all types except NSEC and NSEC3
// grant * self *; // all types except RRSIG, NS, SOA,
// NSEC and NSEC3
// grant * selfsub *; // Allow the key name and anything
// under it.
};
The KEY record is in the zone so it is already trusted. This doesn't
require the zone to be signed.
The rest of the cleanup logic still works.
One could simulate this today with just named and nsupdate.
Simulate DHCP server add/update of KEY record (I'm using in-addr.arpa
because it is easier to type).
nsupdate -k Kdhcp-server-key
update add 4.3.2.1.in-addr.arpa 3600 IN KEY ...
send
Simulate node update
nsupdate -k K4.3.2.1.in-addr.arpa
update add
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 implementations who emit NXDOMAIN for empty non-terminals cannot be used as an excuse not to develop and deploy correct protocol and software enhancements. My suggestion is just for robust minimization without sacrificing the correctness as NXDOMAIN for full domain name is interpreted as is. 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. How widely is EDNS deployed? http://users.isc.org/~marka/ts.html IIRC, about 20 years ago, you said 2KB DNS message of DNSSEC was not a problem because EDNS takes care of it. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
