Re: [DNSOP] Unknown DNS RDATA type presentation syntax vs. e.g. TXT records?

At Sun, 9 Feb 2020 04:28:14 -0500, Viktor Dukhovni wrote: > ---> An implementation MAY also choose to represent some RRs of known type > ---> using the above generic representations for the type, class and/or > ---> RDATA, which carries the benefit of making the resulting master file >

Re: [DNSOP] valid value range for SOA REFRESH/RETRY/EXPIRE

At Fri, 18 Oct 2019 10:49:40 +1100, Mark Andrews wrote: > > > > one obvious interpretation is that REFRESH/RETRY/EXPIRE are signed 32 > > > > bit integers. > > > > > > They are all intervals. How do you have a negative interval? > > > > I actually didn't expect they can be negative. My main

Re: [DNSOP] valid value range for SOA REFRESH/RETRY/EXPIRE

At Fri, 18 Oct 2019 10:25:29 +1100, Mark Andrews wrote: > > one obvious interpretation is that REFRESH/RETRY/EXPIRE are signed 32 > > bit integers. > > They are all intervals. How do you have a negative interval? I actually didn't expect they can be negative. My main question is whether

[DNSOP] valid value range for SOA REFRESH/RETRY/EXPIRE

I have a question for which I believe there's an answer already that I couldn't find: what's the valid range for SOA REFRESH/RETRY/EXPIRE values? RFC1035 says: REFRESH A 32 bit time interval ... RETRY A 32 bit time interval ... EXPIRE A 32 bit time value ... and

Re: [DNSOP] Fwd: HTTPSSVC record draft

At Tue, 23 Jul 2019 17:04:43 +0200, Matthijs Mekking wrote: > But as soon as clients start querying for ANAME (and not address > records) meaning it will chase the target itself, the DNS server > actually does not have to do a target lookup anymore. True, but my understanding is that the key

Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information

At Sat, 29 Jun 2019 22:55:07 +, Paul Hoffman wrote: > > - I think the RESINFO RDATA specification (at least its wire format, > > and preferably also the presentation format) should be more clearly > > specified. At least to me it was not very clear, and I'm afraid > > this can lead to

Re: [DNSOP] Request for adoption: draft-sah-resolver-information

