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

Petr, On 18/07/2024 17.09, Petr Špaček wrote: I'm one of the guys who implemented a server which ignored SOA serial semantics on purpose - because its distributed multi-master backend offered only eventual consistency. Of course it had to expose _some_ value for SOA serial, but the fake ser

[DNSOP] Re: draft-hinden-v6ops-dns

Paul, On 20/06/2024 03.31, Paul Wouters wrote: On Wed, 19 Jun 2024, Tim Wicinski wrote: On Wed, Jun 19, 2024 at 2:49 PM Paul Vixie wrote:   This document makes the argument that because of how things work at the   moment, we should limit our aspirations.   I completely disagree

[DNSOP] alpn parsing in SVCB

Dear Colleagues, I know it's really late, but I hadn't worked with the SVCB until recently. Apologies if this has been thoroughly discussed. 😬 I implemented a parser for the "alpn" service parameter, and the code was a lot more complex than I thought it should be. Basically, the double-encod

Re: [DNSOP] Call for Adoption: draft-salgado-dnsop-rrserial

Tim, On 28/05/2021 16.26, Tim Wicinski wrote: > > We had a lot of good discussion of this draft when it first came out, > and the chairs want to put up a call for adoption. I support adoption of the draft, and am willing to contribute text and review. Cheers, -- Shane OpenPGP_0x3732979CF9

Re: [DNSOP] Call for Adoption: draft-salgado-dnsop-rrserial

Hugo, While I find it a pity that the consensus seems to be that just including the serial instead of the entire SOA is the best way forward, I don't strongly object, since it can indeed be useful for debugging as proposed. Sorry if I missed earlier discussion, but if a query to a resolver

Re: [DNSOP] SVCB without A/AAAA records at the service name

Martin, On 15/01/2021 00.43, Martin Thomson wrote: As requested (I'm not engaged here enough to understand the terms of engagement, so my apologies for using an interaction form I'm accustomed to), moving discussion from https://github.com/MikeBishop/dns-alt-svc/issues/287 to here: The SVCB

Re: [DNSOP] [Ext] partial glue is not enough, I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt

Brian, Thanks for the interesting idea. Apologies for the rambling response below. On 02/07/2020 19.16, Brian Dickson wrote: On Thu, Jul 2, 2020 at 9:14 AM Paul Hoffman > wrote: The interpretation of whether a partial RRset is allowed by 1035/2181 made

[DNSOP] Multi-QTYPES (was: unsolicited HTTPSSVC responses)

Ray and other DNS operations folks, On 27/05/2020 10.30, Ray Bellis wrote: On 27/05/2020 07:33, Petr Špaček wrote: I would much rather spent time on https://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-03 That would bring benefit to broader set of clients and has advantage that serv

Re: [DNSOP] data at delegation points

DNS friends, On 14/04/2020 17.43, Paul Vixie wrote: today it was proposed that NS2 be added as a new record-set type that could exist in either the parent or the child, similar to NS, and reminding several of us about the DS debacle. DS should never have been placed at the delegation point, a

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

Matthijs, On 20/02/2020 09.29, Matthijs Mekking wrote: On 2/18/20 5:17 PM, Olli Vanhoja wrote: On Tue, Feb 18, 2020, 16:20 Klaus Malorny mailto:klaus.malo...@knipp.de>> wrote: I asked myself about the status of the two drafts. I got the impression a little bit that the svcb/

[DNSOP] rrserial as a path to fame and fortune (was: Adoption of new EDNS opcode "rrserial")

Hugo, On 27/01/2020 16.08, Hugo Salgado wrote: Dear DNSOPers, as an operator I tend to have this need to couple an answer for a query to an auth server, with the actual "SOA zone version" used. So I think it'll be valuable to have an EDNS option for it. Here I'm proposing it with this new draft

Re: [DNSOP] future-proofing (Re: Working Group Last Call for: Message Digest for DNS Zones)

Duane, On 13/01/2020 19.26, Wessels, Duane wrote: On Jan 8, 2020, at 3:55 PM, Michael StJohns wrote: There's also the case that future ZONEMD schemes may need a different format for the digest field. E.g. one approach to dealing with incremental changes is to have a NSEC like ZONEMD re

Re: [DNSOP] On .ZZ

