Re: [DNSOP] Fwd: I-D Action:draft-pettersen-subtld-structure-04.txt

for each customer, and should probably therefore be included in your list - it's registry-like. However there's a (large?) unknown number of similar domains that I don't know about. kind regards, Ray -- Ray Bellis, MA(Oxon) Senior Researcher in Advanced Projects, Nominet e: [EMAIL PROTECTED

Re: [DNSOP] WGLC: Requirements for Management of Name Servers for the DNS

Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: r...@nominet.org.uk, t: +44 1865 332211___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Review of draft-livingood-dns-redirect-00

I think we probably also need to address the fact that mail servers should not use resolvers that perform DNS redirect (this was assumed but should be explicit). At least when you do it on your recursive servers you're only affecting your own customers, who in most cases can vote with their

Re: [DNSOP] Review of draft-livingood-dns-redirect-00

Actually, I thought the case was resolvers providing an alternate response, where NO authoritative data exists. ?? An NXDOMAIN response is still authoritative data. Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: r...@nominet.org.uk, t: +44 1865 332211

[DNSOP] Fw: New Version Notification for draft-bellis-dns-recursive-discovery-00

I've just submitted the following draft. --8--8-- A new version of I-D, draft-bellis-dns-recursive-discovery-00.txt has been successfuly submitted by Ray Bellis and posted to the IETF repository. Filename: draft-bellis-dns-recursive-discovery Revision: 00 Title

Re: [DNSOP] Fw: New Version Notification for draft-bellis-dns-recursive-discovery-00

This will work for a short time only because those proxies will likely be changed to return their own address for DOMAIN.LOCAL.ARPA. The draft specifically prohibits this. Of course vendors _do_ ignore RFCs, otherwise this draft wouldn't be necessary. However we'd be in a good position to

Re: [DNSOP] Fw: New Version Notification for draft-bellis-dns-recursive-discovery-00

Mark, I din't think this is true given how the proposed protocol works. For a start, you often cannot fetch the DNSKEY RR for ARPA before running the protocol. Indeed LOCAL.ARPA would need to be unsigned. That needs to be added to the draft. Since (as Bill points out) LOCAL.ARPA would be

Re: [DNSOP] Fw: New Version Notification for draft-bellis-dns-recursive-discovery-00

That's easily remedied, and would be a good addition to the protocol. The first thing the client does is send a query to the candidate new nameserver (possibly with Christmas tree options, e.g. DO set and so forth), and check the reply looks sensible. If not, it doesn't use it. That way it

Re: [DNSOP] Priming query transport selection

EDNS0 RFC restricts EDNS0 to 4096 bytes, number of implementations will not send more even if client ask for it. Firewalls will enforce this. RFC 2671 enforces no such limit - the strict limit is 65535, and §4.5.5 has a hint that 4K might be a reasonable amount of state to maintain for

Re: [DNSOP] Priming query transport selection

when I sent the last message so couldn't check it, but that confirms my recollection. I've already submitted to ISC that the choice of value should be left entirely to the sysadmin, and not restricted to an arbitrary lower value by their software. kind regards, Ray -- Ray Bellis, MA(Oxon) MIET

Re: [DNSOP] Public DNS (Root/gTLD) Health Monitors.

Can someone point me to any public reachable dns (Root/gTLD) health monitors that can I update wiki.outages.org We current have following listed off wiki.outages.org, * RIPE NCC DNS Monitor * CYMRU: Root/gTLD Reachability * OpenDNS System Status Pointers / feedback will be

Re: [DNSOP] cross-wg/area review: draft-ietf-geopriv-res-gw-lis-discovery-02.txt

On 28 Sep 2011, at 16:54, Peter Koch wrote: If you are able and willing to devote some time and energy on a thorough review of this draft, especially the use of the DNS reverse tree as a hook for service discovery and its applicability in today's (and, for that matter, tomorrow's)

