Re: [DNSOP] Working Group Last Call: draft-ietf-dnsop-nxdomain-cut

At Thu, 26 May 2016 14:53:06 +0200, Tim Wicinski wrote: > There has been some good discussion from the working group on the list, > and with the recent discussion on root server tar pitting, it makes > sense to move this document along. > > This starts a Working Group Last

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-02.txt

At Tue, 10 May 2016 15:04:56 +0200, Stephane Bortzmeyer wrote: > > This is true, but I suspect it would be pretty easy for this type > > of attacker to circumvent the effect if and when the nxdomain-cut > > behavior is more widely deployed. An attacker for the '.wf'

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-02.txt

At Mon, 25 Apr 2016 21:39:32 +0200, Stephane Bortzmeyer wrote: > Stephane Bortzmeyer wrote > a message of 17 lines which said: > > > > Title : NXDOMAIN really means there is nothing > > > underneath > > > Authors :

Re: [DNSOP] Call for Adoption for draft-fujiwara-dnsop-nsec-aggressiveuse

At Mon, 09 May 2016 19:46:01 +0900 (JST), fujiw...@jprs.co.jp wrote: > >> >When aggressive use is enabled, regardless of description of > >> >Section 4.5 of [RFC4035], it is possible to send a positive response > >> >immediately when the name in question matches a NSEC/NSEC3 RRs in

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-isp-ip6rdns

At Wed, 4 May 2016 11:43:16 -0400, Ted Lemon wrote: > Jinmei-san, with all due respect, I think that you are missing the mark > here. First off, I didn't intend to be opposed to providing reverse mappings per se. If my comments read that way, that was because of my poor

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-isp-ip6rdns

At Mon, 25 Apr 2016 16:50:42 -0400, Tim Wicinski wrote: > This starts a Working Group Last Call for draft-ietf-dnsop-isp-ip6rdns > > Current versions of the draft is available here: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-isp-ip6rdns/ > > Please review the

Re: [DNSOP] Call for Adoption for draft-fujiwara-dnsop-nsec-aggressiveuse

At Sun, 1 May 2016 19:20:33 +0200, Matthijs Mekking wrote: > - I don't see why setting the CD bit is an indication that NSEC(3) > aggressive usage should not be used. Could you elaborate on that? > >> > >> I am still hoping that someone could response to this :)

Re: [DNSOP] Call for Adoption for draft-fujiwara-dnsop-nsec-aggressiveuse

At Fri, 29 Apr 2016 10:09:30 +0200, Matthijs Mekking wrote: > >> - I don't see why setting the CD bit is an indication that NSEC(3) > >> aggressive usage should not be used. Could you elaborate on that? > > I am still hoping that someone could response to this :)

Re: [DNSOP] Call for Adoption for draft-fujiwara-dnsop-nsec-aggressiveuse

At Sun, 10 Apr 2016 10:18:11 -0400, Tim Wicinski wrote: > This starts a Call for Adoption for Aggressive use of NSEC/NSEC3 > draft-fujiwara-dnsop-nsec-aggressiveuse > > The draft is available here: > > https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/

Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-client-subnet-07.txt

At Tue, 22 Mar 2016 01:15:48 +0530, Mukund Sivaraman wrote: > > > (1) Section 7.2.1. Authoritative Nameserver: > > I'm confused about the revised Section 7.2.1 regarding overlapping > > prefixes. The 07 version of the draft now states: > > > >[...] Because it can't be

Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-client-subnet-07.txt

At Mon, 21 Mar 2016 19:21:59 +0530, Mukund Sivaraman wrote: > (1) Section 7.2.1. Authoritative Nameserver: > > > When deaggregating to correct the overlap, prefix lengths should be > > optimized to use the minimum necessary to cover the address space, in > > order to reduce the

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

At Thu, 17 Mar 2016 10:55:09 -0700, Paul Vixie wrote: > we should describe the positive benefits to the dns system (without > mentioning any benefit or cost to any implementor or implementation style). > > "As implied by STD 13 and as made explicit herein, an authoritative >

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

At Wed, 16 Mar 2016 14:41:36 +0100, Stephane Bortzmeyer wrote: > > > you have to do the "rm -rf $qname" when you receive the nxdomain. > > > > The draft says you have to do this, yes. > > No, it does not. draft-vixie-dnsext-resimprove-00 did but >

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

