[DNSOP] Re: [TLS] Re: Re: Re: AD review draft-ietf-tls-svcb-ech

Distribution trimmed down to just dnsop, where the question is most pertinent. Paul Wouters writes: > Of course even better is using RFC 7901 Chain Query and run the few > signature validations yourself. Related, is there any notable software out there that does 7901? I started implementing it i

[DNSOP] Re: WGLC for draft-ietf-dnsop-compact-denial-of-existence

I have read the most recent version of the document and am strongly in favor of its publication as a proposed standard. I want my NXDOMAINs back. I have little substantive feedback on the text, mostly personal editorial preferences that are not worth fussing about. That said, is "lexicographic s

[DNSOP] Re: Call for Adoption: draft-huque-dnsop-grease

Suzanne Woolf writes: > This message starts a Call for Adoption for "Greasing Protocol > Extension Points in the DNS" (see > https://datatracker.ietf.org/doc/draft-huque-dnsop-grease/) Please adopt the draft as a wg doc. ___ DNSOP mailing list -- dnsop

[DNSOP] Re: RFC for web3 wallet mapping using DNS

Joe Abley writes: > > Would it be recommended to do a proposal that use either RRtype > > (TXT or WALLET) or choose one? > > I haven't read your proposal and don't have an opinion on that. I > agree that it sounds like a good question for you to ask yourself. You don't have an opinion on using

[DNSOP] Re: Fwd: New Version Notification for draft-ietf-dnsop-zoneversion-10.txt

Wessels, Duane writes: > I’m not sure about this. Since every zone will have a SOA record, > and every SOA record will have a serial value, I suppose the question > becomes whether or not a serial number is “meaningful”. I don’t know > how a name server would determine meaningfulness. When I f

[DNSOP] Re: draft-fujiwara-dnsop-dns-upper-limit-values

Jim Reid writes: > IMO documenting the trade-offs in response sizes could be a better > option. ie if the response > X, it breaks foo; if it’s > Y it breaks > bar. I agree with the approach of limiting discussion of limits to recommendations. I am not a fan of enforcing lower limits in the wire

[DNSOP] Re: Side Meeting - DNS Load Balancing

Paul Vixie writes: > somebody asked me a few months ago why "it's always dns"? meaning, > why are so many mysteries and outages ultimately traced down to > something broken in dns? Personally, even despite having the relevant haiku as my desktop background, I push back on this when it rears its h

Re: [DNSOP] Fwd: I-D Action: draft-toorop-dnsop-ranking-dns-data-00.txt

Ray Bellis writes: > I get the impression with DELEG on the horizon that there's a shift > towards the parent side data being considered more "authoritative" even > though in protocol terms it explicitly isn't. Yes and no; there's a bit of nuance to ferret out here. This is part of the original

Re: [DNSOP] Fwd: I-D Action: draft-toorop-dnsop-ranking-dns-data-00.txt

Willem Toorop writes: > Should RFC 8767 stale data be ranked differently than fresh data? > Should EDNS Client Subnet play into ranking? > > I like your thinking! Yes, fresh data should replace stale data in > resolver caches It's basically A- in your draft's hierarchy, I think, though th

Re: [DNSOP] I-D Action: draft-ietf-dnsop-compact-denial-of-existence-03.txt

Shumon Huque writes: > The draft allows (but does not proscribe) NXDOMAIN to be inserted > into the Rcode for non DNSSEC enabled responses. I guess the main > reason for not being proscriptive was what I mentioned - there were > deployments in the field that didn't. But I'm amenable to tightening >

Re: [DNSOP] I-D Action: draft-ietf-dnsop-compact-denial-of-existence-03.txt

Shumon Huque writes: > I've been told the other way is confusing too - we get a different response > depending on the value of the DO flag. Since it isn't clear to me which way > is the least worse, I'm fine with leaving the text as is. Of course, we already get different responses depending on wh

Re: [DNSOP] I-D Action: draft-ietf-dnsop-compact-denial-of-existence-03.txt

Stephane Bortzmeyer writes: > > One current implementation does not differentiate DO=0 vs 1 and gives the > > same NODATA answer for both cases. > > Yes. I see no practical problem with that but, from a philosophical > point of view, it disturbs me. Naive clients may make wrong > conclusions from

Re: [DNSOP] [Ext] About key tags

Mark Andrews writes: > Ed, your reasoning is off. The point of forbidding is to allow the > validator to safely stop as soon as possible when it is under > attack. Uh? Why can't any DNS server safely stop as soon as possible when it is under attack? Count me in the "we don't need a protocol cha

[DNSOP] Extensible from the start - was - Re: [Ext] Re: DNSOPComments on draft-dnsop-deleg-00.txt - section 1

Edward Lewis writes: > Is there going to be an assumed "standard set" of keywords? Yes. Currently it specifies using the Service Parameter Keys registry: https://www.iana.org/assignments/dns-svcb/dns-svcb.xhtml > (And a defined manner to know how to deal with > unknown-to-the-receiver keywords.

Re: [DNSOP] Documenting DELEG design trade-offs

Philip Homburg writes: > DNSSEC has a lot of moving parts that needed to be in place compared > to DoH. Yes, certainly there are many differences between the two, some of which speak to the challenges of DELEG when looked at through the lens of DNSSEC. The core point was that motivation as a fact

Re: [DNSOP] Documenting DELEG design trade-offs

Paul Wouters writes: > I tried to show some of of these in my "Costs of deleg" slide. > A new RRtype has a fairly big cost meassures in years, both in > terms of DNS software, DNS deployment and worse, in Registrar > deployment for Registrant webui elements. Unfortunately, I know of no good way to

[DNSOP] Two points by Joe - was Re: [Ext] Re: DELEG and parent only resolution

Edward Lewis writes: > The impact on the registration system wasn’t raised at the table. Not entirely true. We did recognize that there'd need to be an EPP draft too. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-qdcount-is-one-01

Mark Andrews writes: > It’s a couple of lines of code in a nameserver to support QCOUNT=0. > It will take more time debating this than it took to implement > support for QCOUNT=0. Miek Gieben writes: > yes, please, the amount of code that duplicates checks for > QDCOUNT!=1 is staggering, and that

Re: [DNSOP] [dnsdir] [Ext] Dnsdir last call review of draft-ietf-dnsop-dns-error-reporting-06

> > in responses where there client didn't even use EDNS. 6891 permits > > this, > > RFC6891 explicitly forbids this with a MUST NOT. Ugh, you know, this is exactly what I told you in the hall yesterday but then I actually went and looked when I was writing my last reply. I wanted to emphasize a

Re: [DNSOP] [Ext] [dnsdir] Dnsdir last call review of draft-ietf-dnsop-dns-error-reporting-06

Roy Arends writes: > > Is this a novel risk presented by the proposal? Any more than, say, a > > random subdomain attack targeted directly at the agent domain? > > Nope, not a novel risk, but it was added at the request of some > security focused folk. Fair enough, but out of your own self-int

Re: [DNSOP] [dnsdir] [Ext] Dnsdir last call review of draft-ietf-dnsop-dns-error-reporting-06

Roy Arends via dnsdir writes: > Why would you, as an implementor, guess? Because you've only said only "responses", and then also provided a document that largely talked about DNSSEC as examples. Clarifying that is not intended only for DNSSEC reporting would be great. If you really mean "all r

Re: [DNSOP] [dnsdir] Dnsdir last call review of draft-ietf-dnsop-dns-error-reporting-06

One last bit of wondering I have is about this paragraph from Security Considerations: "This method can be abused by intentionally deploying broken zones with agent domains that are delegated to victims. This is particularly effective when DNS requests that trigger error messages are sent thro

Re: [DNSOP] New Version Notification for draft-yorgos-dnsop-dry-run-dnssec-01.txt

I am not in favour of yet another change to DNSSEC bits without a much larger demonstration of value than what this proposal has. It's not that I think this one has no value, I just think that the bulk of its value is achievable via other mechanisms. While it is true that there could be more user

Re: [DNSOP] The DNSOP WG has placed draft-rebs-dnsop-svcb-dane in state "Call For Adoption By WG Issued"

I'm in favour of working group adoption for this draft. It provides important clarifications for the interaction of DANE and SVCB. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefully ready for WG Last Call

Thanks for the work on this, Stephane, Ralph, and Paul. Could you please clarify explicitly what should happen in the case of encountering CNAMEs? Or DNAMEs? The way I read it, at least for CNAMEs, is that you just keep prepending labels to the ANCESTOR name so encountering the CNAME is in pract

Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

I support adoption, with the caveat that either the draft name should be updated with something like s/powerbind/delegation-only-dnssec/, or the draft should describe why it is being called "powerbind". ___ DNSOP mailing list DNSOP@ietf.org https://www.i

Re: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)