Re: [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document

On 19 Oct 2011, at 07:42, teemu.savolai...@nokia.com teemu.savolai...@nokia.com wrote: Hi all, This second WGLC resulted in very few comments. In the DHC WG we discussed about DHCPv4 option structure and in MIF there was a comment about document-internal reference bug. I have now

Re: [DNSOP] [mif] [dnsext] 2nd Last Call for MIF DNS server selection document

On 21 Oct 2011, at 08:21, teemu.savolai...@nokia.com teemu.savolai...@nokia.com wrote: Do you agree that nodes' behavioral differences between foo and foo. names is out of the scope of this particular MIF draft? In my view neither the draft nor MIF should be encoding any changes to client

Re: [DNSOP] New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt

On 30 Mar 2012, at 12:09, Ondřej Surý wrote: Hi Joseph, since I am not sure if you understood my point (I am not sure if I was able to understand it myself :), I am summarizing it to the mailing list. I like the direction of your work, but I miss a way how to put more stuff under the

Re: [DNSOP] New Version Notification for draft-gersch-dnsop-revdns-cidr-02.txt

Joe, The draft says: The challenge is to preserve this alignment even when even when CIDR prefixes do not fall on octet boundaries. For example, 129.82.128.0/19 is a subprefix of 129.82.128.0/18. The DNS name for 129.82.128.0/19 should be logically below the DNS name for 129.82.128.0/18.

Re: [DNSOP] New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt

On 31 May 2012, at 22:51, Joseph Gersch wrote: Ray and Ondrej, Dan Massey and I have been busy putting together a presentation for NANOG which is in Vancouver next week. We plan on having many discussions with operators and designers there. After we get enough feedback, we will get

Re: [DNSOP] [dane] FYI: Verisign files patent application for way of transfering hosting on DNSSEC Domains

On 8 Oct 2012, at 15:13, Ted Lemon ted.le...@nominum.commailto:ted.le...@nominum.com wrote: On Oct 8, 2012, at 9:58 AM, Tony Finch d...@dotat.atmailto:d...@dotat.at wrote: Prior art: http://tools.ietf.org/html/draft-koch-dnsop-dnssec-operator-change-01 Interesting timing: the Verisign patent

Re: [DNSOP] Question: unknown EDNS0 options and recursive resolvers?

On 8 Nov 2012, at 12:59, Nicholas Weaver nwea...@icsi.berkeley.edu wrote: How do recursive resolvers react to unknown EDNS0 options? Are the requests simply dropped? Is the unknown option removed and ignored? Passed to the authority unchanged? They certainly shouldn't do the latter

Re: [DNSOP] request for working group to adopt draft-gersch-dnsop-revdns-cidr-04.txt

On 5 Mar 2013, at 01:24, Daniel Massey mas...@cs.colostate.edu wrote: Hi, We have an approach for naming IP prefixes and have been using the naming scheme for about a year now. The scheme is documented at: draft-gersch-dnsop-revdns-cidr-04.txt Over the past several months, we

Re: [DNSOP] Extended CNAME (ENAME)

On 21 May 2014, at 11:15, Saku Ytti s...@ytti.fi wrote: Any opinions on SVCINFO[0]. I was really big fan of SRV until I read the draft, it made really compelling arguments to me. It looks interesting. I had a long conversation last night with Martin Thomson, editor of the HTTP/2.0 draft and

Re: [DNSOP] Extended CNAME (ENAME)

Absolutely! Ray Sent from my iPhone On 23 May 2014, at 16:47, Ted Lemon ted.le...@nominum.com wrote: I've been talking privately with some knowledgable httpbis folks about having a special joint session at IETF 90 where we can focus on this topic and hopefully come to a mutual

Re: [DNSOP] draft-ietf-dnsop-edns-chain-query and draft-ietf-dnsop-edns-tcp-keepalive

On 7 Oct 2014, at 18:27, Tim Wicinski tjw.i...@gmail.com wrote: All We have two drafts expiring shortly and I wanted to get the sense of the working group. These are the two EDNS extensions worked on by Mr. Paul Wouters. They initially had no home, and we gave them a home, and there

Re: [DNSOP] {Sender Address Possibly Forged} Re: draft-ietf-dnsop-edns-chain-query and draft-ietf-dnsop-edns-tcp-keepalive

On 8 Oct 2014, at 09:21, Ray Bellis ray.bel...@nominet.org.uk wrote: I do NOT support adoption of edns-tcp-keepalive. Ah, I see that particular horse has already bolted. My comments still stand, though. I do not believe this option is useful, or required. Ray

Re: [DNSOP] draft-ietf-dnsop-edns-chain-query and draft-ietf-dnsop-edns-tcp-keepalive

On 8 Oct 2014, at 10:35, Tony Finch d...@dotat.at wrote: The performance problem that EDNS chain queries are trying to fix is an problem with existing server implementations, NOT a protocol limitation. Both BIND and Unbound fail to handle queries concurrently when they arrive over one TCP

Re: [DNSOP] draft-ietf-dnsop-edns-chain-query and draft-ietf-dnsop-edns-tcp-keepalive

On 8 Oct 2014, at 21:07, David C Lawrence t...@akamai.com wrote: It is just preferable to me that the TCP session behaviour be negotiated. Can you please elaborate? What particular benefits do you anticipate arising from such a negotiation? kind regards, Ray

Re: [DNSOP] Possible slower response with minimization

On 21 Oct 2014, at 11:11, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: It is clearly specified in rfc1034: The domain name space is a tree structure. Each node and leaf on the tree corresponds to a resource set (which may be empty). That’s a matter of interpretation. To

Re: [DNSOP] Followup Discussion on TCP keepalive proposals

i realize that no votes aren't counted. but that's going to be my input if any document along the lines of adding persistence to tcp/53 is adopted by the WG. so, for full disclosure, i wanted to weigh in at this stage. TCP/53 is already persistent, it just happens most clients don't take

Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

On 16 Mar 2015, at 15:05, bert hubert bert.hub...@netherlabs.nl wrote: Sorry? We solve implementation hardship by standards action now? Some modern Authoritative servers, such as those used by CDN's, do not have DNS zones. For those servers answering ANY query truthfully is hard

Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

On 16 Mar 2015, at 15:22, bert hubert bert.hub...@netherlabs.nl wrote: At DNS query rates, you could just query purely based on the name as the key. You'd have to do so anyhow to determine what kind of NXDOMAIN/NOERROR response to generate! Yes, that's a good point :) Or are we going to