At Tue, 15 Mar 2016 13:34:07 +, Ted Lemon wrote: > >> If this observation is correct, I think what we should first agree on > >> is the real intent of the draft: > >> A. nxdomain-cut is "the correct behavior" and implementations SHOULD > >>generally support the

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

At Mon, 14 Mar 2016 16:31:47 +, Ted Lemon wrote: > > No, it does not. > > Yes, it does. You are not calling it implementation advice, but > that's what it is. A normative requirement to do a particular > optimization is nothing other than implementation advice. I

Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.

At Tue, 01 Mar 2016 08:24:05 +1100, Mark Andrews wrote: > > > >Please no. (Ed might disagree with me on this.) I think every document > > > >that talks about the DNS in the IETF is about the IANA-administered DNS > > > >except where loudly noted. > > > > > > I very much disagree

Re: [DNSOP] Updated cheese-shop.

At Mon, 29 Feb 2016 16:54:28 +, Warren Kumari wrote: > > - Section 1 > > > >The title of this draft comes from a famous Monty Python skit - "The > >Cheese Shop". There are some useful parallels between this problem > >and the skit - watching the skit is

Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.

At Mon, 29 Feb 2016 16:54:49 +, Edward Lewis wrote: > >Please no. (Ed might disagree with me on this.) I think every document > >that talks about the DNS in the IETF is about the IANA-administered DNS > >except where loudly noted. > > I very much disagree coming from

Re: [DNSOP] Updated cheese-shop.