Thank you very much for your review, Ben. Benjamin Kaduk via Datatracker writes: >For a comprehensive treatment of DNS terms, please see [RFC8499]. > > (side note: I myself would not use the word "comprehensive" when it > explicitly says that "some DNS-related terms are interpreted quite > di

Re: [DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)

Thank you for the review, Roman. Roman Danyliw via Datatracker writes: > * I agree with Mirja, Section 8 is more informative than what is > alluded to the paragraph starting with “Several recursive resolvers > …” in Section 3, and IMO is worth keeping. I've already updated the GitHub copy in resp

Re: [DNSOP] Adam Roach's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)

Thank you very much for your review, Adam. I have incorporated your feedback into the document (which is not yet pushed to datatracker). Here's the diff: https://github.com/vttale/serve-stale/commit/3ae0f4e5f79e0b326608beaa77b74a1efe62663c Adam Roach via Datatracker writes: > The addition of wh

Re: [DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)

Dave Lawrence writes: > We had a lot of back-and-forth in the working group about > normative language in this document, and but for the Standards Action > section. Huh, I clearly had a slipping brain clutch in the middle of that sentence when it came to the final phrase. I think I had

Re: [DNSOP] Mirja Kühlewind's No Objection on draft-ietf-dnsop-serve-stale-09: (with COMMENT)

Thank you very much for your review, Mirja. > 1) It seems to me that this sentence in section 7 should/could > actually be phrased as a normative requirement in this document: "it > is not necessary that every client request needs to trigger a new > lookup flow in the presence of stale data, [...]

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-09.txt