At Thu, 27 Jun 2019 18:44:09 +, Paul Hoffman wrote: > Greetings. We have again updated draft-sah-resolver-information > based on comments from this mailing list. We think that this is > ready for adoption by the WG so that the initial use of the protocol > (to be able to determine the URI

Re: [DNSOP] ANAME precedence [issue #58]

At Fri, 26 Apr 2019 09:16:58 +0200, Matthijs Mekking wrote: > > Also, especially if both and A sibling records are available, > > what's the purpose of ANAME in the first place if it's (effectively) > > not used? > > > > I'm sure I'm just confused and don't understand the expected usage, >

Re: [DNSOP] ANAME precedence [issue #58]

At Wed, 24 Apr 2019 11:44:37 +0200, Matthijs Mekking wrote: > I would like to start separate threads on the remaining issues of the > ANAME draft. One issue that remains to be solved is whether having an A > or record next to the ANAME should take precedence or not. > > Draft:

Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

At Wed, 20 Mar 2019 12:38:05 +0100, Joe Abley wrote: > > Often as an industry we may discuss various solutions that are great for oneself but don’t scale when looking at the big picture. > > I think what we are seeing is the fundamental tension between privacy and control. You need to give up

[DNSOP] dnsop meeting agenda?

There's still no link to meeting agenda of dnsop sessions on the IETF104 agenda page: https://datatracker.ietf.org/meeting/104/agenda/ Is it some kind of operation error or is the agenda still unavailable? If it's the latter, when can we expect to see it? -- JINMEI, Tatuya

Re: [DNSOP] draft-pusateri-dnsop-update-timeout-02.txt

At Mon, 4 Mar 2019 19:45:02 -0500, Tom Pusateri wrote: > Thanks to the great feedback, we were able to update the document to > better match the preferences of the working group and address the > outstanding concerns. > > A new version of I-D, draft-pusateri-dnsop-update-timeout-02.txt > > has

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

At Fri, 8 Mar 2019 12:03:27 -0500 (EST), Paul Wouters wrote: > [my last email in this thread. I don't think we are progressing and I'd > like to give others a chance to participate in this thread. But feel > free to reply] > > >> But assigned and left completely opague is not really

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

I've read draft-ietf-dnsop-serve-stale-03. In addition to the high-level draft organization matter I mentioned in another thread, here are my other comments on this version: - Section 4: The definition of TTL in [RFC1035] Sections 3.2.1 and 4.1.3 is amended to read: TTL [...] If the

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

At Fri, 1 Mar 2019 15:54:39 -0500, Dave Lawrence wrote: > > I'm not sure a standards track document that updates RFC 1034/1035 > > should be recommending a minimum TTL. > > As previously noted, we're making no such recommendation and that will > be clarified. The first definition of "resolution

Re: [DNSOP] draft-fujiwara-dnsop-fragment-attack-01.txt

At Mon, 04 Mar 2019 20:43:14 +0900 (JST), fujiw...@jprs.co.jp wrote: > > - Section 3 > > > >Linux 2.6.32, Linux 4.18.20 > >and FreeBSD 12.0 accept crafted "ICMPv6 Packet Too Big" packet and > >path MTU decreased to 1280. > > > > I suspect this often doesn't matter much in practice.

Re: [DNSOP] draft-fujiwara-dnsop-fragment-attack-01.txt

At Fri, 01 Mar 2019 21:14:48 +0900 (JST), fujiw...@jprs.co.jp wrote: > Dear DNSOP, > > I submitted draft-fujiwara-dnsop-fragment-attack-01. > >https://tools.ietf.org/html/draft-fujiwara-dnsop-fragment-attack-01 > > It summarized DNS cache poisoning attack using IP fragmentation > and

Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt

At Wed, 20 Feb 2019 07:51:51 -0500, Joe Abley wrote: > The crux of the use case seems to be that it is commonplace for names in the DNS to exist for short periods of time and that for some applications a name that overstays its welcome can cause an operational problem. > > While I can understand

Re: [DNSOP] Call for Adoption: draft-song-atr-large-resp

At Fri, 8 Feb 2019 00:39:27 +0530, Mukund Sivaraman wrote: > > The draft doubles the number of packets involved in a legitimate > > exchange; it more than doubles the number of packets involved in a > > spoofed exchange. About half of these packets are ICMP > > packets. Without the draft, ICMP

Re: [DNSOP] Call for Adoption: draft-song-atr-large-resp

At Fri, 18 Jan 2019 18:55:16 +0100, Benno Overeinder wrote: > We discussed this work (draft -01) in Montreal, and different opinions wrt. adoption were expressed. In the past months, the authors pushed a draft version -02 that addressed and resolved some of these comments. > > This starts a

Re: [DNSOP] [v6ops] Fwd: New Version Notification for draft-v6ops-xie-network-happyeyeballs-00.txt

At Fri, 21 Sep 2018 14:31:50 +0800, Davey Song wrote: > I just submited a new draft intending to provide better connectivity from > network side function . Comments are welcome. Some quick observations: - I don't see why the intended status is Standards Track. It seems to be a document

Re: [DNSOP] Minimum viable ANAME

At Fri, 21 Sep 2018 12:03:13 +0100, Tony Finch wrote: > > Perhaps primary server implementations may eventually have some level > > of support that makes this provisioning much less painful (in a way > > other than performing on-demand resolution). If and when many popular > > implementations

Re: [DNSOP] Minimum viable ANAME

At Wed, 19 Sep 2018 14:55:45 +0100, Tony Finch wrote: > I think there's still a need to standardize ANAME, to provide at least > some level of zone file portability between the various existing > proprietary versions of this feature. And to provide something usable > by zone publisters on a much

Re: [DNSOP] Mirja Kühlewind's Yes on draft-ietf-dnsop-refuse-any-07: (with COMMENT)

At Thu, 13 Sep 2018 17:25:04 +0200, "Mirja Kuehlewind (IETF)" wrote: >>> I'm wondering if it would make sense to provide stronger guidance that the >>> conventional ANY response SHOULD be provided if TCP is used as TCP already >>> provides a retrun routability proof...? Also maybe provide a

Re: [DNSOP] Call for Adoption: draft-bortzmeyer-rfc7816bis

On Tue, Jul 24, 2018 at 9:33 AM Tim Wicinski wrote: >This starts a Call for Adoption for draft-bortzmeyer-rfc7816bis >The draft is available here: https://datatracker.ietf.org/doc/draft-bortzmeyer-rfc7816bis/ >Please review this draft to see if you think it is suitable for adoption

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

At Fri, 27 Jul 2018 16:43:44 -0400, Warren Kumari wrote: > > Right, so I think one main question is why the root DNS zone case is > > so special that a protocol extension is justified. Personally, I'm > > not yet fully convinced about it through the discussion so far. As > > several other

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

At Fri, 27 Jul 2018 10:59:53 +0800, Davey Song wrote: > > The problem is that when you have every recursive server in the world with > > a copy of the root zone from “random places” you want to reduce the > > possible error spaces into manageable chunks when things go wrong which > > they will.

[DNSOP] comments on draft-pwouters-powerbind-01

I don't have a strong reason for opposing the proposal, but, frankly, the need for this wasn't clear to me just by reading the draft. I see the potential problems with evil parents, but the draft didn't convince me that it's an important and critical enough to justify a new protocol extension

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

At Fri, 22 Jun 2018 16:00:51 -0400, Paul Vixie wrote: > >> Minor clarification here: ANAME doesn't require the authoritative server > >> itself to do recursion; it requires it to have access to a reursive > >> server. > > > > I suppose, but that seems to me a distinction without a difference. >

Re: [DNSOP] BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)

At Mon, 18 Jun 2018 17:51:26 -0400, Shumon Huque wrote: > Client applications delegate address sorting to name resolution functions > like getaddrinfo() - correct? > > Doing some quick tests of getaddrinfo() just now on a recent *NIX machine, > it appears to return addresses sorted roughly in

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

At Thu, 31 May 2018 18:18:16 +, "Wessels, Duane" wrote: > > - This digest can't be incrementally updated, [...] > > Incremental updates could be supported if the working group feels it is > important. We have a working proof-of-concept implementation of this that > hashes individual RRsets

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

At Wed, 23 May 2018 15:32:11 +, "Weinberg, Matt"

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

At Wed, 23 May 2018 14:39:40 -0400, Warren Kumari wrote: > Just so the WG knows, the authors (myself in particular) had some > productive discussions with Job at the RIPE meeting in Marseille. > As a reminder, this mechanism is designed to measure the *user* impact of > the

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

At Tue, 22 May 2018 13:50:20 +0100, Neil Cook wrote: > I’m wondering what the status of this draft is? It expired in > September last year. Is there still a desire to get this pushed > through? At least I (and my employer, Infoblox) are interested. The business

Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested

At Fri, 13 Apr 2018 16:47:07 +0200, bert hubert wrote: > In writing this server and while consulting with some other implementors, I > for now have decided that in 2018 it makes no sense to: > > 1) chase CNAMEs that point to another zone It may not even make sense to

Re: [DNSOP] Call for Adoption: draft-dupont-dnsop-rfc2845bis

At Tue, 10 Apr 2018 14:56:53 -0400, tjw ietf wrote: > This draft was widely accepted in Singapore, and the chairs were waiting for > a revision before starting a call for adoption. That revision took a few > months > but it has been done and DNSOP is ready to start a call for

Re: [DNSOP] raising the bar: requiring implementations

At Fri, 6 Apr 2018 04:35:44 +, Evan Hunt wrote: > > At Thu, 5 Apr 2018 13:46:29 -0400, > > tjw ietf wrote: > > > > > What is work: An "informational" document being used as standard is people > > > taking a submitted (expired) draft as "standard"? > > > >

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

At Thu, 05 Apr 2018 17:15:47 +, Job Snijders wrote: > While the chair notes awareness of the point I raised, I’d like the be > explicit to avoid any confusion. > > This document is *not* ready for publication. There is no implementation > report available for review and

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

At Tue, 3 Apr 2018 21:32:04 +, "Wessels, Duane" wrote: > 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

Re: [DNSOP] raising the bar: requiring implementations

At Thu, 5 Apr 2018 13:46:29 -0400, tjw ietf wrote: > What is work: An "informational" document being used as standard is people > taking a submitted (expired) draft as "standard"? I'm not sure how to interpret it (not even sure if it's a question to me)...but I guess what I

