Re: [DNSOP] Fwd: [EXT] New Version Notification for draft-toorop-dnsop-dns-catalog-zones-01.txt

Doesn't that preclude scenarios in which a zone transitions from one catalog to another? On 4/16/20 09:17, Willem Toorop wrote: An authoritative nameserver might have two or more catalog zones, each associated with their own set of configuration. In that case, the member zone that was configur

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

I like this idea, and am aware of at least two other proposals that would (or would have) benefited from a new OPT record [EDNS header flag bit] to communicate "incomplete response" as distinct from "truncated response" (the latter encouraging retry over a transport supporting larger messages,

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

The following excerpts allow for and even encourage software written against this document in its present form to behave in ways that will hinder adoption of future changes, and should probably be altered in order to foster the desired compatibility. Section 2 requires "Each ZONEMD RR MUST spe

Re: [DNSOP] proposal: Covert in-band zone data

Class is a bad idea for a few reasons, but principal among them in my mind is the fact that per section 4.2 of RFC 1034, the concept of zone is subordinate to the concept of class—even if zone cuts were in the same places, example. in a new class would still be a distinct zone from example. in

Re: [DNSOP] question regarding draft-ietf-dnsop-aname-03.txt/proof of non-existence of the ANAME record

When an authoritative server receives a request with QTYPE= (without loss of generality with respect to A or any future ANAME-affected address record) for a domain name in a signed zone, there is either a relevant ANAME or there is not. In the case where there a relevant ANAME, the server

Re: [DNSOP] ANAME high-level benefit question

On 5/10/19 03:12, Brian Dickson wrote: Have any "closed system" implementations of non-standard apex-CNAME hacks, committed publicly to neutral ANAME operations, presuming ANAME as currently envisioned? Oracle are happy to see progress on ANAME and intend to support it. I personally have be

Re: [DNSOP] What should ANAME-aware servers do when target records are verifiably missing?

On 4/12/19 07:34, Matthijs Mekking wrote: I think the logic suggested for ANAME is given this example: 1. Have ANAME and A and sibling address records. 2. Look up ANAME target A and target records. 3. If there is no positive answer (SERVFAIL, NXDOMAIN, NODATA) keep sibling address re

Re: [DNSOP] What should ANAME-aware servers do when target records are verifiably missing?

In further support of preserving sibling records when target chasing comes back negative, I'd like to further explore my offhand mention of "A and/or records". For a domain owner wanting to use a currently IPv4-only service provider (names withheld) while still supporting IPv6, the logica

Re: [DNSOP] What should ANAME-aware servers do when target records are verifiably missing?

On 4/11/19 23:45, Matthew Pounsett wrote: On Thu, 11 Apr 2019 at 20:02, Richard Gibson wrote: The first problem is for the owner of the ANAME-containing zone, for whom the upstream misconfiguration will result in downtime and be extended by caching to the MINIMUM value from their SOA, which

Re: [DNSOP] What should ANAME-aware servers do when target records are verifiably missing?

Responses inline. On 4/11/19 18:50, Matthew Pounsett wrote: On Wed, 10 Apr 2019 at 16:43, Richard Gibson wrote: The first problem is for the owner of the ANAME-containing zone, for whom the upstream misconfiguration will result in downtime and be extended by caching to the MINIMUM value

Re: [DNSOP] What should ANAME-aware servers do when target records are verifiably missing?

Responses below. On 4/9/19 16:04, Bob Harold wrote: If it gets an authoritative answer saying that there are no address records, then it should respect that answer.  If that is incorrect, then whatever gave that answer is broken or misconfigured and should be fixed. Perhaps I am missing some

[DNSOP] What should ANAME-aware servers do when target records are verifiably missing?

Copied from https://github.com/each/draft-aname/issues/54 per Tony Finch. The current draft specifies We treat missing address records (i.e. NXDOMAIN or NODATA) the same successfully resolving as a set of zero address records, and distinct from "failure" which covers error responses such as SE

Re: [DNSOP] ANAME discussion

3:38 PM, Richard Gibson wrote: This loop is one reason of several to eliminate inline resolution for ANAME if possible and minimize it otherwise, but is not quite as bad as it seems because all involved servers can—and should—avoid issuing queries that are redundant with an already-active request

Re: [DNSOP] ANAME discussion

This loop is one reason of several to eliminate inline resolution for ANAME if possible and minimize it otherwise, but is not quite as bad as it seems because all involved servers can—and should—avoid issuing queries that are redundant with an already-active request. But even if they don't, the

Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

On timekeeping: On 11/22/18 07:01, Sara Dickinson wrote: Section 7.5.1 Does "earliest-time" include leap seconds? Thanks for noticing this…after digging into it… The description specifies the number of seconds to be the number of seconds since the POSIX epoch ("time_t"). POSIX requires that

Re: [DNSOP] Fundamental ANAME problems

Responses inline. On 11/9/18 11:39, Tony Finch wrote: Richard Gibson wrote: First, I am troubled by the requirement that ANAME forces the zone into a dynamic zone. I don't see how it is possible to implement ANAME without some form of dymamic behaviour, either by UPDATEs on the primar

Re: [DNSOP] Fundamental ANAME problems

quot; should be "RRSIG". P.P.S. I think it has been discussed before, but this document should also introduce and use a new "Address RTYPE" registry or subregistry, rather than forever constraining ANAME exclusively to A and . On 11/2/18 17:00, Richard Gibson wrote: I

Re: [DNSOP] Further ANAME minimization /\ Ray convergence

This is such a salient point, and always draws me back towards a desire for accompanying questions. They wouldn't directly address exactly the issue handled by ANAME (the addresses of one host corresponding to those of a distinct [probably out-of-bailiwick] name), but might make it moot—or at l

Re: [DNSOP] Fundamental ANAME problems

I haven't reviewed the full draft yet, but am happy to see some people echoing my sentiments from earlier versions [1]. I particularly wanted to agree with some statements from Bob Harold. On 11/2/18 15:20, Bob Harold wrote: Another option to give users is a non-updating fallback A record, that

Re: [DNSOP] review: draft-wessels-dns-zone-digest-04.txt

On 10/31/18 19:50, Joe Abley wrote: It sounds wrong to me to say that identical instances of RRs would not be allowed in a zone. It's true though, right? It's not meaningful to include more than one resource record with the same (owner,type, class, TTL, RDATA) in the same RRSet, and hence al

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-terminology-bis-11

On 08/10/2018 11:51 AM, Giovane C. M. Moura wrote: The response is the entire DNS message that is sent in reply to a question. Great. Do you plan to define it in the document as well? Analogous to a "response" DNS message containing an "answer" (presumably consisting of zero or more records), I

Re: [DNSOP] I-D Action: draft-bellis-dnsext-multi-qtypes-06.txt

This is conceptually similar to [accompanying-questions], but limits all questions to share a QNAME. The result is a more concise payload and simpler processing logic at the expense of an ability to request e.g. (www.example.com, A) and (_443._tcp.www.example.com, TLSA) in one query. I can imag

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-07.txt

This update addresses all of my earlier comments with the exception of implementation-specific extension data using namespaced string keys (as opposed to negative-integer keys)—which I assume to be intentional because of the "String keys would significantly bloat the file size" text in Section

Re: [DNSOP] Current DNS standards, drafts & charter

I'd like to see something similar to what was done with HTTP (cf. https://tools.ietf.org/html/rfc7230#section-1 ), in which one or two foundational documents lay out the core concepts and data structures and then cross-link with others that flesh out more specialized aspects with an intent to p

Re: [DNSOP] A new version of mixfr

I really like this document, especially the changes to version 02. One comment: Section 3.6 (Replace an RRset) specifies that "RDLENGTH must be non-zero" _and_ that "The same syntax is used to delete an RRset and to replace an RRset with an RR whose RDLENGTH is zero". I think the former should

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

TSIGs cover "A whole and complete DNS message in wire format, before the TSIG RR has been added to the additional data section and before the DNS Message Header's ARCOUNT field has been incremented to contain the TSIG RR" (RFC 2845 section 3.4.1), and would therefore be sensitive to decompressi

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

I personally would rather see a single media type with a transport parameter than creation of a distinct media type for each transport (UDP, TCP, QUIC, …). On 03/21/2018 09:36 PM, Davey Song wrote: Hi folks, I just submit a updated version of dns wireformat over HTTP. This draft has been ad

Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-refuse-any-05.txt

That was literally the fastest turnaround I've ever experienced. All the changes look good to me; thank you very much. On 03/05/2018 04:47 PM, Joe Abley wrote: On 5 Mar 2018, at 15:00, Richard Gibson wrote: To re-raise my unaddressed points: • The document should include pl

Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-refuse-any-05.txt

To re-raise my unaddressed points: * The document should include planned text you mentioned acknowledging lack of a signal to indicate "partial response" for section 4.1/section 4.3 subset responses ([1]). * "Conventional [ANY] response" is used but not defined ([2]). * The document need

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-05.txt

On 02/28/2018 12:21 PM, Jim Hague wrote: We'll discuss this. We absolutely meant for negative keys to be restricted to closed systems. Allowing string keys in addition is an interesting idea; off the cuff, I wonder whether folk will want to pay the file space penalty. The cost of interoperabilit

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-05.txt

Thank you so much for the changes, I am confident that this format is now in a state where my organization could build on top of it to suit our needs. I have a handful of remaining comments below, mostly describing ways in which that process could be made more straightforward and standardized.

Re: [DNSOP] I-D Action: draft-huston-kskroll-sentinel-04.txt

Indeed, the concept of "address record" has also come up in https://tools.ietf.org/html/draft-ietf-dnsop-aname-01 , which even suggests (but does not specify) the creation of an IANA registry. On 01/29/2018 05:37 PM, Martin Hoffmann wrote: Warren Kumari wrote: Yes, you are right -- for all p

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

Comments on the latest ANAME draft: In Section 3.1, "records retrieved during ANAME <> resolution" looks like a typo. Should "<>" be ""? Also in Section 3.1, the first five paragraphs could be more explicit about resolving and adding address records instead of specifically A and/or (oth

Re: [DNSOP] Review of draft-ietf-dnsop-terminology-bis-08

On 12/21/2017 02:17 PM, Niall O'Reilly wrote: On 21 Dec 2017, at 16:06, Richard Gibson wrote: first, because it's consistent with the rest of the document in its current form (for example, the very next sentence after my quoted text describes how a fully qualified domain name &quo

Re: [DNSOP] Review of draft-ietf-dnsop-terminology-bis-08

On 12/21/2017 07:31 AM, Niall O'Reilly wrote: On 19 Dec 2017, at 7:09, Richard Gibson wrote: 1. "Domain name" is defined as «an ordered list of one or more labels… identifying a portion along one edge of a directed acyclic graph» (presumably starting at the root). I

Re: [DNSOP] Review of draft-ietf-dnsop-terminology-bis-08

On 12/18/2017 10:20 PM, Martin Hoffmann wrote: That said, there seems to be a mistake in the text for the common display format: | so, in both English and C the first label in the ordered list is | right-most Previously this list was defined as being "ordered ordered by decreasing distance from

Re: [DNSOP] I-D Action: draft-yao-dnsop-accompanying-questions-04.txt

On Wed, Sep 20, 2017 at 3:45 AM, Jiankang Yao wrote: > *From:* Richard Gibson > *Date:* 2017-09-19 10:48 > *To:* dnsop > *Subject:* Re: [DNSOP] I-D Action: draft-yao-dnsop-accompanying- > questions-04.txt > In a more general sense, how are responders to generate—and how a

Re: [DNSOP] I-D Action: draft-yao-dnsop-accompanying-questions-04.txt

I have some questions about this draft. How should responders populate the COUNT fields when one record answers multiple accompanying questions? For example, assume example.com has an MX record but no A or (the latter two thus being covered by an authority section SOA): QUESTION example.com.

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

I'm assuming there's a very obvious answer to this question, but what would break if unsigned wildcard caching were covered by allowing DNSSEC-independent NSEC (and therefore https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse )? $ cat zones/github.io ; apex records github.io. 900 IN S

Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from Richard Gibson

On Wed, Jul 26, 2017 at 2:24 PM, Joe Abley wrote: > > On 26 Jul 2017, at 13:28, Richard Gibson wrote: > > > The need for such a signal also came up recently in > https://tools.ietf.org/html/draft-wkumari-dnsop-multiple- > responses-05#section-10 . But in this case part

Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from Richard Gibson

On Tue, Jul 25, 2017 at 4:52 PM, Joe Abley wrote: > >- There is no mechanism for signaling section 4.1/ section 4.3 > "partial > >response" behavior to clients (e.g., a new OPT record EDNS header flag > >bit > > dns-parameters.xhtm

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-03.txt

On Thu, Jul 6, 2017 at 5:17 AM, Jim Hague wrote: > > All the keys in those maps (and in every map, as far as I can tell) are > > strings, for which "unsigned" is a meaningless concept. > > No. All keys are unsigned ints, with values specified in the CDDL. We > should > make this more explicit in

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-03.txt

On Wed, Jul 5, 2017 at 8:05 AM, Jim Hague wrote: > Timestamps, on the other hand, I always regarded as a basic data type, > so naturally a structure. Plus, of course, there's one per > query/response item, so in a block the size savings are in the 10-15k > bytes region, which is rather more signi

Re: [DNSOP] I-D Action: draft-wkumari-dnsop-multiple-responses-05.txt

Comments: 1. There's a "www.exmaple.com" typo in the introduction. 2. It is very limiting for this functionality to rely upon DNSSEC, given that many practical cases still preclude its use. 3. Why have a composite value for EXTRA instead of just using one EXTRA record per domain (with a Priority fi

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-03.txt

I looked over this draft in detail, and found a handful of ambiguous points ("Clarifications" and "Potentially Missing Data" below). But more importantly, it is very close to defining a format that could replace much of my organization's in-house technology. Would you consider some generalizations

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

On Sun, Apr 9, 2017 at 3:56 PM, Peter van Dijk wrote: > Thank you for taking the time for this. My pleasure; this topic has frequently been on my mind over the past several years. Thank you for drafting it. *Section 3.1* >> > >> This section calls for limiting the TTL of cached address records

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

I'm happy to see progress being made on this front. Some comments: *Section 3.1* This section calls for limiting the TTL of cached address records to the lesser of the ANAME TTL and the TTL of the retrieved address records, but section 3 requires servers to follow chained responses. Are the TTLs

Re: [DNSOP] New draft for ALIAS/ANAME type

I don't think you can drop section 3.4 completely, but it should be updated to acknowledge Refuse-Any . Only behavior 2 (HINFO synthesization) allows total ignorance of special ALIAS behavior; every other (including conventional)

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

To re-raise my unaddressed points from the first Working Group Last Call: - There is no mechanism for signaling section 4.1/ section 4.3 "partial response" behavior to clients (e.g., a new OPT record EDNS header flag bit

Re: [DNSOP] [Ext] A nudge on the new terms in draft-ietf-dnsop-terminology-bis

On Mon, Feb 13, 2017 at 6:34 PM, Viktor Dukhovni wrote: > My beef > would be with the "zero or more" part, as applied to labels, since > zero length labels (if construed as actual labels rather than just > termination sentinels) do not occur except to terminate a domain > name. Otherwise, if the

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

On Mon, Feb 13, 2017 at 1:05 PM, Ólafur Guðmundsson wrote: > HINIFO is such a signal :-) > thus your request applies only to Send-one and Send-useful responses. > Correct, as I covered in my initial message. I do not think adding complexity will help at all. > > ... you want an overhead cost f

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

On Mon, Feb 13, 2017 at 1:02 PM, Wessels, Duane wrote: > Tools like dig, when asked to issue an ANY query over UDP can: > > 1) fail with "ANY over UDP is deprecated", or > That's not true, though, and tools have no way of knowing whether or not such a failure is appropriate without the very sign

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

On Mon, Feb 13, 2017 at 12:38 PM, Robert Edmonds wrote: > You think this would actually provide any sort of useful information? No > operator would understand what "MBZ: 0x" means without re-training, > and if you're re-training operators you may as well point them to this > document. I thi

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

On Mon, Feb 13, 2017 at 11:46 AM, Tony Finch wrote: > OK. But does an EDNS flag help? What if you are using old tools? If you are using old tools, then you don't get new conveniences (the same is true of using OPT class to specify a maximum payload size exceeding 512 bytes, using the DO bit to

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

On Mon, Feb 13, 2017 at 8:03 AM, Tony Finch wrote: > There are several ways to avoid this pitfall: > > Use TCP > > Look for an NSEC(3) record > > Query for the specific types you want to know about The pitfall comes from unexamined muscle-memory assumptions when inspecting a DNS response, so no

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

> > On Thu, Feb 9, 2017 at 8:47 PM, Richard Gibson wrote: > >> With full realization that this is coming very late in the game, we had a >> great deal of internal conversation within Dyn about implementing >> refuse-any, and came away unsatisfied with both the "subse

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

With full realization that this is coming very late in the game, we had a great deal of internal conversation within Dyn about implementing refuse-any, and came away unsatisfied with both the "subset" and "HINFO" approaches—the latter because of reasons that have already been covered, and the forme

Re: [DNSOP] DNSOP Digest, Vol 122, Issue 9

On Fri, 6 Jan 2017 13:01:10 -0500, Robert Edmonds wrote: > It can be rev'd in the same document that introduces a DNS address RR > for that address family :-) > Why not use Address Family like EDNS Client Subn