Bill and all, On 21/11/2019 16.25, Bill Woodcock wrote: On Nov 21, 2019, at 12:18 AM, Brian Dickson wrote: IMHO, there is *no* reason not to advance .zz For the record, I think it’s a really bad idea to start re-purposing the ISO user-assigned codes. Just as bad an idea as if they starte

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-multi-provider-dnssec

Benno and all, Overall the document is clear and I hope helpful to organizations pursuing a multi-DNS vendor setup who want to use DNSSEC (as all do, I am sure). One minor thing I noticed while looking through the document. It mentions the Brazilian ccTLD as background why using a liberal ro

Re: [DNSOP] HTTPSSVC/SVCB bikeshed: poll for what to name them

Viktor, On 20/11/2019 10.04, Viktor Dukhovni wrote: My proposal: 1. SVCB -> SRVLOC Service location, less cryptic than SVCB, and manifestly a generalization of SRV. 2. HTTPSSVC -> HTTPLOC HTTP location, manifestly a variant of the generic service location, with HTTP in t

[DNSOP] RFC 8482 (the ANY -> HINFO hack) and DNAME

Hello, We just implemented DNAME support on an authoritative server that already implements giving an HINFO response to ANY queries, as described in RFC 8482. RFC 8482 is clear about not allowing the HINFO response if there is a CNAME record at the name. While no rationale is given in the RF

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-01.txt

Duane, On 2019-09-06 02:01, Wessels, Duane wrote: With this version the authors feel that it is ready for working group last call. Sorry for a late comment, but I decided to give this one thorough last read-through. I'm a little concerned that the way the Reserved field is described may m

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-00.txt

Duane and all, On 08/08/2019 01.29, Wessels, Duane wrote: AFAICT there was no feedback received after this most recent version of the ZONEMD draft was posted. As I mentioned before, there was one pretty significant change in that version: The most significant change is that multiple ZONEMD

Re: [DNSOP] changes to extended errors based on your comments

Wes, On 10/08/2019 07.30, Wes Hardaker wrote: 8.3.5 NOCHANGE Finally, I note that the suggestion of requiring that the sender have some signal indicating that it is interested in extended errors was not

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-07.txt

Loganaden & all, On 10/08/2019 07.37, Loganaden Velvindron wrote: On Sat, Aug 10, 2019 at 9:14 AM 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 WG of the IETF. Title :

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-08.txt

Wes, Thanks for the continued work on this draft! On 10/08/2019 20.57, Wes Hardaker wrote: internet-dra...@ietf.org writes: 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 WG of the IETF. A quick

Re: [DNSOP] Caching of negative zone (non-authoritative) responses

Paul, Minor nit, just to be pedantic. On 08/07/2019 20.38, Paul Vixie wrote: REFUSED means, in my reading (and coding) that there is no zone declaration at the authority. SERVFAIL means the zone is declared/configured, but not loaded. i now realize that both have to have a holddown timer, not j

Re: [DNSOP] ANAME loop detection

Matthijs, On 04/07/2019 15.19, Matthijs Mekking wrote: On 7/4/19 2:29 PM, Shane Kerr wrote: 2. QTYPE=ANAME: According to the current version of the draft, server answering to ANAME must include the ANAME and should include the sibling records. Let's modify the behavior and say the s

Re: [DNSOP] ANAME loop detection

Matthijs, On 04/07/2019 11.54, Matthijs Mekking wrote: I like something like option 2 the best, I'll react to your options below. I like something like option 1. Details below as well. 😊 On 7/4/19 11:37 AM, Jan Včelák wrote: Hello. [ ... ] We had been thinking about how this could be f

Re: [DNSOP] Verifying TLD operator authorisation

Jim, On 18/06/2019 13.27, Jim Reid wrote: On 18 Jun 2019, at 11:13, Bjarni Rúnar Einarsson wrote: The SOA record for a TLD contains two DNS names which should be under the control of the NIC ... People on this list can probably comment on whether my above assumption is correct, and whether

Re: [DNSOP] Verifying TLD operator authorisation

Nick, On 14/06/2019 04.18, Nick Johnson wrote: I'm working on a system that needs to authenticate a TLD owner/operator in order to take specific actions. We had intended to handle this by requiring them to publish a token in a TXT record under a subdomain of nic.tld, but it's been brought to o

