Re: [DNSOP] Feedback on draft-koch-dnsop-resolver-priming
can someone who followed the POISED effort please explain IETF's policies around restricted IPR? i really feel a need to avoid poisoning my thinking by accidentally reading somebody's draft that recommends restricted IPR. we already know that such drafts won't pass WGLC, and i'm a member of a largish set of people who would lodge process complaints with IESG and/or IAB if such a draft were to somehow sneak through WGLC. so why isn't there a rule against submitting drafts covered by restrictive IPR in the first place? T-M's suggestions here follow his prior IPR attack in dnsext (TAKREM), and it's just one stupid waste of time after another for all concerned. the only possible beneficiary of this waste is T-M himself, if he wants to be able to show prior art during some later patent lawsuit. there ought to be a rule that IPR disclosures must accompany all proposals, including mailing list posts, and the moderator ought to simply squash anything that's encumbered. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Feedback on draft-koch-dnsop-resolver-priming
I think this is exactly the sort of thing the IPR RFC requires for accepting encumbered ideas. (Although the restriction to root zone operators is a bit troubling.) yes. (also, TAKREM was offered free for GPL implementators, and so, worthless.) Anyways, the basic idea is that there's no need to start the flame-fest / endless arguments until it looks like there is actually some support for the idea. i'm trying to uplevel the argument. can we make posting to ietf WG mailing lists contingent on IPR disclosure, and can we make it a moderation principle that IPR'd posts will simply not be published here, ever? my concern is that T-M's encumbered proposals will remove certain approaches from the table. or that once we've all heard one of his ideas, he can claim later that any similar ideas in our work product are based on his proposals. this feels like a mental contamination strategy and i'm angry enough about it by now that i'm willing to raise my hand and object, for once and for all. ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adopt draft-koch-dnsop-resolver-priming as WG work item?
[EMAIL PROTECTED] (Thierry Moreau) writes: This question is serious, to the extent that the DNSOP activities are worth the effort devoted to it by participants. So let me re-prhase the question (actually the question had two facets): Is this proposed wg activity open (i.e. The IETF has basic requirements for open and fair participation and for thorough consideration of technical alternatives. from RFC2418 section 3)? Is this proposed wg activity already limited by the message archived at http://www1.ietf.org/mail-archive/web/dnsop/current/msg05460.html ? i'm not a wgchair or anything, so this is just my opinion. anyone who is going to submit proposals for dns technology should not include encumbered IPR. if i can't implement an RFC in BSDL F/OSS, then it's a bad RFC. if folks can't fetch, compile, build, install, derive from, and make money from the BSDL F/OSS that results from implementing an RFC, then it's a bad RFC. if i see a bad I-D then i will object to it becoming a bad RFC. i think this means that the answer to t-m's questions amount to no even though asullivan's answer (it depends) is probably more accurate. t-m has in the past said that he wants IETF to standardize encumbered IPR so that he can make money from license fees paid by people who deploy it. i think that's offensive screwheadedness and i am opposed to it. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-respsize-07
[EMAIL PROTECTED] (Andrew Sullivan) writes: I note that in section 2.2.3, we have this: A zone's name servers should be reachable by all IP transport protocols (e.g., IPv4 and IPv6) in common use. I have read differing opinions on whether it is better to have protocol-dedicated servers (on the grounds that it makes troubleshooting in a world of poorly implemented dual stacks easier) or to have all-protocol name servers. I think therefore that the reasoning for the above claim should be spelled out in more detail. what i meant was that a zone should have servers reachable by every IP transport protocol in common use, in order that the zone be reachable by all DNS initiators no matter what IP transport protocol they're using. i can see that the writing as quoted above is sloppy, and doesn't say what i thought it said, and i can clean it up if the WG thinks it's important. Other than that, I think this is a good and useful draft, and should be advanced. me too! -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adopt draft-koch-dnsop-resolver-priming as WG work item?
Mr. Paul Vixie to ISC, and the subordination relationship that can be inferred from Mr. Paul Vixie's position as ISC president. Paul has never tried to control what I do as DNSOP WG co-chair, and clearly understands the obligations that go with my position. Paul also knows me well enough to know that I'd tell him to go to hell if he ever did try to keep me from performing my duty as I see it, but the issue has never come up and I don't expect it ever will. assuming for a moment that because rob and i are in the same management chain my instructions were ever different than use your own best judgement even in matters internal to isc (which would indicate that i had more time than i actually do, and that rob had more tolerance for foolishness than he actually does), i wonder if the above inference would also apply to suzanne woolf in her position on the icann board and arin advisory council, or keith mitchell in his position on the nanog program committee and executive director of uknof and programme manager of oarc, or any of the other times when isc employees do external public service work. i don't know if t-m's inference is meant as isc employees are shills or perhaps all employees are shills, but the idea certainly conflicts with my own vision that whatever it is about someone that makes them useful at isc probably makes them useful elsewhere, and if isc's mission is public service, then encouraging this kind of public service would be a good company policy. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adopt draft-koch-dnsop-resolver-priming as WG work item?
Austein needs to avoid participating in issues that affect his company, its financial position, or that of his co-workers. Should Rob recuse himself from *any* matter that Paul's sent an email about? What about opinions Paul may have discussed with Rob privately? Or just things he's vaguely thought about, without saying anything? i'm left wondering how TAKREM could affect isc's finances, or the finances of any of rob's coworkers. is it possible for isc to make less money from DNS software than what we already don't make? i think it's time to declare troll alert! and move on. ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Re: AS112 for TLDs
[EMAIL PROTECTED] (Joe Baptista) writes: No it can't be done with BIND. Very lame. It would be a big asset to root technology of the entire *. wildcard TLD label could be pointed to AS112. AS112 is truly the blackhole of this universe we call the internet. AS112 - the internet garbage can. I support using AS112 for that. Great way to reduce the error traffic at root-servers.net. wildcards can't be cname's or ns's. (of the many important reasons why the suggestion is terrible, that's the first/simplest that comes to mind.) -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
[EMAIL PROTECTED] (William F. Maton Sotomayor) writes: At this point, I'd like to see the current pair of drafts move forward, and would cast this particular issue as the subject of some sort of other document. likewise, me. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
[EMAIL PROTECTED] (黄理灿) writes: Hi, I have updated distributed DNS implementation in Ipv6. Please give your comments. Thanks. Dr. Lican Huang thank you for your work on this. i find no support for this assertion: 1. Introduction Although DNS becomes a vital component in today's Internet infrastructure, the existing DNS architecture will encounter problems in the future for the growth of the Internet. ... DNS implementation currently used may encounter overload traffic in root DNS servers. ... therefore while i find your proposed solution to be of high quality, there is a cost in overall system complexity for adding a virtual routing layer to the DNS, which would have to be justified by a much more complete problem statement and an objective analysis of more than one alternative. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
From: 黄理灿 [EMAIL PROTECTED] ... almost all web pages was unreachable even the machine was in China because of root servers are located in USA. ... according to http://f.root-servers.org/, there are two f-root servers in china. if you have local contacts within china, please help us add more root name servers there, and please help us achieve better peering at the two sites we have (beijing and hong kong). according to http://root-servers.org/, MOST root name servers are outside the united states. i know from living through the transition that this has been true for several years now. i also know that there have been SOME root name servers outside the united states for more than a decade. you are not helping your case by making assertions widely known to be false. what's your actual agenda? is it just that you need to show utility for your academic work in order to finish your PhD? if so, i can offer several suggestions as to real problems that actually do need solutions. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification
note, i have removed the leading tab character from this author's paragraphs, since i find it very distracting. (a cautionary note to marka and bmanning.) [EMAIL PROTECTED] (Phil Regnauld) writes: Question: How do existing implementations react to the presence of a single, terminal dot ? What if an A record is published for '.' ? I know it probably won't happen. but I'm also curious to know, and I think the document should specify this: what is the impact of this on existing implementations ? i'm afraid that this will just result in a lot of QTYPE A messages sent to the authority servers for . asking about ., and a lot of new useless RCODE 3 responses therefrom. Question: In some cases it can be useful to be able to identify the real master anyway. But MNAME was never a reliable way of ascertaining which server in an NS set was the source of data, if such a source existed at all. during the preparation of RFC 2136 we knew that SOA.MNAME was often meaningless, and so the rule is, if it's the same as an NS.NSDNAME, then it's the best target for an update. the purpose of this was to avoid having to forward updates from secondaries toward the master. but as it happened, noone read RFC 2136 carefully. every second of every day, the SOA.MNAME for 10.in-addr.arpa receives update requests from all over the world, even though it is not also an NS.NSDNAME. those update requests are all coming from a single vendor's implementation. Do people on this list think that we are losing any valuable information by using the convention suggested by Joe, or was it already too uncertain, and that no usefull debugging/troubleshooting information is being lost by implementing the suggested approach ? i think it will not be correctly implemented, just as RFC 2136 was not correctly implemented, and if people start putting SOA.MNAME=. then it will just lead to a lot more QTYPE A queries for .. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification
[EMAIL PROTECTED] (Brian Dickson) writes: Are you certain? (And does RCODE 3 mean, as I understand it, NXDOMAIN?) i mean of course ANCOUNT=0 RCODE=0, thank you for your correction. Again, hypothetically, what values for such an A RR would cause benign behaviour? E.g. 127.0.0.1? Just thinking *way* outside the box i think that if LOCALHOST. could be made to return A 127.0.0.1 and ::1 then we could use LOCALHOST. as a meaningless value for SOA.MNAME, but that would just be there to handle the case where RFC 2136 initiators were talking to an SOA.MNAME that did not match any NS.NSDNAME, in which case they are already out of spec and it's difficult to say how much effort should be spent changing the spec further. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification
Is it not the case that ANCOUNT=0 RCODE=0 responses could be cached, whilst
failures to send DNS UPDATE messages to root servers would not be cached?
the data at hand tells me that lots of people don't cache, and those who
do only cache positives. but in principle, yes, if the hosts who aren't
following the spec regarding using SOA.MNAME as a selection criteria among
{NS.NSDNAME} happen not to be the same hosts who aren't caching negative
or empty results, then some good could come of this.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
the fact that masataka's proposal seemed qualitatively better to me eleven years ago is moot. the reason dnssec isn't deployed yet has nothing to do with any such qualitative differences. we are where we are, and what we've got to do now is deploy what we've got now. the dnssec spec at present may be ugly but it is practicable, and there's a large body of expertise and running code and commercial products and interoperability testing behind it. while i didn't enjoy watching masataka's proposal railroaded into the ditch and while it would have taken less time to get masataka's dnssec proposal deployable than it has taken to get to what we've got now, the silver lining for me was that i learned how to railroad my own proposals through IETF using the techniques i learned. RFC 2136, RFC 2671, and RFC 2845 all exist only because of the dirty tricks i learned by watching masataka's mistreatment. (had i known at the outset how IETF worked, i would have worked to prevent that mistreatment, but i was a n00b.) -- Paul Vixie -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
Paul's original proposal, C (if I interpret it correctly) applies to resolver-authority-server communications, not stub-resolver communications. no, i was pretty much ruling them out period. especially (RA=1 AND RD=0). however, i could accept a SHOULD NOT for ADNS vs. a SHOULD for RDNS on TCP/53 as long as we also add a SHOULD on RDNS for accept only transactions from intended clients, most likely from within the same LAN, campus, or ISP. SHOULD is great since people who don't do it are still compliant. opendns wouldn't be in trouble. but vendors would become advised to set their defaults to a non-global ACL and then TCP/53 is safer. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
what would it do if it had a TCP-forbidding firewall between it and its RDNS? Dunno, but when PowerDNS had TCP bugs in its resolver code, all the complaints I got were from Exchange users. they'll cope. What's the rush with deprecating DNS/TCP btw? It languished in the shade for 25 years.. that's what we said about udp port randomization after bernstein invented it. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
Bad example. One of the reasons we don't see more crypto per default on web browsing is precisely the limitations of SSL/CA's on using SSL with virtual host web sites. I'd hardly call the lack of port 443 a success story. we don't need a reason to deprecate tcp/53 beyond what's written in rfc1035. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
[EMAIL PROTECTED] (David Ulevitch) writes: ... -- My goal is not to derail DNSSEC. It does that on its own. My goal is to make sure people don't buy into the kool-aid being poured that DNSSEC is the only solution. It isn't. that depends on the problem statement, really. if the problem statement is how can we secure hop-by-hop then there are other solutions on the table right now besides DNSSEC. if the problem statement is how can we secure end-to-end then there are no other solutions on the table right now. my chosen problem statement is how can we secure end-to-end because i am worried about corruption inside servers not just between them, and i want to defend against provider-in-the-middle attacks (including several that opendns currently monetizes.) -- Paul Vixie -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR
... let's deprecate these bit patterns altogether for OP=QUERY: QTYPE=255 Breaks some sendmail versions and qmail. i once hacked sendmail internals, and what i remember is that it would try a QTYPE=ANY to see if it could get both the MX and its A in one shot, on the hopeful assumption that they had the same domain name. an earlier version had a bug whereby it didn't know ANY was hop-by-hop even in the presence of RD=1, so a partial answer of A alone was taken to mean there was no MX, but this was fixed before my son (who is now 17) was born. no version i know of will fail to make an explicit MX query if ANY comes up dry, or fail to make follow-on A queries if ANY comes up without an A. so, can you explain what you mean by breaks, both for sendmail and qmail? QCLASS=255 QCLASS != IN seems more reasonable to me. i don't think we should foreclose the possibility that QCLASS != IN will be useful to somebody some day. do you know a specific risk for QCLASS != IN? RA=1 AND RD=0 By the responder or the initiator? nonrecursive queries of recursive servers are a useful diagnostic but also an information leak that can help an attacker shape their flows. peter koch has reminded me that a server that's both authoritative and recursive would not be able to answer wearing its authoritative hat if this were literally enforced, and while i think there should be no server wearing both a recursive hat and an authoritative hat, i don't think we should legislate against it in this proposal. so we can't literally outlaw a bit pattern, but we can say, if RD=0 then no non-authority data should be returned. and let's also make explicit that TCP is not to be used unless UDP returns TC or unless QTYPE=AXFR or unless UDP QTYPE=IXFR returned only one SOA. I strongly oppose this approach. Unsolicited TCP has its place. are you strongly in favour of amending RFC 1035 4.2.2 to say that responders initiate close, or that timeouts of less than two minutes are allowed? this is the one of the least scalable and most vulnerable elements in all of DNS. with rich stevens gone and nobody to complete or champion T/TCP, we're left with several bad multipacket protocols including IP fragmentation and TCP for handling data larger than the MTU. i don't know how to make TCP scale for this, it's not like TCP/80 where server operators who want to handle a million simultaneous queries know that they'll need a lot of silicon+power to do it. did RDP (RFC 908, RFC 1151) ever achieve critical mass? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR
i answered this on namedroppers, where the thread actually belongs. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
no hop-by-hop solution can address the problem of a MiTM who can see and/or alter your queries and responses. If you have a malicious man in the middle, he will do bad things to you. DNSSEC will not stop that. please explain how i can get undetectably bad data in a dnssec environment, where bad means did not come from the zone editor. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] trolls (Re: Reflectors are Evil was Re: Anycast was Re: Cache)
[EMAIL PROTECTED] (Danny McPherson) writes: Dean, I'm not going to argue this point by point with you, ... how long is this community going to let a single person dominate its agenda? i'm using kill-by-thread on dnsop now. i have no idea how much i'm missing of what's being posted, but what i really fear is what i'm missing by how much is not being posted, because so many others have also been driven into similar kill-by-thread exhaustion by the endless back and forth on the same small web of interwoven topics by the same four or five people who just can't bear to let foolish or silly or factually wrong statements go unchallenged. an early and elementrary usenet discovery, back the low to mid 1980's, was that some people will not change their views no matter what's said to them, in fact they aren't really hoping for that, all they look for in replies to their articles are hooks on which to hang a renewed restatement of whatever they said before. it is itinerant on all of us to not fall into the trap of needing to set the record straight on a daily basis. some things we don't agree with can be left unchallenged, it won't affect the lense of history nor the views of the silent majority of fence sitters watching the back forth. show some willpower, folks, please. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] trolls (Re: Reflectors are Evil was Re: Anycast was Re: Cache)
the un-answered argument wins only if it's never answered. that would cross the line. answering it every day for the rest of all of our lives crosses the other line. (not responding publically to the personal parts of what bill said to me.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] measuring TCP query performance
Date: Wed, 26 Aug 2009 16:39:31 -0500 From: Michael Graff mgr...@isc.org ... since by definition, I always really need stuff. +1. years ago i tried to differentiate between additional data or authority section data that a requestor could live without, vs. additional data or authority section data that a requestor could not live without. i wanted to not set TC unless the stuff that would not fit was in the answer section or was something from the authority or additional section that a requestor could not live without. i failed utterly to describe this in a way that anybody else could make sense of. i hope someone will try again, rather than falling back to TCP for things that weren't absolutely necessary like in-zone nameserver addresses, or dnssec metadata (if DO=1). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new Questions...
Date: Thu, 03 Sep 2009 06:48:21 -0700 From: Todd Glassey tglas...@earthlink.net Actually Dean - good point - the MOU was never codified in a formal contract meaning that the US Department of Commerce still formally owns the root's and so under this newly proposed cyber-control law would give the US President the legal authority to on a mere presidential order (especially a HSPD) or just a simple presidential directive can shut all - repeat ALL - of ARIN's and each of the root systems down since the US DoC still owns them. todd, please do not feed the trolls. the ietf saw fit to ban mr. anderson from this mailing list (and a few others) and he's now created his own mailing lists and added all of us to them so that he can continue posting, but that shouldn't mean i have to read his text when included by others in their replies, nor should we have threads hijacked in the ways that got mr. anderson banned in the first place. I wonder how many of the Internet-Mavens on this list have figured that out... every statement you made above is factually wrong. so, no. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
From: Nicholas Weaver nwea...@icsi.berkeley.edu Date: Fri, 19 Mar 2010 12:48:24 -0700 ... Enshrining tho shalt never fragment into the Internet Architecture is dangerous, and will cause far MORE problems. Having something which regularly exercises fragmentation as critical to the infrastructure and we wouldn't have this problem where 10% of the resolvers are broken WRT fragmentation. +1. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] dns interface to whois? (Re: Taking Back the DNS )
From: John L. Crain john.cr...@icann.org Date: Sun, 21 Nov 2010 09:51:45 -0800 Why would we do this, who gains by adding this? I don't see the benefit. i think it's so that folks can refuse e-mail from domains under N days old where N is a local policy decision. i have no direct use for it so i'm sort of guessing here. Was the use case outlined? no. i'm guessing it's a way to do http://www.support-intelligence.com/dob/ that does not require downloading TLD zone files every day and diffing them. --- noting that the race to register domains as fast as possible and as many of them as possible has primarily benefitted spammers not their victims, the good guys have built a magnificient system whose highest and best use is against our own interests, and that kind of folly produces requests such as this one -- stuff that in a better overall system would not be asked for. less controversially, the data is already public, the question is whether a standard dns schema as another interface into this public data would be useful to enough people. as to whether some registries might be forced to support it when they don't see a need, that's a governance question not a technology question, and it is: is more transparency better? re: http://www.circleid.com/posts/20100728_taking_back_the_dns/#7331 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] dns interface to whois? (Re: Taking Back the DNS )
Date: Mon, 22 Nov 2010 20:36:17 + From: bmann...@vacation.karoshi.com we tried this a couple time last decade with limited success. (pre SRV). it would work, if and only if there were general agreement by the zone admins to actually keep up w/ the data. while i expect that it would be a gateway rather than a data transform, and while i agree that if it's a data transform then it should be done often enough to not get out of date, i note that i'm asking a different question than would it work. i'm wondering if there's enough interest to have it be worth writing it up as a dns schema so that interested producers and consumers of this information in this form can have a standard rendezvous (qname format) and delivery system (TXT formats). that's not would it work. it's could it ever be useful to anybody. i am not trying to get input on technical feasibility since i think that's pretty obvious. nor am i trying to get input on governance like should registries be required by icann to implement it or should icann implement it for root, arpa, and other non-delegated zones. just is there interest. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] dns interface to whois? (Re: Taking Back the DNS )
Date: Mon, 22 Nov 2010 22:52:34 + From: bmann...@vacation.karoshi.com well, at least two schemas have been proposed and there was limited uptake either time. perhaps times have changed. the fact that so few people have spoken up gives me my answer -- there's not enough interest in this to make it worth doing. previous efforts did not become RFC's in any form, and it seems likely that another would also not make it. well, one thing that kind of makes sense is where to anchor such records... two choices - a WKA such as in-addr.arpa, ip6.int, enum.arpa et.al. or place the entries at each delegation point and sweep the tree periodically to build a stale cache of data... in the basenote of this thread i was only proposing this for registries of names. so, vix._domain._whois._registry.com for vix.com, and similarly pv15._contact._whois._registry.com for the PV15 contact in the COM registry. i'm aware of your prior work to do this for numbers but that wasn't my topic. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A new appoarch for identifying anycast name server instance
On Tuesday, September 27, 2011 09:49:03 am Masataka Ohta wrote: Xun wrote: Unicast address of an anycast server is very useful for many diagnostics, however, as DNS queries is sent to the anycast address and the path is decided by routing system, knowing the set of unicast address may not sufficient to answer that question. That is an issue better handled by IP layer. The purpose I see in this proposal, that cannot be handled by the IP layer, is to tell me which anycast instance is seen by some recursive name server. All our current diagnostics rely on contacting the server itself to see which server answers us. The proposal now being discussed allows the DNS control plane to be tested. In other words if I want to know which F-root instance I am being routed to, I can ask, dig @f.root-servers.net version.bind ch txt or the equivilent in terms of id.server. But if i want to know which F-root node my ISP's name server is being routed to, I have no tools available today. I would like to be able to say dig @75.75.75.75 _hostname._ns_diags.f.root-servers.net txt or similar. To do that, there has to be an NS record at or below the name server name (or some other predictable rendezvous point in the naming system) and each instance must serve that zone locally with localized content. I support the general concept of this draft. re: http://www.isi.edu/~xunfan/research/draft-anycast-diagnostics.txt Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A new appoarch for identifying anycast name server instance
On Tue, 27 Sep 2011 22:51:09 +0900 Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Paul Vixie wrote: The purpose I see in this proposal, that cannot be handled by the IP layer, is to tell me which anycast instance is seen by some recursive name server. All our current diagnostics rely on contacting the server itself to see which server answers us. The proposal now being discussed allows the DNS control plane to be tested. Are you saying that end users, not name server operators, diagnose anycasted name servers? no. Certainly, you, as an end user, can do so. i think i could diagnose problems reported on my authority server if i could get a recursive name server to tell me which of my anycast instances it is talking to. there may also be some network mapping and measurement benefits to this proposal. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A new appoarch for identifying anycast name server instance
On Thursday, September 29, 2011 07:34:55 am Masataka Ohta wrote: The problem is that the report is unreliable. As your assumption is: The purpose I see in this proposal, that cannot be handled by the IP layer, is to tell me which anycast instance is seen by some recursive name server. even you can't diagnose the problem, if what is broken is not your server but the recursive name server used by someone who reported the problem and you can't have access to the recursive name server. that happens sometimes. however, i often end up in an email conversation with a problem reporter, and i often ask them to run certain dig commands. so, even if i can't reach a recursive server, a feature like this can still help me. there may also be some network mapping and measurement benefits to this proposal. May or may not be. there are ~16M open recursive name servers right now. so, i say, may. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] word wrapping and respect for standards
On Thursday, September 29, 2011 03:36:26 pm Nicholas Weaver wrote: Word wrapping MUST be done on the recipient side, not on the sender side, unless you want to maintain ridiculous conventions like text lines are at most 72 characters, monospaced which were obsolete two decades ago. And in this case particular case, blame Microsoft. Apple on their mailer for the longest time implemented a standard method, format=flowed, intended to please BOTH mail readers that can word-wrap and mail readers that can't. But they dropped this way back in 10.6.2, because Microsoft never recognized it right. Given the choice between pleasing a few recipients who cling to an obsolete convention with obsolete tools and pleasing the very large population of recipients with a tool unwilling to accept a standard which could please both, Apple went with the natural choice: it is the mail reader's responsibility to word wrap to the reader's own display parameters. format=flowed gave the nec'y hint, told my user agent that the text was meant to be wrapped. in the absence of this hint, i don't get word wrapping because the columns might be fixed. (like code fragments or similar.) so i do blame microsoft for not doing the right thing with format=flowed, but i also blame apple for going off-rails and violating the principle of least astonishment for an unknown but nonshrinking population of non-microsoft e-mail readers. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Sanity check
On Thursday, October 27, 2011 10:06:25 Havard Eidnes wrote: I wonder if I could please have someone say whether they agree with me on this one: ... My claim is that it is a Registry Error for the operator of the registry for the 'z' domain to permit this to happen, as it violates the basic idea of what a delegation means. ... i'm +1 with this interpretation. not just because implementations do not all do the same thing in the presence of this data pattern, but because in recent decades we've adopted a mount point semantics view of dns delegations. this should be written down somewhere, because the rfc 1034 rules about scan down the tree looking for a delegation logic does not mesh well with the closest enclosure logic that most implementations actually follow. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Data model and field names for DNS in JSON or XML
On 1/18/2012 7:06 PM, W.C.A. Wijngaards wrote: this sounds very cool; is there an internet draft or tech note describing the protocol so that others may also implement this? It exists to bypass deep inspection firewalls, and it works. The plain DNS format as you would use over TCP, but then on an SSL connection, so its encrypted by SSLv3. Uses port number 443 (the https port, no other use of that protocol, but then, because of SSL the firewall should not be able to tell). alas, DPI can tell the difference between HTTPS and TLS in a TCP/443 stream. (the Tor guys told me this.) The SSL-certificates are there to make the SSL connection look legit to the firewall. The DNSSEC inside the DNS wireformat provides authentication. There could be a technote or draft for it, but really: TCP-style-DNS inside SSL for transport. That should tell enough for an implementation? it's not enough. in particular, the order in which it's probed (compared to EDNS0 UDP, EDNS0 TCP, old style UDP, old style TCP) should be specified. the NS RRset gives no hint of the name server's capabilities. and the IETF definition of interoperable depends not just on independent implementations being able to talk to each other, but independent implementations both based on the same specification that can also talk to each other. signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [rssac] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt]
On 2/11/2012 5:25 PM, Paul Hoffman wrote: On Feb 9, 2012, at 1:39 PM, bmann...@vacation.karoshi.com wrote: I think that starting work on such a draft is a great idea -BUT- in the mean time do not let perfect get in the way of good enough. Just to be clear: a good handful of people, me included, have said that the wording in the current doc is not good enough, or only good enough if you squint hard. It is clearly much worse than the document that this is supposed to replace. wearing my rfc 2010 co-author hat: +1. paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt]
On 2/14/2012 5:20 PM, David Conrad wrote: ... I agree, however I'd think a better approach would be to write a BCP for important DNS servers, not a document that sets up false expectations or assumptions. +1. there are a lot of important non-root dns servers, and the collected wisdom of all of there operators would be a good thing to gather and peer-review and publish. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
On 2012-02-28 12:27 AM, Edward Lewis wrote: At 13:35 -0500 2/27/12, Hector Santos wrote: If it doesn't already exist or not considered in the past as an unfeasible concept, I am interest in seeing if this is something worth pursuing. One (not the only, Ohta replied with another) of the oft-cited obstacles is the presence of only one RCODE field in the packet. (What if one query would be NXDOMAIN and the other has an answer?) indeed, this is why multiple queries were not supported in the original DNS, and it's why EDNS doesn't have it either. the number of signalling bits needed to explain what went on with the multiple queries made folks' heads explode. the logic is still online if you want to see it: http://nsa.vix.com/~vixie/edns1.txt. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
On 2/28/2012 3:28 AM, Hector Santos wrote: Paul Vixie wrote: ... http://nsa.vix.com/~vixie/edns1.txt. Thanks Paul. Great material. I'm just winging it at this point. First, I was focusing on the batching of related types, i.e. a protocol with new RR type but has an initial default intro record and fallback to TXT. The goal is to have a single call that will yield a managed result to assist with the current concerns and waste associated with the migration of TXT to the new RR type usage. the way this was handled for MX was to have A (and later ) as additional data for the MX QTYPE. we should have made QTYPE include type A as additional data. we still can. we should have amended QTYPE A to include type as additional data. we still can. using additional data for this is great since if it's missing you query for it but it won't always be missing. Second, I considered there is no room for a packet count, but I was thinking of simply bundling two separate packets, i.e. 2*RR for the UPD send and how would the servers read this. RCODE FORMERR. this means the initiator would have to be prepared to try again with discrete queries. this is a form of protocol negotiation -- the fact of a responder's nonsupport would have to be discovered (and cached for a while) by each initiator. this is already happening for EDNS. i would recommend against adding more responder state to initiators. this would also mean that when it works you've got one round trip and when it doesn't work you've got either three (assuming you don't blast #2 and #3 without inter-record gap) or two round trips (if you use blast on #2 and #3.) If DNS servers will barf, then never mind. :) yes. But if its offers a way to perform this concept with no breakage, perhaps the server will just read the first one and act on it or it will process the residual packet as well. Of course, the client will still need to manage the responses with all the potential delays. Again, just winging it. I don't like kludges. :) please consider additional data, or blast. paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
On 2/28/2012 5:57 PM, Nicholas Weaver wrote: But since if you could coalesce you could do parallel, this savings doesn't help latency much at all: just the transit time for 50B out and 50B back. If anything, parallel will be BETTER on the latency since batching would probably require a coalesced response, while parallel is just that, parallel, so if the first record is more useful, it can be acted on immediately. parallel (what i called blast) is great solution for things that don't run at scale. but the lock-step serialization that we get from the MX approach (where the A/ RRset may be in the additional data section and so we have to wait for the first answer before we ask the second or third question) has a feedback loop effect on rate limiting. it's not as good as tcp windowing but it does tend to avoid WRED in core and edge router egress buffers. all i'm saying is, we have to be careful about too much parallelism since UDP unlike TCP has no windowing of its own. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] 2 internet drafts relevant to DNSOP
joe, et al, your draft-gersch-dnsop-revdns-cidr-01 is very clean and simple; the draft and the design are of admirable quality. as a co-author of RFC 2317 i agree that it does not suit the needs of bgp security since it seeks only to provide a method of fully naming hosts, not networks. importantly, i see no reference to RFC 1101 in your draft. RFC 1101 describes a way to name networks, and while at first it did not seem to be compatible with CIDR, implementation (in netstat -r back in BSD/OS 3.1) showed that RFC 1101 was in fact not as classful as it appeared. i recommend a review of these functions, contained in the file dns_nw.c, present in bind8 as src/lib/irs/dns_nw.c, and also present in older versions of bind9, as well as various versions of netbsd and athena. static struct nwent * get1101byaddr(struct irs_nw *, u_char *, int); static struct nwent * get1101byname(struct irs_nw *, const char *); static struct nwent * get1101answer(struct irs_nw *, u_char *ansbuf, int anslen, enum by_what by_what, int af, const char *name, const u_char *addr, int addrlen); static struct nwent * get1101mask(struct irs_nw *this, struct nwent *); static int make1101inaddr(const u_char *, int, char *, int); you may find that some of your work has already been done for you, or, you may find that this is related work that should be referenced in your draft along with the reasons why your proposed method is necessary. paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt
On 3/30/2012 10:19 AM, Ray Bellis wrote: With the current scheme it's possible to delegate longer prefixes, and this is a necessary feature. The stuff Dan was saying about two alternate representations concerns me, though. As written, by default: 192.168.64/18 is 1.0.m.168.192 but 192.168.64/24 is 64.168.192 which is not a sub-domain of the enclosing /18 representation. This way lies dragons, I think... +1. thus my earlier observation: RFC 1101 supports classless networks even though it didn't mean to. RFC 2317 is entirely compatible with RFC 1101 (there's only one delegation tree covering both.) if there's a need for a new netblock-specific DNS schema like the one in the gersch draft, then i recommend learning from what we did in RPZ, where the prefix size is _always_ given as are all octets of the mantissa except the :: longest-zero string which is given as .zz.. more information about RPZ can be had from: https://deepthought.isc.org/article/AA-00525/0/Building-DNS-Firewalls-with-Response-Policy-Zones-RPZ.html and specifically from: https://deepthought.isc.org/article/AA-00512/0 which has the actual spec, in .txt and .pdf format. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Request to adopt draft-sotomayor-as112-ipv4-cull as WG item
On 2012-04-04 12:20 PM, William F. Maton Sotomayor wrote: It seems that after delivering my presentation on subsequent AS112 delegations in Quebec City, I hadn't recalled what the group thought about adopting this work as a dnsop item. So, I'm soliciting feedback on this request. I have posted version 03 for your consideration. i think it should be adopted, but i have no time to work on it, so my vote may not count. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on Negative Trust Anchors
the information economics of this draft are all wrong. with all possible respect for the comcast team who is actually validating signatures for 18 million subscribers and is therefore way ahead of the rest of the industry and is encountering the problems of pioneers... this is not supposed to be comcast's problem. if someone that comcast's customers want to reach, blows their dnssec out by using the wrong keys or using expired signatures or whatever, then the problem ownership should rest with whosoever blows their dnssec -- not with comcast. it's only because comcast is first that comcast has to watch out for the deleterious effects of OPM (other people's mistakes) on comcast's own customers. comcast can't afford the help desk call volume that would come from another wrong-key failure at the social security administration's domain. but that doesn't make it comcast's problem. it would remain the social security administration's problem. we need to move quickly to the point where lots of large eyeball-facing network operators are validating, such that any failure to properly maintain signatures and keys and DS records, is felt most severely by whomever's domain is thus rendered unreachable. if everyone interested in working on this draft would take the time to turn on validation, then we could avoid inverting the information economics here. people who can't manage their keys and signatures properly (and i include my own vanity zones in that, since i'm not yet converted to the bind 9.9 way of doing things) should either expect trouble or uplevel their game or stay out of the game. i'm opposed to negative trust anchors, both for their security implications if there were secure applications in existence, and for their information economics implications. paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on Negative Trust Anchors
On 2012-04-14 1:51 AM, Doug Barton wrote: ... The problem, and I cannot emphasize this highly enough, is that there is absolutely no way for an ISP (or other end-user site doing recursion/validation) to determine conclusively that the failure they are seeing is due to a harmless stuff-up, vs. an actual security incident. IOW, if we do this, we might as well just abandon DNSSEC altogether. this is what i was alluding to in some text up-thread: On 2012-04-13 5:43 PM, Paul Vixie wrote: ... i'm opposed to negative trust anchors, ... for their security implications if there were secure applications in existence, ... because a secure application must be able to fail reliably under attack. introducing third party bogosity breaks that failure, and it won't matter whether it's SOPA or NTA that breaks it. if i can leave you all with one thought its that dnssec failure must be reliable, end to end. see also http://www.circleid.com/posts/20121012_dns_policy_is_hop_by_hop_dns_security_is_end_to_end/. paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on Negative Trust Anchors
On 2012-04-15 4:09 PM, Patrik Fältström wrote: On 15 apr 2012, at 16:42, Joe Abley wrote: Nobody is talking about creating NTAs. NTAs already exist. The question for this group is whether or not they are worth standardising. Fair. I am the one that extrapolate from standardizing to wide deployment. extrapolating further, standardizing is a form of legitimization. i argue that this would do more harm than good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on Negative Trust Anchors
On 2012-04-15 4:20 PM, Stephan Lagerholm wrote: ... However, the open resolvers that don't support DNSSEC are a bigger issue since the Service Providers' customer instantly can get what he believes is a better working resolver by switching to one of those. If we could convince 8.8.8.8 (208.67.222.222 and 4.2.2.1) to turn on DNSSEC validation, then there would not be any need for NTAs. ... dnssec makes dns less reliable. that's because it's a security technology not a resiliency technology. security makes things harder to use and makes failures more apparent. in the real world if you put a lock on your house or your car then you're at risk for forgetting or losing your key and not being able to enter or use your own property. you could mitigate that risk by removing the lock but then you'd have other risks. what's unique about dnssec is that if you lose your key or use the wrong key or forget to re-sign your zones then it's not you (the property owner) who cannot enter or use the zones, but rather, everybody else. i don't think that asymmetry of cost changes the fundamentals. the operators of 8.8.8.8 and so on (from the above examples) may have done a cost:benefit analysis leading them to not deploy dnssec validation at this time. that will make their systems more reliable in the eyes of end users. that's true and that's inevitable. i'm imagining that some NTA-using party notices via their syslogs that validation is failing for some zone, and believing that access to this zone in an unsecure way has a better cost:benefit ratio to them and to their own customers than letting the failure propagate and so enters the zone into the NTA... only to have it turn out later that there was a key compromise and the failure was due to a credential or key or system attack rather than due to someone forgetting or losing their key. people who sign their zones must be told, early and often, that adds risk. they will have to re-sign their zones before signatures expire, they will have to carefully coordinate key changes with their parent zone, they will have to keep their signing key under secure but redundant control... and any failure by them to do any of those things will make their zones unreachable by a large and growing audience. if they sign anyway then any resulting failures have to be laid at their doorstep, not at validating server operators' doorsteps. if a secure application knows that a zone is supposed to be signed (because there are DS RRs in the parent and the parent is signed) then an upstream NTA will just look like a signature-stripping attacker. let us not imagine that there will never be secure applications other than recursive name servers (and here i'm thinking of DANE), and let us also not imagine that every secure application (here i'm again thinking of DANE) will have to subscribe to a trusted NTA. dnssec is end to end, including dnssec failures, which are statistically inevitable. i'd tell validator operators who think they need NTA's in order to control the risks posed by zone owner errors, if you can't stand the heat then stay out of the kitchen. see also http://www.circleid.com/posts/defense_in_depth_for_dnssec_applications/. paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on Negative Trust Anchors
On 2012-04-15 7:04 PM, David Conrad wrote:
On Apr 15, 2012, at 9:37 AM, Paul Vixie wrote:
i'd tell validator operators who think they need NTA's in
order to control the risks posed by zone owner errors, if you can't
stand the heat then stay out of the kitchen.
Given the benefits provided by DNSSEC (to date) are largely invisible and the
costs quite non-trivial, I'd think this would ensure DNSSEC validation never
gets deployed, thus secure applications (such as DANE) will never exist.
I thought we'd learned that flag day deployments don't work on the Internet
anymore.
i thought so too until we had world ipv6 day last year. noting that
adding a record to www.{facebook,yahoo,google}.com has been seen to
hit all kinds of roadblocks due to teredo and other failed tunneling
mechanisms, the only way big companies will feel safe turning it on
(knowing that they'll lose 0.3% of unique eyeballs when they do) is if
they're traveling in a pack with other big companies.
so it apparently will be for dnssec. nobody should validate until
everybody validates, because otherwise the failures at the social
security administration or nasa to sign and re-sign their zones, and to
properly maintain the relationship between the keys they use and the DS
RRs their parent zones have for them, will be felt by early adopters.
ipv6 and dnssec both have incredibly strong early adopter penalties:
you can break me now, or you can break me later. i seek to avoid
legitimizing the igor hack in bind9, and negative trust anchors.
i know that people will do this stuff but i also know that IETF should
not give either one an implicit +1.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on Negative Trust Anchors
On 2012-04-15 9:07 PM, David Conrad wrote: I guess in the end it boils down to the philosophical question of the role of the IETF. If DNSOP declines to accept this topic, I suspect it merely means each vendor will come up with their own implementation with their own quirks that operators will have to wade through. I fail to see how this improves anything. if you don't want something to live forever and get turned on by default or left on across sysadmin churn, don't put it in an RFC. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NTA... the new NAT?
On 4/17/2012 9:51 AM, Shane Kerr wrote: Is it just me, or does the NTA discussion remind anyone else of NAT discussions? And not just because they have the same letters. ;) Operators say, wow, here is a useful tool that can solve real-world problems, maybe it would be helpful to recognize these problems and perhaps standardize the solution? Protocol zealots answer, but this is bad for this long list of very valid reasons, so sorry about your problems but really we know better. If we insist on DNS Purity, I predict a similar end state with NTA as with NAT: they will be almost universally deployed, and completely non-standard, and result in a lot of potential breakage due to inconsistencies and semi-broken implementations. Yay. what potential breakage or semi-broken implementations are you thinking of? in NAT, it's all rather broken. the fix for NAT, had the IETF been willing to recognize this technology in spite NAT's non-purity, would have been in the form of what we now call firewall traversal or perhaps PnP. neither of which the world was ready for at the time, and neither of which was something that could have been standardized soon enough to stop bad NAT from getting out, nor standardized at a high enough quality and relevance level at that time since in the early days noone knew yet how many things NAT would break. but let's continue the analogy anyway. what would have saved the world from bad NAT was a change to the underlying connection model of the internet -- not just an RFC that says here's how you can use 192.168 but rather one that said here's how you can preserve some aspects of end-to-end, not break FTP, not have to reframe your TCP sessions at the gateway layer if they might contain embedded IP addresses. in that sense, i agree with your comparison: a fundamental change to the nature of DNSSEC to allow for secure signalling of errors and secure signalling of middle-man policy would definitely help us head off a generation of bad NTA. but that's not what's on offer here. DNSSEC currently presumes reliable end-to-end failure, and offers no way to signal other conditions. so if somebody breaks into your primary name server and alters your zone and either doesn't sign their changes or signs the whole zone with some key that's not matched by your delegating DS RRset, right now it will cause the modified content to be marked as bad and ignored or dropped by any validating server. NTA will change that, by adding middlemen who can decide as a matter of their own policy to just ignore these bad or missing signatures and pass your data to their stub clients as though DNSSEC had not been in use. that's horrible. that's worse for deployment confidence in DNSSEC than anything the social security administration or NASA could otherwise do by failing to re-sign or using the wrong keys. so i'm all for changing DNSSEC itself to accomodate these other use cases. but i'm not on-board at all for a standardized way for middlemen to block unwanted (by them) DNSSEC signalling. this means i'm in favour of the thing you're suggesting (do better with DNSSEC than we did with NAT) but i'm also opposed to the thing you're supporting (make end-to-end DNSSEC failures less reliable). i think this means you're offering me a false dichotomy above. let me know if i'm misreading you. paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NTA... the new NAT?
On 4/18/2012 6:28 PM, David Conrad wrote: ... Their validator, their rules. ... that would be a fundamental change to the architecture of dnssec. see again: http://www.circleid.com/posts/20121012_dns_policy_is_hop_by_hop_dns_security_is_end_to_end/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] an editorial review of draft-ietf-dnsop-respsize-13
On 4/25/2012 4:58 PM, Alfred � wrote: It has been pointed out that the DNS Referral Response Size Issues I-D should not be left going to final expiry, and I have performed a new review of the last version, draft-ietf-dnsop-respsize-13. I only found a small number of remaining editorial nits -- either formerly overlooked or newly introduced. You might want to take the opportunity of the notes below to refresh the draft. thanks. see below. (1) Section 1 (1.1) 1st paragraph a) The object of the first sentence lacks an article; the should be supplied. ok. b) In a few places, the draft uses very terse forms of precise citations, which better should be expanded a bit for readability; the first occurrence of this is here as well: (see [RFC1035] 4.2.1)should say (see [RFC1035], Section 4.2.1) or even better (see Section 4.2.1 of [RFC1035]) . i don't agree. we'll make the change, since we're not going to stand on minutiae, but for the record this is your personal style preference not an objective style guide reference. i would actually prefer [RFC1035 4.2.1] since terseness is to me virtuous. again: you're over reaching here, but, we'll make the change for you anyway. Chosing the latter form, the corrections will accumulate to: | The original DNS standard limited UDP message size to 512 octets (see | [RFC1035] 4.2.1). Even though this limitation was due to the required minimum IP reassembly limit for IPv4, it became a hard DNS protocol limit and is not implicitly relaxed by changes in a network layer protocol, for example to IPv6. --- v | The original DNS standard limited the UDP message size to 512 octets | (see Section 4.2.1 of [RFC1035]). Even though this limitation was due to the required minimum IP reassembly limit for IPv4, it became a hard DNS protocol limit and is not implicitly relaxed by changes in a network layer protocol, for example to IPv6. (1.2) 2nd paragraph Again, please expand the reference (see [RFC2671] 2.3, 4.5) in the same way as above. (1.3) 4th paragraph Again, a definite article is missing, and also whitespace is missing in front of a citation -- both in the first sentence. Please adjust: | While more than twelve years passed since the publication of EDNS0 vv ^ | document[RFC2671], approximately 65% of the clients support it as observed at a root name server and this fraction has not changed in recent few years. The long tail of EDNS deployment may eventually be measured in decades. --- | While more than twelve years passed since the publication of the vvv | EDNS0 document [RFC2671], approximately 65% of the clients support it as observed at a root name server and this fraction has not changed in recent few years. The long tail of EDNS deployment may eventually be measured in decades. that's all fine. this, though: (2) Section 2.3 (2.1) 2nd paragraph When used as a noun, DNS should be written with the definite article: | While DNS distinguishes between necessary and optional resource records, [...] --- v | While the DNS distinguishes between necessary and optional resource records, [...] The Domain Name System as abbreviated to the acronym DNS is a proper noun. we do not write The IP even though we would write The Internet Protocol. similarly for TCP, UDP, NFS, and so on. (2.2) last paragraph There are two grammar flaws in the text. a) s/independent to/independent of/ b) I assume that ... the DNS server _might_ just see ... is the needed verb that you had in mind. So please correct: | The glue record order should be independent to the version of IP used v^^ | in the query because the DNS server just see a query from an intermediate server rather than the query from the original client. --- | The glue record order should be independent of the version of IP used vvv ^^ | in the query because the DNS server might just see a query from an intermediate server rather than the query from the original client. ok. (3) Section 3, last paragraph According to the RFC Editor explanations of the most frequent flaws in grammar and style (see RFC Editor educational presentation material from all recent IETF meetings), which is inappropriate in Technical English and should be replaced by that here: We're assuming a medium query name size of 64 since that is the typical size seen in trace data at the time of this writing. If | Internationalized Domain Name (IDN) or any other technology which ^^ results in larger query names be deployed significantly in advance
Re: [DNSOP] A good chance to get all riled up - draft-wkumari-dnsop-omniscient-as112-00
On 6/27/2012 6:15 PM, Joe Abley wrote: ... Adopt this doc? yes please. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-dnssec-key-timing
On 2012-08-30 9:40 AM, Johan Ihrén wrote: On Aug 20, 2012, at 17:33 , Paul Hoffman wrote: On Aug 20, 2012, at 6:19 AM, Peter Koch p...@denic.de wrote: My current reading of the sense of the WG is that we move to WGLC with -03, declaring the July 24 suggestion out of scope for this document and keep momentum for 'dnssec bis'. dnssec-bis was delegated signer. dnssec-ter was type code roll. we're on dnssec-nextgen now. That's one way to do it. A better one would be to start WG LC on key-timing with an explicit question to the WG about folding in the keytiming-bis changes. That way, the WG would know the status of both, and we would would possibly produce just one document. The operations community would be better off with just one document, if this WG can do that. Not to question the abilities of the WG, but I still have to ask whether (in your opinion) the operations community would be better off with a single document that may be finished around Christmas Eve 2020 or rather live with multiple docs that are published somewhat sooner than that. while i agree with these sentiments i have a broader concern. ietf's mantra is good engineering. if we know now that keytiming has flaws, and we are only considering publishing it because we know our own record shows that reaching consensus for keytiming-bis will take a long time, then it's an implicit indictment (by us) of our own record and habits. we should have a better reason for publishing two documents, like new ideas occurred to us after the first one was beyond reach of our pen, or they have different topics. paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new version of IPv6 rDNS for ISPs
On 2012-11-21 4:44 PM, Ted Lemon wrote: ... Aside from this quibble, I think the document is useful and should be published. my quibble is different. ipv6 is bringing some tough love to the consumer-facing edge. the fact that ISP's auto-populated the IPv4 PTR tree made it impossible for mail server operators to distinguish between consumer grade and business grade internet connections. since consumer grade connectees should really not be connecting to SMTP servers on other networks, there's been a great deal of work to find all of the common auto-populated PTR naming patterns in use anywhere in the world, in order to reject off-net e-mail from consumer grade connections. this work is inefficient, ineffective, painful even when correct, and often wrong. there are some excellent reasons not to use PTR RR records for this purpose, starting with good security practices and continuing through good engineering practices. nevertheless this is a pre-existing property of the existing server plant, and even if server operators were willing to give it up, the tail would be very long. i'm going to treat this as an unavoidable universal mistake that all of us will have to live with, forever, period. network operators should provide PTR RR's for specific addresses which have real names. the inability due to IPv6's richness of address space to provide auto-naming for PTR's does not to me, a problem statement make. paul -- It seems like the rules for automagic completion of incomplete names typed into browsers are going to start to look like those for the game of fizbin. --rick jones ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] finding the closest delegation
On 2012-11-23 2:34 PM, Mark Andrews wrote: ... There is nothing wrong with using the SOA record from the -ve response. Named has been doing it for about 15 years in nslookup. If it is not there it falls back to stripping a label at a time until it gets the SOA record. indeed not. i think mark means nsupdate here. the history of this is, i wrote for late model bind8 a function called res_findzonecut(), which was part of integrating a contributed implementation of RFC 2136, which i'd been the editor and main author of. the comments at the top of lib/res/res_findzonecut.c are shown below. there's nothing untoward, or spec-violating, or even spec-bending going on here. /* * int * res_findzonecut(res, dname, class, zname, zsize, addrs, naddrs) * find enclosing zone for a dname,class, and some server addresses * parameters: * res - resolver context to work within (is modified) * dname - domain name whose enclosing zone is desired * class - class of dname (and its enclosing zone) * zname - found zone name * zsize - allocated size of zname * addrs - found server addresses * naddrs - max number of addrs * return values: * 0 - an error occurred (check errno) * = 0 - zname is now valid, but addrs[] wasn't changed * 0 - zname is now valid, and return value is number of addrs[] found * notes: * this function calls res_nsend() which means it depends on correctly * functioning recursive nameservers (usually defined in /etc/resolv.conf * or its local equivilent). * * we start by asking for an SOAdname,class. if we get one as an * answer, that just means dname,class is a zone top, which is fine. * more than likely we'll be told to go pound sand, in the form of a * negative answer. * * note that we are not prepared to deal with referrals since that would * only come from authority servers and our correctly functioning local * recursive server would have followed the referral and got us something * more definite. * * if the authority section contains an SOA, this SOA should also be the * closest enclosing zone, since any intermediary zone cuts would've been * returned as referrals and dealt with by our correctly functioning local * recursive name server. but an SOA in the authority section should NOT * match our dname (since that would have been returned in the answer * section). an authority section SOA has to be above our dname. * * however, since authority section SOA's were once optional, it's * possible that we'll have to go hunting for the enclosing SOA by * ripping labels off the front of our dname -- this is known as doing * it the hard way. * * ultimately we want some server addresses, which are ideally the ones * pertaining to the SOA.MNAME, but only if there is a matching NS RR. * so the second phase (after we find an SOA) is to go looking for the * NS RRset for that SOA's zone. * * no answer section processed by this code is allowed to contain CNAME * or DNAME RR's. for the SOA query this means we strip a label and * keep going. for the NS and A queries this means we just give up. */ paul ___ 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?
if we can't return nxdomain, then i'm opposed to the omniscient spec, and we should continue as before, enumerating on the responding servers every zone to which we wish to delegate. noerror/nodata is the wrong answer. ___ 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?
... Tony Finch wrote: ... Why not something like Paul's metazone idea to automate the configuration of which zones the server should answer for? for reference: http://www.ietf.org/mail-archive/web/dnsop/current/msg05192.html paul ___ 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?
... Paul Vixie wrote: ... Tony Finch wrote: ... Why not something like Paul's metazone idea to automate the configuration of which zones the server should answer for? for reference: http://www.ietf.org/mail-archive/web/dnsop/current/msg05192.html that message's pdf attachment appears to have been corrupted. another copy is here: http://ss.vix.su/~vixie/mz.pdf paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
Joe Abley wrote: ... ONION is like LOCAL. Neither are like ARPA (or any other TLD). How like LOCAL is ONION? ICANN knows it can't sell .LOCAL, but does ICANN know it can't sell .ONION ? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-hzhwm-start-tls-for-dns-00: Starting TLS over DNS
Zi Hu wrote: We recently posted draft-hzhwm-start-tls-for-dns-00 (Starting TLS over DNS) to explore one proposal to add standard TLS over standard DNS to improve privacy. http://tools.ietf.org/html/draft-hzhwm-start-tls-for-dns-00 This topic may be of interest to DNSOP and PERPASS. Some of the authors will be at the London IETF and can discuss it at the DNS privacy BOF if there is interest. ... this is good work. i recommend it be adopted by the working group, and i will act as a reviewer. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] meta issue: WG to discuss DNS innovation (was Re: draft-hzhwm-start-tls-for-dns-00)
Joe Abley wrote: ... If we believe all these problems are intractable, then we might as well just accept that overloading TXT records and reflection attacks are a fact of life, and stop worrying about them. reflection attacks aren't a fact of life. DNS RRL does not require a forklift upgrade of the infrastructure, isn't stopped by middleboxes, and does not change the protocol. i think you should discriminate more finely as to what we ought and ought not give up about. What I would prefer, though, is a more entrepreneurial approach where the likelihood of short-term operational problems (or even long-term failure of the work) should not stop us from trying. ... those were my exact words upon the publication of RFC 2671. it's been fifteen years. i think if any change to the dns protocol was going to be useful enough to overcome edge corruption and edge inertia, it would be EDNS0. however, it's heartening to see another generation of cannon fodder lining up to enter the trenches. you go, joe. i'll cheer you on. but i'll be working on a RESTful/JSON API to hide DNS edge traffic inside TLS, in sessions not managed by any X.509 CA, while cheering you on. So, how about a starting point where we assume that if a particular extension has value to anybody, the operators (the market) will adjust to allow it to work, and if it doesn't, then adjustments are not necessary? Anybody else feel like working on the specification for SCTP transport? :-) go, joe, go! vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Passive DNS COF
Lawrence Conroy wrote: Hi Chaps, stupid quick question, listening to the stream: How does this work with CDNs (I think you may need to capture the IP address; bailiwick could act as a proxy for that, but ...) this is well described, as follows: https://archive.farsightsecurity.com/Passive_DNS/passive-dns-architecture.pdf vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on the subject of dnse
Phillip Hallam-Baker wrote: This was the use case that originally drove the development of OmniBroker. If we do DNS Encryption right it is going to be very easy for end users to chose their DNS provider and very hard for the authorities to block them. +1. Security is a balance. Going through 8.8.8.8 rather than direct means that you are leaking privacy sensitive information to Google. But that is probably less important here than the censorship attack. noting, google's public claims about not data mining any part of the 8.8.8.8 query flow, are believable. we also now know that the greater risk is an on-path nation-state MiTM. i think we should solve for the latter and not worry about the former. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] port 0 requests leading to errors
bert hubert wrote: ... 43.504115 IP x.y.117.10.0 192.175.48.6.53: 6365+ SOA? 168.192.in-addr.arpa. (38) 45.504152 IP x.y.117.10.0 192.175.48.6.53: 6365+ SOA? 168.192.in-addr.arpa. (38) 49.505124 IP x.y.117.10.0 192.175.48.6.53: 6365+ SOA? 168.192.in-addr.arpa. (38) PowerDNS now refuses to attempt to answer such packets, which silences the error messages. mark andrews sent me a similar patch to bind 4.9 back in 1992, which made no sense to me but i put it in anyway. thanks for explaining. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] port 0 requests leading to errors
Christopher Morrow wrote: If I have a patch which makes no sense, will you also add it? nope. not for you anyway. only mark andrews. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS over DTLS (DNSoD)
for reasons well-spoken up-thread, if we're going to add a dns transport, i'd like it to be RFC 6013 style TCP (in which session context can be compressed and retained after FIN for full-window-size restart, and which permits the query to be bundled into the SYN packet), or at a minimum, SCTP. DTLS does not solve any of the problems described at https://queue.acm.org/detail.cfm?id=2578510. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call to work on edns-client-subnet
Andrew Sullivan wrote: Dear Uncle Ben, keep it civil, please. On Wed, May 07, 2014 at 07:26:51PM +0200, P Vixie wrote: The architectural context of a feature should not be divorced from its specification. RFC is an imprimatur. With great power comes great responsibility. I disagree with this point of view. I see nothing at all wrong with one thing that states clearly and precisely how a feature works, and another one that says, Here is the wider environment in which such-and-thus thing works. let me show you something wrong with that, then. http://www.cisco.com/c/en/us/products/collateral/wireless/5700-series-wireless-lan-controllers/data_sheet_c78-722607.html an rfc is seen by sellers and buyers as an unalloyed good. we can (and i do) criticize uneducated people making appeals to authority, but that's a far cry from pretending it won't happen or that any undesirable result from its happening is not the responsibility of those who write and edit and approve RFC documents. the current thrust is to move from ietf should do good engineering to ietf should document anything that has to be interoperable, and in that move we have to plan on being quite detailed in our applicability statement sections. my draft for that section of a client subnet option goes more or less like this: APPLICABILITY STATEMENT The method described in this document is controversial, as is the use of wide area anycasting for Full Service Resolvers (recursive DNS servers). The Domain Name System as originally contemplated and implemented made the assumption that a Full Service Resolver would either share a host with, or a LAN with, or a campus with its end-user stub resolvers. In that scenario, the need for something like the client subnet option does not arise. Since at the time of this writing, personal electronics are far more complex and resource intense than a Full Service Resolver, even when including DNSSEC validation and DNS firewall policy. The purpose of this document is to describe the client subnet option so that cooperating systems can interoperate. No recommendation is expressed or should be implied as to whether this method should be used, or that its antecedent, wide area anycasted Full Service Resolvers (recursive DNS servers) should be used. if i thought i could get consensus on an addition, i'd add: The client subnet option is only useful when other earlier assumptions about Internet architecture are violated. Specifically, it's when a market driven CDN (content delivery system) desires to tune DNS authority responses to control end-user web performance, is reached by an end user who uses a market driven anycast recursive DNS service. Neither the described authority DNS tuning nor the described anycasted recursive DNS service are Internet architecture requirements, or even recommendations. A web site without a CDN front end will still work, as will a CDN who has no insight into each requestor's actual address at the time it receives an authority DNS request. End users who use local recursive name servers will receive faster service per query due to the reduced round trip time (one millisecond instead of a dozen or more milliseconds) and will be less affected by cloud outages. Design by market force can lead to unnecessary features and not always to good engineering. obviously i'm miffed that Stupid DNS Tricks ultimately demands more complexity for the DNS, and so on. Even the DNS protocol itself has this separation of duties, between 1034 and 1035 (though heaven knows the actual protocol specification could use some attention). that's a terrible example since neither one of them talks about the limited applicability of the other. If this were not the case, then in fact we'd have had to discuss the entire architectural context of any DNS feature. It only seems like the DNS RFCs are infinitely long. that's a terrible example since any internet draft describing a controversial technique either failed or got an applicability statement. if you think there are cases where RFC 2136 should not be used, over and above the IAB-demanded statement about authentication, speak on. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call to work on edns-client-subnet
Tony Finch wrote: Barry Margolin pointed out an amusing interaction between two stupid DNS tricks on the bind-users list: https://lists.isc.org/pipermail/bind-users/2014-May/093171.html If you have an authoritative server with ANAME or CNAME flattening support, and the target of the ANAME is a CDN that does source-based answer selection, then the synthetic A / records will be based on the auth server address rather than the client address, unless you have some special arrangement between the auth server and the CDN like edns-client-subnet support. madness. this way lies madness. the dns design had moving parts and nonmoving parts. the dns implementation is becoming something else entirely. see also What DNS Is Not https://queue.acm.org/detail.cfm?id=1647302. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call to work on edns-client-subnet
Ralf Weber wrote: ... There is madness, but the madness is in mixing authoritative and recursive functions in one server and not in using DNS to direct traffic. while i'm on record has holding that view, it turns out that RFC 1035 does describe recursion and authority as co-residing in a server. so while this is in my view a dangerous practice and a bad idea, it's well supported by the scriptures. After all that's what all lookups do, give you an IP address you connect to. i don't think so. dns lookups have many purposes unrelated to returning IP addresses. i'd like to see 100 more things like SSHFP this decade. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call to work on edns-client-subnet
one of the icann ssac (then secsac) consensus processes i am most proud to have been part of was this, in 2004: http://www.icann.org/en/groups/ssac/report-redirection-com-net-09jul04-en.pdf indeed, this document and the process followed in creating it may still stand today, as ssac's finest hour. see especially section 2.3, design principles and good practice in the internet technical community, starting on page 8. unless i can think of anything new to say on this topic, this will be my final comment on this thread. consensus tally people: i'm yes we must document it, but we must also explicitly withhold recommendation of it, both in the introduction section and in some kind of applicability section down near the iana considerations. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
Mark Delany wrote:
On 17May14, Mark Andrews allegedly wrote:
domain ENAME domain {0|1} [type list of included / excluded types]
(0 == include, 1 == exclude)
As I recall, the HTTP/2.0 folks have been intermittently talking about
supporting SRV. Would encouraging that group on that front be easier
than inventing CNAME support at the apex?
yes. by far.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
Mark Andrews wrote: ... Everytime I have mentioned SRV records to HTTP folks they say it won't work as the extra lookup takes too long. this sounds strange to me. TTL=0 SRV RR's strike me as precisely what the CDN industry needs, since they can include an (or for back-compatibility, an A) RR in the same response as additional data. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
Ted Lemon wrote: On May 19, 2014, at 6:12 PM, David C Lawrence t...@akamai.com wrote: Not so much pushing required, at least of Akamai. You have a ready-made [SRV] ally in me, if only clients actually made good use of it. The clients are the real obstacle. Yup. It would be great if we could get the HTTP 1.1 clients to do it [SRV], but getting HTTP 2.0 clients to do it [SRV] seems at least as do-able as any of the alternatives that have been proposed. i was there when SRV was conceived. we intended it to be used opportunistically, like MX before it, falling back to or even A queries if there was no SRV. it can be added to any protocol at any time, including HTTP/0.9 clients to the extent there are still any of those around. SRV's rules are defined for a service not by the client. if we decide that web servers can be reached by SRV records, then any web client can start looking for the SRV that describes that service, falling back to whatever tin-cups-and-string it did before if it can't find the SRV it wants. in that sense mark andrews' HTTP SRV I-D from all those years ago should not have been controversial. if you want to do this, here's how everybody else agreed to do it. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
Mark Delany wrote: one can lookup A, and SRV in parallel and positive answer to SRV, as Paul mentioned, can have additional A and RRs. A downside is that clients has to wait for the SRV query to complete so they can be sure of the presence or not of an SRV. ... in a blast protocol where all N queries are sent to the same destination, one can reset the blast timeout upon first response, to 1.2x that response time. or even 1.1x. the total time cost delta of a blast protocol is thus ~10%. since this is only happening on a cache miss, i don't see it as decisive. ... You're also ensuring that the global query rate will substantially increase on the assumption that HTTP/2.0 becomes as popular as HTTP/1.0. not so. 97% of the queries reaching the root name servers (as an example of an important subset of global DNS traffic) are unanswerable due to an initator-side screwup of some kind (rfc1918 source; firewall doesn't permit response; etc). if we doubled the traffic that is not that 97%, it would still be mouse nuts compared to that 97%. ... Generally speaking, the challenge is that SRV is likely acceptable to commercial CDN providers that have thus far relied on CNAME - with it's intrinsic level of indirection - but will be less welcome by those who are using every trick to squeeze latency out of HTTP. disagreeing for a third time, SRV is an opportunity to squeeze even more latency out of HTTP. ... If you want to make everyone happy, you need to invent a single round-trip resolution that supports indirection... content-centric networking would do this. lixia and van have been talking about it for a few years. alas it's a totally non-IP model and not likely to replace the internet during the time it will take us to decide what to do about SRV (and also do whatever it is we decided.) vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
Masataka Ohta wrote: Mark Andrews wrote: The reason why CNAME is prohibited at a zone apex is described in RFC 1034: If we must change something, isn't it easier to allow CNAME at a zone apex than introducing ENAME? the reasons for prohibiting it, as given in RFC 1034, still apply. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] rssac caucus
Greetings, If you are interested in participating at ICANN's Root Server System Advisory Committee (https://www.icann.org/resources/pages/charter-2013-07-14-en) as a Caucus member, please kindly read the relevant information and Caucus document published at https://www.icann.org/resources/pages/rssac-caucus-2014-05-06-en and submit your statement of interest to rssac-members...@icann.org The RSSAC executive is working on publishing the final version Procedures documents and at the moment is establishing the Caucus and with a few work items ready to be discussed by the Caucus. If you would like to volunteer please kindly indicate those intentions known by sending an email to rssac-members...@icann.org. Kind Regards, Kaveh Ranjbar, RSSAC Membership Committee Chair Tripti Sinha, RSSAC Membership Committee Member Paul Vixie, RSSAC Membership Committee Member ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rssac caucus
Dear colleagues, This is a friendly reminder to apply for RSSAC Caucus membership. The cut-off date for first round of membership is end of June, so please kindly submit your statement of interest before 1st of July to rssac-members...@icann.org. On Monday 23rd of June RSSAC had its public session at ICANN 50 and it was announced that first face to face caucus meeting will be held during IETF 90 in Toronto. Kind regards, Paul Vixie on behalf of RSSAC Caucus membership committee re: Paul Vixie wrote: Greetings, If you are interested in participating at ICANN's Root Server System Advisory Committee (https://www.icann.org/resources/pages/charter-2013-07-14-en) as a Caucus member, please kindly read the relevant information and Caucus document published at https://www.icann.org/resources/pages/rssac-caucus-2014-05-06-en and submit your statement of interest to rssac-members...@icann.org The RSSAC executive is working on publishing the final version Procedures documents and at the moment is establishing the Caucus and with a few work items ready to be discussed by the Caucus. If you would like to volunteer please kindly indicate those intentions known by sending an email to rssac-members...@icann.org. Kind Regards, Kaveh Ranjbar, RSSAC Membership Committee Chair Tripti Sinha, RSSAC Membership Committee Member Paul Vixie, RSSAC Membership Committee Member ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00
Tim Wicinski wrote: ... On 6/24/14 3:57 AM, Paul Hoffman wrote: My hope is that DNSOP doesn't become too DNSEXT-like where if the -00 for a proposal isn't universally loved, it is destroyed instead of worked on. We as chairs do not have that mind set. My personal feeling is to figure out what parts do seem to be useful and have some interest, and guide discussions along those lines. We may be also completely delusional, but I'd like to keep believing otherwise for a little while longer. i don't think universal love should be the standard for surviving one's -00 or not -- so that would be a straw man argument if anyone is actually making it. however, the standard for consensus should remain good engineering in view of the overall system. i've authored any number of silly -00's over the years, which were killed before there could be a -01, because discussion in the forum pointed in that direction. e.g., dns-0x20 remains a bad idea, and will remain a bad idea, no matter how much work the group does on it. let's not learn the wrong lesson from dnsext's disgrace -- some -00 ideas do deserve to die. warren introduced dist-root to me in warsaw during dns-oarc as possibly one such stupid idea, and i agreed with him and told him why. per drc, i owe this forum a copy of those reasons. the chairs, and the co-authors, should be open to the possibility that no amount of work will yield consensus that the idea is sound and that the resulting overall system would be stronger than either the system we have now or other more easily reached alternatives. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] please review CGA-TSIG
Hosnieh Rafiee wrote: Hello, We actually put all our efforts to change the document thoroughly and not only consider the IPv4 scenario that was comment of some people in mailinglist but also we expand the DNS privacy section and explained it in more detail (no need to change the protocol.) http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-08 thank you. i am not a member of the int-area@ mailing list, so please forward this reply to that forum. So, any more comments? Any more feedback? do you think it is now a good acceptable version? :-) see below. The TSIG keys, which are manually exchanged between a group of hosts, need to be maintained in a secure manner. tsig keys have no needs. i suggest must be maintained here. or to assure a Slave Server that the zone transfer is from the original Master Server and that it has not been corrupted. or as an access control method to permit AXFR/IXFR only when a shared TSIG key is present. Handling this shared secret in a secure manner and exchanging it does not appear to be easy. This is especially true if the IP addresses are dynamic or the shared secret is exposed to the attacker. this is nonsequitur. either give a reference for what does not appear to be observed, or simply note that out of band key exchange by sneaker-net does not scale and was never expected to. also, _what_ ip addresses? you've not introduced that concept before referencing it. this document proposes two algorithms which support both IPv4 and IPv6 scenarios. does each of the two support both protocols? if not, the above wording is wrong. perhaps you mean two algorithms, one for IPv4, and one for IPv6. This document updates the following sections in TSIG document: ... those details should not be in the Introduction section. There are several different methods where DNS records can become compromised. Some examples of methods are DNS Spoofing; DNS Amplification Attacks; Resolver Source IP Spoofing; Unauthorized DNS Update; User Privacy Attack; and Human Intervention. this Problem Statement is grossly inadequate to motivate the proposal you've submitted. consider the User Privacy Attack scenario. the thing that you'd like to hide is the q-tuple, since the response is public information. only the requester's interest in a particular q-tuple at a particular time is worth protecting. we end up having to encrypt the response not because the response itself is sensitive but because a response will implicate a q-tuple which is sensitive. in the stub-to-recursive data path, existing data mining is not occuring in-channel, but at the endpoints. A/V products instrument end-system resolvers to learn and sometimes intercept or redirect DNS transactions. that isn't a problem -- users who don't want it to happen can't stop it with encryption, but they can stop it by uninstalling the A/V. at the other end, an RDNS often participates in some kind of passive DNS collection effort for security analytics purposes, and that is again not the problem being stated here -- because that's happening outside the channel where encryption would do any good. asking for dns path protection end-to-end from stub to authority, such that the RDNS did not know the q-tuple, raises the questions of how could it cache or reuse anything, how could DNS function without caching and reuse, and how could the RDNS route a query to an ADNS without knowing the q-name. yet you're proposing hop-by-hop channel encryption. there is no stated justification for who that helps or how. only if a user wants to use a distant RDNS like opendns or googledns would a form of channel encryption that prevented the user's ISP and other intervening ISP's (or national security agencies in the wide-area data path) be useful. if that's the value you intend to add then you should say so -- after contextualizing it and defining your taxonomy. Disadvantages: - Offline generation of the signature DNSSEC [RFC6840 http://tools.ietf.org/html/rfc6840] needs manual step for the configuration. For instance, when a DNSSEC needs to sign the zone offline. offline generation is not a disadvantage. dnssec makes it optional, and offers it because it is a desirable feature. moreover you appear not to know about SIG(0) which worries me since that ought to have been part of any reasonable background check on this topic before writing a proposal as fundamental as this one. - IP spoofing The public key verification in DNSSEC creates a chicken-and- egg situation. In other words, the key for verifying messages should be obtained from the DNSSEC server itself. This is why a query requester needs to verify the key. If this does not happen, DNSSEC is vulnerable to an IP spoofing attack. this is completely wrong, as in, 100% counter-factual. i stopped reading this draft at the end of section 1. it appears not to be worth my time to read the
[DNSOP] various approaches to dns channel secrecy
i've now seen a number of proposals reaction to the snowden disclosures, seeking channel encryption for dns transactions. i have some thoughts on the matter which are not in response to any specific proposal, but rather, to the problem statement and the context of any solution. first, dns data itself is public -- the data is there for anybody to query for it, if you know what to query for. only the question, questioner, and time can be kept secret. answers are only worth keeping secret because they identify the question, questioner, and time. second, dns transactions are not secret to protocol agents. whether stub resolver, full resolver, forwarder, proxy, or authority server -- the full identity of the question must be knowable to the agent in order to properly process that question. if the agent does logging, then the question, questioner, and time will be stored and potentially shared or analyzed. by implication, then, the remainder of possible problem statement material is hide question from on-wire surveillance, there being no way to hide the questioner or the time. to further narrow this, the prospective on-wire surveillance has to be from third parties who are not also operators of on-path dns protocol agents, because any second party could be using on-wire surveillance as part of their logging solution, and by (2) above there is no way to hide from them. so we're left with hide question from on-wire surveillance by third parties. this is extremely narrow but i can envision activists and dissidents who rightly fear for their safety based on this narrowly defined threat, so i'm ready to agree that there should be some method in DNS of providing this secrecy. and as we know from the history of secrecy, if you only encrypt the things you care about, then they stand out. therefore, secrecy of this kind must become ubiquitous. datagram level channel secrecy (for example, DTLS or IPSEC) offers a solution which matches the existing datagram level UDP transport used primarily by DNS. however, the all-pervasive middleboxes (small plastic CPE devices installed by the hundreds of millions by DSL and Cable and other providers) have been shown to be more powerful than IPv6, DNSSEC, and EDNS -- we could expect them to prevent any new datagram level channel secrecy protocol we might otherwise wish to employ. TCP/53 is less prone to middlebox data inspection, and may seem to be an attractive solution here. i think not for two reasons. first, TCP/53 is often blocked outright, and second, because TCP/53 as defined in RFC 1035 has a connection management scheme that prohibits persistent TCP/53 connections at Internet scale, and we cannot afford the setup/teardown costs of a non-persistent TCP-based channel secrecy protocol for DNS. to those who suggest redefining TCP/53 and upgrading the entire physical plant and all software and operating systems, i challenge you to first show how this is less global effort than other proposals now on the table, and then show how you would handle the long-tail problem, since many agents will never be upgraded, or will only be upgraded on a scale of half-decades. DNS works today because TCP/53 is a fallback for UDP/53. its definition and deployment makes it unsuitable either currently or as-would-be upgraded to become the primary transport. i suggest that any channel secrecy protocol we wish to add to the DNS system must be suitable as the primary transport, to which the existing UDP/53 and TCP/53 protocols are fallbacks. i further suggest that any new transport be operable at internet scale, which demands connection persistence. finally i suggest that this be done using a protocol that the internet's middle boxes (cheap CPE devices who think they know what all valid traffic must look like) will allow to pass without comment. one candidate for this would be RESTful JSON carried over HTTPS. because of its extensive use in e-commerce and web API applications, HTTPS works everywhere. because HTTPS currently depends on X.509 keys, other groups in the IETF world are already working to make HTTPS proof against on-path surveillance. (google for perfect forward secrecy to learn more), and others are working to defend the internet user population against wildcard or targeted SSL certificates issued by governments and other anti-secrecy agents with on-path capabilities. stephane bortzmeyer has already shown us that JSON representation of DNS transactions is possible. i have heard from another protocol engineer who is also working in this area (and who credits bortzmeyer for informing his work). the special advantage of TCP/443 as a primary transport for persistent DNS with channel secrecy is that HTTPS's connection management permits massive scale, as in, a single protocol agent with tens or hundreds of thousands of open connections, even with local and global load balancing and connection pinning. in summary, i agree that we have a narrowly defined problem of on-path surveillance
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
Joe Abley wrote: Hi Paul, Warren, On 4 July 2014 at 16:50:08, Paul Hoffman (paul.hoff...@vpnc.org) wrote: Greetings. Warren and I have done a major revision on this draft, narrowing the design goals, and presenting more concrete proposals for how the mechanism would work. We welcome more feedback, and hope to discuss it in the WG in Toronto. I think there is much in the language of this draft that could be tightened up, but this is an idea for discussion so I'll avoid a pedantic line-by-line dissection. But I can give you the full pedantry if you like :-) On the pros and cons, however (crudely pasted below), see below. TL;DR: there are way more cons than pros to this proposal. The pros listed are weak; the cons listed are serious. I don't see a net advantage to the DNS (or to perceived performance of the DNS for any client) here. This proposal, if implemented, would represent non-trivial additional complexity with minimal or no benefit. I am not in favour of it, if that's not obvious. ... i am +1 to joe's comments above and analysis elided. i consider joe's response to be at least as good as the because i owe DRC after my first short answer to the -00 version of this draft. however, i want to add two other countervailing points. first, this approach was tried in freebsd, when doug barton (then freebsd's BIND9 maintainer) made it the default. all hell broke loose due to changes in firewall config. debugging cost was maximized, and the debugging skills were minimized. this config was removed with prejudice. this experience, where freebsd users are actually among the smartest of all dns users, should serve as a warning sign to others: abandon hope all ye who enter here. so, joe's recommendation that this draft be retitled and rekerned to be draft-ietf-dnsop-slaving-root-on-resolvers-harmful resonates very strongly with me. second, this approach asks millions or tens of millions of rdns servers to change their config in order to actually scale the capacity of the root. (so, high cost and low benefit, as joe said.) the reason i proposed a radically different solution in my ICANN ITI contribution (now described at http://tools.ietf.org/html/draft-lee-dnsop-scalingroot-00) is to allow a few dozen to a few hundred self selected highly skilled and motivated network-level admins to scale the capacity of the root for everyone. it's a plain hierarchical solution allowing the operators of any loopback network on any host, or any LAN segment, or any campus, corporate, or ISP network to add root name service as a local capability; it also allows unlimited scale at the global BGP layer. it is patterned after the success of AS112. it is apolitical since existing rootops are also expected to participate. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] various approaches to dns channel secrecy
Matthäus Wander wrote: * Paul Vixie [7/5/2014 5:04 AM]: datagram level channel secrecy (for example, DTLS or IPSEC) offers a solution which matches the existing datagram level UDP transport used primarily by DNS. however, the all-pervasive middleboxes (small plastic CPE devices installed by the hundreds of millions by DSL and Cable and other providers) have been shown to be more powerful than IPv6, DNSSEC, and EDNS -- we could expect them to prevent any new datagram level channel secrecy protocol we might otherwise wish to employ. DTLS works on top of UDP (among others) and thus can pass CPE devices. no, it cannot. DTLS does not look something that the CPE was programmed to accept; thus in many cases it is silently dropped. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] various approaches to dns channel secrecy
Matthäus Wander wrote: * Paul Vixie [7/5/2014 7:47 PM]: Matthäus Wander wrote: DTLS works on top of UDP (among others) and thus can pass CPE devices. no, it cannot. DTLS does not look something that the CPE was programmed to accept; thus in many cases it is silently dropped. DTLS can be used on top of UDP. CPE devices allow outgoing UDP sessions to arbitrary ports. If they didn't, many online games and VoIP applications would not work. it's possible to find single counter examples to almost any assertion. however, consider RFC 2671 (EDNS), published fifteen years ago. because it changes the format of a UDP/53 datagram, there is silent loss across most CPE boundaries. implementers of EDNS have had to investigate and deploy about a dozen different fallback strategies since then, not to make EDNS work, but to make it fail reliably enough so that normal non-EDNS can be tried. since DNSSEC relies on EDNS0, this is a real problem. to the extent that it's gotten any better it's because someone changed this CPE logic: if (normal dns packet) intercept it and answer inappropriately, 30% of the time; let it get where it's going, 70% of the time; else drop; to this: if (normal dns packet) intercept it and answer inappropriately, 30% of the time; let it get where it's going, 70% of the time; else if (normal edns packet) intercept it and answer inappropriately, 30% of the time; let it get where it's going, 70% of the time; else drop; in other words what fixes have been made have been EDNS specific, where the real fix is: if (packet addressed to you) handle it or send ICMP; else let it get where it's going; that fix is not going into the O(10^9) CPE devices now in place, ever. if we can't get this right for EDNS in 15 years, my bet is that another 15 (or 150) years of trying won't produce better results. in fact, by jim gettys and dave taht i've been made to understand that the world's CPE problem is much worse than i knew. we might be able to fix it for the next billion devices some day, but the devices shipping today are still crippled. incentives are such that a CPE provider hopes to sell web access, not internet access. your counter-example of DNS gaming does not change the treatment now accorded UDP/53 at the internet edge. if you seriously think that a DTLS solution can be universally deployed, including in hotel rooms, home CPE environments, coffee shops, and mobile, then you and i are having a same planet, different worlds experience, and i wish you well on your walk. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Int-area] various approaches to dns channel secrecy
Hannes Tschofenig wrote: Just a minor note on this paragraph: because HTTPS currently depends on X.509 keys, other groups in the IETF world are already working to make HTTPS proof against on-path surveillance. (google for perfect forward secrecy to learn more), and others are working to defend the internet user population against wildcard or targeted SSL certificates issued by governments and other anti-secrecy agents with on-path capabilities. TLS has this ciphersuite concept and allows you to more than just X.509 certificates. As such, you have more freedom than you think (if you know what you want). you are right of course. we would use TLS PSK for this, avoiding the X.509 system entirely. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Int-area] various approaches to dns channel secrecy
Bernard Aboba wrote: this is extremely narrow but i can envision activists and dissidents who rightly fear for their safety based on this narrowly defined threat [BA] Presumably protection would only be from an attacker that can snoop on the wire, but not have access to the logs? yes. which i said explicitly: by implication, then, the remainder of possible problem statement material is hide question from on-wire surveillance, there being no way to hide the questioner or the time. to further narrow this, the prospective on-wire surveillance has to be from third parties who are not also operators of on-path dns protocol agents, because any second party could be using on-wire surveillance as part of their logging solution, and by (2) above there is no way to hide from them. so we're left with hide question from on-wire surveillance by third parties. so, to your question: Is the assumption that the DNS server is hosted out of country, and that measures are used to avoid identification of DNS traffic? I am trying to understand the scenario in which this actually would have a plausible chance of making a difference. there are two kinds of channel in dns queries. (i'm not going to account for updates or zone transfers here.) one channel is from the stub to the recursive. it's pointless to add secrecy to that unless a stub wants to use a very distant name server, like opendns or googledns, or as in your example, one in another country. however, these long stub/recursive paths do exist and are becoming more common, either to avoid poisoning by the local recursive operator (typosquatting and so on) or to avoid surveillance by the local recursive operator or to access poisoning by a distant local recursive operator (opendns for example is actually a security company, and they deliberately filter out dns results to known-dangerous locations, as a service.) the other channel is from the recursive to the authoritative. these transactions contain very little PII, since the IP address of the end-user is not present, and since cache re-use events are not present, only cache-miss events. however, this channel is frequently intercepted (see china's GFW) and frequently observed/logged. (my $DAYJOB does this kind of observation/logging, but only with the explicit permission of the recursive operator who must deliberately install our sensor software, and only with the implicit permission of their stub population, which we can't ourselves verify, but we require be attested.) secrecy on either of these channels is only rarely important, but in order to avoid exceptional appearance (standing out like a sore thumb) it's going to be necessary to make secrecy on both of these channels ubiquitous. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Int-area] various approaches to dns channel secrecy
Paul Ferguson wrote: ... That is *not* to say that DANE is not a desirable thing to deploy/accomplish. DANE relies on DNSSEC which relies on EDNS. the placement of a DNS-over-HTTPS channel would have to be below EDNS in the stack, and non-reliant. therefore my correction up-thread -- this HTTPS session would rely on PSK for keying information, not X.509. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] various approaches to dns channel secrecy
Nicholas Weaver wrote: ... One important observation: ONLY the path between the client and the recursive resolver in the classic model substantially benefits from channel security. if i were proposing a secrecy scheme that was easy to do on stub-to-recursive but hard to do on recursive-to-authority, then i'd be looking very much harder at the benefits of recursive-to-authority. however, what i'm proposing is no easier to do in one case than the other, and so any purported difference in benefit is outweighed by the lack of difference in the cost. pay once, benefit twice, is good engineering economics as far as i'm concerned. ... Even if you wave a magic wand and all resolver-authority communication becomes protected with 0-cost, 100% perfect data encryption, basic traffic analysis will largely be able to determine which domains are being looked up. Individual names within the domain are protected, but that is relatively minor. The other problem is DNS is used to guide endpoint communication. Between the resolver-authority information leak, and the actual IP selected by the endpoint itself for communication, this allows a nation-state observer adversary to pretty much recover what the hostname was in question in many cases, and at least the domain in almost all cases. i wish it noted that i am responding to the general post-snowden call for channel secrecy, and that i don't myself see much need for it in the case of DNS, but that the proposals i've seen come out of the security community for how to add channel secrecy to DNS are alarming in their lack of understanding of what DNS is, how large DNS is, and how DNS works. therefore, i'm attempting to isolate the cases which might be relevant to somebody, i am drumming up a definition of dissident, and crafting a proposal that would protect that mythical person's interests. the fact that the QNAME can be recovered in many cases by a well resourced nation-state actor is meaningless here, since that surveillance would have to be targeted, and would be both inaccurate and expensive; whereas the surveillance i'm solving for is the ubquitous kind, which is presently very accurate and very cheap. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] various approaches to dns channel secrecy
Matthäus Wander wrote: ... I didn't mean to imply that a DTLS solution can be universally deployed. because the dns is a map to the territory known as the internet, and because most internet packet flows begin with a dns transaction, i'm dismissing out of hand anything that will almost universally not work for some class of user, such as those in hotel room wireless networks, or behind CPE that either can't pass new protocols or would require above-average skill to configure for such. in my own configuration i'd set EDNS to be the primary protocol, and add HTTPS as the first fallback to be tried, so that the fallback to plain DNS on UDP/53 can be as rare as possible. this may even be a reasonable default. but we can't spend any of our time pretending that the internet architecture isn't a hostage to a billion poorly built CPE devices, no matter how hopeful we are as to the future, and no matter how many personal counter-examples we can cite. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
David Conrad wrote: Paul, ... that's why query minimization is the preferred solution to this problem. This isn't either/or. are you proposing to solve problem A (junk queries at the root) and problem B (junk queries at tld's and pseudo-tld's) using different mechanisms? why is the cost of a second mechanism worth paying, if a single mechanism would solve both problems? granted, we can solve any given problem in any number of ways including one, or more than one. but what's our incentive to pay more than we have to? ... one key point of slaving the root is that folks who do slave the root are accepting the responsibility to keep it up to date. Failure to do so only impacts their own customer base. This is a self-correcting problem -- get too stale and your (presumably paying) customer scream at you ... my experience has been that when dns doesn't work the call reporting this can go just about anywhere. if i could be sure that the first call from most users would go to the actual person who had the power to fix whatever caused the call, i'd certainly make that a primary design assumption. put it the other way. as a domain holder, i'd like the system recommended by IETF whereby my delegation data is distributed to be as error-unlikely as possible. if you give me a vote, wearing my domain holder hat, i will pick please tell the small number of people who want to run root anycast nodes to do so rather than please tell the large number of RDNS operators to slave the root. this is me wanting, selfishly, uptime and a low number of dependencies and state-permutations. but i consider myself to be representative of other domain holders in this regard, so it could be worth paying attention to my selfish desires this time. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
Declan Ma wrote: Zhiwei, Your proposal seems reasonable. But we can not separate the recursive-level and authorative-level, as you call it by the way, since the DNS is an integrated one. If both of the two solutions are feasible, we need to figure out how and to what extent, both solutions could collaborate on root zone file distribution, not in the “respective scenarios” . Declan Ma ZDNS in my opinion, the applicability statement of a recursive solution would be: if you want these benefits and can manage these risks, then you can configure your rdns as follows. whereas the applicability statement for an authoritative solution would be: if you want to serve root dns content to a loopback, lan, campus, or global network, then configure your adns and your routing as follows. separate from applicability, there is vision. the vision statement for an rdns solution would be: to allow self selected recursive dns operators to become less dependent on the root name server system, the following proposal is offered. whereas the vision statement for the adns solution would be: to better server root dns content to the internet, the following proposal is offered. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Recursive solutions and authoritative solutions
Paul Hoffman wrote: On Jul 9, 2014, at 12:43 AM, Paul Vixie p...@redbarn.org wrote: in my opinion, the applicability statement of a recursive solution would be: if you want these benefits and can manage these risks, then you can configure your rdns as follows. whereas the applicability statement for an authoritative solution would be: if you want to serve root dns content to a loopback, lan, campus, or global network, then configure your adns and your routing as follows. separate from applicability, there is vision. the vision statement for an rdns solution would be: to allow self selected recursive dns operators to become less dependent on the root name server system, the following proposal is offered. whereas the vision statement for the adns solution would be: to better server root dns content to the internet, the following proposal is offered. These statements assume that there is a need for an authoritative solution, ... no. these statements offer specific motives to specific self-identified parties. ... Given that you are one of the co-authors of draft-lee-dnsop-scalingroot, can you say why your authoritative proposal is significantly better than the current operational base? yes. in https://www.icann.org/en/system/files/files/report-21feb14-en.pdf (section 9.4) i wrote as follows: Criticisms of the current and historical Root Name Server System include lack of resistance to DDoS attack, noting that even with the current wide scale anycasting by every Root Name Server Operator, there are still only a few hundred name servers in the world who can answer authoritatively for the DNS root zone. We are also concerned that reachability of the Root Name Server System is required even for purely local communication, since otherwise local clients have no way to discover local services. In a world sized distributed system like the Internet, critical services ought to be extremely well distributed. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Recursive solutions and authoritative solutions
Paul Hoffman wrote: On Jul 9, 2014, at 10:45 AM, Paul Vixie p...@redbarn.org wrote: Criticisms of the current and historical Root Name Server System include lack of resistance to DDoS attack, noting that even with the current wide scale anycasting by every Root Name Server Operator, there are still only a few hundred name servers in the world who can answer authoritatively for the DNS root zone. We are also concerned that reachability of the Root Name Server System is required even for purely local communication, since otherwise local clients have no way to discover local services. In a world sized distributed system like the Internet, critical services ought to be extremely well distributed. Apologies, but that doesn't answer the question. In the face of lack of resistance to DDoS attacks, why is it better to have more *authoritative* root servers, as compared to validating recursive resolvers that have an up-to-date signed copy of the root? Similarly, for purely local communication, why is it better to have more *authoritative* root servers? The last sentence above makes good sense, but it too is not related to the number authoritative servers. my comparison of the recursive vs authoritative approach to scaling root name service was given in the attached e-mail. --vix ---BeginMessage--- Joe Abley wrote: Hi Paul, Warren, On 4 July 2014 at 16:50:08, Paul Hoffman (paul.hoff...@vpnc.org) wrote: Greetings. Warren and I have done a major revision on this draft, narrowing the design goals, and presenting more concrete proposals for how the mechanism would work. We welcome more feedback, and hope to discuss it in the WG in Toronto. I think there is much in the language of this draft that could be tightened up, but this is an idea for discussion so I'll avoid a pedantic line-by-line dissection. But I can give you the full pedantry if you like :-) On the pros and cons, however (crudely pasted below), see below. TL;DR: there are way more cons than pros to this proposal. The pros listed are weak; the cons listed are serious. I don't see a net advantage to the DNS (or to perceived performance of the DNS for any client) here. This proposal, if implemented, would represent non-trivial additional complexity with minimal or no benefit. I am not in favour of it, if that's not obvious. ... i am +1 to joe's comments above and analysis elided. i consider joe's response to be at least as good as the because i owe DRC after my first short answer to the -00 version of this draft. however, i want to add two other countervailing points. first, this approach was tried in freebsd, when doug barton (then freebsd's BIND9 maintainer) made it the default. all hell broke loose due to changes in firewall config. debugging cost was maximized, and the debugging skills were minimized. this config was removed with prejudice. this experience, where freebsd users are actually among the smartest of all dns users, should serve as a warning sign to others: abandon hope all ye who enter here. so, joe's recommendation that this draft be retitled and rekerned to be draft-ietf-dnsop-slaving-root-on-resolvers-harmful resonates very strongly with me. second, this approach asks millions or tens of millions of rdns servers to change their config in order to actually scale the capacity of the root. (so, high cost and low benefit, as joe said.) the reason i proposed a radically different solution in my ICANN ITI contribution (now described at http://tools.ietf.org/html/draft-lee-dnsop-scalingroot-00) is to allow a few dozen to a few hundred self selected highly skilled and motivated network-level admins to scale the capacity of the root for everyone. it's a plain hierarchical solution allowing the operators of any loopback network on any host, or any LAN segment, or any campus, corporate, or ISP network to add root name service as a local capability; it also allows unlimited scale at the global BGP layer. it is patterned after the success of AS112. it is apolitical since existing rootops are also expected to participate. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ---End Message--- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Recursive solutions and authoritative solutions
Paul Hoffman wrote: On Jul 9, 2014, at 11:15 AM, Paul Vixie p...@redbarn.org wrote: Paul Hoffman wrote: ... Apologies, but that doesn't answer the question. In the face of lack of resistance to DDoS attacks, why is it better to have more *authoritative* root servers, as compared to validating recursive resolvers that have an up-to-date signed copy of the root? Similarly, for purely local communication, why is it better to have more *authoritative* root servers? The last sentence above makes good sense, but it too is not related to the number authoritative servers. my comparison of the recursive vs authoritative approach to scaling root name service was given in the attached e-mail. --vix I'll take that as a no to you having answers to the questions about why it is better to have the additional servers be authoritative. i don't know how to state the case more clearly. my answer is not no as you surmise. the cost of the recursive solution is high and the benefit low. the cost of the authoritative solution is low and the benefit high. if you consider the number of operators involved, their skill and motivation levels, and the number of affected end users -- in each case -- you should be able to reason your way to the same conclusion. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Recursive solutions and authoritative solutions
Paul Hoffman wrote: On Jul 9, 2014, at 1:47 PM, Paul Vixie p...@redbarn.org wrote: i don't know how to state the case more clearly. my answer is not no as you surmise. the cost of the recursive solution is high and the benefit low. the cost of the authoritative solution is low and the benefit high. a) You didn't actually calculate the cost of the recursive solution, you simply pulled a large number of servers needed out of thin air. about 20M IP addresses answer as open recursive. most of these are low quality CPE and other servers without skilled operators. i don't believe that the rdns-root proposal is aimed at this set of users, but if it is, we've got a NOTIFY problem as well as a debugging problem. to the best of my knowledge opendns and google dns already operate as stealth secondaries for the root, not that they can answer AA for root data, but that they don't need to ask a real root name server for any TLD information, and they can generate NXDOMAIN without having to swim upstream to get a purpose built NXDOMAIN for the root. if not, both should. if the rdns-root proposal is aimed at this set of users, then that's great, it just needs an applicability statement similar in concept to the one i suggested up-thread. the middle of the market is where we lose cognitive traction. from my point of view this set of operators is not skilled enough, and is not ever going to be skilled enough, to both configure and operate and audit and debug a stealth root slave. the freebsd experiment proved this to my satisfaction, though i was previously informed on this topic by selling BIND support for a decade or two. but if we imagine that the skills gap could be closed with good documentation and good software, the portion of the internet that can be isolated from root name server reachability errors using this approach is still very small -- and the roll out time for vendors like nominum, microsoft, infoblox, ISC and others to inform their customers of this option is measured in years. and the total mass of held state in terms of software revisions, version numbers, stored content has a multiplier in the tens of thousands if not hundreds of thousands. there's no thin air here. based on the freebsd experiment with stealth root zone service, it can't scale. (the freebsd community is Very Smart in the grand scheme of things.) whereas based on the AS112 experience with unowned anycast, that approach can scale -- all we needed was DNSSEC so as to erase the temptation of local root operators to amend the zone content in any way. b) You didn't say why would need any fewer authoritative servers to get the same benefit. i said why fewer authoritative servers would have a greater benefit. ... If the goal is to get the correct answers for root queries closer to more users, both proposals do that. i'd like a small number of operators to be able to effect internet-wide improvement, and specifically, i'd like a moderate number of edge network operators to be able to offer root name service to their rdns-running populations without them having to pirate the address space of an existing root name server operator. i want to avoid having this burden shift to every single rdns operator who wants the benefit of better access to root zone content, because (a) the world's supply of rdns operators motivated and skilled enough to do that is insignificant; (b) the complexity of configuration and monitoring and debugging will scale with the affected population; and (c) the affected population will be extremely small compared to the size of (for example) the affected population of the AS112 system. so my goal is different -- both more broad and more narrow -- than the goal you're describing. i'll stop here. feel free to have the last word. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Recursive solutions and authoritative solutions
David Conrad wrote: On Jul 9, 2014, at 2:17 PM, Paul Vixie p...@redbarn.org wrote: the freebsd experiment proved this to my satisfaction, My understanding of the freebsd experiment you keep referencing was that one individual on the FreeBSD core team decided to change the default on an OS distribution in a very unexpected and infrastructure impacting way without significant (any?) public notice, resulting in an 'interesting' set of surprises for folks who merely upgraded their OS. that happened, except that the backout of this config feature was driven not just by the experiences of those surprised by it, but also by those who knew it was coming and knew it was happening. two wizard level freebsd power users went so far as to describe a failure caused by the root zone timing out due to an upstream firewall change. rather than teach the system how to monitor and report this sort of thing, and back out the local root zone if it went stale, there was a brief and overdue cost:benefit analysis after which this config was backed out of freebsd itself. Can you please point to your evidence that the failure of the freebsd experiment was driven by a lack of skill to both configure and operate and audit and debug a stealth root slave? i did not keep notes as to who did or said what and on which dates. perhaps doug barton could be persuaded to say more. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
Tony Finch wrote: John C Klensin john-i...@jck.com wrote: IN MX 0 . At least in the near term, some SMTP Server (MTA) implementations will conform to that rule (many already use it) and some won't. For the latter, they will presumably do what the SMTP specs say to do. In summary, that is to look up the address(es) associated with the root and try to open a mail connection to one of them. There are no addresses associated with the root, so the mail server will immediately report a delivery error. RFC 5321 section 5.1 paragraph 2 final sentence. The SMTP server will not try to connect to the root name servers, as your message suggested. true as stated. what's unstated here is that every SMTP sender who encounters such an MX without understanding its new meaning will do two or three lookups: . MX, [. ,] and . A. if they are behind an RDNS that doesn't do negative caching (and there are many, though none of them are open source; the open source RDNS servers do negative caching right) then these two or three queries will flow through to the authority servers for . which is to say the root name servers. the long tail on old interpretation is between one and three decades. (which is also why repurposing/redefining things like TCP/53 is unworkable, as discussed separately.) if IETF had rules, one of them should be, don't redefine things that are in an existing datapath -- make a new datapath. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Masataka Ohta's 2004 draft...
David Conrad wrote: Masataka, On Jul 23, 2014, at 7:57 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: http://tools.ietf.org/html/draft-ietf-dnsop-ohta-shared-root-server-03 In what context, did you mention it? I asked if the authors had compared their draft (http://tools.ietf.org/html/draft-lee-dnsop-scalingroot-00) to yours. this author isn't in toronto so i'll answer here-- i had not and have not compared -lee-dnsop-scalingroot- to -ohta-shared-root-. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
i think there's a necessary and healthy tension between the installed base and new technology. i would not like to see every new application designed to run inside TCP/80, even though that's the only universal wide area protocol. and we won't see any new application that requires a forklift upgrade of the whole internet before it can be used -- no market. in this case i think mark's approach is right, because it works better for people who fix their firewalls, but it finds a way to work, no matter what. this puts a little bit of pressure on middlebox makers who mindlessly constrain future protocols. sardonically, the reason i chose fragmentation for EDNS rather than a new MD (More Data) bit in the flags and a new fragment number N of M option in the OPT RR, is that i imagined getting EDNS deployed in less than five years. now that it's been almost fifteen years and we're still fiddling with it, i can see that i made the wrong choice in RFC 2671. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
bert hubert mailto:bert.hub...@netherlabs.nl Sunday, September 21, 2014 4:52 AM ... PS: the above is currently not yet supported for DNSSEC domains! i'd be very interested in a standards-track (interoperable; including DNSSEC support and AXFR/IXFR) version of this feature. my hope is that you will remove out-of-zone capability here, that is, the target of ALIAS should have to be authority data in the same zone. this would simplify the DNSSEC case, but more importantly, it would avoid having authority servers make upstream queries. if you decide to work on this, i'll contribute as at least a reviewer and perhaps (if invited) as an editor. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