Re: [DNSOP] raising the bar: requiring implementations

At Wed, 4 Apr 2018 11:22:33 +0200, Petr Špaček wrote: > >> This is actually quite a good example of another problem: > >> Client-subnet was documented for Informational purposes; it was > >> already in wide use in the public internet and had an EDNS opt code > >> codepoint

Re: [DNSOP] I-D Action: draft-muks-dnsop-dns-catalog-zones-04.txt

At Sat, 10 Mar 2018 21:56:15 +0530, Mukund Sivaraman wrote: > > I've read draft-muks-dnsop-dns-catalog-zones-04. I see the motivation > > of automating the synchronization of primary/secondary configurations. > > Personally, however, I'm not (yet?) convinced that this should be >

Re: [DNSOP] meeting agenda?

Thanks, I'm looking forward to seeing it:-) On Fri, Mar 9, 2018 at 11:05 AM, Tim Wicinski <tjw.i...@gmail.com> wrote: > > Hi > > I have one and was waiting for Suzanne to land in Puerto Rico and we can > confirm but you should see that soon enough. > > thanks! > t

[DNSOP] meeting agenda?

dnsop meeting agenda hasn't yet been uploaded on https://datatracker.ietf.org/meeting/agenda.html Is there at least an unofficial meeting agenda so we can have more specific idea of what will be discussed? Thanks. -- JINMEI, Tatuya ___ DNSOP mailing