Re: [DNSOP] [TCP] Review of draft-ietf-dnsop-5966bis-00.txt

On 9 Mar 2015, at 16:32, Stephane Bortzmeyer bortzme...@nic.fr wrote: I re-send here two questions that have apparently not been addressed in -01 On Sun, Jan 04, 2015 at 06:42:26PM +0100, Stephane Bortzmeyer bortzme...@nic.fr wrote a message of 37 lines which said: Section 3, some

Re: [DNSOP] go further about DNS over TCP?

On 25 Mar 2015, at 09:52, Paul Vixie p...@redbarn.org wrote: well then it bears further discussion, because to me it's certainly a change. there is no guidance in RFC 1035 as to whether an initiator should treat premature closure by the responder as a signal to try the same server again

Re: [DNSOP] Definitions of foo-centric

On 25 Feb 2015, at 08:58, Stephane Bortzmeyer bortzme...@nic.fr wrote: I'm not sure they appear in a RFC. They are commonly used (see for instance https://mex.icann.org/ar/file/22921/download/23075) when discussing resolvers' behaviour. Let me suggest: Child-centric resolver: a DNS

Re: [DNSOP] {Sender Address Possibly Forged} Re: Definitions of foo-centric

On 25 Feb 2015, at 09:14, I wrote: This is my understanding of the terms too. However in the child-centric case this can cause problems when the NS set held by the parent changes (i.e. the zone is redelegated) but the NS set in the old set of servers isn't also updated. Such a

Re: [DNSOP] Adoption and Working Group Last Call for draft-ietf-dnsop-dns-terminology/

On 20 Apr 2015, at 17:57, Paul Hoffman paul.hoff...@vpnc.org wrote: Yes. There are differences between the explicit definition for DNS forwarder in RFC 2308 and the strongly implied definition in RFC 5625. The WG needs to decide which definition it prefers, and an explanation of why

Re: [DNSOP] Clarification on EDNS 6891