Benjamin Kaduk writes: > Isn't there still some latent risk of such fielded implementations > that would be incompatible with this change if it ever did show up > on the wire? There's always some risk with any change, right? I'm not trying to be flatly dismissive of the concern. I do, however, f

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-09.txt

internet-dra...@ietf.org writes: > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-serve-stale-09 This revision addressed the one remaining outstanding issue that Brian Carpenter raised in the Gen-ART Last Call Review. The following text was

Re: [DNSOP] draft-ietf-dnsop-serve-stale: lightly-suggested ranges

Paul Hoffman writes: > Greetings again. draft-ietf-dnsop-serve-stale has a few places where > it suggest ranges for values, but these suggestions are vague. "Vague"? They give hard numbers with the intended flexibility for the considerations that might go into them. > Could be: > Values SH

Re: [DNSOP] draft-ietf-dnsop-serve-stale: returning stale answers when faced with SERVFAIL responses

Paul Hoffman writes: >However, implementations MUST NOT send stale data if they have received >any answer from an authoritative server. I personally strongly disagree with this. ServFail is a signal from the authoritative operator that something is amiss, and is in practical terms is not

Re: [DNSOP] ANAME high-level benefit question

Brian Dickson writes: > Have any "closed system" implementations of non-standard apex-CNAME > hacks, committed publicly to neutral ANAME operations, presuming > ANAME as currently envisioned? I.e. If each such provider will > ONLY support ANAME with targets on their own infrastructure, I don't > t

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-05.txt

Davey Song writes: > Normally end user have more than one configured resolvers. If only > one resolver experience the outage and serve the stale data, could > the user tell which resolver have more refreshed data ? Not in the usual resolution process, no. Whether the user's system will fall back

Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

On Tue, Mar 26, 2019 at 12:48 PM Tony Finch wrote: >> I think the suggested max stale timer of 7 days is excessive. The aim is >> to cope with an outage, so I think 1 day is much more reasonable (though I >> have configured my servers with a 1 hour limit). Olli Vanhoja writes: > I agree. At least

Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

Ray Bellis writes: > Serve stael must not become a vector whereby malware can keep its C&C > systems artificially alive even if the parent has removed the C&C domain > name. I wholeheartedly agree with this ideal, and am very open to considering text improvements. The document already has guida

Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

bert hubert writes: > I too object. This is partially due to the apparently unresolved IPR issue > from Akamai, who are known not to be shy asserting their IPR. This is definitely a problem. Even though Akamai had previously agreed to specify under what IETF-acceptable terms the IPR would be mad

Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