Re: [DNSOP] I-D Action: draft-muks-dnsop-dns-catalog-zones-04.txt

At Sat, 3 Mar 2018 22:07:57 +, Ray Bellis wrote: > > Abstract: This document describes a method for automatic DNS zone > > provisioning among DNS primary and secondary nameservers by storing > > and transferring the catalog of zones to be provisioned as one or > > more

[DNSOP] comments on draft-dupont-dnsop-rfc2845bis-01

I have a couple of high-level comments on rfc2845bis-01: - Section 11.1 and Appendix B says "the MAC must be considered to be invalid until it was validated". This is fine, but it was not immediately clear to me specifically how RFC2845 was updated based on this principle until I actually

Re: [DNSOP] Updated KSK Sentinel document

At Wed, 21 Feb 2018 08:53:23 -0500, Warren Kumari wrote: > > - General > > I think it's worth pointing out that SERVFAIL can be returned for > > various other reasons and the detection mechanism relying on it > > isn't reliable. This is probably okay given the purpose

Re: [DNSOP] Updated KSK Sentinel document

At Mon, 12 Feb 2018 15:28:50 -0500, Warren Kumari wrote: > Anyway, we've finally posted an updated version - > https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/ I've read draft-ietf-dnsop-kskroll-sentinel-01 (this is my first careful read of this draft) and

Re: [DNSOP] meaning of tag "match" for CAA RDATA

At Thu, 8 Feb 2018 08:25:35 +1100, Mark Andrews wrote: > > I happen to have this question while reading RFC6844: what does the > > "matching" mean in the following description of Section 5.1? > > > > Tag: The property identifier, a sequence of US-ASCII characters. > > > >