On 03/06/2015 17:22, Joe Abley wrote: I think there's a baked-in expectation that OPT pseudo-RR is included in every DNS message, not on every connection (where the transport is connection-oriented). Joe, Part of the reason this came up is this text in draft-ietf-edns-tcp-keepalive: DNS

[DNSOP] Clarification on EDNS 6891

Whilst discussing 5966-bis with my co-authors connection-close with the co-authors, we were reminded of this point I made in draft-bellis-dnsop-connection-close in relation to §7 of RFC 6891: TODO: note - the constraint in RFC 6891 appears unnecessarily strict - it appears to mandate that

Re: [DNSOP] Clarification on EDNS 6891

On 03/06/2015 17:22, Joe Abley wrote: On 3 Jun 2015, at 17:17, Shane Kerr wrote: On Wed, 03 Jun 2015 13:57:39 +0100 Ray Bellis r...@bellis.me.uk wrote: Whilst discussing 5966-bis with my co-authors connection-close with the co-authors, we were reminded of this point I made in draft

Re: [DNSOP] Clarification on EDNS 6891

On 12/06/2015 17:49, Paul Vixie wrote: Ray Bellis wrote: RFC 2671 (§4.1) says OPT RRs shall never be ... forwarded. as the author of that text, i claim that i was referring to DNS Forwarding, in the sense described by https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-terminology

Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-tcp-keepalive-02.txt

Authors : Paul Wouters Joe Abley Sara Dickinson Ray Bellis Filename: draft-ietf-dnsop-edns-tcp-keepalive-02.txt Pages : 12 Date: 2015-07-03

Re: [DNSOP] Some distinctions and a request - Have some class?

On 05/07/2015 01:35, Andrew Sullivan wrote: Classes don't work in the general case, because CNAME (and following it, DNAME) is class-independent. This is arguably a bug in the protocol, but it's a fact nevertheless. As a result, different classes aren't really different namespaces.

Re: [DNSOP] Some distinctions and a request - Have some class?

On 05/07/2015 18:16, Evan Hunt wrote: On Sun, Jul 05, 2015 at 10:44:40AM -0400, Andrew Sullivan wrote: Imagine the alternative-resolution class FAKE. In the IN class, example.com has a DNAME entry pointing to example.net. What should happen when someone performs a query for QNAME

Re: [DNSOP] Some distinctions and a request

On 30/06/2015 12:43, Edward Lewis wrote: Is being an entry a barrier to being used in the DNS? This is not clear - I can ssh to a .local machine. So can I, but that's because my computer's name service stub used mDNS to find it, not DNS. Ray ___

Re: [DNSOP] Review of draft-ietf-dnsop-cookies

On 06/07/2015 16:42, Paul Hoffman wrote: Because there are lots of other systems that watch either end. A logger that expects a query is the one I am most concerned about, but there are probably others as well. I understand that you feel they are broken and we shouldn't care about them. I

Re: [DNSOP] The EDNS Key Tag Option