Paul Vixie writes: > i would withdraw that objection if this draft incorporates section 2 of > https://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00, to wit: I always liked resimprove. Warren and I were talking about it, and if you would like we'd be quite happy to pick it up and get it m

Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

Thank you very much for the feedback, Jinmei. Combined with previous changes we made following the other messages on the draft we expect to republish it before the Monday IETF 104 submission deadline, after one last review by all of the co-authors. Jinmei: >> The definition of TTL in [RFC1035]

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt [and 1 more messages]

Jinmei: > I also found it confusing on my fresh re-read of serve-stale-03 in > that the "example method" section contains normative descriptions > using RFC2119 keywords. You're in good company in that co-author Puneet has voiced the same opinion. My own take is that it's appropriate because if

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

Joe Abley writes: > if you can find a set of DNS authority servers that silently > discards a particular kind of query, sending such queries through > resolvers that are known to support serve-stale might suppress other > queries and trigger the serve-stale behaviour even though the > authority ser

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

Tony Finch writes: > This sounds like it will lead to stale answers being given instead of > re-trying other potentially working servers. The document is explicit that you need to keep trying to get an answer, so if an implementation is not retrying other potentially working servers that is its ow

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

Tony Finch writes: > If the zone has a mixture of lame and working servers, the lame servers > should not trigger serve-stale, because the resolver still needs to try > asking the working servers. Yes, complete agreement. That is the thrust of what the document says.

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

Christopher Morrow writes: > My point is that the recursive reoslver has no idea why an authoritative > is unreachable and that doing anything like sending stale records is > going to cause unintended problems. Given the operational benefit that has already been observed in production with serve-

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

Paul Wouters writes: > I am a bit confused here. The goal of the draft is to keep data past > the TTL in case you cannot reach the authoritative servers during a > DDOS attack. There are many different failure modes in operating the DNS and the goal of this draft has been to accommodate the ones t

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

Paul Wouters writes: > In the non-DDOS case, the auth server is reachable and none of the data > is getting additional TTL added: > > Answers from authoritative servers that have a DNS Response Code of > either 0 (NOERROR) or 3 (NXDOMAIN) MUST be considered to have > refreshed the data

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

Paul Vixie writes: > On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote: > > can I ask, what happens when a domain is intentionally down though? For > > instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the > > master/shadow NS go down, hard. All public auth servers ev

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt [and 1 more messages]

Paul Hoffman writes: > I'm not sure a standards track document that updates RFC 1034/1035 > should be recommending a minimum TTL. As previously noted, we're making no such recommendation and that will be clarified. The first definition of "resolution recheck timer" in section 5 does already say

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

Bob Harold writes: > Will the "resolution recheck timer" cause ttl's less than the timer > to be effectively lengthened, by refusing to look them up again? I > think 'serve-stale' should focus on the situation where the auth > server is not available, and not change the handling of short ttl's. >

Re: [DNSOP] Review of draft-ietf-dnsop-serve-stale-02.txt

Thanks very much for the review, Mukund! Puneet has already incorporated the editorial feedback into the GitHub copy. Mukund Sivaraman writes: >> "It is predicated on the observation that authoritative server >> unavailability can cause outages even when the underlying data >> those servers

Re: [DNSOP] Informal meeting about root KSK futures at IETF 103

Dave Lawrence writes: > Count me as another, for that very reason. When I first saw Paul's > message I thought, "oh that's a shame" but figured it to be fairly > set. If there's flexibility for making the meeting happen earlier in > the week, I'd be i

Re: [DNSOP] Informal meeting about root KSK futures at IETF 103

Joe Abley writes: > I'm sure I'm not the only person planning to fly out from Bangkok on > Friday morning, given that there are no working group meetings > scheduled on that day. Count me as another, for that very reason. When I first saw Paul's message I thought, "oh that's a shame" but figured

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-02.txt

internet-dra...@ietf.org writes: > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-serve-stale-02 Here's a summary of the functional updates: Puneet Sood @ Google added as co-author in the short-lived -01. A second, simpler EDNS option for s

Re: [DNSOP] state management related to TTL

Paul, apologies for taking nearly a year to recall this message and respond to it: https://www.ietf.org/mail-archive/web/dnsop/current/msg21367.html I'll trim down citation material for response, but that's not to mean the parts I am not responding to are ignored. For example, I pretty much agre

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-13.txt