[DNSOP] meaning of tag "match" for CAA RDATA

I happen to have this question while reading RFC6844: what does the "matching" mean in the following description of Section 5.1? Tag: The property identifier, a sequence of US-ASCII characters. Tag values MAY contain US-ASCII characters 'a' through 'z', 'A' through 'Z', and the

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

At Fri, 26 Jan 2018 14:24:10 -0500, Ted Lemon wrote: > > IMO, however, that doesn't mean we can casually use the fact to > > silence objections when the requirement level might actually be too > > strong. In my understanding and also according to my experiences, > > MUST

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

At Thu, 25 Jan 2018 20:22:36 +, Tony Finch wrote: > > Could you be more specific about it? It may be a minority > > implementation, but I thought traditional stub resolver > > implementations in BSD variants systems (getaddrinfo/gethostbyname > > with the backend of

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

At Fri, 26 Jan 2018 17:32:33 +0100, Petr Špaček wrote: > > as these are requirements without a user-configurable knob. If the > > actual intent was just to specify the default behavior with a > > configurable knob, I'd expect SHOULD-variants are used in cases like > > these.

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

At Fri, 26 Jan 2018 12:47:29 +0100, Petr Špaček wrote: > > I myself don't have a particular opinion on whether to send it to the > > IESG, but I don't think it's ready for it based on my understanding of > > the WG discussion so far. In particular, I don't think I saw a wg >

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

At Mon, 22 Jan 2018 11:18:08 -0500, Suzanne Woolf wrote: > Please focus feedback on: Is this draft ready to go to the IESG for > approval as an RFC? If not, can you suggest specific changes it > needs? I myself don't have a particular opinion on whether to send it to the

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

At Thu, 25 Jan 2018 16:03:08 +, Tony Finch wrote: > > I am not nearly so enthusiastic about an important component of > > the draft. Specifically, I'd like to suggest that while the > > requirement for recursive resolvers to return NXDOMAIN for "localhost." > > is

Re: [DNSOP] 4035 3.1.4.1 erratum? dig ds root-servers.net @X.root-servers.net

At Thu, 11 Jan 2018 11:29:20 -0800, Ólafur Guðmundsson wrote: > > > In the spirit of being helpful to recursive resolvers the right answer > > IMHO > > > is the referral from the > > > zone above the query name. > > > > I'm not sure if I understand you so please let me be

Re: [DNSOP] 4035 3.1.4.1 erratum? dig ds root-servers.net @X.root-servers.net

At Wed, 10 Jan 2018 17:05:00 -0800, Ólafur Guðmundsson wrote: > >That is, it answers as if it is authoritative and the DS record does > >not exist. DS-aware recursive nameservers will query the parent zone > >at delegation points, so will not be affected by

Re: [DNSOP] 4035 3.1.4.1 erratum? dig ds root-servers.net @X.root-servers.net

At Thu, 4 Jan 2018 08:12:26 +1100, Mark Andrews wrote: > The reply also has to work for STD13 clients which already know > about the child zone. The NODATA response is the correct one despite > it requiring more work for a DNSSEC client. Section 2.2.1.1 of RFC 3658 also explains

Re: [DNSOP] Measuring DNS TTL Violations in the wild

At Sat, 2 Dec 2017 20:09:25 +0530, Mukund Sivaraman wrote: > > Strictly speaking yes, it is the same as when a Secondary does not update > > the zone for a long time. > > An authoritiative server operator knows what the consequence of setting > SOA RDATA fields is. It isn't the

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

At Thu, 16 Nov 2017 22:02:33 -0800, Paul Vixie wrote: > > Realistically, I expect virtually everyone will implement 3, given how > > this kind of feature is sold in the marketing context. ,,, > > me too. that's why, in: > >

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

At Wed, 15 Nov 2017 05:41:04 +, P Vix wrote: > >1) when the request explicitly signals it is ok; > >2) when the request groks EDNS but might or might not understand > > a staleness option; or > >3) in all cases. > > > >My current understanding is that you and Paul are of

Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale

