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 implemen
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 that,
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
round-
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 "schizophr
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
Cc: dn
-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 major
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
The more generalized form, of course, is for the client to provide a bitmap
and/or an enumerated list, of the RRTYPEs it wishes to receive and/or not
receive.
One of the sticky problems to deal with, however, is how the server should
respond if it implements some, but not all of the RRTYPEs req
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 sof
Kevin
-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 , "Darcy Kevin
(FCA)" writes:
> Thats a very good catch. Restrictions on *hostna
, _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 this morni
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 r
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 va
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 k
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 [mailto:dns
- 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,
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, d
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.
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 take
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 "Authorit
).
- Kevin
From: Roy T. Fielding [mailto:field...@gbiv.com]
Sent: Wednesday, August 12, 2015 1:05 PM
To: Darcy Kevin (FCA)
Cc: Alec Muffett; Joe Hildebrand; Edward Lewis; Ted Hardie; i...@ietf.org;
Richard Barnes; dnsop@ietf.org; Mark Nottingham
Subject: Re: [DNSOP] Last Call: (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 e
Add yet another category of websites to block in corporate web proxies: DNS
query anonymizers.
- Kevin
From: DNSOP [mailto:dnsop-boun.
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
Intriguing. I think there might be a temptation to take this idea one step
further and say that preference should be given to the *smallest* RRset
possible -- to reduce the degree of amplification. But that would be a mistake.
It would, for instance, discriminate IPv4 over IPv6 (since A records
According to their own statement, Cloudflare perceived the "problem" to be the
code-complexity of their DNS implementation -- in particular, they
characterized the complexity of their (former) QTYPE=*-handling code as
"enormous". Their "fix" was to feign ignorance (RCODE=NOTIMP) of QTYPE=* and
So you're thinking it's more likely that we'll get folks to understand this new
type, that's designed to frustrate QTYPE=* queries in a more-or-less graceful
way, than it is to convince them to stop making QTYPE=* queries in the first
place?
Don't get me wrong -- I would actually *applaud* the
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
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 c
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 iterat
"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 zo
- Kevin
-Original Message-
From: Paul Vixie [mailto:p...@redbarn.org]
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
Some form of "optimization", perhaps?
I too have been tempted to comment on the fact that there is no QNAME that is
being "minimized" here (which would imply making it shorter; not the gist of
the proposal at all).
If we're stuck on the term "minimization", make it clear that it's not the
QNAM
36 matches
Mail list logo