Re: [DNSOP] Deprecating the status opcode

Petr, On 16/05/2019 12.23, Petr Špaček wrote: On 15. 05. 19 19:57, Bob Harold wrote: On Wed, May 15, 2019 at 1:00 PM John Levine mailto:jo...@taugh.com>> wrote: In article <064ba295-f3dd-46e4-86a9-e03cf68eb...@sinodun.com > yo

Re: [DNSOP] Deprecating the status opcode

John, On 15/05/2019 12.06, John Dickinson wrote: In the spirit of deprecating things I have submitted a draft to deprecate the status opcode. This seems like the most non-controversial document ever in the history of documents. 👍 Cheers, -- Shane _

Re: [DNSOP] [Ext] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-01.txt

Paul, On 13/05/2019 10.08, Paul Hoffman wrote: On May 13, 2019, at 3:00 PM, Evan Hunt wrote: On Mon, May 13, 2019 at 07:47:35AM +, Paul Hoffman wrote: A far easier approach is for any developer to feel free to treat these RRtypes as unknown RRtypes. I'm not sure I understand the distin

[DNSOP] Feedback on extended error from the IETF hackathon

Hello everyone, Several folks have worked on implementing the draft-ietf-dnsop-extended-error at the IETF Hackthon yesterday and today. This is my own feedback on the draft based on trying to get it added to dnsdist. Stéphane Bortzmeyer pointed out that it wasn't clear how

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

Ray and all, On 04/03/2019 17.27, Ray Bellis wrote: This new draft describes a way for clients and servers to exchange a limited amount of information where the semantics of that information are completely unspecified, and therefore determined by bi-lateral agreement between the client and s

Re: [DNSOP] Multiplexing DNS & HTTP over TLS

Klaus, On 14/02/2019 14.00, Klaus Malorny wrote: On 14.02.19 11:03, Shane Kerr wrote: Is there a write-up on this? Thinking about it naively, a demultiplexer really only needs to say "is there a non-ASCII character in the first 2 or 3 bytes of a TLS session?". please think

[DNSOP] Multiplexing DNS & HTTP over TLS (was: extension of DoH to authoritative servers)

Stephane, On 14/02/2019 09.05, Stephane Bortzmeyer wrote: On Wed, Feb 13, 2019 at 10:51:00PM +0100, Vladimír Čunát wrote a message of 118 lines which said: Technically you can run DoT on whatever port you like. Example: with knot-resolver it's easy - you just add @443, either on side o

Re: [DNSOP] Implementations of extended error?

Wes, On 01/02/2019 22.21, Wes Hardaker wrote: Shane Kerr writes: I was thinking about adding some support for this at the IETF hackathon, but I'll be meeting with some of the open source DNS folks this weekend at FOSDEM, and seeing if that collides with their existing plans. Exce

Re: [DNSOP] Implementations of extended error?

Anbang Wen, On 02/02/2019 20.04, Anbang Wen wrote: At Cloudflare, we are testing our crude implementation on our public resolver which is built on top of knot-resolver. It would be good to nudge others into working on it. Is it already on GitHub or GitLab or something like that? Nudging is e

Re: [DNSOP] Implementations of extended error?

Wes, I was thinking about adding some support for this at the IETF hackathon, but I'll be meeting with some of the open source DNS folks this weekend at FOSDEM, and seeing if that collides with their existing plans. On 1 February 2019 18:32:40 CET, Wes Hardaker wrote: > >Folks, > >We (some de

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-extended-error

Dear DNS colleagues, I definitely agree with George that last call seems a bit premature. As he points out, section 6 is a large open question. We need to either change EDNS behavior to allow an unsolicited EDNS option in a response or change this draft to include an appropriate EDNS option wh

Re: [DNSOP] Clarification question: compression pointers always to names earlier in the packet?

John, On 24/10/2018 15.38, John Dickinson wrote: On 24 Oct 2018, at 10:01, Viktor Dukhovni wrote: My reading of RFC 1035 is that DNS name "compression" via "pointers" is restricted to name strictly earlier in the DNS message:    4.1.4. Message compression    In order to reduce the size of me

Re: [DNSOP] Clarification question: compression pointers always to names earlier in the packet?

