Re: [DNSOP] Prefixed name spaces and DANE client TLSA
[Commenting only on technical aspect of the name structure -- discussion of whether the namespace is cluttered, pretty, intuitive, etc, are too abstract for me. Not making light of user confusion issues, just recusing on them.] I would recommend that you think about how any of these proposed schemes interact with DNS wildcards. Yes, some people use wildcards with TLSA RRs, or even with CNAME RRs pointing to TLSA RRs: this allows one to express "every service on machine foo.example.org uses the same certificate" concisely. So if one buys George's analysis of this as a role vs protocol distinction, the question becomes whether it's more useful to be able to group by roles or by protocols. That is, are you more likely to want to say "all roles for protocol foo use the same certificate", "all protocols for role foo use the same certificate", or just not allow any kind of grouping here at all. The first of these makes the most sense to me, YMMV. Wildcards are probably also the main technical reason for caring about differences between the naming for TLSA and SRV RRs. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [internet-dra...@ietf.org: New Version Notification for draft-sullivan-dns-class-useless-01.txt]
At Tue, 15 Mar 2016 21:24:53 -0400, Andrew Sullivan wrote: > > On Wed, Mar 16, 2016 at 12:20:40PM +1100, Mark Andrews wrote: > > It's more that the registry failed to scoop up all the old definitions. > > Perhaps. The documentation I could find for chaosnet is pretty thin, > and STD 13 is pretty clear that A records are only defined for IN. RFC 882, page 10; RFC 1034, page 13. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [internet-dra...@ietf.org: New Version Notification for draft-sullivan-dns-class-useless-01.txt]
At Thu, 17 Mar 2016 11:24:57 +1100, Mark Andrews wrote: > In message <20160316235134.gi1...@mx2.yitter.info>, Andrew Sullivan writes: > > > > I'm apparently having a hard time reading this month :-/ But your > > point makes the problem yet worse, since there's no sense that in > > the CS net class here the RDATA of an A record is a host address. > > I suppose that, since it's in 882 (which is obsoleted) that > > doesn't matter. RFC 973 deprecated the CS class. > > But in CH according to the definition it's not just a host > > addressm but "a domain name followed by a 16 bit" address. (Maybe > > that actually means that the domain name is not in the RDATA. Since > > I'm having so much trouble reading this month, it's probably better > > that I not form an opinion.) > > RFC 1034 has: > > Similarly we might see: > > XX.LCS.MIT.EDU. IN A 10.0.0.44 > CH A MIT.EDU. 2420 >From which point people with sufficiently long memories can probably tell you whose fault this is. PVM and I came up with the CH class A RDATA layout over lunch one day in 1985 when he happened to be visiting LCS. Chaosnet is strictly a LAN protocol (well, OK, if anybody had ever actually implemented anything using IP protocol number 16, it would have been an Internet protocol running somewhere around OSI layers 4+5, but I digress), so the idea was that the RDATA contains a DNS name naming the LAN and a 16-bit address naming the node on that LAN. We already had CS A RRs as a precedent for class-specific RDATA, so we just followed that. This was long enough ago that Chaosnet was in much wider use within MIT than TCP/IP, and it was not yet a foregone conclusion that the Internet would grow to subsume all other networking technologies on the planet. So we were trying to plan ahead. Then stuff happened. MIT's Chaosnet ended up sticking with host tables until we shut it off, so we never did implement this in JEEVES or CHIVES. Symbolics may have gotten as far as using CH A RRs as one of the many inputs to their Namespace system, but that was pretty late in their corporate life cycle, so I doubt many users ever saw it in the wild. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the Chaosnet installed base
At Thu, 17 Mar 2016 08:21:06 +, Jim Reid wrote: > > Though IIRC, a handful of universities dabbled with Hesiod in the > late 80s or theresabouts and that used the Chaosnet Class. That > stuff should be long dead and buried by now. No, that was yet another class, HS. Hesiod was an MIT Project Athena thing, and arguably was the first example of "screw it, just encode it in DNS TXT RRs" syndrome. IIRC the only RR types ever used in class HS were NS, TXT, and (maybe) A; I have a vague recollection that they just looked for IN A RRsets corresponding to the names in the RDATA of HS NS RRs. And yeah, a few other universities did pick up Hesiod, but I'd be astonished if there were any surviving instances today. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AAAA4Free
At Mon, 11 Apr 2016 15:54:05 +0200, Shane Kerr wrote: > At 2016-04-08 11:28:12 -0300 Ray Bellis wrote: > > > May I please remind the WG of draft-bellis-dnsext-multi-qtypes-01 > > I note that your idea was about 3 years ago. When it was mentioned, > Alfred Hönes noted his ideas about his presented 3 years before that. > My guess is that we could probably go back and every 3 or 4 years find > a similar proposal. :) Going back at least to the mid '90s, yes. Don't recall whether this came up in the '80s. :) As I recall, the thing that stopped this every time was lack of consensus on pesky details such as "to which QNAME does the RCODE apply when this fails" and "to which QNAME does the AA bit apply?" It's possible that DNSSEC-aware stub resolvers would provide some leverage here, since fields like RCODE and the AA bit are somewhat redundant if one can just check the freaking signatures. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AAAA4Free
At Tue, 12 Apr 2016 00:01:20 +, Evan Hunt wrote: > > So, unless I'm missing something (certainly more than possible), I don't > see server workloads or client latency being significantly reduced by the > deployment of a mechanism like this. Bingo. Also keep in mind that A and for the same QNAME are in the same zone, so by the time you've fetched (and validated, I hope) the chain all the way down to one of them, you've done almost all of the work involved in fetching (...) the other one. I remain skeptical of the claim that the round trip time to the iterative resolver is the critical factor. Or, to put it another way, if that's the critical factor, you almost certainly have other problems that a multiple query hack isn't going to solve. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Feedback on draft-koch-dnsop-resolver-priming
My co-chair has recused himself from WG chair issues related to this draft, for the obvious reason. If I understood M. Moreau's message, he is not making any IPR claims against anything covered in Peter's current draft. Rather, he is: a) Suggesting that Peter incorporate an idea discussed in one of his own drafts; b) Claiming that he has an IPR interest in the idea he is suggesting that Peter incorporate into Peter's draft, c) Making some non-binding comments about what he might do in the future if his IPR claims are held to be valid, and d) Stating that he will file a formal IPR statement at some future date. With no disrespect to M. Moreau intended, and without expressing any opinion on the validity of M. Moreau's claims, the suggestion seems only peripherally related to the main purpose of Peter's draft, and I see no pressing need for the WG to dive into the IPR rathole without having even explored any other alternatives. Absent strong support from disinterested WG participants for having Peter's draft explore M. Moreau's putatively encumbered idea, I will direct Peter to decline M. Moreau's suggestion, at least until M. Moreau has filed his IPR statement and it is possible for a disinterested person to reach an independent opinion on the extent, relevance, and validity of M. Moreau's IPR claims. ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
[DNSOP] Adopt draft-koch-dnsop-resolver-priming as WG work item?
This is a call to confirm the decision made at the face to face WG meeting in Prague to adopt draft-koch-dnsop-resolver-priming. Discussion in Prague showed reasonably strong support and no objections, but as always, decisions at face to face meetings are subject to confirmation on the mailing list. Absent strong objections, I'll ask Peter and his co-author (to be appointed, we already have a list of volunteers) to submit the next version as draft-ietf-dnsop-resolver-priming-00. Please send any comments on this subject within the next week, so that Peter and his co-author have time to rev the document before the 2 July submission cutoff. ___ 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?
At Mon, 04 Jun 2007 13:18:25 -0400, Thierry Moreau wrote: > > Is this a genuine invitation for open participation, or are the wg > activities subject to the arbitrary censorship directive issued earlier > by you (ref > http://www1.ietf.org/mail-archive/web/dnsop/current/msg05460.html)? http://en.wikipedia.org/wiki/Mu_%28negative%29 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-respsize-07
At 07 Jun 2007 05:38:19 +, Paul Vixie wrote: > > [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. I think that clarifying this would be advisable, as the present wording is subject to misinterpretation. Given how long the WG has spun on this draft, I'd recommend doing it just by proposing a replacement for the sentence quoted above, getting agreement on the list that it says what you meant it to see, but holding off on spinning a revised draft until any other comments are in, and restricting the subsequent revision to changes already discussed on the list, otherwise we'll still be at this next year. Pedantic nit while we're at it: while I understand your use of the term "transport protocol" here, it's at odds with conventional use of the term in the IETF. You're talking about transport over multiple versions of IP (ie, multiple protocols at layer 3, not layer 4). Don't know whether it's worth trying to fix that while at this. ___ 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?
I don't usually bother with refuting slander against me, as I have better things to do with my time than argue with fools, but one specific point in a recent posting does call for a response to the WG: At Wed, 06 Jun 2007 17:34:38 -0400, Thierry Moreau wrote: > > I bring your attention to the common affiliation of Mr. Rob Austein and > 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. ___ 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?
At Sat, 02 Jun 2007 18:15:04 -0700, I wrote: > > This is a call to confirm the decision made at the face to face WG > meeting in Prague to adopt draft-koch-dnsop-resolver-priming. > Discussion in Prague showed reasonably strong support and no > objections, but as always, decisions at face to face meetings are > subject to confirmation on the mailing list. > > Absent strong objections, I'll ask Peter and his co-author (to be > appointed, we already have a list of volunteers) to submit the next > version as draft-ietf-dnsop-resolver-priming-00. > > Please send any comments on this subject within the next week, so > that Peter and his co-author have time to rev the document before > the 2 July submission cutoff. The stated interval having passed without any anyone posting an objection to adoption, the decision made in Prague stands. We were fortunate to have several volunteers for the role of co-author. From that pool I've selected Matt Larson to work with Peter on this draft. ___ 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?
At Tue, 12 Jun 2007 20:47:57 -0400, Thierry Moreau wrote: > > Now that the draft-koch-dnsop-resolver-priming is adopted as as WG work > item, and that an IPR disclosure has been filed [2], I would request Rob > to revisit his (premature) directive regarding this work [3], and > retract it. Thanks for looking into this. To date I have seen no support for M. Moreau's suggestion from anyone other than M. Moreau, nor have I seen anyone other than M. Moreau disagree with my analysis that his suggestion is only peripherally related to the topic of Peter's draft. If anyone other than M. Moreau -does- wish to see Peter's draft incorporate M. Moreau's suggestion, please say so, and state: a) Why you think that the topic belongs in this draft, and b) Whether M. Moreau's IPR disclosure addressess whatever concerns (if any) you might have with respect to the IPR issues related to M. Moreau's suggestion (if you have no IPR concerns, say so). ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Request for IETF69 DNSOP Agenda Items
At Fri, 6 Jul 2007 11:45:25 -0400 (EDT), Dean Anderson wrote: > > I would like to have the WG discuss taking up my draft > (draft-anderson-reverse-dns-status) as a WG document. > > Thanks, > > --Dean Per Dean's request, I asked those WG participants who were present at the Chicago meeting two questions: Q1) How many had read Dean's draft? A1) 12 people claimed to have read Dean's draft. Q2) Of those who had read Dean's draft, how many supported adoption as of Dean's draft as a WG document instead of draft-ietf-dnsop-reverse-mapping-considerations A2) Nobody present in the room supported adoption of Dean's draft. As with any decision made at a face to face meeting this is not official until confirmed on the mailing list. So if there is anyone who: 1) Has read Dean's draft, and 2) Supports WG adoption of Dean's draft, please speak up. The chairs will assume that Dean himself has read and supports his own draft. Anybody else? Silence will be taken as confirmation of the tentitive decision from the face to face meeting, as will off-topic postings. So if you want the WG to adopt this draft, please say so calmly and distinctly. Cut-off for this confirmation call will be 00:00:00 UTC on 19 August 2007. This is longer than I would ordinarily wait for a confirmation call, but many people take holidays in August, and Dean has done the right thing here by offering the WG an alternative draft for consideration rather than just complaining about the draft that he opposes, so I want to make sure that Dean's alternative draft gets a fair chance. ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
[DNSOP] Confirmation of Chicago decision on draft-anderson-reverse-dns-status
[Resending with fixed subject line, sorry for the duplication --sra] At Fri, 6 Jul 2007 11:45:25 -0400 (EDT), Dean Anderson wrote: > > I would like to have the WG discuss taking up my draft > (draft-anderson-reverse-dns-status) as a WG document. > > Thanks, > > --Dean Per Dean's request, I asked those WG participants who were present at the Chicago meeting two questions: Q1) How many had read Dean's draft? A1) 12 people claimed to have read Dean's draft. Q2) Of those who had read Dean's draft, how many supported adoption as of Dean's draft as a WG document instead of draft-ietf-dnsop-reverse-mapping-considerations A2) Nobody present in the room supported adoption of Dean's draft. As with any decision made at a face to face meeting this is not official until confirmed on the mailing list. So if there is anyone who: 1) Has read Dean's draft, and 2) Supports WG adoption of Dean's draft, please speak up. The chairs will assume that Dean himself has read and supports his own draft. Anybody else? Silence will be taken as confirmation of the tentitive decision from the face to face meeting, as will off-topic postings. So if you want the WG to adopt this draft, please say so calmly and distinctly. Cut-off for this confirmation call will be 00:00:00 UTC on 19 August 2007. This is longer than I would ordinarily wait for a confirmation call, but many people take holidays in August, and Dean has done the right thing here by offering the WG an alternative draft for consideration rather than just complaining about the draft that he opposes, so I want to make sure that Dean's alternative draft gets a fair chance. ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Confirmation of Chicago decision on draft-anderson-reverse-dns-status
The 19 August cut-off having passed, and having seen no support for WG adoption of draft-anderson-reverse-dns-status from anyone but the draft's author, the Chicago decision not to adopt the draft stands. ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Rude legalese phone call, possibly related to "patent infringement"
Ok, that's enough. Todd, you have made your point that you believe you have IPR in this space. Noted. Now everyone please stop this, immediately. This is not a forum for legal debates, let alone insults, and claims that Todd might or might not have against various implementors are between him and the implementors, to be settled elsewhere. Stop, now. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
Having just gone through this entire thread again as prep for tomorow's WG meeting, I have a few minor comments that attempt to answer a few of the dangling questions: 1) Stephane is correct that http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html is talking about wildcards rather than redirect, but is (IMHO) wrong that in saying that this makes it irrelevant. That document includes a non-exhaustive list of things that were seen to break when RCODE 3 responses suddenly turned into redirections to an unexpected location. While the mechanism involved was different, many of the effects are the same regardless of the mechanism, so that list may provide a partial answer to Jason's request for information about things that redirection hacks break. 2) Without getting into whether one -should- do any of this, I don't think the DNSSEC "workaround" for validating stub resolvers even "works" (please don't give me a hard time about that word in this context) at a technical level. Others have hinted at this but not stated the reason, so, at least for Jason's benefit, here it is: unless I'm confused, this hack only "works" if the redirector strips off -all- DNSSEC data in -all- traffic to this resolver and replaces it with its own. In other words, this hack pretty much requires sign-on-the-fly for all DNSSEC traffic, which is unlikely to scale well. It also reduces the entire function of DNSSEC in this context to a weird and not very efficient form of channel security, and it seems unlikely that anyone would choose to get channel security this way. 3) As far as I can recall there is no explicit prohibition against modifying DNS data in transit in any standards track RFC, but there's something pretty close in an RFC old enough that it predates the current standards process. See RFC 973, specifically the section "Making up data". It doesn't talk about DNS redirect per se, but the overall intent seems reasonably clear (YMMV). --Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-perreault-dnsop-stats-mib-00.txt
At Tue, 24 Apr 2012 08:51:46 -0400, Simon Perreault wrote: > We have just submitted a new draft about a DNS server stats MIB. > Any feedback would be appreciated! If you haven't already read RFC 3197, please do so. It's short. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
