Re: [DNSOP] key lengths for DNSSEC
Joe Abley (jabley) writes: 1. subverting sufficient NTP responses over a long enough period to cause the remote resolver's clock to turn back in time (long period suggested due to many/most? implementations' refuse large steps in times, and hence many smaller steps might be required) Many systems will run ntpdate on startup. This seems like an intractably difficult thing to accomplish. It does seem far fetched. What am I missing? There may be good reasons to increase key length, this is not one I'm worried about (then again, no one worried about source port randomization before 2008 :) P. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt
W.C.A. Wijngaards (wouter) writes: Yes I wrote the code and say so. (Not sure how that is better than reading the source). Results, anecdotally, are very modest. It does remove latency spikes for popular names. What does the latency spike translate to in terms of extra traffic (clients) ? A thundering herd effect ? Congestion ? Considering how many tricks modern browsers have up their sleeves (including prefetching data linked on a page), I'm wondering how the two interact. I've always mentioned the expiring RR prefetch option to be a cool feature of Unbound, but in reality, what does it mean for users ? Aside, I agree that prefetching before the TTL expires is overly aggressive. If it mitigates other issues... But lengthening the TTL is worse (for DNSSEC rollovers TTLs MUST expire, or the signatures become bogus). :) P. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-yoneya-dnssec-kskro-failure-recovery-01
Yoshiro YONEYA (yoshiro.yoneya) writes: Indeed, the document is imcomplete, and need feedbacks from experiences. There are indeed many ways to facilitate recovery, not all of them practical or realistic. Here's one that's more in the realm of prevention, but would faciliate recovery, assuming the implementation doesn't suffer from the same operational errors that led the zone owner to consider recovery in the first place, and assuming the DS-set has been completely borked by the parent: Case 6: always have a backup (fallback) DS, published alongside the existing (production) DS record or records (during rollover) currently associated with the currently active (production) KSK. Keep this backup KSK in a safe place, and in case of serious SNAFU with the existing DS-KSK couple, pull the backup KSK out of the Safe Place, and start signing the ZSK with that. The DS-set containing the active + backup KSK being by definition always published, this should allow for faster convergence (assuming a fairly low TTL for the DNSKEY RRset in the signed zone). The problem with the ID may be that there are so many different ways of doing this (hinted at by the phrase Registration system (or zone generation system) of parent zone will be complicated.)... Phil ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112/local zones documents published -- and next steps
Joe Abley (jabley) writes: (b) Inclusion of IPv6-related RFC6303-style zones on AS112 servers (2) whether the list of zones specified is complete and accurate [...] (b) and (2) above also prompt the question of how we (more generally) might manage the zones served by AS112 nodes, given that there is only loose coordination between AS112 node operators and potentially a significant deployment of (globally) invisible AS112 nodes which serve captive audiences (enterprises, ISPs own customers, etc). ... all of whom may have a voluntarily incomplete implementation of AS112 zones on, or upstream of, their recursive servers - not the least because they may themselves be using the networks that the reverse zones provide reverse information for. There is a risk, depending on the update mechanism, that additional zones delegated to the existing AS112 servers might be lame on a significant number of servers, and the impact of that lameness ought to be assessed. With regards to private AS112 announcement leaking from these servers ? Or did you have other things in mind ? Would make sense to dig a bit deeper on the effect. In addition we now have a registry of locally-served zones, per RFC6303, and we might consider mechanisms to update AS112 nodes from that registry (or constrain the procedures for updating that registry also to consider AS112 support for the zones, as they are added). Got any ideas on that front already ? And, where would the the official list of locally-served zones reside ? draft-cheshire-dnsext-special-names-01 suggest that IANA needs to create a new registry of Special-Use Domain Names. It feels like there's an opportunity here to align these various registries and knit in some process relating to the AS112 project. What exists right now, together with what is proposed to exist, is a little messy. Sounds like a plan :) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] dns data exchanged between host and local dns-sever
Holger Zuleger (Holger.Zuleger) writes: Even BIND as a (local) forwarding name server is not able to use GSS-TSIG to protect the communication with the recursive name server. You can setup TSIG between recursive nameservers. Please correct me if I'm wrong. I'm looking for a TSIG aware stub-resolver for years. Well, Unbound does provide the necessary pieces to build one, but I've yet to see the OS stub resolver implement TSIG. Phil ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-jabley-dnsop-missing-mname-00
(updated subject to reflect draft being discussed) Paul Vixie (vixie) writes: 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, I actually considered that option for a moment. 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. Is it then out of spec if we're working with a hidden/unreachable master server, and even though it is disclosed in SOA.MNAME, it is not listed in NS.NSDNAME ? What should one put in the SOA.MNAME in that case ? Any one of the slaves ? Phil ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
Dean Anderson (dean) writes: A number of the points you raise have already been addressed. Hi Dean, Where ? The IPV6 Reverse resolution question has been discussed at length in DNSEXT previously. In fact, it was proposed to remove reverse resolution entirely from IPV6 for just the reason Dr. Huang notes. Which one ? There's still nothing showing that there effectively is going to be a bottleneck of traffic to the root. Some curve, some data points, anything, we could use to extrapolate future problems from current trends, or even a *simulation* of load based on guesstimages/projections of network host population would come in handy. A 128 bit IPV6 address is 16 octets. To perform reverse resolution requires traversing 16 levels of DNS tree. How is that better than 32 steps for the proposed implementation ? (from the draft, §2.3) The Total address space of IPv6 is huge. But, only the Reserve Domain Name Servers managing used IP addresses will join the Virtual Hierarchical Overlay Network for DNS. And the worst maxium query steps are 32. With route cache the query steps will be less than 32. Therefore, this strategy for Reverse Resolution is feasible. Note: I may very well have gotten lost in the logic, and if there's something I missed, please point it out... Even the delegations impose significantly larger trees on the registries. It is recognized that this isn't going to be very scalable, or even possible. Again, where ? The references you point to below are somewhat old, and of course it doesn't make them any less relevant (after all, IPv6 is only going to be get used more and more), but still, I fail to see any kind of model that really does show that it will be a problem. C. Huitema's argument that the ... operational implications are daunting, I can easily identify with -- autoconfiguration, if it does get used, will mean that everything has to be automatized and most likely dynamic. Alain Durand does point out that due to the size of ipv6 space, reverse information for large ranges of IP addresses will have to be dynamically generated, use wildcard, only record some, or drop. But it still doesn't say how this is going to be a problem, that Mr. (not a Dr. it seems) is arguing his draft is the solution to. IPV6 proposes to use ICMP Node Identification query instead. You mean ICMP Node Information ? (RFC4620) Yes, it definitely looks like an interesting solution. It has issues, though, for example, the fact that it assumes that every node on the internet will be reachable so that they can be queries: (from RFC4620, §8. Security Considerations) This protocol has the potential of revealing information useful to a would-be attacker. An implementation of this protocol MUST have a default configuration that refuses to answer queries from global- scope [3] addresses. ... and the protocol doesn't propose implementing a collector/ local aggregator which could handle/reverse proxy such queries at the edge router or firewall level, so I guess if you've got a firewall, you haven't got reverse anyway. At present, there is an IPV6 reverse tree, but it is not guarenteed it will stay. It is for transition--so that gethostbyaddr() still works on IPv6 during transition. That's not the impression I got. Decisions to phase out ip6.int and use ip6.arpa look to me like ip6.arpa is here to stay. HOW we populate it -- or rather: how do we make that namespace return something useful, using gethostbyaddr(), is part of the challenge -- for the reasons stated by the sources you site. But I don't see either of these issues in anyway related to the the overload of traffic in tree structure that Mr. Huang says should be avoided. See for example the discussions here: http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00931.html http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01828.html Cheers, Phil ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Revising RFC 4641 on DNSSEC Operational Practices
Paul Hoffman (paul.hoffman) writes: Olaf agreed that there may be more operational input from people who are currently deploying DNSSEC, and that this document might be ripe for a renewal even though it is less than two years old. How do people in the WG feel about this? Recent events have shown (and there may be yet more to come) that DNSSEC is gaining steam, and there's a fair amount of upcoming operational experience to be harvested. So it sounds like a good idea to start working a revised draft now, but be aware that it might be worth taking the time in the process to gather feedback from the field, and not be too hasty in pushing for a final document. Phil ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
Paul Vixie (vixie) writes: 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. I would put it much more concisely: this is a solution looking for a problem. Phil ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Stephane Bortzmeyer (bortzmeyer) writes: On Mon, Jun 09, 2008 at 10:29:27AM -0400, Andrew Sullivan [EMAIL PROTECTED] wrote a message of 52 lines which said: Is there any way to turn this off in Firefox 3? Switch to a free software browser without this very bad policy? http://www.konqueror.org/ Less radical... about:config in firefox search for IDN disable network.IDN.whitelist for all listed TLDs. Cheers, Phil ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-licanhuang-dnsop-urnresolution-00
Lican Huang (huang_lican) writes: One problem is how to implement the DNS with huge amount domain names. Define huge -- it's already pretty huge today. I don't think today's DNS implementation can handle successively with huge amount domain names in the future. Why ? Another question is when there are so huge amount domain names in the future, why we don't give these domain names semantic meaning? Can you figure out what's the meaning about www.u8erbjsdhdfdsdf.com from bilions of domain names? DNS is a labelling mechanism, as has been pointed out before. I don't think people care about assigning meaning to www.u8erbjsdhdfdsdf.com. You may say we can use SEARCH by the key words and get the link of www.u8erbjsdhdfdsdf.com. But, in this way, domain names are useless , because we can totally use IP address or any other handle to represent www.u8erbjsdhdfdsdf.com. And we don't because the idea was to have a labelling mechanism that was distinct from the addressing mechanisme. Nothing more. You may say we use domain names as stable name because Ip address may be changed. But , why use these ugly domain names? Why not semantic domain names? Because it's not DNS anymore ? How to name semantic domain names? We can let specific virtual organizations ( or registrar comanies ) to do. That is, ICANN controls top level domains. Lower level domain names is controlled by virtual organizations ( or registrar comanies) according to the clasification of contents. In this way, we can figure out hieararchical classification of contents very easily by trace down the heararchical domain names. But it's not the same protocol and architecture is it ? Semantic domain names does not takeover the current domain names in the first stage. We can use new TLDs to manage semantic domain names, and let the old TLDs to be managed as the way today. The second part may be interesting, but I still fail to see how the existing DNS architecture will not be adequate for IPv6. ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS pinning, anti-pinning and rebinding in DNSOP?
Pekka Savola (pekkas) writes: Thanks for the interesting link. This certainly shows that use hostnames everywhere idiom that the IETF has been repeating doesn't quite work as intended in the real life :-) Yes it does, it's not a bug, it's a feature. It does exactly the right thing from the point of view of the implementation. This is, in my opinion, the same problem scope as IDN homographic attacks, just one level of interaction (App - DNS, as opposed to User - APP). Section 5.2 of the paper suggests: Instead of trying to prevent a host name from rebinding from one IP address to another -- a fairly common event -- a different approach to defending against rebinding is to prevent the attacker from naming the target server. IMHO the problem is there, i.e.: fix the application (browser javascript/sandboxing mechanisms), don't blame DNS for doing exactly what it was intended to do. It'd be even more stupid to look up IPs once and stick to those during the life of the application (== execution of the Flash code, or JS code, which can be anything from a few milliseconds to several hours). The problem is the same as for traditional (read: standalone) applications which lookup IPs once and never look them up again. Other solutions are outlined such as blocking direct DNS queries to the outside world, and/or using DNS software that refuses to relay replies containing internal IP addresses from the outside. That's just spoofing protection at the DNS level. The section on Host Name authorization is interesting, but it's a hack. ___ 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] (bmanning) writes: actually, the key point here is that apparently a number of (good) people are avoiding the IETF process because they believe their ideas, intended to be partof open standards development, are being patented by others and then used as leverage to force particular outcomes. Such beliefs are corrosive and distructive to the IETF process and it is not clear how such concerns could be avoided in todays environment. So work is being done outside the IETF, where there is trust. s/IETF/W3C/ and it's mostly valid as well. ___ 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?
Paul Vixie (vixie) writes: 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. Nah, they'll just go the way of other encumbered RFCs: they'll be labelled as such, ignored, worked around, and something better will be designed and standardized upon. Waste of IETF resources and time though. ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