Viktor, On 24/10/2018 11.01, Viktor Dukhovni wrote: My reading of RFC 1035 is that DNS name "compression" via "pointers" is restricted to name strictly earlier in the DNS message: 4.1.4. Message compression In order to reduce the size of messages, the domain system utilizes a comp

Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-06.txt

All, On 2018-09-05 20:45, 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 WG of the IETF. Title : Reverse DNS in IPv6 for Internet Service Providers

Re: [DNSOP] IETF 102 Hackathon: prototype implementation of draft-wessels-dns-zone-digest-02

All, On 2018-07-18 14:36, Wessels, Duane wrote: It seems to work, although since I have no other implementation to compare against I can't be sure that the digest values are in any way correct. My own implementation, alluded to in the draft, is here: https://github.com/verisign/draft-dns-z

Re: [DNSOP] [Doh] SRV and HTTP - 18:30 Tuesday (room change)

All, I took some random notes at the meeting. Apologies for any errors or misstatements. Cheers, -- Shane 2018-07-17 Bar BoF with about 35 people. Mark Nottingham leads the discussion. Why not SRV for HTTP? Some work before: * draft-andrews-srv-http * New URI scheme also died. Use cases

[DNSOP] IETF 102 Hackathon: prototype implementation of draft-wessels-dns-zone-digest-02

Bonjour, I decided to implement draft-wessels-dns-zone-digest-02 at the IETF 102 Hackathon. As expected, it is fairly straightforward. You can see the code on GitHub: https://github.com/shane-kerr/ZoneDigestHackathon It seems to work, although since I have no other implementation to

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

Petr, Petr Špaček: Dne 1.6.2018 v 12:51 Shane Kerr napsal(a): Wessels, Duane: On May 25, 2018, at 11:33 AM, 神明達哉 wrote: At Wed, 23 May 2018 15:32:11 +, "Weinberg, Matt" wrote: We’ve posted a new version of draft-wessels-dns-zone-digest.  Of note, this -01 version in

Re: [DNSOP] SIG(0) useful (and used?)

Ondřej, Ondřej Surý: > as far as I could find on the Internet there are only SIG(0) implementation > in handful DNS implementations - BIND, PHP Net_DNS2 PHP library, > Net::DNS(::Sec) Perl library, trust_dns written in Rust and perhaps others I > haven’t found; no mentions of real deployment wa

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

Wessels, Duane: > >> On May 25, 2018, at 11:33 AM, 神明達哉 wrote: >> >> At Wed, 23 May 2018 15:32:11 +, >> "Weinberg, Matt" wrote: >> >>> We’ve posted a new version of draft-wessels-dns-zone-digest. Of note, >> this -01 version includes the following changes: >> [...] >>> We plan to ask for ti

Re: [DNSOP] [Ext] Lameness terminology

Amreesh, Amreesh Phokeer: > On Wed, May 2, 2018 at 11:47 PM, Edward Lewis > wrote: >> >> >> If I can't find the text soon, I'll try to recreate the list of references >> at least. >> > > We are in process of implementing a "Lame delegations" policy at AFRINIC > > >

Re: [DNSOP] [Ext] Lameness terminology

Ed, Edward Lewis: > On 4/23/18, 10:23, "DNSOP on behalf of Shane Kerr" behalf of sh...@time-travellers.org> wrote: > >>I don't know if this is documented anywhere so that it can be >>referenced properly, sorry. I am happy to discuss further but I thi

[DNSOP] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

Hello everyone, Paul Hoffman: > We're still not done yet. I took a hiatus from finishing the list of > definitions that people wanted more scrutiny on, but will start that > again soon. I hope we'll be done with that list by mid-April and then be > ready for WG last call. I noticed that the lates

Re: [DNSOP] Fwd: New Version Notification for draft-wessels-dns-zone-digest-00.txt

Wessels, Duane: > >> On Apr 4, 2018, at 4:01 AM, Shane Kerr wrote: >> >> One issue is that the algorithm proposed requires that the recipient who >> is generating a digest has to store basically the entire zone before >> beginning the digest calculation, s

Re: [DNSOP] Fwd: New Version Notification for draft-wessels-dns-zone-digest-00.txt

