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] on "Negative Trust Anchors"
Livingood, Jason (Jason_Livingood) writes: > On 4/15/12 10:42 AM, "Joe Abley" wrote: > > >Patrik, > > > >Nobody is talking about creating NTAs. NTAs already exist. The question > >for this group is whether or not they are worth standardising. > > > >Joe > > Quite true, Joe! We'll keep using NTAs as needed. But I've had enough > people ask me to document what it was we were doing and why, and other > ISPs ask about it that I figured an informational document certainly > couldn't hurt. I think quite a few people new to DNSSEC might be happy to know that NTAs do in fact exist (and at least one vendor actually has knobs to turn them on it their GUI), and how they can be (mis)used. Additionally, I found the discussion on the possibility of having NTAs automatically limited in time quite healthy. So at the very least having the concept documented seems worthy of the effort. Phil ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
Shane Kerr (shane) writes: > > 1. Send query with the magic EDNS to a server. > 2. If the response is in the new format, then remember that. > 3. Subsequent queries go to a different port, using a new format. Would it be nuts to sugggest that the different port could be specified using SRV ? _dns._udp isn't that far off once you've primed the pump (and you've got dynamic port numbers to boot, yay!). Oh, that means you'd need to know the new port number, if you don't do an initial port 53 lookup. Scratch that :) Cheers, 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] 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] 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] Fwd: New Version Notification
Paul Vixie (vixie) writes: > 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.) I'll trade my tabs (bad editor, no cookie) for the capitalization of your lead words. ;-P > 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. Ok, thanks for clarifying. I suspected so. Phil, not tabbed. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-licanhuang-dnsop-distributeddns-04.txt
Edward Lewis wrote: > [0] - I cringe when I see a response to a new idea that contains that > phrase. It can be so, um, anti-innovative and un-motivating plus > antagonistic. Sometimes the application of a tool to a problem may be > wrong though sometimes it can spark another idea. I promised I would reread this, and try to be constructive about it. The idea of P2P DNS intrigues me, so I thought I'd give it a shot. > ZST University [...] > Abstract > >This file is a proposal for P2P based Domain Name query stratagy in >IpV6. The DNS servers construct n-tuple overlay virtual hierarchical >overlay network. With cached addresses of DNS servers, the overload >of traffic in tree structure can be avoided. Already there, as has already been pointed out, we have a flawed and unsupported assertion. >for Domain Name query and reverse Domain Name query in IpV6 for a >large number of domain names. Question: Why is this limited to IPv6 ? > 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. Comment: DNS has already become a vital component in today's Internet infrastructure. Also, "will encounter problems" needs to be supported. The rest of the document does not provide examples, or refer to external document that may support this assertion. >This file is a proposal for P2P based DNS query stratagy in IpV6. The >DNS servers construct n-tuple overlay virtual hierarchical overlay >network. With cached addresses of DNS servers, the overload of >traffic in tree structure can be avoided. Question: What overload ? >There are huge numbers of IP address in IpV6. Moreover, there may be >use case for multi domain names associated with a sigle IP address. And vice versa. >DNS implementation currently used may encounter overload traffic in >root DNS servers. Question: why ? > This document uses VIRGO[VIRGO] overlay network to solve the above > problem. The problem area is stated, but never fully developed or supported in the rest of the document. >Unlike query pathes currently used in Domain Name >Systems allways go to root servers, Comment: only initial queries go to the root, they are (often) subsequently cached. Ed Lewis pointed out the two great strengths of DNS, there are in fact three: distribution/replication, hierarchy, and caching. > Virtual Hierarchical Overlay >Network for DNS routes quest message to the server with theoretical >least hops from destination server. Question: Based on which metric ? How would this be different from say anycasting the addresses and relying on the routing protocol to solve the least hops question ? >controlled domain name by cutting off leaves as its Identification, >which is called as Domain Name Server Identification (DNSI).For >example, for Grid.network.computer.science, >Wireless.network.computer.science, etc., Domain Name Servers have >Identifications -- network.computer.science.It keeps RRs for >Grid.network.computer.science,Wireless.network.computer.science,etc. >The Domain Name Server can be replicated by machines with different >IP addresses, but all with same RRs and route tables. >Gateway is a node role which takes part in routing functions in >several different layers of virtual groups. Question: what impact on the operational requirements of existing DNS installations would this have ? >Domain Name Servers are virtually architectured as Tree Structure. >Some Domain Name Servers takes roles of gateways. When a Domain >Name Server joins the network, it first finds one of Domain Name >Servers which share the maxmium prefixs with the joining Domain Name >Server, then the joining server sends the JOINMESSAGE to the >latter,the latter will broadcast the message to all Domain Name >Servers in the virtual group. The Network establishment is shown at >Appendix 4.2. Question: In 4.2, it is specified: >1. P_join finds one of Domain Name Servers P_groupToJoin(which > belongs to virtual group--joinGroup) sharing maximium prefixs with > P_join. Above, it is mentioned "broadcast the message to all Domain Name Servers" in the virtual group. 1. What communication type is used to find "one of the Domain Name Servers which shares the maximum prefixes" ? 2. I imagine that the broadcast mentioned is some kind of P2P discovery/ flooding mechanism ? ... there are other implementation questions which remain to be discussed, b
Re: [DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-missing-mname-00
Joe Abley (jabley) writes: > Hi all, > > Comments on this document in this list would be most welcome. >the MNAME field of an SOA record has no benefit, and in fact may well >cause unwanted traffic (DNS UPDATE messages) to be received by the >named server. ... if the named server is at all reachable/exists. Think stealth servers or other zone population and provisioning mechanisms that do not use AXFR/IXFR as their method of distribution (i.e. where each nameserver for the delegation could arguably be itself a master). I won't even get into MNAMEs pointing to RFC1918 addresses (see http://www.ripe.net/ripe/maillists/archives/dns-wg/2005/msg00264.html) >This document specifies a convention by which a zone operator may >include an empty MNAME field in order to deliberately specify that >there is no appropriate place for Dynamic Updates to be sent. 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 ? >For zones whose SOA record contains an MNAME field which corresponds >to a server listed in the apex NS set, making the MNAME field empty >might well cause additional NOTIFY traffic. If this is a concern, >the operators of the authority-only servers for the zone might choose >to specify an explicit notify list. ... which excludes the "master". 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. 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 ? Otherwise a good idea. 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] AS112 for TLDs
William F. Maton Sotomayor (wmaton) writes: > > I think it very may well be suited to that task, but are we crossing a line > here that may result down a path we might regret later on. I think what > would need to be worked out is what criteria would be used to declare a > local or nonsense domain, nonsense or junk, and have that suitably delegated > to AS112. It could go ad infinitum (ever word in every language), or it > could be we need to take whatever floats to the top 25 of a domain lookup > chart. Of course, someone needs to determine what makes a good sample to > create that statistic. The first step is to decide whether delegating to AS112 is reserved to standardized (read: RFC) zones, like RFC1918, 169.254, etc..., or whether anything sufficiently large -- and bogus -- is sufficient. .local fits the latter criteria. But yes, it does make the requirement criteria more fuzzy. ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
Stephane Bortzmeyer (bortzmeyer) writes: > > I cannot find another report about the TLDs most often queried at a > root name server. Other reports I've seen aggregated data, while this > small glimpse, however partial, at least *names* the TLDs. > > All the non-existing TLDs queried are local domains (such as Apple's > ".local"), leaking through a configuration error. This looks like a > job for AS112. .local is most likely broken internal Windows AD domains (MS has for a long time recommended using .local for internal domains) -- Apple's use of .local is multicast only AFAIK. Phil ___ 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
Re: [DNSOP] I-D ACTION:draft-regnauld-ns-communication-00.txt
Paul Vixie (vixie) writes: > > the attached paper was published last year but i've not got around to > writing an I-D for it nor releasing the software that implements it. i > have shared it privately with a number of folks, and it's in fairly wide > use among the folks ISC trades slave nameservice with. my big worries > are that it's either too BIND-specific or that it'll spawn a dozen > competing non-interoperable schemas (like my QUOTE SITE INDEX hack did > in wu-ftpd). so if you hate this, plz don't hack up your own -- instead, > write an I-D or help me write an I-D, and let the community drive some > coherence into this functionality.) Hi Paul, Thanks for sharing the paper. I just checked it out quickly and it looks very interesting indeed. I like the concept of meta-zone. Cheers, Phil ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-regnauld-ns-communication-00.txt
Joe Abley (jabley) writes: > > Consider the various approaches used by ISC and others to populate a > zone with data that can be extracted by a nameserver and used to > configure itself, for example. No protocol there -- more like a zone > schema. I am certain that most of the requirements defined in the draft can be implemented as third-party tools, and totally out of band with regards to the nameserver software itself. Some of the other stuff involving views, for example, will require some level of integration with the nameserver. By that I mean that the tools will need some knowledge of what features are implemented by the nameserver, maybe through some sort of capability negotiation. We were focusing primarily on zone management when we wrote the draft, as I consider them to be implementation neutral. One way could be to have some sort of one schema, or pseudo-zone, call it "._conf" Clients implementing the protocol could listen to updates on the "._conf" zone, and reconfigure the nameserver as required (adding or removing a zone if it appeared in the pseudo-zone, for instance). Things like nameserver configuration, runtime options and health reporting are definitely nameserver specific. But to avoid hitting a wall too early, we might as well address these things now. Phil ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