At Thu, 07 Sep 2017 13:42:45 -0700, Paul Vixie wrote: > > If we don't work on a proposal like this, I'd love to see a specific > > counter proposal that doesn't violate the current protocol > > specification (i.e., using a cached answer beyond its TTL) and still > > avoids

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

At Tue, 15 Aug 2017 13:40:00 +0200 (CEST), Mikael Abrahamsson wrote: > > If it's a commonly-used name, isn't this a one-time event, though? The > > happy eyeballs client asks for A and , gets A because it was in the > > cache, but also winds up in the cache, and then

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

At Sat, 29 Jul 2017 14:27:57 +0100, Tony Finch wrote: > > - One possible idea of another extended error code: one that indicates > > a type-ANY query is responded with just one type of RRset when there > > can be more. > > Note that it is almost always the case that ANY

Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from 神明達哉

Hi, sorry for the delayed response. At Tue, 25 Jul 2017 16:53:12 -0400, Joe Abley wrote: > https://mailarchive.ietf.org/arch/msg/dnsop/zy86pvg139PaKFXo-BO6SPUfh3k > > > I've reviewed the 04 version. I still do not think it's ready to move > > forward as it still abuses

Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use

At Tue, 18 Jul 2017 18:20:56 +0530, Mukund Sivaraman wrote: > Dealing with water torture and some other attacks have had several > band-aid approaches that don't always work well in practice. The most > promising (and what feels correct) is > draft-ietf-dnsop-nsec-aggressiveuse,

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

At Mon, 03 Jul 2017 11:23:01 +0200, "Peter van Dijk" wrote: > > In that sense I see some disparity with the > > ALIAS record of Amazon Route53, one of the earliest (and probably > > largest) players of the idea: > > - Supporting other types of records than and A

[DNSOP] comments on draft-muks-dnsop-dns-opportunistic-refresh-00

I've read draft-muks-dnsop-dns-opportunistic-refresh-00. In short my current impression is: "interesting but not yet very convincing idea". High-level comments: It's an interesting idea. However, depending on its main motivation I'm not sure how effective it is. As it's listed in the dnsop

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

At Tue, 27 Jun 2017 13:15:52 -0400, Dave Lawrence wrote: > > Also, it's not clear to me why the TTL is set to 1 second. Since > > it's actually expired, a zero TTL seems to be a more sensible choice > > here (a similar feature of unbound uses a zero TTL). If there's a > >

Re: [DNSOP] DNSOP Call for Adoption: draft-kristoff-dnsop-dns-tcp-requirements

At Fri, 12 May 2017 06:45:52 -0500, John Kristoff wrote: > > I've read draft-kristoff-dnsop-dns-tcp-requirements-02. > > Thank you for taking the time to read, review, and comment on it! > > > I think RFC7766 already pretty clearly states TCP is a MUST. > > IETF RFC 7766 does

Re: [DNSOP] DNSOP Call for Adoption: draft-kristoff-dnsop-dns-tcp-requirements

At Fri, 12 May 2017 11:35:26 +0100, Tony Finch wrote: > > I'm not sure if DDNS update bolsters the need for TCP. In > > my understanding DDNS update exchanges are largely done over UDP > > today (e.g., ISC's nsupdate utility uses UDP by default): > > Well, that depends on

Re: [DNSOP] DNSOP Call for Adoption: draft-kristoff-dnsop-dns-tcp-requirements

At Thu, 11 May 2017 06:57:51 -0400, tjw ietf wrote: > There was a lot of consensus during our last meeting in Chicago that this > should move forward, so it's time that we do so. > > This starts a Call for Adoption for: > draft-kristoff-dnsop-dns-tcp-requirements > > The

Re: [DNSOP] Call for Adoption draft-hunt-dnsop-aname

