All
Donald and Mark have worked out the issues on the DNS Cookies draft,
mostly around the issue of returning an error code (no), and getting an
official Option-Code (10).
This starts a Working Group Last Call for draft-ietf-dnsop-cookies
Current versions of the draft is available here:
Hi,
I think that Andrew's effort to distinguish between a domain name and
a DNS name is useful. It gives us some clear terminology to use to
discuss domain names that wish to use a non-DNS name resolution
method.
RFC6761 introduces a mechanism for the handling of these types of cases.
In the
Paul Wouters p...@nohats.ca wrote:
You would only add it to the question for DNSKEY of the root.
Yes.
Maybe only after you determined a validation failure, so you clearly
have the wrong trust anchor.
No, the point of this option is to signal to the root what trust anchors
are in use by the
I hope you don't mind replying publicly to this, because I think you did a
very good thing describing it as a one-act play. (Seriously.) Kinda like
why we parody Harry Callahan at times. (That's Dirty Harry's name for
those under the age of, oh 50.)
On 7/1/15, 16:59, Warren Kumari
On 7/2/15, 6:02, DNSOP on behalf of Hugo Maxwell Connery
dnsop-boun...@ietf.org on behalf of h...@env.dtu.dk wrote:
Hi,
I think that Andrew's effort to distinguish between a domain name and
a DNS name is useful. It gives us some clear terminology to use to
discuss domain names that wish to use
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 07/02/2015 10:05 AM, Edward Lewis wrote:
You're right. To underscore, it's because of the groups that
don't engage, and have no responsibility to do so, that the IETF
has to defend itself.
It wouldn't take much work
Keep in mind that
Edward Lewis edward.le...@icann.org wrote:
RFC 5483, section 2.4 talks about this (and gives an example plus a
citation of an errant RFC) - although related to regular expressions in
NAPTR Resource Record RDATA fields, not to the domain name. This does
mention the impact on on-the-wire DNS
On 7/1/15, 18:37, DNSOP on behalf of str4d dnsop-boun...@ietf.org on
behalf of st...@i2pmail.org wrote:
I admit to being highly surprised that you are unfamiliar with the
P2P-Names draft[0], given that it pre-dates the later .onion-only
draft.
I don't read everything, and I'm not usually
On 7/2/15, 8:51, Edward Lewis edward.le...@icann.org wrote:
What I mean by rules inconsistently applied is a case of apparently
mis-aligned RFCs on ENUM. In one RFC, domain names were presented as
conversions to ASCII and the other following the rules of the old RFC for
escaping characters.
manning wrote:
There in lies the problem. These systems have no way to disambiguate a
local v. global scope.
It seems like the obvious solution is to ensure that these nodes do
NOT have global scope, i.e. No connection to the Internets
and no way to attempt DNS
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
On 2July2015Thursday, at 16:44, Robert Edmonds edmo...@mycre.ws wrote:
Have a look at the later HTTP/1.1 RFCs (7230) and the URI generic syntax
RFC (3986). RFC 7230 defines http URIs, but it relies on the
agreed. but a “reserved string” registry isn’t the way to do that… at least
in a scaleable fashion.
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
On 2July2015Thursday, at 10:34, Paul Vixie p...@redbarn.org wrote:
manning wrote:
... STRONGLY suggests
the ^G registration was done prior to RFC 1123 being written.
I think, this whole discussion (particularly Ed Lewis’s POV about wire formats
v. readings from RFC 1034 suggest
reopening the can’o’worms that was/is the IDN debate and 8bit clean, native
Unicode, etc.
Regarding Andrew S.
On 2July2015Thursday, at 18:21, Robert Edmonds edmo...@mycre.ws wrote:
manning wrote:
There in lies the problem. These systems have no way to disambiguate a
local v. global scope.
It seems like the obvious solution is to ensure that these nodes do
NOT have global scope, i.e.
On Thu, Jul 02, 2015 at 10:34:42AM -0700, Paul Vixie wrote:
what the internet should be doing is defining escape mechanisms for
non-internet systems, rather than saying we are the only thing you can
use.
The Internet _has_ done that. Unfortunately (and I do think it's
unfortunate), the
Hi Mr Lewis, and list,
I believe that you are making a category error here. The key
point is that the softwares that are using the domain name (dot
separated network identifier) labeling system do not wish to
use the DNS architecture for name to address resolution, at all.
However, they may
manning wrote:
... STRONGLY suggests that “domain-looking-string” is , in fact, a
host that is identified using the Internet DNS.
i agree with this interpretation, which means, it's the spec itself
that's wrong, not hugo's interpretation of it. the internet people
didn't love .UUCP addresses
manning,
The defense is the defense of the privacy of their community
due to the commonality of the URI format.
(protocol)://(domain-looking-string)/(path).
Open that with the right software and all is good, no privacy is
lost, and the DNS is not involved. Open it with
DNS based software and
Hum… “domain-looking-string” … Per RFC 1945, we read:
3.2.2 http URL
The http scheme is used to locate network resources via the HTTP
protocol. This section defines the scheme-specific syntax and
semantics for http URLs.
http_URL = http: // host [ : port ] [ abs_path ]
If that is the case, that these folks don’t want to use the DNS name-address
resolution at all, then
there should be no objection to use of those labels in the DNS by folks who DO
wish to use DNS
for its intended purpose. If House Finch Feathers OY applies to ICANN for
the .ONION TLD,
On 7/2/15, 12:04, DNSOP on behalf of Hugo Maxwell Connery
dnsop-boun...@ietf.org on behalf of h...@env.dtu.dk wrote:
I believe that you are making a category error here. The key
point is that the softwares that are using the domain name (dot
separated network identifier) labeling system do not
On 7/2/15, 13:34, DNSOP on behalf of Paul Vixie dnsop-boun...@ietf.org
on behalf of p...@redbarn.org wrote:
manning wrote:
... STRONGLY suggests that “domain-looking-string” is , in fact, a
host that is identified using the Internet DNS.
i agree with this interpretation, which means, it's
As an idea: some months ago dkg looked at hooking up unbound to an
upstream resolver over TCP/TLS. It works, but it isn't ideal right
now. Our findings:
A) client and server together negotiate TLS 1.2 (that's good!)
B) client doesn't appear to even try to validate the certificate
C) client
On Thu 2015-07-02 16:20:30 -0400, Tom Ritter wrote:
As an idea: some months ago dkg looked at hooking up unbound to an
upstream resolver over TCP/TLS. It works, but it isn't ideal right
now. Our findings:
A) client and server together negotiate TLS 1.2 (that's good!)
B) client doesn't
In message d1bafc60.ca8f%edward.le...@icann.org, Edward Lewis writes:
On 7/2/15, 13:34, DNSOP on behalf of Paul Vixie dnsop-boun...@ietf.org
on behalf of p...@redbarn.org wrote:
manning wrote:
... STRONGLY suggests that =E2=80=9Cdomain-looking-string=E2=80=9D is , in
fact, a
host that
25 matches
Mail list logo