Duane, Wessels, Duane: > > This draft proposes a technique and new RR type for calculating and verifying > a message digest over the contents of a zone file. Using this technique, the > recipient of a zone containing the new RR type can verify it for completeness > and correctness, especially

Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

All, Matthijs Mekking: > > > On 24-03-18 14:48, Joe Abley wrote: >> On Mar 24, 2018, at 13:49, Jared Mauch wrote: >> >>>     isc/bind can and perhaps should implement logging for these >>> rrtypes that say they may be going away so folks can see the impact. >> >> I'm actually surprised to see t

Re: [DNSOP] DNS Camel Viewer

Bert, bert hubert: [tl;dr, check out https://powerdns.org/dns-camel/ ] Cool! > If you know of RFCs that should or should not be on the list, please edit > dns-rfcs.js on https://github.com/ahupowerdns/dns-camel/ I think that's fine, but probably some discussion is necessary before a PR? (I'm ha

Re: [DNSOP] [v6ops] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt

ai. [ snippity ] > zw. Your list is missing bf., which does not appear to have any IPv6 name servers right now. It also counts quite a few more than my checks: gf. mq. mh. mv. ni. xn--lgbbat1ad8j. ye. zw. I'm not sure what your methodology is exactly, but I put mine on GitHub: https://

Re: [DNSOP] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt

Stephane, Stephane Bortzmeyer: > On Mon, Nov 27, 2017 at 09:32:00AM +, > Shane Kerr wrote > a message of 45 lines which said: > >> I just ran a check, and there are 23 TLD without any name servers >> that support IPv6. > > Can you detail the methodology?

Re: [DNSOP] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt

Joe, Joe Abley: > Hi Fred, > > [I haven't read Jordi's draft; I'm just responding to what I've read in this > thread.] Me too. > On Nov 25, 2017, at 14:00, Fred Baker wrote: > >> One thing you might want to think about: the root servers are all >> IPv6-capable today and serve requests using

Re: [DNSOP] draft-ietf-dnsop-isp-ip6rdns

All, Paul Hoffman: > > On 16 Nov 2017, at 20:12, Lee Howard wrote: > >> I updated this draft months ago, based on feedback from the previous >> WGLC, >> and it expired without comment. I’ve refreshed it, and would like to ask >> again for reviews (especially if anything has changed in the past >

Re: [DNSOP] About draft-ietf-dnsop-extended-error

Viktor, Viktor Dukhovni: > On Mon, Nov 13, 2017 at 06:02:11PM -0800, Wes Hardaker wrote: > >> Tony Finch writes: >> It can be argued that NODATA (pseudo rcode, I know) is an "error" as well as NXDOMAIN... >>> >>> Or, neither of them are errors :-) >> >> We'll remove the restriction in

Re: [DNSOP] New I-D for OCSP over DNS

Dr. Pala, Dr. Pala: > Hello all, > > As suggested by some people from other WGs, I just wanted to cross-post > this message here since the proposal heavily rely on DNS and can be > leveraged in many different environments (e.g., Server and Client > (browsers) authentication, document validation,

Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error

I guess that I understand your concern, but we don't have any way to authenticate servers in DNS today and we already send error messages back. I'm happy with error codes that are informational, but don't change client behavior. Yes, I realize that users may be tricked, but that's also the case

Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error

Tim, At 2017-07-25 12:04:04 -0400 tjw ietf wrote: > This draft was the only one which seemed to have broad support in some form > during the meeting last week. To be fair, I think that we could say that this was the only one having complete support during the meeting. Several drafts had support

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-wireformat-http-01.txt

stem Operations of the IETF. > > > > Title : DNS wire-format over HTTP > > Authors : Linjian Song > > Paul Vixie > > Shane Kerr > > Runxia Wan > &

Re: [DNSOP] DNSOP Call for Adoption: draft-hardaker-rfc5011-security-considerations

Tim, At 2017-03-16 03:16:50 -0400 tjw ietf wrote: > We've had a lot of WG discussion on this, and it seems relevant to do a > formal call for adoption. If there are outstanding issues raised during > the CfA, time in Chicago will be set aside to have those discussions. > > > This starts a Ca

Re: [DNSOP] Kindly review draft-woodworth-bulk-rr-05.txt

John, At 2017-02-15 10:33:50 + "Woodworth, John R" wrote: > I fully understand we are scheduled to hold an interim meeting > tomorrow and have a Iot to think about but am hoping at least a > handful of you may have a cycle or two left in you to look at our > updated draft (-05). > > We welc

Re: [DNSOP] New Version Notification for draft-hardaker-rfc5011-security-considerations-02.txt

Warren, I am still wondering about the: 3 * (DNSKEY RRSIG Signature Validity) / 2 Term in the draft, which I see survived the update. Why is this not just the DNSKEY RRSIG Signature Validity? In principle once the signature has expired it cannot be used to replay the old DNSKEY RRset right?

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

Bill, At IETF 96 in Berlin, Warren gave a presentation discussing how Google is using this in their recursive servers. Here's the link to the recorded video for the whole dnsop session: http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_DNSOP&chapter=chapter_1 For me the most inter

Re: [DNSOP] NSEC3 aggressive use for unsigned zones

John, At 2016-11-27 15:18:18 - "John Levine" wrote: > >What are the consequences of the authoritiative server returning > >synthesized unsigned NSEC3 RRs upon being signalled by the resolver > >using an EDNS option? > > A message to the world that there is no need to sign your zones, > be

Re: [DNSOP] Would you please review our draft on deploying new DNSSEC crypto algorithms?

Mark, At 2016-11-25 15:45:08 +1100 Mark Andrews wrote: > > > > Sorry for being stupid and ignorant here, but again, is there an RFC > > which says you need multiple signatures? > > Yes. RFC4035 and RFC6840. Note the words "entire zone". You can't > have two algorithm is use without multiple

Re: [DNSOP] Would you please review our draft on deploying new DNSSEC crypto algorithms?

Mark, At 2016-11-16 08:39:37 +1100 Mark Andrews wrote: > In message <20161116000530.19ed4...@pallas.home.time-travellers.org>, Shane > Kerr writes: > > Dan, > > > > At 2016-11-15 12:41:01 + > > Dan York wrote: > > > The draft is at either of:

Re: [DNSOP] Heads-up - draft about "letting localhost be localhost" in SUNSET4 that really should be in DNSOP

Andrew, At 2016-11-21 12:16:41 -0500 Andrew Sullivan wrote: > On Mon, Nov 21, 2016 at 03:50:08PM +, Ray Bellis wrote: > > As has been mentioned before, there's (currently) no process for this, > > but that doesn't mean we can't ask. The lack of process doesn't mean > > it's impossible. >

[DNSOP] [OT][rant-ish] Electronics & business models (was DNSSEC operational issues long term)

Ondřej, At 2016-11-17 01:02:10 +0100 Ondřej Surý wrote: > > Given the low margin, my suspicion is that most CPE manufacturers would NOT > > want > > to add in any additional components to solve what for them would be an edge > > case in terms of volume. > > This is the main problem. Most CP

Re: [DNSOP] Heads-up - draft about "letting localhost be localhost" in SUNSET4 that really should be in DNSOP

Ted, Isn't this more-or-less the same as .ONION then? We're searching for a label-based switch to disable DNS? An alternate interpretation would be that this is something that could be added to RFC 6303, "Locally Served DNS Zones". While that RFC is only about reverse DNS now, one could step back

Re: [DNSOP] Would you please review our draft on deploying new DNSSEC crypto algorithms?

Dan, At 2016-11-15 12:41:01 + Dan York wrote: > The draft is at either of: > > https://datatracker.ietf.org/doc/draft-york-dnsop-deploying-dnssec-crypto-algs/ > https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-04 > > Please send any comments to the list or to us as

Re: [DNSOP] DNS-in-JSON draft

Paul, At 2016-09-05 10:21:40 -0700 "Paul Hoffman" wrote: > On 5 Sep 2016, at 0:47, Shane Kerr wrote: > > > First, it seems like it might be nice to have a way to express RDATA > > in > > DNS presentation format. The document is very clear that no way is &

Re: [DNSOP] DNS-in-JSON draft

Tony, At 2016-09-05 11:22:48 +0100 Tony Finch wrote: > Shane Kerr wrote: > > > > It occurs to me that maybe we want an option to have arrays of RRset > > instead of arrays of RRs? > > If you do that, how do you represent the covering signature(s)? I'm not su

[DNSOP] Self-describing RTYPE in the DNS, draft-levine-dnsextlang (was DNS-in-JSON draft)

John, At 2016-09-05 16:38:00 - "John Levine" wrote: > >First, it seems like it might be nice to have a way to express RDATA in > >DNS presentation format. The document is very clear that no way is > >provided for this, but it seems like it would be really, really useful. > > If you want t

Re: [DNSOP] DNS-in-JSON draft

Paul, At 2016-09-03 15:43:34 -0700 "Paul Hoffman" wrote: > Greetings again. I have updated my draft on describing DNS messages in > JSON. I still don't think that this WG needs to adopt this given that it > is, as far as I can tell, thinly implemented. I think it's probably > about baked enou

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

Paul, At 2016-08-10 16:54:39 -0700 "Paul Hoffman" wrote: > [[ A month later, we're still eager to hear responses to the draft. We > got a few that we have incorporated for a new version, but want to be > sure we're on the right track before we move ahead. ]] I'm back from vacation and catchin

Re: [DNSOP] The Larger Discussion on Differences in Response Drafts

Tim, [ Apologies for coming late to the party. I was on vacation. ] At 2016-08-16 08:57:04 -0400 Tim Wicinski wrote: > In Berlin we had two presentations on different methods of returning > multiple responses: > > https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/ > > h

Re: [DNSOP] AAAA for e.root-servers.net

Bill, At 2016-08-28 21:28:19 -0700 william manning wrote: > Actually, any of the root ops have that data. I suspect this is a > "pre-opening", to gauge reachability of the prefix before public commit. > That was the operational practice for the 20+ years I was active in root > ops. Can you ple

Re: [DNSOP] AAAA for e.root-servers.net

Ray, At 2016-08-26 18:40:40 +0100 Ray Bellis wrote: > On 26/08/2016 17:57, 神明達哉 wrote: > > I just noticed e.root-servers.net has : > > > > % dig @a.root-servers.net e.root-servers.net +short > > 2001:500:a8::e > > > > It seems to be added very recently: > > http://root-servers.org/arc

[DNSOP] Possible issues with DNS over HTTP wire format draft

Hello, There are a few suggestions about the DNS over HTTP draft made off-list, which I will try to characterize here: * We should expand the motivations to explain why DNS over HTTP makes sense at all. * We should restrict the protocol to TLS. I am happy to expand the motivation section, al

Re: [DNSOP]  Working Group Last Call draft-ietf-dnsop-resolver-priming

All, At 2016-08-04 20:03:35 -0400 Tim Wicinski wrote: > Remember the Resolver Priming draft? This thing has been kicking around > for a good solid 5 years. It stalled for a few years waiting for the > busy authors perform some updates. > Then Paul Hoffman took the reins and has done a great jo

Re: [DNSOP] new dnsop related draft: RFC5011 security considerations

Wes, At 2016-08-01 15:00:52 -0700 Wes Hardaker wrote: > The following draft, authored by Warren and I, might be of interest to > the dnsop crowd: > > https://tools.ietf.org/html/draft-hardaker-rfc5011-security-considerations-00 > > [it currently does not have a home] Reading this document it

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

Tim, At 2016-07-22 21:39:41 -0400 Tim Wicinski wrote: > I know we've just started talking about this, and the authors are still > sorting out a few things, but the sense of the room we received was to > adopt it, work on it, etc. > > It appears they have simplified it in the -01 version. > >

[DNSOP] JavaScript implementation of DNS over HTTP wire format draft

s with the same server that the script itself comes from. * The type specifying the DNS transport requested was changed to X-Proxy-DNS-Transport since the browser will not add unknown header fields when sending a POST command. Source for the server proxy can be found at: https://github

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

John, At 2016-07-11 01:02:19 -0400 "John R Levine" wrote: > I agree that a protocol that had versioning and signalling and negotiation > and other stuff would be cool, but it wouldn't be DNS. With respect to > the stuff in the manifesto, I think it needs to take another step back and > figur

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

George, I *do* want people to consider radical positions - although I feel very strongly that we should focus on an evolutionary path for the technology. What I mean is that we should not feel constrained by the DNS as it is today when thinking of ideal solutions, *but* that we should at some poi

[DNSOP] JavaScript use case for DNS-over-HTTP (was Call for Adoption: draft-song-dns-wireformat-http)

John, At 2016-07-11 23:50:05 - "John Levine" wrote: > I'd also want to change some of the motivation text. To me, by far > the most likely scenario here is javascript applications that want to > do DNS queries, e.g. for SRV, but can't because javascript doesn't let > you do that. Now the s

[DNSOP] The case for the UDP flag on DNS-over-HTTP (was Call for Adoption: draft-song-dns-wireformat-http)

John, At 2016-07-11 23:50:05 - "John Levine" wrote: > >Please review this draft to see if you think it is suitable for adoption > >by DNSOP, and comments to the list, clearly stating your view. > > Yes, we should adopt it. It needs some work, but what draft doesn't. > > >Please also in

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

Marek, At 2016-07-11 22:26:00 -0500 Marek Vavruša wrote: > > You get queueing for free, but not pipelining and out-of-order > responses, that has to be defined. > The draft mentions this, but I think at this point it should just > depend on HTTP/2, > as it's the only way to get decent performanc

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

Paul, At 2016-07-12 07:00:17 -0400 Paul Wouters wrote: > On Mon, 11 Jul 2016, Tim Wicinski wrote: > > > The draft is available here: > > https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/ > > > > Please review this draft to see if you think it is suitable for adoption by > > DNSO

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

b page here for pull requests: https://github.com/shane-kerr/DNSManifesto I'm not really sure what the next steps are, if any. One fear I have is that nobody is looking at the overall architecture of the DNS, and so we'll end up muddling along one patch at a time, forever. Hopefully

[DNSOP] Love for draft-bellis-dnsext-multi-qtypes (was The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state "Candidate for WG Adoption")

Paul, At 2016-07-06 07:34:03 -0700 "Paul Hoffman" wrote: > On 6 Jul 2016, at 3:54, Ray Bellis wrote: > > > On 06/07/2016 10:09, fujiw...@jprs.co.jp wrote: > >> * My idea > >> > >> I prefer multiple query sections (with some restrictions) > >> and merged answers. > >> > >> multiple query

Re: [DNSOP] Fwd: I-D Action: draft-tldr-sutld-ps-01.txt

Ted, What a great document! I had not read the -00 version, so this was basically new to me. I am not sure how you managed to document so many problems without hinting at a solution, but I think this document does it pretty well. What's your intention with this document? Do you want this to be

Re: [DNSOP] I-D Action: draft-ietf-dnsop-resolver-priming-07.txt

Stephane, At 2016-05-05 17:47:48 +0200 Stephane Bortzmeyer wrote: > On Sat, Mar 19, 2016 at 10:57:26AM -0400, > Paul Hoffman wrote > a message of 49 lines which said: > > > With respect to the DO bit, there was a suggestion: > > Resolvers SHOULD send DO, and should try validate (if it get

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

review-dns-over-http-03.txt has been successfully submitted by Shane Kerr and posted to the IETF repository. Name: draft-shane-review-dns-over-http Revision: 03 Title: A review of implementation DNS over port 80/443 Document date: 2016-05-03 Group: Individual

Re: [DNSOP] New Version Notification for draft-bortzmeyer-dname-root-02.txt

Stephane, At 2016-04-29 16:35:41 +0200 Stephane Bortzmeyer wrote: > On Fri, Apr 29, 2016 at 04:31:15PM +0200, > Shane Kerr wrote > a message of 49 lines which said: > > > I think I said this in person but I don't know if I ever wrote it > > down. > >

Re: [DNSOP] Fwd: New Version Notification for draft-song-dns-wireformat-http-03.txt

Adrien, Thanks for your comments. At 2016-05-03 05:14:31 + "Adrien de Croy" wrote: > Some general comments: > > I don't think you can claim that https provides data integrity or > privacy any more, since MitM proxies are abundant. Can you explain this further? TLS is designed to provide

Re: [DNSOP] New Version Notification for draft-bortzmeyer-dname-root-02.txt

Stephane, At 2016-04-29 15:57:27 +0200 Stephane Bortzmeyer wrote: > No objection from the AS112 operators was received. Now, what do you > think of this draft? Should we continue or is it a bad idea (or a good > one, but hopeless?) I think I said this in person but I don't know if I ever wrote

  1   2   3   >