At Thu, 11 May 2017 06:55:55 -0400, tjw ietf wrote: > I'm caught up with my day job, and the discussion on this has died down, > but it looks like the work is moving along smoothly, it's time to kick off > a Call for Adoption on this document. (well, maybe late). > > This

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

At Tue, 18 Apr 2017 13:54:54 +0100, Tony Finch wrote: > > I also wonder whether it's okay to allow ' or A' and ANAME to > > coexist for the same owner name. Shouldn't it be prohibited similar > > to that CNAME and other types can't coexist? > > From the point of view of a

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

At Fri, 7 Apr 2017 18:11:39 +, Evan Hunt wrote: > Here's the new ANAME draft I mentioned last week. > > This is similar to existing non-standard approaches (ALIAS records, > CNAME-flattening, etc) but also sends the ANAME record to the resolver so > that, if the resolver

Re: [DNSOP] Second Working Group Last Call: draft-ietf-dnsop-refuse-any

On Thu, Mar 16, 2017 at 12:11 AM, tjw ietf wrote: > During the first WGLC of draft-ietf-dnsop-refuse-any, several issues were > raised by the working group that needed to be addressed. The Authors > addressed the issues, but the changes are enough that there should be a >

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

On Mon, Jan 9, 2017 at 4:43 AM, Ray Bellis wrote: > I've submitted a -01 revision to address most of the feedback received > so far. I have some minor comments on this version. - Section 3.1 IP Version: The IP protocol version number used by the client, as defined in the

Re: [DNSOP] draft-ietf-dnsop-terminology-bis and "recursive resolver"

At Thu, 19 Jan 2017 13:51:33 -0500, Ted Lemon wrote: > I'm updating a document for another working group, and Ralph Droms > in his last call comments on that document asked me to use > "recursive resolver" instead of "caching name server", referencing >

[DNSOP] comments on draft-vixie-dns-rpz-04

This is my technical comments on draft-vixie-dns-rpz-04 that I promised to submit when I responded to the wg adoption call. Some of the points may be considered "out of scope" if the draft really intends to just describe what's currently deployed, but I nevertheless made these points for the

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

On Tue, Dec 20, 2016 at 7:16 AM, tjw ietf wrote: > The draft is being present as "Informational", and the point here is to > document current working behavior in the DNS (for the past several years). > It is obvious that some feel this draft is a large mistake, but like >

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any

Sorry for the delayed response. I've been unusually busy for these several weeks... At Sat, 3 Dec 2016 12:44:47 -0500, Olafur Gudmundsson wrote: > > I've read the 03 version of the document. I do *not* think this is > > ready for publication since I still believe we should not

Re: [DNSOP] Second Working Group Last Call - draft-ietf-dnsop-nsec-aggressiveuse

At Tue, 13 Dec 2016 14:13:27 -0500, tjw ietf wrote: > We felt another formal Working Group Last call was needed, though hopefully > shorter. > > This starts a Working Group Last Call for: > "Aggressive use of NSEC/NSEC3" > draft-ietf-dnsop-nsec-aggressiveuse > >

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any

At Fri, 25 Nov 2016 19:50:48 -0500, tjw ietf wrote: > Please review the draft and offer relevant comments. Also, if someone feels > the document is *not* ready for publication, please speak out with your > reasons. > > *Also*, if you have any opinion on changing the document

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-aggressiveuse-06.txt

At Thu, 17 Nov 2016 11:36:04 +0100, Ralph Dolmans wrote: > Maybe I'm missing something, but it is not clear to me whether this > document (-06) allows generation of NODATA answers using matching NSEC > records that do not have the QTYPE set in the type bitmap. > > I don't see

Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00

At Tue, 15 Nov 2016 04:21:05 +0100 (CET), Ondřej Surý wrote: > > I'm not sure how you can be so sure about the author's assumption when > > the draft itself doesn't explicitly clarify the assumption (maybe > > based on an off-list conversation with Fujiwara-san?), but if

Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00