At Thu, 25 Feb 2016 04:58:11 +, Warren Kumari wrote: > We have recently updated "Believing NSEC records in the DNS root" ( > https://tools.ietf.org/html/draft-wkumari-dnsop-cheese-shop-01). > > This incorporates some comments, but also does a better job of explaining > the

Re: [DNSOP] New version of draft-ietf-dnsop-resolver-priming

At Wed, 03 Feb 2016 07:49:22 -0800, "Paul Hoffman" wrote: > >> The priming response is expected to have an RCODE of NOERROR, and to > >> have the > >> AA bit set. Also, it is expected to have an NS RRSet in the Answer > >> section (because the > >> NS RRSet originates from

Re: [DNSOP] Cache utilization review and suggestion for EDNS client-subnet

At Wed, 3 Feb 2016 09:31:31 +0530, Mukund Sivaraman wrote: > It's possibly still not too late for many of these issues to be > addressed by behavioral descriptions in the draft (without any protocol > changes). I agree at least *some* of the issues have to be addressed before

Re: [DNSOP] Cache utilization review and suggestion for EDNS client-subnet

At Mon, 28 Dec 2015 07:59:14 +0530, Mukund Sivaraman wrote: > https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-06 > > One of the main concerns while implementing EDNS client-subnet is about > keeping the size of cache small and in check. It seems cache handling > for

Re: [DNSOP] New version of draft-ietf-dnsop-resolver-priming

At Fri, 22 Jan 2016 09:28:21 -0800, "Paul Hoffman" wrote: > > Right, but there's no requirement what to be put in the additional > > section, so this "expected property" relies on a particular > > implementation behavior (rather than something we can expect from any > >

Re: [DNSOP] Call for Adoption: draft-fanf-dnsop-rfc2317bis

At Mon, 18 Jan 2016 17:56:24 +0200, Andreas Gustafsson wrote: > > Can you point to specific wording that needs changing? > > Mainly, the "Updates: 2136", and each instance of "UPDATE client". > For example, in the Introduction, you could change > >While these methods

Re: [DNSOP] New version of draft-ietf-dnsop-resolver-priming

At Thu, 14 Jan 2016 17:29:04 -0800, "Paul Hoffman" wrote: > > Here are my comments on the 06 version: > > > > - Section 3.1 > > > > [...] This would be when the resolver starts with an empty cache, > > and when one or more of the NS records for the root servers has > >

Re: [DNSOP] New version of draft-ietf-dnsop-resolver-priming

At Wed, 13 Jan 2016 13:53:06 -0800, "Paul Hoffman" wrote: > We'd really like folks to review it, particularly because this is such a > large change from earlier versions. The document is still definitely > open for discussion, and if there is consensus to reverse some of

Re: [DNSOP] Call for Adoption: draft-fanf-dnsop-rfc2317bis

At Wed, 13 Jan 2016 10:13:42 +, Tony Finch wrote: > > - I wonder why its intended status is standards track. It generally > > just talks about operational techniques rather than describe some > > new protocol, so a BCP seems to be more appropriate (in fact RFC2317 > >

Re: [DNSOP] Call for Adoption: draft-fanf-dnsop-rfc2317bis

At Sun, 13 Dec 2015 22:08:13 -0500, Tim Wicinski wrote: > This starts a Call for Adoption for draft-fanf-dnsop-rfc2317bis > > The draft is available here: > https://datatracker.ietf.org/doc/draft-fanf-dnsop-rfc2317bis/ > > Please review this draft to see if you think it is

Re: [DNSOP] ECS badly formatted ADDRESS field

At Thu, 24 Dec 2015 08:01:14 +0530, Mukund Sivaraman wrote: > https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-06 > > says in Section 6. Option Format: > > > o A server receiving an ECS option that uses more ADDRESS octets > > than are needed, or that has

Re: [DNSOP] ECS badly formatted ADDRESS field

At Thu, 24 Dec 2015 08:33:27 +0530, Mukund Sivaraman wrote: > > I have a related clarification. What if the ADDRESS field has fewer > > octets than than SOURCE PREFIX-LENGTH indicates? Should REFUSED or > > FORMERR be returned in this case? The draft must clarify this if it's > >

Re: [DNSOP] Last Call: (Client Subnet in DNS Queries) to Informational RFC

At Mon, 07 Dec 2015 11:07:59 -0800, The IESG wrote: > The IESG has received a request from the Domain Name System Operations WG > (dnsop) to consider the following document: > - 'Client Subnet in DNS Queries' >as Informational RFC > > The IESG plans to make a

Re: [DNSOP] Fw: New Version Notification for draft-shane-review-dns-over-http-00.txt

At Tue, 8 Dec 2015 14:11:16 +0100, Shane Kerr wrote: > As I mentioned a while ago, we have been working on a document to > describe the various ways of (ab)using HTTP to transmit DNS traffic. We > have finished a -00 draft, and I would appreciate it if you had a look >

Re: [DNSOP] comments on draft-bortzmeyer-dnsop-nxdomain-cut-00

At Sun, 29 Nov 2015 15:16:28 +0100, Stephane Bortzmeyer wrote: > > > That was exactly my point, and in that sense I'd say "SHOULD > > > delete" is redundant (and possibly imposes unnecessary > > > restrictions on implementations). > > > > Yes, I agree. The current description

Re: [DNSOP] comments on draft-bortzmeyer-dnsop-nxdomain-cut-00

At Sun, 22 Nov 2015 14:52:34 +0100, Stephane Bortzmeyer wrote: > > I've read draft-bortzmeyer-dnsop-nxdomain-cut-00 > > Do note that -01 will be out in the next days and there are > substantial changes. So, readers may prefer to wait 48h :-) Okay, I'm now referring to 01. >

Re: [DNSOP] Last Call: (DNS Transport over TCP - Implementation Requirements) to Internet Standard

At Mon, 23 Nov 2015 21:37:48 +0530, Mukund Sivaraman wrote: > While looking at a bug last week in an implementation of 5966bis and > AXFR, I found that there's no explicit mention of AXFR and out-of-order > replies. AXFR replies [RFC 5936] can arrive in several messages over > TCP.

Re: [DNSOP] Last Call: (DNS Transport over TCP - Implementation Requirements) to Internet Standard

At Tue, 24 Nov 2015 01:28:26 +0530, Mukund Sivaraman wrote: > > I'm not sure if I understand the concern...do you mean, for example, > > if an AXFR consists of the following 3 messages: > > > > Message1: beginning SOA and some RRs > > Message2: some intermediate RRs > > Message3:

[DNSOP] comments on draft-bortzmeyer-dnsop-nxdomain-cut-00

I've read draft-bortzmeyer-dnsop-nxdomain-cut-00 and have a few comments. (I support the basic idea of the proposal, btw) - Abstract: s/status code/response code/ This document states clearly that when a DNS resolver receives a response with status code NXDOMAIN, it means that the name in

Re: [DNSOP] comments on draft-jabley-dnsop-refuse-any-01

At Mon, 02 Nov 2015 11:47:26 -0500, "Joe Abley" wrote: > > - Section 3 > > > > ANY queries are sometimes used to help mine authoritative-only DNS > > servers for zone data, since they return all RRSets for a particular > > owner name. A DNS zone maintainer might prefer

[DNSOP] comments on draft-wessels-edns-key-tag-00

I've read draft-wessels-edns-key-tag-00. I think it's generally well written. I have a few small comments. - Sections 5.2.1 When the recursive server receives a query with the option set, the recursive server SHOULD set the edns-key-tag list for any outgoing iterative queries for that

[DNSOP] comments on draft-muks-dnsop-dns-message-checksums

I've read draft-muks-dnsop-dns-message-checksums-01. I think it's quite well written. I have a couple of comments about the draft: 1. I wonder whether this should be merged to draft-ietf-dnsop-cookies, as both try to solve the same/similar problems with quite similar approaches (note: I

[DNSOP] comments on draft-jabley-dnsop-refuse-any-01

I've read draft-jabley-dnsop-refuse-any-01. I have a few comments: - Section 3 ANY queries are sometimes used to help mine authoritative-only DNS servers for zone data, since they return all RRSets for a particular owner name. A DNS zone maintainer might prefer not to send full ANY

Re: [DNSOP] Closing out issues in draft-ietf-dnsop-resolver-priming

At Fri, 16 Oct 2015 17:07:27 +, "Darcy Kevin (FCA)" wrote: > Let's see, millions of full-service resolvers, times the > packet-count differential between UDP and TCP, times the average > reload/restart frequency of those full-service resolvers per > day/week/month.

Re: [DNSOP] Fwd: Working Group Last Call on draft-ietf-dnsop-5966bis

At Thu, 15 Oct 2015 13:20:29 +0100, Sara Dickinson wrote: > > I think the additional text for these sections has the same problem I > > pointed out before for the sending side of Section 8: [...] > > Point taken! How about the following: > > @@ -477,6 +477,12 @@ >specified

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-tcp-keepalive

At Thu, 15 Oct 2015 16:32:40 +0100, Sara Dickinson wrote: > My hesitation here is that if it is a SHOULD, then I think the > document would need a bit more detail regarding what ‘regularly’ > means, rather than simply saying the precise behaviour is out of > scope. I like to

Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-5966bis

At Wed, 14 Oct 2015 13:20:39 +0100, Sara Dickinson wrote: > > Section 8: is there benefit perhaps in including a matching SHOULD for the > > desired server behaviour? The paragraph notes that servers may respond in > > an unhelpful way if the message length and the message

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-tcp-keepalive

At Wed, 14 Oct 2015 11:55:02 +0100, Sara Dickinson wrote: > > I've read the 03 version of draft. It's very well written and I've > > not found any critical technical issues. So I basically think it's > > ready to ship. > > I have a couple of minor comments, which the authors

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-tcp-keepalive

On Mon, Oct 5, 2015 at 1:08 PM, Tim WIcinski wrote: > This starts a Working Group Last Call for > draft-ietf-dnsop-edns-tcp-keepalive > Current versions of the draft is available here: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/ > > The chairs

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-client-subnet

At Sun, 4 Oct 2015 11:49:22 -0400, Dave Lawrence wrote: > > It would be nicer if it can be clarified before advancing > > it: are we expecting newer implementations are developed based on this > > specification, or is this document literally for describing the > > current practice

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-client-subnet

On Wed, Sep 16, 2015 at 9:05 AM, Suzanne Woolf wrote: > This begins the working group last call for > draft-ietf-dnsop-edns-client-subnet, "Client Subnet in DNS Queries.” The > document has gotten significant feedback and the editors have worked hard to > document current

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-client-subnet

At Wed, 30 Sep 2015 16:32:07 -0400, "Joe Abley" wrote: > > I'm not necessarily opposed to advancing it, but I have one high level > > question. It would be nicer if it can be clarified before advancing > > it: are we expecting newer implementations are developed based on

Re: [DNSOP] Order of CNAME and A in Authoritative Reply.

At Wed, 12 Aug 2015 07:23:59 -0400, Andrew Sullivan a...@anvilwalrusden.com wrote: So we are in agreement that glibc's stub resolver is acting really dumb here? I think that's overstating it. It appears that glibc implemented the protocol according to a widely-held but (at least mostly)

Re: [DNSOP] Requesting review of draft-ietf-dnssd-mdns-dns-interop-01

At Fri, 7 Aug 2015 16:08:00 -0400, Ralph Droms rdroms.i...@gmail.com wrote: Hi - The dnssd chairs would like to get some reviews of draft-ietf-dnssd-mdns-dns-interop-01, On Interoperation of Labels Between mDNS and DNS, from dnsop participants. draft-ietf-dnssd-mdns-dns-interop-01 is

Re: [DNSOP] Seeking more WG Last Call review for draft-ietf-dnsop-cookies

At Sat, 8 Aug 2015 10:19:34 -0400, Donald Eastlake d3e...@gmail.com wrote: - Section 4.1 In order to maintain the security properties of this protocol, a client MUST NOT use the same Client Cookie value for requests to all servers. Specifically what does this mean? Does

Re: [DNSOP] Seeking more WG Last Call review fordraft-ietf-dnsop-cookies

At Wed, 05 Aug 2015 10:58:56 +0200, Ralf Weber d...@fl1ger.de wrote: But lets focus on the way the server handles cookies. I think I discussed that with you or Donald in Prague. There are two ways to do this so that each client gets a different cookie, which is what the draft suggest: [...]

Re: [DNSOP] Seeking more WG Last Call review for draft-ietf-dnsop-cookies

On Thu, Jul 16, 2015 at 12:52 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: secretary-hat on Greetings. The WG Last Call for draft-ietf-dnsop-cookies was supposed to end today, but it got extremely little review during the Last Call. It would be helpful to all of us if more people can review

Re: [DNSOP] comments on draft-ietf-dnsop-5966bis-02

At Mon, 3 Aug 2015 22:47:24 +, Wessels, Duane dwess...@verisign.com wrote: - Section 8 For reasons of efficiency, DNS clients and servers SHOULD transmit the two-octet length field, and the message described by that length field, in a single TCP segment. I suspect we

[DNSOP] comments on draft-ietf-dnsop-5966bis-02

I have a couple of minor comments on 5966bis-02: - Section 8 For reasons of efficiency, DNS clients and servers SHOULD transmit the two-octet length field, and the message described by that length field, in a single TCP segment. I suspect we cannot reasonably require this (with a

Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt

At Mon, 13 Jul 2015 22:01:29 -0400, Shumon Huque shu...@gmail.com wrote: While I see what it tries to say and don't disagree with it, I think this is not very accurate. In fact, NXDOMAIN for a.example.com says there is no such name *or any subdomain of it*. So it would still be usable

[DNSOP] comments about draft-wkumari-dnsop-trust-management-00

I have a few comments about draft-wkumari-dnsop-trust-management-00. (I hope I'm not repeating something already commented on) - I think the body (not appendix) of the draft should discuss what the TA maintainer is supposed to do. In its current document organization the main sections of the

Re: [DNSOP] relax the requirement for PTR records?

At Wed, 13 May 2015 09:02:25 -0700, Paul Vixie p...@redbarn.org wrote: I’m revising draft-howard-isp-ip6rdns again. Several folks have said something like, “There should be no expectation that a residential ISP will populate PTRs for all of its customers.” When I started this document,

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

At Tue, 12 May 2015 11:44:28 +0200, Warren Kumari war...@kumari.net wrote: In BIND, NTA's are set by an rndc command, but in other implementations they might be set up in a config file. If you have both a TA and an NTA for the same node in the same configuration, that would be sensible to

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

At Sat, 9 May 2015 15:08:11 +0200, Warren Kumari war...@kumari.net wrote: 1. In my very original comment on this matter: www.ietf.org/mail-archive/web/dnsop/current/msg12614.html I noted one other corner case, which we might also want to clarify: On a related note, there are

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

At Sat, 9 May 2015 18:50:28 +, Evan Hunt e...@isc.org wrote: Actually, weirdly enough, after I implemented NTA's in BIND, one of the very first applications somebody came up with for them was to temporarily disable DNSSEC validation by setting an NTA for .. This was seen as better than

Re: [DNSOP] Seeking discussion of draft-ietf-dnsop-cookies-01

At Wed, 6 May 2015 18:33:24 +, Evan Hunt e...@isc.org wrote: Can someone explain why we'd need the separate error codes based on the position of supporting them (i.e, not to persuade others on dropping them)? msg13984.html was basically written to argue against them, so it could

Re: [DNSOP] Seeking discussion of draft-ietf-dnsop-cookies-01

At Fri, 1 May 2015 23:21:30 +, Evan Hunt e...@isc.org wrote: The chief difference between the two is the presence of an error code field in Eastlake cookies; Andrews found it redundant/unnecessary (as discussed in https://www.ietf.org/mail-archive/web/dnsop/current/msg13984.html). The

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

At Tue, 5 May 2015 17:06:04 -0400, Warren Kumari war...@kumari.net wrote: ... and now I'm replying to the rest of the comments. Thanks, I've confirmed that my major and minor points are addressed in the 05 version. So I'm now basically fine with shipping it. Some non-blocking comments

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

At Mon, 27 Apr 2015 18:58:10 -0400, Tim Wicinski tjw.i...@gmail.com wrote: This starts a Working Group Last Call for Adoption for draft-ietf-dnsop-negative-trust-anchors (I guess this is for Publication, not for Adoption). Also, have we decided to publish it as an Informational document? I'm

Re: [DNSOP] draft-livingood-dnsop-negative-trust-anch...@tools.ietf.org

At Fri, 24 Apr 2015 23:59:22 -0400, Warren Kumari war...@kumari.net wrote: So, I have gone back through previous mail and it seems that this was the only email that got missed. Anyway, it seems that other folk also made similar comments, and so, by -03, we had addressed almost all of them.

Re: [DNSOP] New version of the DNS terminology draft

At Wed, 21 Jan 2015 07:54:18 -0800, Paul Hoffman paul.hoff...@vpnc.org wrote: On Jan 21, 2015, at 6:52 AM, Colm MacCárthaigh c...@allcosts.net wrote: RRSet: Are the RRs in an RRSet required to have different data? For types such as A//SRV/MX this makes sense, but maybe not for TXT. I

Re: [DNSOP] MIXFR: Smaller IXFR in the DNSSEC case

At Fri, 16 Jan 2015 09:27:27 +0100, Matthijs Mekking matth...@pletterpet.nl wrote: On the draft text (also related to this higher level point): The goal of this proposal is to allow small changes to be communicated over UDP, and remove as much redundant information from the

Re: [DNSOP] MIXFR: Smaller IXFR in the DNSSEC case

At Fri, 16 Jan 2015 10:51:17 -0500, Olafur Gudmundsson o...@ogud.com wrote: The goal of this proposal is to allow small changes to be communicated over UDP, and remove as much redundant information from the zone transfer as possible. We still need to send new RRSIGs, and since the

Re: [DNSOP] MIXFR: Smaller IXFR in the DNSSEC case

At Thu, 15 Jan 2015 11:13:10 +0100, Matthijs Mekking matth...@pletterpet.nl wrote: IXFR with DNSSEC is suddenly not so small anymore. Do you recognize this? Olafur and I have some ideas on keeping those zone transfers small. Your feedback is appreciated.

Re: [DNSOP] comments on draft-ietf-dnsop-edns-client-subnet-00

At Thu, 8 Jan 2015 19:36:00 +, Wilmer van der Gaast wil...@google.com wrote: Re NETMASK: Yeah, sorry, poor choice of terminology early on in the doc. Prefix length is the right term to use, it just felt like the point was clear and it was too late to change it. But feel free, of course,

Re: [DNSOP] comments on draft-ietf-dnsop-edns-client-subnet-00

At Thu, 08 Jan 2015 15:52:12 +0100, Yuri Schaeffer y...@nlnetlabs.nl wrote: If I understand this (and Section 6.3 in general), the following suboptimal scenario could happen: - The Authoritative Server is configured with two prefixes for optimized responses: 2001:db8::/32 and

Re: [DNSOP] comments on draft-ietf-dnsop-edns-client-subnet-00

On Thu, Jan 8, 2015 at 10:58 AM, jin...@wide.ad.jp wrote: - Using my server side configuration example of 2001:db8::/32 and 2001:db8:2::/48 again. With this definition of SCOPE and caching behavior at the Recursive Server, the Recursive Server would have to cache separate responses for

[DNSOP] comments on draft-ietf-dnsop-edns-client-subnet-00

I've read the draft and have the following comments. - Section 5 o SOURCE NETMASK, unsigned octet representing the length of the netmask pertaining to the query. In replies, it mirrors the same value as in the requests. It can be set to 0 to disable client- based lookups,

Re: [DNSOP] I-D Action: draft-ietf-dnsop-child-syncronization-04.txt

At Thu, 04 Dec 2014 13:41:05 -0800, Wes Hardaker wjh...@hardakers.net wrote: Ok, how about this: 3. Query for the child zone's data records, as required by the CSYNC record's Type Bit Map field * Note: if any of the resulting records being queried are not

Re: [DNSOP] I-D Action: draft-ietf-dnsop-child-syncronization-04.txt

At Mon, 01 Dec 2014 13:31:23 -0800, Wes Hardaker wjh...@hardakers.net wrote: From a quick check some of them still seem to be open. And, as far as I remember there has been no response to my comments, so I'm not sure if they were considered/discussed but dismissed or simply overlooked.

Re: [DNSOP] I-D Action: draft-ietf-dnsop-child-syncronization-04.txt

On Wed, Nov 26, 2014 at 4:52 PM, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : Child To Parent

Re: [DNSOP] Call for Adoption draft-livingood-dnsop-negative-trust-anchors

At Wed, 26 Nov 2014 10:58:52 -0500, Tim Wicinski tjw.i...@gmail.com wrote: This starts a Call for Adoption for draft-livingood-dnsop-negative-trust-anchors. There was much discussion at the last meeting about adopting this draft and working on it. The draft is available here:

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

At Sat, 01 Nov 2014 16:31:07 -0700, Paul Vixie p...@redbarn.org wrote: if there were an RFC (let's be charitable and assume it would have to be an FYI due to lack of consensus) that gave reasons why PTR's would be needed and reasons why the absence might be better (so, internet access vs.

[DNSOP] draft-livingood-dnsop-negative-trust-anch...@tools.ietf.org

I've read the draft. Overall it's pretty well written. I also personally support the idea of NTAs; although I see its side effect and the possibility of abuse, the draft seems to do its best to explain the implications and avoid abusing. Here are some specific comments on the 01 version: -

Re: [DNSOP] Last Call: draft-ietf-dnsop-child-syncronization-02.txt (Child To Parent Synchronization in DNS) to Proposed Standard

I followed previous discussions on this draft but don't remember all of the details, so I may be rehashing some old discussions (in which case that's not intentional...) Overall: I think the idea is useful and it's eventually worth publishing. But I've noticed a few non-trivial points that may

Re: [DNSOP] Fwd: New Version Notification for draft-mekking-dnsop-kasp-00.txt

At Mon, 28 Jul 2014 10:17:51 +0200, Matthijs Mekking matth...@nlnetlabs.nl wrote: I have just one very minor comment at this moment. While the draft says in Section 1.2 as follows: A key and signing policy can be expressed in any format. This document uses XML as example.

Re: [DNSOP] Fwd: New Version Notification for draft-mekking-dnsop-kasp-00.txt

At Fri, 04 Jul 2014 15:12:24 +0200, Matthijs Mekking matth...@nlnetlabs.nl wrote: I see more and more road maps that include implementing Key and Signing Policies, so Jerry and I thought it would be a good idea to standardize the policy model and the behavior of its elements. Ideally,

Re: [DNSOP] NOTE RR type for confidential zone comments

At Wed, 28 May 2014 12:57:55 -0400, Ted Lemon ted.le...@nominum.com wrote: What you are proposing is essentially a management function, not a naming function. Using the DNS to provide that function can work, and may even make sense in some cases, but I don't think it's the right thing to do

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

At Thu, 24 Apr 2014 07:55:52 +0200, Matthijs Mekking matth...@nlnetlabs.nl wrote: The child can also signal its desire to remove DS records by removing the corresponding records from the CDS/CDNSKEY RRset again. ...unless that would make the resulting CDS/CDNSKEY RRset empty. Otherwise it can

Re: [DNSOP] draft-ietf-dnsop-delegation-trust-maintainance - should child remove the CDS RR?

At Mon, 14 Apr 2014 15:10:56 +0200, Matthijs Mekking matth...@nlnetlabs.nl wrote: C: The child MAY remove the CDS/CDNSKEY RR from the zone once the parent has published it, and this is how to do that safely. So I'm ok if they stay in, but we need a way to get them out for the ones that

Re: [DNSOP] dnse related docs.

At Tue, 04 Mar 2014 21:52:53 +, Tim Wicinski tjw.i...@gmail.com wrote: If we created a new session in the thursday evening 18:40-20:40 slot to accommodate expanded discussion of the Drafts discussed during DNSE and deconflicted that discussion with UTA on friday

Re: [DNSOP] [dnsext] We want to have fruitful discussions - please review

I have one quick question for my own understanding: At Fri, 28 Feb 2014 15:55:21 +0100, Hosnieh Rafiee i...@rozanak.com wrote: [...] For DNS resolver, it receives this IP address securely via the option in the router advertisement message. So, the security of this approach relies on how

Re: [DNSOP] how to delete obsolete DS for obsolete DNSKEY using CDS/CDNSKEY

At Thu, 6 Feb 2014 14:13:05 -0500, Warren Kumari war...@kumari.net wrote: At time T+3 the child sees that the parent has published the new key information ( and the standard keyroll stuff has all happened (records are signed with new key, waited for old TTLs to expire, etc)) and so wants to

[DNSOP] how to delete obsolete DS for obsolete DNSKEY using CDS/CDNSKEY

I have one quick question about CDS/CDNSKEY: what's the (or an) expected operation for the parent to remove a DS RR of a child that was obsolete and is now removed from the child zone? This point is not clear to me on a quick rescan of draft-ietf-dnsop-delegation-trust-maintainance-02. According

Re: [DNSOP] prefetch (HAMMER_TIME) draft

At Thu, 7 Nov 2013 06:53:28 +0100, Daniel Migault mglt.i...@gmail.com wrote: Thanks for the complete answer. As you mention, this benefits not only the end users but also authoritative and resolving servers (especially with DNSSEC). It's already noted in this thread, but: I'd note that's a

Re: [DNSOP] some implementation notes: binding to all IP addresses

At Mon, 8 Oct 2012 21:53:04 +0200, bert hubert bert.hub...@netherlabs.nl wrote: The post is currently short on details for Solaris and Windows. If you have clues, please share! As far as I know Windows doesn't support RFC 3542. --- JINMEI, Tatuya Internet Systems Consortium, Inc.

[DNSOP] comments on draft-ietf-dnsop-resolver-priming-02

Basically, I think this document is useful and I support it to be (eventually) published. Here are my comments on the current version: - Section 2.2 A resolver SHOULD NOT originate a priming query more often than once per day (or whenever it starts). Depending on the TTL of the NS,

Re: [DNSOP] how DNS redirect works with empty response

At Mon, 03 Aug 2009 08:02:40 +0200, Florian Weimer f...@deneb.enyo.de wrote: What does a recursive server that implements the DNS redirect service do in this case? Empty responses are typically rewritten. Okay, then what about the followup question? If it's the latter, what if only one

[DNSOP] how DNS redirect works with empty response

(apologize if this point was already discussed in the thread. I've read all relevant threads but due to their volume I may miss something). I have one quick question about what the DNS redirect service does/would/should with an empty response in terms of Web Error Redirect. Suppose that a zone

[DNSOP] how DNS redirect works with empty response

[resending it after resolving the mismatched sender address...] (apologize if this point was already discussed in the thread. I've read all relevant threads but due to their volume I may miss something). I have one quick question about what the DNS redirect service does/would/should with an

Re: [DNSOP] WGLC: Considerations for the use of DNS Reverse Mapping

At Thu, 3 Apr 2008 22:34:29 -0400, Andrew Sullivan [EMAIL PROTECTED] wrote: or something else? In either case, does this mean we don't have to provide reverse mappings for addresses that are NOT referenced in a forward mapping? No. We added this text exactly to address your

Re: [DNSOP] WGLC: Considerations for the use of DNS Reverse Mapping

Hello, again, Thanks for the detailed response. I now understand what I was concerned about more clearly, and hopefully I can be clearer on that point this time. At Sun, 30 Mar 2008 11:42:34 -0400, Andrew Sullivan [EMAIL PROTECTED] wrote: As a meta (and most substantial) level, this version

<    1   2   3   >