Re: [DNSOP] Meaning of lame delegation
mats> For the *delegation* to be lame it is not enough for one name mats> server to be ``broken''. The entire set must be such that the path mats> to the child zone content is not available. mats> For individual name servers it could be meaningful that say that mats> it is a *lame name server* in relation to a certain zone. I like this distinction. Agree that calling just one server not working is a lame name server. Still want better clarity for lame delegation on if we really care why we aren't getting auth/AA responses from at least one nameserver. If no listed nameserver gives auth/AA, I'd call that a clear criteria for lame delegation, regardless of the underlying reason, at least as far as a recursive server should care. Humans debugging may care but I don't see a "better" definition of lame server really informs that debugging process. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Meaning of lame delegation
>> Perhaps if we inverted the logic? I realize this does broaden the >> fundamental definition but what if, instead of saying "gave >> non-authoritative response" we define lame as "failed to give an >> authoritatve/AA response"? jtk> Isn't that what I originally suggested and Joe disagreed with? jtk> Let's trust P. Hoffman to iron this all out in a revision of the jtk> definitions RFC. :-) Yup. I agree with you that this is the operationally most useful and simplest way to think of it. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Meaning of lame delegation
Perhaps if we inverted the logic? I realize this does broaden the fundamental definition but what if, instead of saying "gave non-authoritative response" we define lame as "failed to give an authoritatve/AA response"? >> I continue to think that if you don't get a response, you can't tell >> whether the delegation is lame. Lameness (as I use the term) relates >> the configuration of the nameserver, not it's availability. jtk> I won't push on this any further after this, but the absence of a jtk> response happens quite a bit in my experience, and it is often a jtk> lame delegation in my view due to a problem in the delegating jtk> config or apex config (e.g., bogus or stale address specified, jtk> system removed from service but config not updated). A mention of jtk> this ambiguity, that it might be lame, might not be a bad idea to jtk> cover those cases imo. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft: Compact Lies/Denial of Existence in DNSSEC
gih> for what its worth I would like to chime in and support George's gih> view. The technique is NOT a lie per se. I'll "me too" this with George and Geoff. Figuring out a more efficient way to do what is ultimately wanted (crypographically provable denial of existence) that works better than the original conception is a good thing. And using "lie" was cute but George is right here too; clarity/consistency to not confuse the world is more useful than yet another "in" joke in DNS. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Solicit feedback on the problems of DNS for Cloud Resources described by the draft-ietf-rtgwg-net2cloud-problem-statement
tmorizot> I would also like to understand why global and unique names tmorizot> are unacceptable. Why do folks insist on NAT and RFC 1918? or ULA v6? There is a common feeling that it's another layer of security. I personally am not a fan of it but I think this is probably the most critical thing to have in the draft/RFC, i.e. pointing out that using globally unique names is way cleaner and outlining the issues not doing that will force you to deal with. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-multi-provider-dnssec
tjw> This starts a Working Group Last Call for tjw> draft-ietf-dnsop-multi-provider-dnssec [...] tjw> Please review the draft and offer relevant comments. I think this draft is in good shape. We've been using this as validation of $DAYJOB procs around this area and have not found any holes in the draft. I'd support this as a standard. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-sah-resolver-information
While there is definitely a lot of work needed, this seems to be getting substantive interest in the draft, so I'd support the WG adopting this draft. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] proposal: Covert in-band zone data
ebersman> If what you're arguing for is something that's actually mixed ebersman> into the zone data, how do you handle non-compatible/legacy ebersman> and avoid leakage? wpk> non-compatible/legacy servers won't know the RRTypes that are wpk> covert - and therefore won't be able to load them from disk. In a polite/sane implementation, sure. But I have scars from my years at ISC tech support dealing with very broken implementations not done by the usual FOSS DNS folks. They might fail to load the zone at all, might stop loading and serve what they have, only serve what they recognize, crash, etc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] proposal: Covert in-band zone data
dmahoney> I'd be fine with this data ONLY living on the master, but dmahoney> having it survive things like named-compilezone or rndc dmahoney> freeze/thaw, or the slew of DDNS updates that things like ACME dmahoney> DNS-01 requires. dmahoney> Effectively, this would be an internal-only DNS record that dmahoney> had a database representation but NO defined wire-format, so dmahoney> there'd be little chance of snooping over the wire (absent dmahoney> some kind of memory leak in the DNS implementation). Gotcha. So presumably also only on hidden master if that's the architecture. And transfer of data with these super-comments would be done by file copy, not any DNS standard method? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] proposal: Covert in-band zone data
rharolde> If you are looking at putting it outside the zone, it occurs rharolde> to me that any of the IPAM solutions have a database where you rharolde> can attach information to records, zones, IP addresses, rharolde> etc. Even Active Directory can probably do that. "Buy a commercial IPAM" isn't an open standards based solution. Nor are any of those extra compatible between different implementations. Not being send in the AXFR or stored as zone data doesn't mean separate database either. That's assuming an implementation before we even have a protocol design/extension. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] proposal: Covert in-band zone data
ebersman> Actually, I think this moves your goal nicely. If we could ebersman> have things marked as "not zone data, sensitive" and dealt ebersman> with only over a covert channel after various auth/acl checks ebersman> are done, it would be easy enough to have metadata that won't ebersman> leak. ebersman> Then we define some of these things we consider ebersman> "private"/non-zone. dmahoney> I also envision the "presentation format" looking like a dmahoney> regular comment so non-compatible implementations that tried dmahoney> to load a zone with these simply ignored them as they do dmahoney> regular comments. Similar, perhaps to how server-side dmahoney> includes work in the web world. ebersman> Legacy/non-compatible would fall out because they wouldn't ebersman> ever see this because they'd fail whatever auth/negotiation ebersman> was necessary to believe that sending covert/metadata was OK ebersman> and they'd never get it. dmahoney> Right, my argument was more in the case of the "without dmahoney> covert". I.e. you've dumped your zone on bind and loaded it dmahoney> into NSD. On disk, not wire. If what you're arguing for is something that's actually mixed into the zone data, how do you handle non-compatible/legacy and avoid leakage? Doing it as separate meta-data not part of the zone data and not needing to be DNS wire format solves that but, again, without some covert or non-AXFR transfer method, how do you get it around? If you don't care about backward compatibility, this is a more easily solvable problem. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] proposal: Covert in-band zone data
I was also one of those folks that put things in txt zone files for years. My whole IP address management was comments in the in-addr.arpa zones. While I went to dynamic zones to make DNSSEC easy and lost that, I still see value in things that should be attachable to a zone but not zone data and not something you wanted to "publish" in the open DNS. ebersman> I think we're allowed to replace something after 20+ years ;) ebersman> Things that might go in: ebersman> - AXFR/IXFR/*XFR ebersman> - zone meta data (create/modify/delete/digital-sigs) ebersman> - "covert" data dmahoney> As far as extending/replacing the AXFR protocol, this is dmahoney> great, however, I still see an orthogonal need for the thing dmahoney> I'm asking for: Parseable metadata. For humans. Not as a dmahoney> gateway to some sort of clever signaling or key-transfer dmahoney> protocol. Analagous more to HINFO than TXT. Actually, I think this moves your goal nicely. If we could have things marked as "not zone data, sensitive" and dealt with only over a covert channel after various auth/acl checks are done, it would be easy enough to have metadata that won't leak. Then we define some of these things we consider "private"/non-zone. dmahoney> I also envision the "presentation format" looking like a dmahoney> regular comment so non-compatible implementations that tried dmahoney> to load a zone with these simply ignored them as they do dmahoney> regular comments. Similar, perhaps to how server-side dmahoney> includes work in the web world. Legacy/non-compatible would fall out because they wouldn't ever see this because they'd fail whatever auth/negotiation was necessary to believe that sending covert/metadata was OK and they'd never get it. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] proposal: Covert in-band zone data
olafur> My suggestion is to take a step back and say we have outgrown olafur> AXFR and we need better mechanism to sync various servers. olafur> Lets start work on a new "SYNC Name servers" protocol that can olafur> meet modern requirements paulw> +1 +1. I think we're allowed to replace something after 20+ years ;) Things that might go in: - AXFR/IXFR/*XFR - zone meta data (create/modify/delete/digital-sigs) - "covert" data My only hesitation is we seem to slow logarithmically as we increase scope but this sure seems like the right direction. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-livingood-dnsop-dont-switch-resolvers & draft-livingood-dnsop-auth-dnssec-mistakes
I support these as a combined draft to be worked on by the DNSOP WG and I'm willing to contribute editing/verbage. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Request for Adoption (draft-moura-dnsop-authoritative-recommendations)
moura> We have a new draft and we'd like to ask the WG to adopt it: moura> [[https://datatracker..ietf.org/doc/draft-moura-dnsop-authoritative-recommendations/]] msj> Do you have any authoritative server operators that have signed on msj> to these recommendations other than the authors? I'll be going through it. $DAYJOB includes gTLD, ccTLD and second level domains (Neustar). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fundamental ANAME problems
mansaxel> IMNSHO _any_ work on "fixing CNAMES at apex" that gets mansaxel> traction is a spanner in the works for what we seem to agree mansaxel> is a better solution. A interim fix will be deployed and stall mansaxel> every attempt at DTRT. While I agree with this approach in principle, the reality is we've had a couple of decades and never come up with anything enough better to get used. There are times when an 80% solution is better with 0%, even if it might slow down perfect. jabley> So for what it's worth, this is what I think we should be doing: jabley> 1. Make the existing, proprietary, non-interoperable dumpster jabley>fire better if we can (maybe we can't; the way to tell is jabley>whether the enterprise DNS people are interested); Yes. And get buyoff from the browser and large auth folks so it actually gets used. jabley> 2. Find a client-side solution to this, and try really hard not jabley>to invent something new that is really just SRV with a hat jabley>and a false moustache. Also yes. Folks saying that SRV won't work for them aren't stupid. They have their own agendas that don't consider DNS to be the most important thing to them; to them it's a handy tool. We should respect that attitude and come up with a legit new solution both sides can live with. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fundamental ANAME problems
ray> Architecturally, the important part of my proposal is that ray> resolution of the A and records is done *at the recursive ray> layer* of the DNS, with no interference with how authoritative ray> resolution works. Have you confirmed with the large CDNs doing geo-ip, load-balancing, etc that this is what they want, since they are largely driving all of this? I'd guess that they would prefer this in the auth layer, where they own or have contractual relationship with the zone owner. Yes, as DNS software folks, we'd like to keep auth doing auth and have only recursive doing lookups but I'm not sure that solves the problem in a way that will be accepted. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fundamental ANAME problems
ray> HTTP Redirects cause the URI in the address bar to be changed. A ray> lot of the whole "CNAME at the Apex" issue arises because lots of ray> marketing people don't want end users to have to type *or see* the ray> www prefix. ray> Those folks aren't going to stand for their nice clean ray> "example.com" URL getting replaced with the real CDN address in the ray> address bar. Last I heard, they're taking care of this by taking away the address bar completely. You and I will have to set some kind of debug mode to ever see this. So that in and of itself isn't a deal breaker. But let's get comment from the firefox/chrome folks. I agree with you that we're having some productive back and forth. I think that we've learned some but not all of each other's spaces. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft for dynamic discovery of secure resolvers
pusateri> Come to think of it, DNSSEC validation in the stub resolver or pusateri> browser is really a place DoH could shine. Instead of all the pusateri> round trips required for validating up (down) the chain, the pusateri> webserver could package up all those validated records and pusateri> push them so the client/stub could do the validation quickly pusateri> for all of the links in a page in an order that the user is pusateri> most likely to need based on previous statistics and scrolling pusateri> position. Agreed. My discomfort with some current proposals where I get DNS answers to questions I didn't ask yet would be a lot less if I had full validation info to DNSSEC validate them. Even getting SRV and other service entry points would be less if they're in the domain I'm already playing in and the DNSSEC validate. Trick with this will be getting browser support. We're still debating why SRV is too many lookups vs CNAME at zone apex. Fingers crossed we make progress on both. For other apps, stubby seems like a fine way to get this in the app. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft for dynamic discovery of secure resolvers
ebersman> That may be the consensus at the IETF but it's not even close ebersman> the consensus with ISPs, nor large enterprise. That seems to ebersman> cover most of the eyeball/consumer... DHCP is still how much ebersman> of the world gets connected and that hasn't changed in decades. pusateri> You're misquoting me and arguing against a point I didn't pusateri> make. There was no one saying we don't need DHCP. There was a pusateri> general agreement that DHCP should not be extended. pusateri> The DHC working group never completed the work for DHCP pusateri> authentication. It's not trustworthy enough in its current pusateri> form to add more things to it. And I'd argue that this is also an IETF opinion, not the majority of the internet. There's a reason it's still the most widespread configuration management for devices. "Not trustworthy enough to extend" is a fine academic opinion but doesn't hold water in the marketplace. DHCP is no worse currently than TOFU. We trust that the OFFER packet will be from the DHCP server we're supposed to use. Trust On First Use. Not great but it works more than not. At least that's the argument I kept hearing for TOFU. We actually have operational experience of decades for DHCP and this isn't a wide spread enough problem to kill any innovation forever because it's not perfect. If we want the world to use what the IETF develops, we have to be able to balance theoretical risk vs sane and widespread deployment. If not, someone will just wind up shoving this into yet another DHCP vendor option and every vendor will be different. That will be even less secure. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft for dynamic discovery of secure resolvers
pusateri> Another point I remember most clearly is that DHCP has fallen pusateri> out of favor for communicating all but the most minimal pusateri> network bootstrap configuration information. There was general pusateri> agreement in the room that you only should use DHCP in IPv4 pusateri> for address/router info and then use trusted sources for pusateri> everything else. In IPv6, SLAAC generally provides this. That may be the consensus at the IETF but it's not even close the consensus with ISPs, nor large enterprise. That seems to cover most of the eyeball/consumer... DHCP is still how much of the world gets connected and that hasn't changed in decades. pusateri> One more point (from the Android crowd) was that they are pusateri> going to try to connect to the DNS server's IP address using pusateri> port 853 using DoT at the same time they are trying to resolve pusateri> names over port 53 with UDP. If they're able to make a DoT pusateri> connection, they'll use it. This doesn't provide for a way pusateri> to have an ADN to verify the certificate but a PTR query can pusateri> give you a name to do certificate validation and/or DANE pusateri> validation. So they seemed to be making the point that no DHCP pusateri> extensions were necessary. The google/android crowd's bias against DHCP and DHCPv6 is well known and is why android is having trouble penetrating said enterprise market. Getting DOH via DHCP is the same argument as TOFU and the IETF has used TOFU. DHCP is how hotspots, ISPs and enterprise work. Users able to understand security risks and who read drafts from the IETF already know how to deal with this and won't need a DHCP option. Much of the world does need and want configure hosts/devices via DHCP. Saying this is all broken and that we need to protect the world from themselves by not having a DHCP option simply means that vendors will have a slew of non-standard ways of doing it and we've helped noone. Let's just give the option, document the security holes and risks and at least offer much of the world a standard way of doing this if they so choose. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft for dynamic discovery of secure resolvers
mellon> Think about DHCP providing an SMTP server address. Does that mellon> make sense? That doesn't. But DHCP already hands out DNS servers. You are already trusting the DHCP server to give you default gateway and DNS server (or you are choosing not to use DHCP). Take the use case of coffee house or wireless hotspot. I think that it would be an improvement of privacy to not allow anyone there to sniff DNS packets because the owner of the network uses DOH for their recursive resolver. I'm already trusting the network for default gateway and most users would trust the DNS servers handed via DHCP. So no huge new leap of trust and improved privacy. Seems like a win. Why not allow network operators that option via a new DHCP option? You don't have to use it but it would be a good choice for some. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-bortzmeyer-rfc7816bis
tjw> We discussed this and there appears to be support to adopt this, tjw> with the caveat of adding more content to the section on tjw> Operational Considerations. [...] tjw> Please review this draft to see if you think it is suitable for tjw> adoption by DNSOP, and comments to the list, clearly stating your tjw> view. I think this revision is good and agree that operational considerations review is important, as there have been interoperability issues with minimization and some auth servers. I can review the updated draft. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-huque-dnsop-multi-provider-dnssec
tjw> This starts a Call for Adoption for: tjw> draft-huque-dnsop-multi-provider-dnssec I support adoption of this document. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
bellis> AIUI, a large part of the supposed issue with SRV was the bellis> inertia of the installed base of browsers that wouldn't know how bellis> to access them. drc> I thought the more fundamental problem was the additional latency drc> caused by the second lookup since SRV specified domain names as drc> targets. You're not mis-remembering this. I hear this from the major browser folks every time we mention SRV. We may or may not think this isn't relevent (or that dozens of embedded objects are way slower to load on a web page) but it doesn't matter. If browser folks believe this and won't change, we aren't likely to convince them if we haven't by now. SRV is a technically cleaner solution that will never get deployed... While I understand cautions about changing CNAME, legacy issues, etc. I've come more and more to the camp that we lost this argument years ago and we should just let server software folks allow CNAME at apex and be done. This is DNSOP. Operational. The world wants CNAME at apex. Let's give it to them. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Stephen Farrell's Yes on draft-ietf-dnsop-negative-trust-anchors-10: (with COMMENT)
sfarrell - section 2: immediately restores - well that depends on the sfarrell screw-up doesn't it? Or are you saying (where?) that an NTA sfarrell must only be put in place when the screw-up is specifically sfarrell and only about and because of DNSSEC and where ignoring DNSSEC sfarrell will result in things working? Yes. This only addresses validation failures, not server/infrastructure failures. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Seeking edns-client-subnet implementers
tale At IETF this week it was decided to refocus the effort on the tale edns-client-subnet draft on only documenting the existing tale behaviour of deployed implementations. f4t That's disappointing and somewhat at odds with the theme of the f4t on-list discussions since the last draft was posted. Oh well. Dave also replied but a couple of us have volunteered to spin a new draft that lists the issues with the existing implementations and design and proposes a new design based on comments and lessons learned from the early implementers. It seemed cleaner to use the current draft to simply document current state of the art and have a new document that works on enhancements. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] negative-trust-anchors-02
ajs I have read draft-ietf-dnsop-negative-trust-anchors-02. I have ajs some comments. Thanks. These seem like reasonably comments and I'll fold them into the doc. Hope to have a new version out next week. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Call for Presentations - DNS-OARC Spring Workshop, May 2015
Apologies if you are on multiple lists and see multiple copies of this email. - The next OARC Spring Workshop will take place in Amsterdam on May 9th and 10th, the weekend before RIPE70. OARC is requesting proposals for presentations, with a preference for DDoS attack reports and mitigation techniques. Reports and field stories can cover DNS-based DDoS attacks, attacks to DNS infrastructure or side effects suffered by cache resolver operators. This workshop intends to build from previous strong OARC workshops, where operational content and research is welcome. Presentations from DNS operators are particularly welcome, as well as from DNS researchers. All DNS-related subjects are accepted, introduction to new tools, visualizations, DNSSEC and novel uses of the DNS. If you are an OARC member, and have a sensitive topic you would like to present for members-only, we will accommodate those talks too. Adopting practice from other conferences, a timeslot for lighting talks will be available for short presentations (5 to 10 minutes). Workshop Milestones * 18 December 2014, Call for Presentations posted * 8 January 2015, Open for submissions * 5 March 2015, Deadline for submission * 26 March 2015, Final Program published * 7 May 2015, Final deadline for slideset submission Details for abstract submission will be published here: https://indico.dns-oarc.net//conferenceCFA.py?confId=21 The workshop will be organized on different tracks, depending on the topics and the timing of each presentation. If you are interested in a lightning talk, let us know at the time of submission. You can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via submissi...@dns-oarc.net if you have questions or concerns. Sebastian Castro, for the OARC Programme Committee OARC is also seeking sponsorship for this workshop, please contact spon...@dns-oarc.net if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) - ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-eastlake-dnsext-cookies
tjw This starts a call for adoption for draft-eastlake-dnsext-cookies. [...] tjw Please review this draft to see if you think it is suitable for tjw adoption by DNSOP, and comments to the list, clearly stating your tjw view. +1 to adopt and can review if needed. It's another useful tool to have in the quiver. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Requesting adoption of draft-wkumari-dnsop-root-loopback
warren We are requesting a call for adoption of warren draft-wkumari-dnsop-root-loopback. Support. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Using PTRs for security validation is stupid
kumari I think that there is consensus that it is stupid. There is also kumari consensus that using a fork to get the stuck toast out of the kumari toaster is a bad idea -- however york I'm not sure that there's necessarily a whole lot of value in us york coming out with a document Using PTRs To Reject SSH Connections york Considered Harmful - I don't know that our doing so will york necessarily motivate the authors of SSH servers to change york anything. Certainly I think the SSH case could be listed in your york document of bad things people do with PTRs in IPv4 that will break york in IPv6. Yup... There is discussion in a couple of distro web sites on changing this default but while most novice sysadmins will tend to use distros, if they upgrade, it doesn't stomp the /etc files. That's usually a feature. In this case, it means we're going to be living with this bad default for a while. But no reason not to talk to our friends that work on debian/freebsd et al and have them change the default to at least not make it worse but it will be around a while. I would say that this is a situation where the part of the v6 PTR space we seem to be more inclined to argue about (broadband/consumers) are probably not being bit as much by this. Most won't use ssh and those of us that do use ssh over v6 probably do know our friendly sysadmin (or have ways of getting PTRs fixed by hand). So as we resurrect the reverse mapping considerations draft, we point out there that doing this check seems to be current default but that it isn't useful/helpful? That and get the distros to fix the default? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Using PTRs for security validation is stupid
TLemon There may be some other reason why a bogus PTR record is better TLemon than no PTR record, but we are at present not aware of such a TLemon reason. There is the NYT web site case and may be others. In the past, ISPs have just pre-populated v4 PTRs because it wasn't hard to do in configs and it masked folks doing things like NYT. This draft does give us a chance to see if that really is still at all common. It it turns out that it really is just one or two large sites and we can document it, that does give DNS folks at ISPs some ammo for fixing something that isn't broken, at least according to mgmt. That ISP default isn't likely to change quickly but hard facts do go a long way in such discussions. ;) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] PTR usage cases for networking Re: Using PTRs for security validation is stupid
ogud The usage case that got brought up at the mike ``PTR records are ogud used by logging systems'' got me thinking ``when does a logging ogud system need this information'' and the answer is I think ``when a ogud human is looking at the log'' in all other cases if the system is ogud running at high speed the delay in looking up addresses is just ogud too long. Depends on the environment and application. For enterprise and security, seems more common to do PTR lookups in real time. For web sites and really high traffic volume, more common to post-process. ogud ``End-user'' addresses do not need a PTR record but could be ogud simple wild card responses like ``[[Customer.HNL.biz-ISP.net]]'' ogud as none is complaining about ogud 123.136.133.31.in-addr.arpa. 3600 IN PTR [[dhcp-887b.meeting.ietf.org]]. ogud or ogud 9.5.9.d.7.4.e.f.f.f.9.e.f.c.a.2.6.3.1.0.0.7.3.0.c.7.6.0.1.0.0.2.ip6.arpa. 15 ogud IN PTR ogud s2001067c037001362acfe9fffe47d959.hotel-wireless.v6.[[meeting.ietf.org]]. Other than mail/spam filtering, these do seem to work most places. That's why ISPs have mostly gotten away with wildcarding PTRs in v4. ogud That to me indicates that people use log post processing all the ogud time and Intrusion Detection Systems are doing PTR lookups by ogud policy For IDS are their expectations any different than log ogud processors? and if IDS's are taking decisions based on the ogud content of PTR records what granularity do they need? IDSs presumably have a more known and stable user population; things that don't match that tend to be assumed as hostile. Not sure it's a good assumption but I suspect most IDS teams assume that they (or at least their organization) have some control over A//PTR cleanliness and response time. Enterprises are also more likely to have their IP addr mgmt, DHCP and DNS talking. This leads to higher quality PTRs than in consumer ISP or wireless hotspot environments. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Using PTRs for security validation is stupid
ebersman There is the NYT web site case and may be others. TLemon 'splain? I'm not finding anything with google. Not sure if it's still the case but did confirm a couple of years ago that NYT web access breaks if you don't have some kind of PTR. Doesn't matter what's in it; you just need non-NXDOMAIN response. Never understood it but have talked to other operators who'd see this too. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Using PTRs for security validation is stupid
paul Actually, distros try to use a dir.d/*.conf type structure these paul days for exactly this reason. It allows base options that are paul untouched to be upgraded even if there are custom user paul options. openssn is one of those that unfortunately does not paul support that. Thanks for the correction/clarification. paul Distros tend to stick to upstream options. So for example if you paul want this changed in fedora/rhel, you will need to talk to openssh paul because according to their man page (for openssh-6.4p1-5): paul UseDNS Specifies whether sshd(8) should look up the remote paul host name and check that the resolved host name for the paul remote IP address maps back to the very same IP address. The paul default is yes. paul ps. if you talk to them, please also get them to change the paul default for VerifyHostKeyDNS= to ask. I can ask... But I'm also finding various best practice websites recommending turning on VerifyReverseMapping. Seeing shades of augean stables... ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
sthaug If you assume that IPv6 mail servers have static PTRs, there is sthaug zero added value (and a bit of work) in creating/synthesizing sthaug IPv6 PTRs for residential customers. Much better to simply not sthaug do it in the first place. I'm in agreement that legitimate, well run mail servers will have static forward and reverse in v6. My concern is random folks who currently accept any v4 PTR regardless of format (but caring if there is no PTR at all) will do something equally bad in v6. i.e. NYT web content and similar pointless cruft. Putting in an auto-gen'ed v6 PTR would satisfy that level of check. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
ebersman It's a nice thought. But considering how little we've ebersman converged on SLAAC vs DHCPv6, random assignment vs eui-64 vs ebersman static for host ID, RFC 6106 vs DHCPv6 DNS, etc. (and I won't ebersman even start on how many IPv6 transition techs there are), any ebersman consensus on better is going to be a fascinating trick. TLemon This is not an accurate representation of the situation. There TLemon are some people who see DHCPv6 versus SLAAC as an ideological TLemon problem rather than a choice between features, but this is TLemon completely orthogonal to the DNS issue. Sorry. Unclear analogy. Not conflating v6 and DNS, just pointing out that reaching consensus when we have non-compatible operational views and requirements tends to not lead to a solution in any real time frame. Proponents of SLAAC vs DHCPv6 tend to have different pain points and biases based on how they run their networks and we aren't likely to come to a meeting of the minds any time soon due to those differing needs. Not saying either network design is wrong or bad either. Just saying that different needs means we won't get a one size fits all solution. TLemon There is real work going on on the DNS problem, and while it's TLemon not clear everyone will want to deploy a nice solution, I don't TLemon think there's any serious argument within the IETF that such a TLemon solution should not be deployed, nor is there serious contention TLemon over how to do it (although there are several options). I don't TLemon _think_ there are any ideological disputes; the question is TLemon simply which solution is best for any particular use case. And, TLemon of course, actually getting the documents done that describe the TLemon several different ways of approaching the problem. I'd agree that we all would like the option of a nice use of PTRs. It does seem like there are two sets of conflicting pain points for which it's not clear to me there is a compromise in what we're talking about in this draft. The two groups with obvious pain points are: - service providers who want a way to avoid breaking things for customers while not being operationally complicated/insane - mail/spam folks who seem to be saying that the current v4 method is a time bomb that will explode any minute, is unmaintainable and doing v6 the same way is untenable to them Doing autogen'd PTRs in v6 violates the anti-spam folks' needs. Not having any PTR at all for consumers potentially violates the ISP needs. Things I don't know that anyone knows for sure but make it hard to reach consensus on a solution: - what are the various interesting/crazy/insane uses PTRs in v4 now (beyond the mail req of forward/reverse existing and matching), i.e. what will break now and in the future if there are no v6 PTRs for consumer IPs if content providers do the same uses in v6 - how much is the current v4 autogen being done by ISPs truly breaking mail/spam, how/when/how-soon will it explode and how much additional stress/breakage would doing v6 autogen add ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
ebersman My concern is random folks who currently accept any v4 PTR ebersman regardless of format (but caring if there is no PTR at all) ebersman will do something equally bad in v6. i.e. NYT web content and ebersman similar pointless cruft. Putting in an auto-gen'ed v6 PTR ebersman would satisfy that level of check. TLemon The status quo is that the ISP doesn't add a PTR record for a TLemon customer IPv6 address, nor delegate the zone. Lots of IPv6 TLemon users are getting by just fine right this very moment (including TLemon me) without this. So I think it's safe to say that we do not TLemon need to solve this problem: if there is damage, it has already TLemon been routed around. This is a lovely thought. And I really hope it's true. I've thought since the early 90s that most things we did with PTRs other than network interfaces were questionable usefulness for pain that we're still dealing with supporting. However, I'm concerned that this (v6 working fine without already) is just as much an unsupported assumption as that we must support PTRs for content with no good data (other than various anecdotal stories) and no idea of what would break if we didn't do them. IPv6 is still in early adoption for broad general use and we don't know what plans folks have for requiring PTRs. TLemon So really all we need to talk about is whether there are TLemon features to add, not whether we need to fix something right now. TLemon It's already too late for that. I would still like to see: - actual data on how/where PTRs are being used and abused now (beyond the known mail filtering) to see if any of those folks are planning on continuing the bad idea into v6 - suggestions on how/if we can clean PTR usage, v4 and v6 I'm not expecting anything I'll be able to use to clean up current v4 usage, but I'd love to be pleasantly surprised. If someone does come up with a solid performance/efficiency improvement or a biz case for keeping better track and use, I'd certainly take that to my mgmt. As for the current draft, if it doesn't happen, I'll still need to cope with customer breakage and vendors will produce solutions that customers like me pay for. I'd much rather have a consistent approach across vendors and guidance in the IETF I can point to but I will probably have to do something about PTRs in the next year or two. And it will probably be something icky but less icky than screaming customers... ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
sthaug To me this is really simple: If many/most ISPs continue *not* sthaug adding useless/artificial/synthesized PTRs, the content / server sthaug people will have no choice - if they want their content to get sthaug out and their services to be used by the large majority of IPv6 sthaug users, they'll have to accept connections from IPv6 addresses sthaug without PTRs. One hopes... I would certainly love to not have to do (yet more) crap PTRs. I'm just not as optomistic that stupid people aren't really really persistent. And I'd still love to get better data on how it's currently used. If I could also stop doing the v4 crap and not have users screaming, that's a large pain point gone. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] new drafts? (Was Draft Reverse DNS in IPv6 for Internet Service Providers)
I've come to the conclusion that this draft doesn't give me the data I need to choose when/where/how I might do v6 PTRs for my broadband customers. It is sufficient for servers, networking gear and business customers; just not for broadband. There are two things lacking that would be cleaner to tackle as two new drafts. These would be: - document current usage of v4 PTRs - document IETF recommendations for what we *should* be doing with PTRs When we have these, we can actually discuss *how* to do v6 PTRs in this draft. I'm willing to work on documenting current usage in v4. Is there someone willing to drive the recommendations on what we should be doing with v4/v6? I'm willing to review but don't know that I have the cycles or background to do a complete job. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
ebersman IPv6 is still in early adoption for broad general use and we ebersman don't know what plans folks have for requiring PTRs. TLemon I apologize for picking and choosing from your response, but I TLemon think this sums it up perfectly: if we do not yet know what TLemon plans they have, then we need not care. [...] TLemon So if e.g. Comcast were coming to us right now and saying we're TLemon getting a lot of phone calls because of foo, then we could talk TLemon about foo. Comcast (or any large company/provider) does not move nimbly. The IETF does not move nimbly. Vendors do not implement what the IETF specifies energetically without beating/cash. I'm sympathetic to the idea that I should avoid borrowing trouble. However, I'd say that looking ahead and trying to be prepared for things that seem likely is not borrowing trouble; it's being prepared. If I wait until I have screaming customers, I have months and months of hell before I have any solution. Hence why I'm suggesting that we document v4 PTR usage and make recommendations on what we think are appropriate usage. If we can get a better idea of what bad ideas are being done now and try to folks to not do this, then we can indeed maintain the pleasant status quo in v6 PTRs. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
To step back up a level again. Most ISPs and most email/spam folks find the current v4 pointer usage to be functional. I'm not saying that we all think it's not somewhat broken, couldn't be better, etc. However, it solves the problems it's supposed to solve in a functional way and doesn't generate lots of customer complaints. This draft basically outlines how to get more or less the same level of functionality and trust that exists in v4 in v6. The techniques being described in the draft are in use or being implemented soon and there is value in having an IETF draft that documents what is being done and what the operational tradeoffs are. Describing current state of operations and operational tradeoffs is the DNSOP bailiwick. There have been several comments about wanting to clean up PTR usage, either doing better in v6, or in both v4 and v6. There were also several folks observing that documenting how PTRs are actually being used would be handy. I think both a how are PTRs currently used and a how to do better with PTRs are both useful but should be separate drafts from this one. I'd even push that the how to do better talk about v4 and v6. As an operator, I'm not sure when or if I'd ever be allowed to spend resources to clean things up. However, if we can document what will actually break and how and why to better and there's some business problem solved or business opportunity created, I might have a fighting chance of getting resources to do this. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
vixie Indeed not. We currently have to maintain a large and complex vixie distributed registry of ipv4 ptr patterns which are meaningless vixie and must therefore be filtered out before making policy decisions vixie about the presence/absence and match/doesn't of a ptr record and vixie it's associated a record. You are already doing this, correct? Not good, has pain, but at least in place? And if I used a generation method for v6 that exactly matched v4, I'd just get caught in exactly the same filters, right? I know you want to make things better but does adding v6 records with the same format make things worse or just no better? If the current v4 is so fragile, it will break at any minute, you're already at risk. If what I produce in v6 adds no new checks, it should add no new risks; only the risk you have in v4 already. vixie V6 should attempt to be better than v4 in this regard. In fact v4 vixie should attempt to improve in this regard. It's a nice thought. But considering how little we've converged on SLAAC vs DHCPv6, random assignment vs eui-64 vs static for host ID, RFC 6106 vs DHCPv6 DNS, etc. (and I won't even start on how many IPv6 transition techs there are), any consensus on better is going to be a fascinating trick. I have already mentioned that you and others are interested in some PTR usage solution that is better for both v4 and v6. And having actual real data on what is using PTRs in v4 and how as a second draft. I'd love to have real data to make an informed choice. I'm just suggesting that doing so is two drafts and significant effort on their own. paul Functional at high cost and risking complexity collapse every day paul and twice on Sunday is not a status quo to love, not to copy from paul v4 to v6. And what's the plan for v4 if collapse is imminent? Who's working on it? And I sure hope it isn't that v6 will just replace v4, if time is of the essence. Large providers, including my $DAYJOB, are already looking at what/where/how we should do PTRs in v6. Going back to management and saying that we need to completely redo v4 (which they view as already working) and do v6 in some complicated way isn't something they're going to buy into without solid business case for cost savings and/or new income stream. So far, I haven't heard anything like those, for this draft or in potential new drafts. ___ 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] 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
marka Or we could stop debating whether we should maintain it and marka assume that if we give people tools that will allow it to be marka automatically maintained they will eventually deploy them. For providers with millions or tens of millions of end customers, any system that just lets any customer scribble in DNS is unlikely to be employed for security or stability reasons. marka Document what a node should do to register itself in the reverse marka tree and to cleanup when its address changes. Write some code to marka do it. And of course all CPE vendors put out quality products with these advances in code and never put out cheap crap. And consumers always upgrade their CPEs based on this improved code immmediately. Heh. The reality is that this will take decades and in the meantime, consumers will have problems doing what they want and they will complain to their service provider, who won't have a good solution. This document tries to lay out the challenges and tradeoffs of not having PTRs or not having clean PTRs. We should be sure it makes those tradeoffs clear, along with the problems service providers will see if they do or don't pick one of the solution sets. If there are issues or tradeoffs not in the document, suggest a text change. The just do it right and folks will roll it out argument doesn't solve the problem in any useful timeframe and doesn't let folks who do have to support millions of customers make informed operational decisions. And automating at the scale we'll see with real IPv6 deployment is going to be very hard. Add in that embedded devices are some of the least likely to be current, clean or remotely upgradeable as we learn of mistakes and you'll wind up with more boxes doing it wrong than right. ___ 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 Or we could stop debating whether we should maintain it and marka assume that if we give people tools that will allow it to be marka automatically maintained they will eventually deploy them. [...] marka Document what a node should do to register itself in the reverse marka tree and to cleanup when its address changes. Write some code to marka do it. To put things another way, I think you're trying to optimize for a problem most folks don't want solved. Anti-spam folks *like* it that it's not trivial to get correct rDNS/PTRs. It's easy to find consumer connections based on the ISP doing bulk/lazy PTR generation and just reject SMTP traffic from them. Large ISPs don't care about clean PTRs as long as no customers complain and they don't care if end customers can't do SMTP without having to ask for it in some special way. They do care about and probably don't want complicated automated systems with all sorts of complicated behavior when autogen'ed PTRs solve most customer problems. While I as an individual may find it annoying to have to go to a web page to get a port 25 block removed and I may have to find someone better connected than me to get my email to real folks like google, I'm not most of the internet. Not even a teeny weeny fraction of it. And while I admit that I tend to disable auto-update on most of my devices and do updates by hand, at $DAYJOB, it's a feature when we can push new versions out to fix things and not wait for consumer gear to spout smoke and get replaced in 3-5 years. So for a large chunk of the providers out there, the recommendations in this draft solve a real problem in a mostly non-painful way and I think it's done a decent job of laying out the tradeoffs. There have been some comments about making it clear that providers that do bulk $GENERATE equivs in IPv6 will find that those addrs won't be able to send email. Seems like a fine thing to point out. What else in the way of tradeoffs is missing? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
ebersman I don't even know how many broken sites there are and I don't ebersman care to waste valuable staff time tilting at this ebersman windmill. ... vixie no worries. meanwhile i'm going to try to build an internet that vixie can grow for 200 more years. Suddenly being socially responsible with PTR use is going to save the internet. Cool. :) vixie that's not going to happen if all we ever do is add layers and vixie complexity. if PTR's are silly, then we have a responsibility to vixie say so in writing, with an RFC number to point at, and we should vixie begin what may be the several-lifetimes-long task of getting vixie people to pay attention differently. i have little or no use for vixie the world as it is, and i never have had. If you do really want to try to cure 20+ years of bad ideas and document it, go for it. I'd speak against doing so in this draft, other than a possible reference if said RFC ever happens. One of the big problems with the whole v6 PTR discussion is that every time somone (including me) has asked so how are we using them in v4, noone has anything like a definitive list of what we're doing now. That doesn't even touch whether or not said uses are actually good ideas. I think there is value in making recommendations now based on current operational reality and detailing tradeoffs and real customer support costs in doing PTRs in v6, which seems to be the goal of this draft. If this turns into an RFC and eventually becomes a quaint bit of history, we can retire it. ebersman Folks trying limit spam will hopefully figure out something ebersman that doesn't involve reputation by IPv6 addr, 'cause at 18 ebersman quadrillion per /64, that won't scale... vixie ain't it great? a lot of servers are going to demand PTR's for vixie V6. this will force the number of SMTP senders to be small. i vixie don't love the mechanism, but i can't quibble with the social vixie impact. So your grand scheme is to limit who can get v6 PTRs and that will be the new standard of whether or now you're tall enough to send email with the big boys? How's that worked out so far in v4 in the last few years? How about we admit that PTRs as a measure of trust and reputation is broken to begin with and won't scale or magically work better for v6 than v4? Let's come up with a better solution(s). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
ebersman So your grand scheme is vixie decorum? No objections here if you succeed. :) ebersman ... to limit who can get v6 PTRs and that will be the new ebersman standard of whether or now you're tall enough to send email ebersman with the big boys? vixie yes. Well, for my $DAYJOB, that's certainly something we support. As someone who runs my own mail server and knows other small businesses who do as well, I'm still hoping we can come up with a better system that lets some of the smaller players in too. ebersman How about we admit that PTRs as a measure of trust and ebersman reputation is broken to begin with and won't scale or ebersman magically work better for v6 than v4? Let's come up with a ebersman better solution(s). vixie i think we're on the same page, actually. where we're still far vixie apart is in our understandings of how things work today, in other vixie words, what status quo are we living with; and also, whether and vixie in what direction we can change it. I'm happy to be educated or corrected by hard facts. And I agree we probably ultimately want the same thing: email that is more signal than noise to mail servers. Getting back to this draft, I think there is enough value in enumerating the challenges and tradeoffs of doing some kind of v6 PTRs to try to get the draft out soon. Plenty of folks (including $DAYJOB) want something short term that doesn't break anything and looks/smells somewhat like what we already have in v4. No argument that a better solution here long term would be welcome too; I just don't want folks to have another excuse not to roll out v6 now. As for a grander scheme to clean up the PTR space, do you agree that breaking that out into a separate draft is more productive? It does seem to make sense to mention that folks doing the $GENERATE equiv will get the same short shrift from the anti-spam folks that the v4 PTRs get currently. Any other comments/additions to this draft? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
vixie if there were an RFC (let's be charitable and assume it would vixie have to be an FYI due to lack of consensus) that gave reasons why vixie PTR's would be needed and reasons why the absence might be better vixie (so, internet access vs. internet service), then that RFC might vixie give our last-mile industry buddies the air cover they need to be vixie first movers in dropping PTR's for both V6 and V4 internet vixie access addresses. Hate to rain on your parade but this isn't going to happen. The problem is not one example, like NYT. It's that we have 20+ years of sloppy habits and people making golden calves of PTR records. As a last mile provider, customer screams are way more expensive than just whipping out garbage PTRs that mean nothing and are of no security/validation use but mean I don't get calls. I don't even know how many broken sites there are and I don't care to waste valuable staff time tilting at this windmill. I just want to avoid customer calls by suddenly deciding after decades that PTR records deserve to be cleaned up. My current expecation is somewhat like the following: - all routers/network interfaces will have PTRs so my traceroutes are of some use to my NOC - all service machines will have legit forward and reverse that match so that I can keep track of my own stuff and other folks will have less reason to ditch my email traffic - will probably get our DNS server folks to do lie on the fly v6 PTRs for any customer addrs, with sign on the fly so they do at least DNSSEC validate Folks using PTRs for insane uses like as part of VPN validation, to get web content or similar things that were useless in v4 will get the same delusional warm fuzzies they get now. Folks that find the current $GENERATE v4 stuff evil and untrustworthy will find the v6 stuff no better. Folks trying limit spam will hopefully figure out something that doesn't involve reputation by IPv6 addr, 'cause at 18 quadrillion per /64, that won't scale... ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-livingood-dnsop-negative-trust-anchors-01.txt
srose Should there be text describing auto-adding of NTA's based on srose important domains (for the ISP/resolver's definition of srose important)? So that domains that are used by low level services srose don't fail that also aren't normally visible to end users? One srose example is nist.gov. When nist.gov messed up and went DNSSEC srose BOGUS, time.nist.gov was unreachable by validating resolvers. warren Sorry, but to me this sounds like a bad idea -- you should find warren out that you not normally visible to end users failures are warren happening because your network monitoring system goes Beep Beep warren Beep when low level important services die. The NOC then goes warren off and investigates and discovers that e.g the NTP monitor it warren sad because time.nist.gov is unresolvable. warren At this point there really needs to be a *human* in the loop to warren decide what to do, if the failure really *is* a DNSSEC failure warren and, more importantly, if installing an NTA is the right answer. I'd hope it would be good operational sense for folks to have automated checks of critical things and checks of DNS logs for DNSSEC validation failures and that we shouldn't have to spell that out. But do we want to at least have a mention of doing such kinds of checks as a better way of noticing DNSSEC failures than pissed off customers or puzzled NOC folks? I do agree that we should not be inserting NTAs automatically for anything. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet
suzworldwide The draft is available here: http://datatracker.ietf.org/doc/draft-vandergaast-dnsop-edns-client-subnet/ suzworldwide Please review to see if you think this document is suzworldwide suitable for adoption by DNSOP and comment to the list. I support this draft as a working group item and am willing to review the draft. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-livingood-dnsop-negative-trust-anchors-01.txt
pwouters So I'm confused. What is the goal of this document? How does pwouters it help us? The other side of this document is that there 3 of the most popular vendors of DNS server software have this out. We as the IETF should be explaining the tradeoffs and risks of using an NTA. I certainly don't want enterprises, small service providers and govt agencies that may not have senior DNS folks just putting these into their configs with no idea of the security implications of doing so. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing
srose I can't speak for all of .gov, but I think the draft is ready for srose publication. Once it has an RFC number it will get worked into srose products and ops manuals. Since a lot of .gov agencies srose outsource, or use appliances, I wouldn't expect much feedback. :) Having worked recently at one of said vendors, where .gov customers wanted that DNSSEC checkbox thingie but did use various NIST and other standards, it means that this RFC will get into the check list of RFCs vendors need to say yes to in bids, so there will be use of the recommendations. Sadly, you are probably right on feedback from some of the vendors and most .govs... ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing
ajs giving useful advice, even if not perfect, on this topic will be ajs more helpful than producting perfect advice. [...] ajs Please publish it. +1 Many folks won't implement this until it's an RFC (.gov, etc.) but will and give feedback once it's out. Perfect is the enemy of progress... ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc6598-rfc6303-00
jabley I would prefer the pragmatic option 5: jabley 5. Leave both registries as-is, publish Mark's document as-is, jableyand work on a separate registry clean-up draft later, since I jableyam guessing that work will not be uncontentious and the jableyguidance provided by the draft at hand is sufficiently useful jableynot to stall. +1 for pragmatic approach and moving forward. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?
nick I like this and think it should be adopted as a WG doc. Am not nick going to volunteer for formal document review, but would be happy nick to run + provide feedback for this sort of code in a live nick environment. I also support this being adopted as a WG document. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