At Tue, 15 Nov 2016 03:12:43 +0100 (CET), Ondřej Surý wrote: > > Yes, it is. Otherwise, what would be the point of using the NS in the > > parent instead of the authoritative one? > > Let me rephrase it, the assumption here is that parent NS are: > "as good as they get to

Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00

At Wed, 02 Nov 2016 15:10:18 +0900 (JST), fujiw...@jprs.co.jp wrote: > I submitted draft-fujiwara-dnsop-resolver-update-00 that tries to > improve resolver algorithm. > > Please read it and comment. As promised, here are specific comments on the draft text: - general: the title and file name

Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00

At Wed, 02 Nov 2016 15:10:18 +0900 (JST), fujiw...@jprs.co.jp wrote: > I submitted draft-fujiwara-dnsop-resolver-update-00 that tries to > improve resolver algorithm. > > Please read it and comment. In short: I support the motivation of the draft with some big reservations about specific

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

At Wed, 26 Oct 2016 14:55:49 +0800, "Jiankang Yao" wrote: > >If it's also intended to be used between recursive and > > authoritative, how does it handle a delegation answer? > > Most RRs needed to parallel query are normally located in the same zone. That's probably true, but

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

At Mon, 24 Oct 2016 21:58:42 +0800 (GMT+08:00), "Jiankang Yao" wrote: > We have updated it to the new version, simplying the mechanism. > pls kindly help to review it. any comments are welcome. > If Seoul DNSOP meeting has some time slot for it, I will appreciate it. A few

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-edns-key-tag

At Thu, 6 Oct 2016 03:00:36 -0400, Tim Wicinski wrote: > The authors for this document have addressed some lingering outstanding > issues, and it appears ready for Working Group Last Call. > > This starts a Working Group Last Call for: > draft-ietf-dnsop-edns-key-tag > >

Re: [DNSOP] Working Group Last Call

At Thu, 6 Oct 2016 02:49:34 -0400, Tim Wicinski wrote: > >> I did some fix up - how do you like: > >> "If a validating resolver gets a query for cat.example.com, it will > >> query the example.com servers and will get back an NSEC (or NSEC3) > >> record starting that there

Re: [DNSOP] Working Group Last Call

At Tue, 4 Oct 2016 17:39:55 -0400, Warren Kumari wrote: > > - Section 3: this section also has an issue of "recursive resolver". > > Although it may not be as critical as other part of the draft since > > it's only used as an example scenario, it's probably better to not >

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

At Mon, 29 Aug 2016 12:01:20 -0400, Warren Kumari wrote: > > On 29/08/2016 13:46, william manning wrote: > >> You should probably wait until it's formally added to the root hints > >> file. > > > > It is in the root hints file. > > It's also not super urgent. I didn't mean to

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

At Mon, 22 Aug 2016 21:57:12 +, "Wessels, Duane" wrote: > > - Section 5.3 > > > > Unless the zone operator has intentionally added > > "_ta-" records to the zone, the server MUST generate an NXDOMAIN > > response. > > > > Perhaps a pedantic comment, but I

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

At Fri, 19 Aug 2016 16:31:18 -0700, "Paul Hoffman" wrote: > > - Section 2 > > > >Therefore, it is important that resolvers be able to cope with > >change, even without relying upon configuration updates to be > > applied > >by their operator. > > > > If we

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

At Wed, 10 Aug 2016 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. ]] > > We

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

At Sat, 13 Aug 2016 14:01:52 +0300, Andreas Gustafsson wrote: > There is nothing wrong with existing resolvers that use the same > timeout and retransmission strategies for priming queries as for any > other query, and it seems wrong to me that a specific retransmission >

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

On Fri, Jul 22, 2016 at 6:39 PM, Tim Wicinski wrote: > This starts a Call for Adoption for draft-bellis-dnsop-session-signal > > The draft is available here: > https://datatracker.ietf.org/doc/draft-bellis-dnsop-session-signal/ > > Please review this draft to see if you think

  1   2   3   >