Warren Kumari writes: > On Wed, Jul 18, 2018 at 9:36 AM Warren Kumari wrote: > > > > The authors are more than happy to change the name to that... > but we would really really appreciate more comments / review. I support publication as-is, existing title and all. It is a valuable document a

Re: [DNSOP] SRV and HTTP

Dave Lawrence writes: > Mark Nottingham writes: > > I'll start collecting. How about Tuesday, say 6:45-7:45pm? > > Last session ends at 6:20 and social starts at 7, not sure how late > the last bus (if any?) will be leaving the hotel. Nevermind, walking distance to so

Re: [DNSOP] SRV and HTTP

Mark Nottingham writes: > I'll start collecting. How about Tuesday, say 6:45-7:45pm? Last session ends at 6:20 and social starts at 7, not sure how late the last bus (if any?) will be leaving the hotel. ___ DNSOP mailing list DNSOP@ietf.org https://www.

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

Joe Abley writes: >but collapsing the address selection back to the extent that you can > avoid name resolution at all seems like a better end goal. > > So rather than resolverless operation, think about resolutionless or > nameless, eliminating the DNS as unnecessary overhead. > > Perhaps I ha

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

Tim Wicinski writes: > "Are you trying to re-invent DNSSEC for people who don't want to deploy > DNSSEC?" > > My magic 8-ball says "signs point to Yes" I don't grok how y'all got "trying to re-invent DNSSEC" out of this, so this is sure to be an entertaining discussion. _

Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

Paul Vixie writes: > > For example www.example.com pushes you a > > record for img1.example.com . Should you use > > it? > > no. sibling names might be delegation points. kashpureff taught us this > in 1996 or so, and kaminsky reinforced that

Re: [DNSOP] re original_transport indicator