On 30/07/2015 17:10, Wessels, Duane wrote: I am proposing (Sectino 5.2) that a recursive/forwarder would copy edns-key-tag values from incoming queries to outgoing queries, and append its own if different. There really needs to be a way to signal EDNS0 option forwarding (as opposed to

Re: [DNSOP] The EDNS Key Tag Option

On 30/07/2015 17:50, Paul Vixie wrote: why so? i argued for hop-by-hop in EDNS for reasons which still appear good to me. just as with additional-data section processing (which is per-Qtype), this kind of data forwarding should be part of each option's specification. Mostly because IMHO it

Re: [DNSOP] I-D Action: draft-ietf-dnsop-5966bis-02.txt

On 16/07/2015 22:41, Shane Kerr wrote: I think it is worse than flooding with UDP. It allows fire and forget actions from clients: # we can comfortably fit 20 queries into a single 1280-byte packet for i = 1 to 20: packet.append(EXPENSIVE_QUERY) conn =

Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-tcp-keepalive-02.txt

On 20/07/2015 10:49, Petr Spacek wrote: 3.3.2. Sending Responses Current text seems to allow servers to send tcp-keepalive option even if the client did not explicitly request it. Is it intended? If it is the case it would be nice to say it explicitly. Right now I do not if it is just

Re: [DNSOP] RFC 2181 - a pathway forward.

On 11/07/2015 23:04, manning wrote: the one change i am working on is to obsolete RRsets since they are a primary cause of DNS originated DDoS in the Internet. How do you propose to do that without completely breaking DNSSEC ? RRSIGs are calculated over entire RRsets, not RRs. Ray

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

On 26/10/2015 09:52, I wrote: > That's clear - what isn't perhaps, is what the RCODE should be, given > that this text is in a section with "Name Error" in its title. For what it's worth, I expect the answer to be NOERROR, but I think the text that lumps empty-non-terminals in with "name

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

On 26/10/2015 09:50, Roy Arends wrote: > Speaking only for myself, though I happen to be one of the authors. > > ... > > An Empty Non Terminal NoData response requires the same NSEC records as > an Name Error Response. That's clear - what isn't perhaps, is what the RCODE should be, given that

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

On 26/10/2015 06:39, Paul Vixie wrote: > sanity check, someone? > > i believe that in dnssec, an empty non-terminal has a proof that the > name exists, and a proof that there are no RR's. thus, vastly > different from the signaling for NXDOMAIN. RFC 4035 §3.1.3.2 appears to say differently :(

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

On 26/10/2015 15:32, Evan Hunt wrote: > But RFC 5155 is clear on the subject; empty non-terminal nodes are > mentioned under "no data" rather than "name error". Ah, thanks, that's useful to know, and further it specifically says that the NSEC3 ETN response is different to an NSEC ETN response.

Re: [DNSOP] simple question

On 13/11/2015 16:55, A. Schulze wrote: > should I add a entry in example.com to delegate the subzone to myself? Yes, you should. Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Registry of non-service _prefix names?

On 13/11/2015 18:00, John Levine wrote: Over in the dbound working group we have some proposals that would use yet another underscore prefixed name to avoid name collisions. (It's not a substitute for a new RRTYPE; they need the prefix whether the data is TXT or a new type.) In the mail

Re: [DNSOP] Registry of non-service _prefix names?

On 14/11/2015 17:07, Dave Crocker wrote: > Done. > > This will be the third or fourth try for the document. Perhaps there is > now enough community interest to make it happen? Thanks Dave :) >From my previous recollection of this, ISTR there was a suggestion that your draft only directly

Re: [DNSOP] we already have a new version of this problem

On 05/11/2015 10:11, George Michaelson wrote: > So can somebody explain to me what we are meant to do with a possible > emerging homenet desire for .home? > > https://datatracker.ietf.org/doc/draft-cheshire-homenet-dot-home/ This particular proposal was being discussed long before any of the

Re: [DNSOP] draft-jabley-dnsop-ordered-answers

On 06/11/2015 07:04, Paul Vixie wrote: > there's an installed base consisting of over a billion stubs and a few tens > of > millions of recursives who will fail to parse your response if the CNAME > comes > after the thing it points to. > > generally speaking, that has to be documented,

Re: [DNSOP] draft-jabley-dnsop-ordered-answers

On 06/11/2015 00:54, Niall O'Reilly wrote: > Wouldn't it be a simpler clarification to say that a client MUST NOT > depend on the order of the RRsets in an answer? That's what I meant (blame jetlag). Ray ___ DNSOP mailing list DNSOP@ietf.org

Re: [DNSOP] draft-jabley-dnsop-ordered-answers

On 05/11/2015 11:37, Joe Abley wrote: > Hi all, > > I couldn't quite interpret the questions and hums in the room; was the > consensus > > (a) this clarification is not needed; the existing spec is clear enough, or > > (b) a clarification might be useful, but the proposed clarification in >

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

On 14/10/2015 17:15, Sara Dickinson wrote: > Yes, it says: > > “ When sending multiple queries over a TCP connection clients MUST take >care to avoid Message ID collisions. In other words, they MUST NOT >re-use the DNS Message ID of an in-flight query. " > > So maybe that should

[DNSOP] Call for Presentations - DNS-OARC 24th Workshop, Mar 2016

on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) Ray Bellis, ISC on behalf of the DNS-OARC Programme Committee ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Benoit Claise's No Objection on draft-ietf-dnsop-5966bis-05: (with COMMENT)

