RFC 6724 specifically says: "Rules 9 and 10 MAY be superseded if the
implementation has other
means of sorting destination addresses. For example, if the
implementation somehow knows which destination addresses will result
in the 'best' communications performance."
So, technically, if an
The document candidly categorizes itself, in Section 1, as “a pedantic network
protocol description”. As such, I think it might be appropriate for it to
describe DNS names as appearing in the only form that is unambiguous and
implementation-agnostic, i.e. dot-terminated FQDN.
Having said
The whole phenomenon is what I would call “context-sensitive resolution”
(although we don’t like neologisms, so I’m not proposing that).
Context-sensitive resolution encompasses “split DNS”, “views”, policy-based
resolution (blacklists, etc.), GSLB algorithms, geolocation, even plain old
The trouble with "split horizon" is that it is a term of inter-network routing
of much older and more-established provenance, and thus to use it for DNS can
be viewed as a usurpation, and ultimately, confusing. (I know Cricket had the
same observation, circa 2000).
I occasionally use
Suggestion to the (first, Section 1) suggestion:
s/go detected/be detected/
- Kevin
-Original Message-
From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of
Sent: Thursday, January 25, 2018 2:24 PM
To: Suzanne Woolf
-Original Message-
From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Peter van Dijk
Sent: Tuesday, August 29, 2017 4:09 AM
To: dnsop@ietf.org
Subject: Re: [DNSOP] Definition of QNAME (Was: I-D Action:
draft-ietf-dnsop-terminology-bis-06.txt
On 29 Aug 2017, at 0:20, Darcy Kevin
Please understand that I don't have a strong opinion on the DNS terminology
discussion, _per_se_, but I do have them with regard to semantics, logic and
proper citation, which was kind of my prior life, before I even got into DNS,
or even Information Technology (at various times an English
Honestly, I think the part of RFC 1034 (Section 4.3.2) that says "change QNAME
to the canonical name in the CNAME RR, and go back to step 1" is just treating
the string "QNAME" as a variable in a loop. One will note that the analogous
portion of the *resolver* algorithm (5.3.3) says "change the
Your English literacy is fine. I believe sentences which are logically
connected into one super-sentence have been accidentally severed into one
sentence and one non-sentence.
That super-sentence would be:
"In the case where a zone that contains HINFO RRSets is served from an
authority server
With respect to
"ptr names of NS addresses should match the associated A/ names"
you might want to
a) avoid or modify the term "ptr names", since there is nothing about the PTR
record type which *restricts* it to the reverse-mapping function, and
b) disclaim the recommendation as only a
, _per_se_.
- Kevin
From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Jacques Latour
Sent: Tuesday, February 09, 2016 12:00 PM
To: Warren Kumari; Darcy Kevin (FCA); dnsop
Subject: Re: [DNSOP] DNS Delegation Requirements
Hi,
Sent something relating to this on DNS-OARC th
-Original Message-
From: Mark Andrews [mailto:ma...@isc.org]
Sent: Tuesday, February 09, 2016 6:35 PM
To: Darcy Kevin (FCA)
Cc: dnsop
Subject: Re: [DNSOP] DNS Delegation Requirements
In message <cd765f8368da465ea1078e20e77ea...@mxph4chrw.fgremc.it>, "Darcy Kevin
(FCA)" writes:
>
My 2 cents…
I don’t think any DNS RFC should be tied to any specific element of Internet
routing technology. Keep it relatively generic and avoid mention of “ASes” and
the like, since this RFC may outlive the use of ASes for Internet routing.
”Path diversity”, “link diversity”, “network-level
It's not really a "normal" query, in the sense that it's not coming from a stub
resolver, typically, and the initiator wouldn't normally assume that recursion
is required to fetch the answer.
So, in the typical case I'd expect RD=0.
Not sure that the "although" verbiage below really adds any
I'm still reading through this draft, but a few things jumped out at me right
away. Some of them are typos, others merely "style" issues, one is a
jargon/definitional issue, and then one observation that goes somewhat deeper.
TYPOS: Intro: "not a necessarily" should be simply "not necessarily".
Seems there's some hair-splitting here over the definition of the word
"service".
While RFC 6335 assumes, more than it defines, what a "service" encompasses, it
offers the following "functional" definition of the kind of things which need
and use "service name"s:
Service names are the unique
I think there’s something elided from that sentence, since, irrespective of
semantics, “An outcome of that the convention …” isn’t even
grammatically-correct English.
- Kevin
From: DNSOP
Let's see, millions of full-service resolvers, times the packet-count
differential between UDP and TCP, times the average reload/restart frequency of
those full-service resolvers per day/week/month. Can't a case be made from
sheer volume?
Sorry for bringing math into the discussion.
It would be wise to get a clear statement of preference from the Internet root
operators on this, but don't forget that whatever gets defined in IETF
standards, and implemented in leading DNS software packages, also affects
private enterprises too. Many of us run internal roots and I, for one,
- Kevin
-Original Message-
From: Joe Abley [mailto:jab...@hopcount.ca]
Sent: Friday, October 16, 2015 5:18 PM
To: Darcy Kevin (FCA)
Cc: dnsop WG
Subject: Re: [DNSOP] Closing out issues in draft-ietf-dnsop-resolver-priming
On 16 Oct 2015, at 16:36, Darcy Kevin (FCA) w
This may be a little off-topic for DNSOP, but has anyone considered submitting
Errata for RFC 4291 to add the word "physical" before the word "interface" to
the sentence
"A packet received on an interface with a destination address of loopback must
be dropped"
?
Because, as it stands, if
Ed,
I find the document useful, and illuminating, but that it suffers from
one glaring omission -- no substantive discussion of the relationship between
domain names and URIs (the related term "URN"[1] is mentioned in Section 1.2,
but never expanded upon). To be sure, while the
In retrospect, the definition of the “http” and “https” schemes (i.e. RFC 7230)
should have probably enumerated clearly which name registries were acceptable
for those schemes, so that the following language from RFC 7320 (a BCP) could
be invoked against any attempt by an app – Onion or anyone
My 2 cents...
The presence or absence of a PTR record is, to me, like a reverse-DNS Literacy
Test.
History records that Literacy Tests didn't fare too well, as voting
requirements, in the real (non-IT) world. In fact, they were just thin
pretexts for racial bigotry, recognized as such, and
Regarding the statement query type ANY 'matches all RR types CURRENTLY IN THE
CACHE'.
Actually, there's nothing in RFC 1034 that clearly *mandates* this behavior --
Section 3.7.1 says only that a QTYPE of * matches all RR types, whereas
Section 5.3.3 (Algorithm) says to return the answer or
My 2 cents...
It is commonplace, these days, to clearly enumerate MANDATORY TO IMPLEMENT
elements of a protocol specification. But, this was not the typical practice at
the time RFCs 1034/1035 was written, and I don't think we can apply modern
standards-parlance retroactively. RFC 1034/1035
I understand cache-only or caching-only DNS server as being, strictly
speaking, one which loads *no* authoritative data. Typically, this is a
resolver which populates its cache by initially priming with some root hints
configuration, and then walking down the namespace hierarchy via iterative
Asynchronous makes no sense to me. In what way is an AXFR asynchronous?
Authoritative transfer? As opposed to what? Non-authoritative transfer?
Authoritative seems rather redundant in that phrase -- AXFRs are always
comprised of authoritative data, aren't they?
The reference to full zone
]
Sent: Thursday, October 30, 2014 4:35 PM
To: Darcy Kevin (FCA)
Cc: dnsop
Subject: Re: [DNSOP] Comments on draft-ietf-dnsop-qname-minimisation-00.txt
the term query minimization appeals to me since each server, during
iteration, sees the minimum substring of the qname needed
29 matches
Mail list logo