Martin Thomson writes: > I think that a better choice is message/dns. I personally prefer this to dns-udpwireformat / dns-wireformat ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Re: [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

Martin Thomson writes: > Right now, abandon draft-ietf-dnsop-dns-wireformat-http. But I'll > concede that I'm probably missing something. I think that's right. -05 with the original_transport optional parameter accommodates the aims of that other draft. _

Re: [DNSOP] [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

Martin Thomson writes: > If I understand your response (not sure that I do), that seems pretty > academic and not at all persuasive. For instance, if a client cared > about testing TCP capabilities, it can always do its own resolution. That testing TCP capabilities part is a distraction from the

Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt

Davey Song writes: > To keep the transparency of DOH proxy, the proxy server should use > the same transport as the proxy client receive queries from > stub-resolver, transports patterns like UDP-DOH-UDP, and > TCP-DOH-TCP. So the proxy client should signal the proxy server the > initial transport

Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt

Davey Song writes: > Is a media type "application/dns-tcpwireformat" acceptable Without yet having (re-)read the draft, I'm unclear on what benefit this media type is bringing over dns-udpwireformat, since the only difference presumably is explicitly adding the two octets of a content-length <= 65

[DNSOP] Notice to dnsop: doh @ IETF 101

Please be aware that at the doh meeting on Thursday afternoon in London there will be a summary discussion of the state of https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ with the expected outcome being soon moving it on to working group last call. _

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

Paul Vixie writes: > i'm of the opposite view. we should not change behaviour without > explicit signaling. if that means it takes 10 years to reach 50% > penetration, like EDNS did, then that's the cost of doing business. Just so I'm clear, am I understanding correctly from this that you believ

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

tale: >> It is significantly less operationally beneficial if it demands EDNS. Paul, and echoed by Paul: > i'm of the opposite view. we should not change behaviour without > explicit signaling. I've opened this as an issue to track toward WG consensus and suspect that, unless strong consensus for

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

Alexander Mayrhofer writes: > I'm torn on the question whether or not stale data should be served > (without signaling, in that case) when the request does *not* > contain an OPT request. I'm personally not torn on this; for me the whole point of implementing this functionality is to add resilienc

Re: [DNSOP] Clarifying referrals (#35)

Evan Hunt writes: > Okay. I haven't encountered a resolver that propgates REFUSED from the > authority to the stub. If there is such a beast, then IMHO that, not the > authority, is the one that's mis-using REFUSED; REFUSED only makes sense on > a hop-by-hop basis. Very much agree. I'd be surpri

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

Bob Harold writes: > I am a little concerned about yet another option that the client > might want to send with every query. Can the existence of *any* > EDNS option from the client be taken to mean that EDNS options are > understood in general, and the resolver is ok to respond with this > ENDS o

Re: [DNSOP] DINRG update

On Nov 13, 2017, at 8:12 AM, Melinda Shore wrote: > With regrets to the fine folks of dnsop, we've scheduled the > dinrg side meeting from 9:30 - 12:00 this morning. We realize > that there are many people in the dns community who are > interested in decentralized approaches to naming but schedul

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

Dave Lawrence writes: > The main changes, based on previous feedback, are: > > * Clarifying what the action is for Standards Track; > * Describing the algorithm previously proposed (and still included) as > one example way of achieving the goals; and, > * Adding a rough pr

Re: [DNSOP] I-D Action: draft-woodworth-bulk-rr-07.txt

internet-dra...@ietf.org writes: > Title : BULK DNS Resource Records > Filename: draft-woodworth-bulk-rr-07.txt Changes are here: https://www.ietf.org/rfcdiff?url1=draft-woodworth-bulk-rr-06&url2=draft-woodworth-bulk-rr-07 The primary differences are to add a bit mo

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

internet-dra...@ietf.org writes: > Title : Serving Stale Data to Improve DNS Resiliency > Filename: draft-ietf-dnsop-serve-stale-00.txt This is the same as draft-tale-dnsop-serve-stale-02, only renamed for WG adoption. The differences between -01 and -02 are here: h

Re: [DNSOP] I-D Action: draft-woodworth-bulk-rr-07.txt

Bob Harold writes: > I don't understand this section: > > 5.1.1. On-the-fly Signatures > ... >One possibly mitigation for addressing the risk of keeping the zone >signing key online would be to continue to keep the key for signing >positive answers offline and introduce a second key f

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-edns-isp-location-02.txt

Have you had any feedback from authority server implementers who are interested in using this? I'm having a hard time picturing many CDNs wanting to switch, in no small part because geo is not the only goal of mapping. The < COUNTRY, AREA, ISP > tuple that is defined is insufficient. __

Re: [DNSOP] comments on draft-tale-dnsop-serve-stale-00

Jinmei writes: > In this suggested text I've made two unrelated changes: > > - s/, where a hostname changed/when a hostname changed/ > sine the original phrase was a bit confusing to me (it could read as > if it talked about something about the BIND implementation, but it's > actually talkin

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsext-multi-qtypes-04.txt

On 7/4/17 6:13 AM, Paul Wouters wrote: >> Although, we should also be a bit careful not to create a new ANY >> type query that will get abused for amplification, so it should >> really all have source verified IP transports (DNS-COOKIES, TCP, etc) Ray Bellis writes: > I'd rather not constraint thi

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsext-multi-qtypes-04.txt

Ray Bellis writes: > This is just a "keep alive" so as to keep this draft in consideration as > one of the multiple solutions in this problem space while DNSOP decides > whether this is a problem worth solving. > > I still think it's the most elegant of those proposed ;-) I whole-heartedly agree,

Re: [DNSOP] comments on draft-tale-dnsop-serve-stale-00

Thank you for the feedback, Jinmei! Now that Akamai finally posted its IPR notice we can work on moving it forward. We plan on asking for WG adoption now that -01 is up. https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/ Jinmei wrote: > - I suspect it should include 'Updates: 1035 (

Re: [DNSOP] draft-tale-dnsop-edns-clientid

On 30/03/2017 09:52, Bob Harold wrote: >> Just a thought - would it be better to have two different EDNS0 options >> that carry an IP, or to have one EDNS0 option that carries both an IP >> and a 'type', and allow multiples of that option in a packet? Ray Bellis writes: > IMHO, two options is bett

Re: [DNSOP] draft-tale-dnsop-edns-clientid

Ray Bellis writes: > It's effectively the same argument about TXT records - there's plenty of > things that use TXT format, but it's preferred that separate RRTYPEs are > used to indicate the use case. If that's the position the WG would like to take, I'd be fine with that. __

Re: [DNSOP] draft-tale-dnsop-edns-clientid

Ray Bellis writes: > I therefore think there's a simple test here: [...] Well yes, but there's another simple test, the limited Expert Review guidance against duplicate functionality. Both xpf and clientid provide the functionality of conveying an IP address in an EDNS0 option. _

Re: [DNSOP] [Errata Rejected] RFC7871 (4736)

RFC Errata System writes: > http://www.rfc-editor.org/errata_search.php?rfc=7871&eid=4736 > Status: Rejected > --VERIFIER NOTES-- > Internet Software Consortium occurs only in the acknowledgements and > while incorrect now it is generally the perogative of the authors to > include in this section

Re: [DNSOP] draft-tale-dnsop-serve-stale

Paul Vixie writes: > speaking of resimprove, i hope you'll include in this draft the idea of > using delegation-TTL as a delegation-recheck interval, and using an > authoritative NXDOMAIN from the delegator as proof that you need to run > an "rm -rf" in your cache. I definitely like the latter ide

Re: [DNSOP] draft-tale-dnsop-edns-clientid

Peter van Dijk writes: > On 28 Mar 2017, at 16:35, Dave Lawrence wrote: > > I grant that there is reason for pause because both Nominum and > > OpenDNS have squatted code points which have duplicate functionality. > > Should this squatting perhaps be documented in the

Re: [DNSOP] draft-tale-dnsop-edns-clientid

Ray Bellis writes: > I'm somewhat philosophically opposed to anything that injects client > related information such that it's shared between different parties. Understandable. I honestly have similar reservations. One thing that clouds this a little, as far as our draft is concerned, is that th

Re: [DNSOP] draft-tale-dnsop-serve-stale

Pieter Lexis writes: > I feel that the authors should attempt to describe the goal of the > algorithm and suggest possible limits and describe pitfalls rather > than describing the exact algorithm to use. I confess I'm a bit flummoxed by this comment, as I believe the document already does describ

Re: [DNSOP] draft-tale-dnsop-edns-clientid

Olafur Gudmundsson writes: > Strictly speaking the draft was never formally submitted via IANA. This is part of the problem with documentation. At least one natural entry point for the process, the IANA assignments page, doesn't indicate how to initiate expert review. https://www.iana.org/assig

[DNSOP] draft-tale-dnsop-edns-clientid

One of the two drafts I wanted to talk about at dnsop today for WG adoption was "Client ID in Forwarded DNS Queries": https://datatracker.ietf.org/doc/draft-tale-dnsop-edns0-clientid/ The core idea of this document is to be able to provide device-specific identification in an EDNS option sent to a

[DNSOP] draft-tale-dnsop-serve-stale

One of the two drafts I wanted to talk about at dnsop today for WG adoption was "Serving Stale Data to Improve DNS Resiliency": https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/ In short, this describes a method for increasing DNS resiliency by treating the inability to refresh data a

[DNSOP] New Version Notification for draft-tale-dnsop-serve-stale-00.txt

FYI. Some of you may be aware that there are at least a couple of patents in this area (US8972580 and US8832283), and we'll be handling them through the usual IETF IPR disclosure process. --- start of forwarded message (RFC 934 encapsulation) --- From: Subject: New Version Notification f

Re: [DNSOP] Updated NSEC5 protocol spec and paper

Paul Hoffman writes: > Is there a community of zone admins who want this so much that they > won't start signing until it exists? I think that question is a little extreme and need not go that far to determine whether something is worthwhile to pursue. My interest in NSEC5 is largely around the

Re: [DNSOP] Updated NSEC5 protocol spec and paper

Phillip Hallam-Baker writes: > There are two reasons for splitting out the VRF [...] Thanks, Phill! Those were our thoughts as well. Though the VRF appendix is still included in -04, the VRF document has already been started. It is planned that the appendix will disappear (to be replaced with

[DNSOP] Client ID in Forwarded DNS Queries

FYI. --- start of forwarded message (RFC 934 encapsulation) --- From: Subject: New Version Notification for draft-tale-dnsop-edns0-clientid-00.txt Date: Wed, 15 Feb 2017 13:56:46 -0800 A new version of I-D, draft-tale-dnsop-edns0-clientid-00.txt has been successfully submitted by David

Re: [DNSOP] naming and shaming broken implementations

On 22 Jun 2016, at 11:13, Stephane Bortzmeyer wrote: > It is not "fun", it is the only way to have broken implementations > (Akamai, djbdns) fixed. If we do not name them, they will continue forever. Even ignoring the loaded "shaming" terminology that Jim added to this thread, I still have to dis

  1   2   >