On 06/01/2016 13:46, Benoit Claise wrote: > -- > COMMENT: > -- > > I was slightly surprised by "implementation requirements" in the title. > If we write a RFC,

Re: [DNSOP] draft-jabley-dnsop-ordered-answers

On 27/11/2015 13:16, Paul Wouters wrote: > RFC 1122: "Be liberal in what you accept, and conservative in what you > send"). > > It's cute, but it will lead to interop issues. It will also make > debugging more annoying for humans. See also draft-thomson-postel-was-wrong-00

Re: [DNSOP] The DNSOP WG has placed draft-andrews-dns-no-response-issue in state "Candidate for WG Adoption"

On 12/11/2015 18:58, IETF Secretariat wrote: > > The DNSOP WG has placed draft-andrews-dns-no-response-issue in state > Candidate for WG Adoption (entered by Tim Wicinski) I support adoption of this draft, and will review it. Ray [ObDisclaimer - the author is a colleague].

[DNSOP] Call for Presentations - DNS-OARC Fall Workshop, Dallas, Oct. 2016

[with apologies to those who see this on multiple lists] Call for Presentations The DNS-OARC 25th Workshop will take place in Dallas, Texas during October 15th and 16th 2016, the Saturday and Sunday before NANOG68. To attract the best DNS minds, DNS-OARC is requesting proposals for

Re: [DNSOP] Prefixed name spaces and DANE client TLSA

On 13/01/2016 20:01, John Levine wrote: I suppose, but doing it as _._client._ puts it in > the existing service namespace. It's not a huge difference, and it's > been clear for a while that if we do Dave's registry, part of what > it includes will be a list of the underscore names that are

Re: [DNSOP] Prefixed name spaces and DANE client TLSA

On 13/01/2016 17:12, John R Levine wrote: > Here's a concrete example. My laptop is named mypc.example.com. Because > I am a forward thinking guy, I send a DANE-verified client cert whenever > I connect for submission, POP, IMAP, or jabber, and because I'm still > lazy, I use the same

Re: [DNSOP] DNS Delegation Requirements

On 08/02/2016 12:07, Jakob Schlyter wrote: > On 8 feb. 2016, at 11:00, Ralf Weber wrote: >> 6.2 The name servers SHOULD NOT belong to the same AS I would drop >> that requirement altogether or make it a MAY. We really should not >> tell people how to build networks from the DNS

Re: [DNSOP] [Technical Errata Reported] RFC7719 (4611)

On 02/02/2016 15:21, RFC Errata System wrote: > Type: Technical > Reported by: Nikolai Malykh > > Section: 2 > > Original Text > - > CNAME: "It is traditional to refer to the owner of a CNAME record as >'a CNAME'. This is unfortunate, as 'CNAME' is an

Re: [DNSOP] SRV-related _underscore registry (was Re: Call for Adoption: draft-crocker-dns-attrleaf)

On 29/02/2016 22:27, John R Levine wrote: > The existing port and service registry already has all of the _service > names, and is updated as people invent new services. What's the benefit > of duplicating it rather than just pointing to it? +1 [and this is pretty much the proposal I made to

Re: [DNSOP] [internet-dra...@ietf.org: New Version Notification for draft-sullivan-dns-class-useless-01.txt]

Andrew, Thanks for writing this. I do take minor issue with this bit: "But given the DNS message format, the name server cannot find the class until it knows the name." I don't believe that this is relevant. I do think that putting the class and type fields after the variable length name

[DNSOP] AAAA4Free

May I please remind the WG of draft-bellis-dnsext-multi-qtypes-01 (expired, but seems eminently applicable in this case as a signalling mechanism, and is more general purpose) Ray ___ DNSOP mailing list DNSOP@ietf.org

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

On 01/03/2016 15:26, Ólafur Guðmundsson wrote: > Thus I consider your document a distraction, we should push the general > solution not a special case +1 Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] SRV-related _underscore registry (was Re: Call for Adoption: draft-crocker-dns-attrleaf)

On 01/03/2016 16:56, John Levine wrote: > If you take a look at that registry, it's a stroll down memory lane. > You'll find NVP-II from RFC 741 in 1977, PUP and XNS-IDP from Xerox in > 1980, and other great hits from networking history. > > I really doubt that people are going to ever publish

Re: [DNSOP] SRV-related _underscore registry (was Re: Call for Adoption: draft-crocker-dns-attrleaf)

On 01/03/2016 16:39, John Levine wrote: > The other which I prefer is simply to put the four _proto tags into > the new underscore registry. Add a note that they have subnames from > the RFC 6335 services registry, and for anew new protocol tags try to to > keep the protocol names consistent

Re: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-accompanying-questions-00.txt

On 29/04/2016 02:01, Jiankang Yao wrote: > Dear all, > > We submit a draft about "A DNS Query including A Main Question > with Accompanying Questions". > >Any comments are welcome. I am unconvinced that the ability to specify multiple QNAMEs offers any benefits and can't think

Re: [DNSOP] [rfc-edi...@rfc-editor.org: RFC 7788 on Home Networking Control Protocol]

On 25/04/2016 08:25, Stephane Bortzmeyer wrote: > And, anyway, I cannot blame the homenet people for having "registered" > .home surreptitiously because there is no other open way to do it > "properly". To the best of my knowledge there was no intent to get around 6761 here surreptitiously or

Re: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-accompanying-questions-00.txt

On 03/05/2016 07:21, Jiankang Yao wrote: > when receiving an email from a...@example.com > , I often would like to visit the website of > www.example.com too when I reply the email. IMHO it would be an incredibly unwise thing for any software

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

On 15/04/2016 05:19, Mark Andrews wrote: Or we could just complain to the operators of the servers that echo EDNS options and request that they fix them. It's not like it isn't a fixable problem. It just requires a little co-operation to find and report broken servers to the operators and

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

echo... Ray Forwarded Message Subject: New Version Notification for draft-bellis-dnsext-multi-qtypes-02.txt Date: Thu, 14 Apr 2016 10:09:47 -0700 From: internet-dra...@ietf.org To: Ray Bellis <r...@isc.org> A new version of I-D, draft-bellis-dnsext-multi-qtypes-02.txt ha

Re: [DNSOP] 答复: Fw: New Version Notification for draft-shane-dns-manifesto-00.txt

On 11/07/2016 22:55, George Michaelson wrote: > UDP+cookies could work for you? Yes, it possibly could, but it's still "to be determined". Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] https://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-02

On 12/07/2016 14:35, John Dickinson wrote: > Hi, > > I think that a bit more should be said on the problem statement in > the introduction. > > I might have missed it, but what entity originates the query? Stub or > resolver? It's suitable for both. It could perhaps benefit from being

Re: [DNSOP] I-D Action: draft-bellis-dnsop-session-signal-02.txt

Notwithstanding the ongoing Call for Adoption, we've just posted a further update to this draft which addresses some of the comments already received, and also removes the explicit "Start Session" TLV in favour of just using the "Idle Timeout" TLV to request a "long-lived session". Ray

Re: [DNSOP] Call for Adoption: draft-bellis-dnsop-session-signal

On 26/07/2016 16:03, Shane Kerr wrote: > I think the document itself needs some work (such as more detailed > motivation statement, some use cases, probably getting rid of "terminate > session", and so on). > > At first I thought that this should stay in homenet, but it does use a > lot of DNS

Re: [DNSOP] [apps-discuss] Draft of interest in DNSOP: draft-ietf-dnsop-attrleaf

On 04/08/2016 05:05, John R Levine wrote: > As of Berlin, I thought I heard that there was (still) deviations. The one I thought was a deviation was "xmpp-client" (5222), but it turns out that's just because my macOS /etc/services file is out of date and still lists that as "jabber-client".

Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

On 12/07/2016 12:00, Paul Wouters wrote: > > I am very hesitant to accept any protocol-over-http wrapper, as it just > moves the problem around and generate a new set of middleware boxes that > mess with the data. +lots Ray ___ DNSOP mailing list

Re: [DNSOP] draft-bellis-dnsop-session-signal-00 nit

On 18/07/2016 16:30, Matthew Pounsett wrote: > > In § 5.3, the typecode registry leaves codes 3966 and 3967 undefined. > Thanks Matt. Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-session-signal-00.txt

On 17/07/2016 10:52, Matthew Pounsett wrote: > I think this draft is a good candidate for adoption. > > I'd like to echo Ted's comment that the draft should explicitly > state the sort of context this is meant to be used in. Calling out > TCP sessions as an example would be a good start. OK,

Re: [DNSOP] The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state "Candidate for WG Adoption"

On 06/07/2016 10:09, fujiw...@jprs.co.jp wrote: > We need summaries of previous discussions, > and need to consider why many idea stopped. > > * For the draft, > > Using unstructured data (TXT format) is not good. > > I agree query name restriction (Additional records MUST be leaf >

[DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-session-signal-00.txt

-session-signal-00.txt has been successfully submitted by Ray Bellis and posted to the IETF repository. Name: draft-bellis-dnsop-session-signal Revision: 00 Title: DNS Session Signaling Document date: 2016-07-06 Group: Individual Submission Pages: 10 URL

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-session-signal-00.txt

On 06/07/2016 23:28, Ted Lemon wrote: > Hm, you seem to have left out a definition of what a "session" is. Do > you mean a TCP connection? Are you referring to something that's > already defined in a document that I have, lamentably, not read? (In > which case, a reference would be helpful).

Re: [DNSOP] Benoit Claise's No Objection on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with COMMENT)

On 07/07/2016 10:31, Benoit Claise wrote: > Based on my operational experience, I have seen multiple DNSSEC > packets dropped by firewalls because they try to use EDNS0 rather > than fragmenting. Does your I-D also address this issue? This is the wrong way around - EDNS *relies upon*

Re: [DNSOP] 答复: Fw: New Version Notification for draft-shane-dns-manifesto-00.txt

On 11/07/2016 07:13, George Michaelson wrote: > Things like client capability signalling, I suspect are in a harder > bucket. I won't say intractably hard, but last time I floated > capability flagging, I got pretty strong pushback. I think capability flagging is difficult in a stateless

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On 06/02/2017 15:29, Ólafur Gudmundsson wrote: > Ted, > > What RFC are you referring to? > > Why do you think .ARPA is for services? > It's for infrastructure and homenet wants to join the infrastructure. > > It is waste of time arguing if name A or B is better take the one you > can get

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On 06/02/2017 16:55, Tony Finch wrote: > Ray Bellis <r...@bellis.me.uk> wrote: >> >> Yes, that's right, with the caveat that all existing locally served >> zones are in the reverse space - there's no forward zones registered (yet). > > There are several :-) RFC

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On 06/02/2017 16:12, Suzanne Woolf wrote: > Hi, > > Before this goes any further, I’m not sure an incomplete rehashing of > the consensus in another WG is a good use of our time. +1 :) > For now, let’s keep it relevant to the decision this WG has to make, > about what to do with .alt and

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On 06/02/2017 16:18, Suzanne Woolf wrote: >> Yes, that's right, with the caveat that all existing locally >> served zones are in the reverse space - there's no forward zones >> registered (yet). > > Could you clarify why that’s relevant? > > Does it just come down to the assumption that

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On 04/02/2017 02:13, Andrew Sullivan wrote: > Right, that's always been the problem with using this _for the DNS_. > Homenet has no choice in that, because the whole point of the homenet > name is precisely to enable in-homenet DNS without reference to the > global DNS. I think you're quite

Re: [DNSOP] New Version Notification for draft-bellis-dnsop-xpf-00.txt

On 10/02/2017 12:52, Peter van Dijk wrote: > However, both in ECS, and now in XPF, we do not get client’s port > number. With increasing CGNAT deployment, this makes it impossible to > distinguish clients once a request has passed through a proxy, like > dnsdist or a TLS frontend. > > Can you

  1   2   3   4   >