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:
ht
Paul Wouters 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 population
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 r
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" wrote:
On 7/2/15, 6:02, "DNSOP on behalf of Hugo Maxwell Connery"
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 a non-DNS name resolution
>method.
Until thi
On 7/1/15, 18:37, "DNSOP on behalf of str4d" 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 focusing on this. That's the
trouble with volunteers.
On 7/2/15, 8:51, "Edward Lewis" 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. Specifically, a back-
-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
Edward Lewis 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 representations.
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 wis
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, there
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 an
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
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
On 7/2/15, 12:04, "DNSOP on behalf of Hugo Maxwell Connery"
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 wish to
>use the DNS architecture for name to a
On 7/2/15, 13:34, "DNSOP on behalf of Paul Vixie" 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 the spec itself
>that's wrong, not hugo's in
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 do
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 does
In message , Edward Lewis writes:
> On 7/2/15, 13:34, "DNSOP on behalf of Paul Vixie" 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 is identified using the Internet DNS.
> >
> >i
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 In
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 wrote:
>
>
> manning wrote:
>> ... STRONGLY suggests that “domain
Edward Lewis wrote:
> To me a domain name is: a sequence of bits that, when rendered in hex
> notation, can look like this:
>
> 0x03 0x61 0x62 0x63 0x07 0x65 0x78 0x61 0x6d 0x70 0x6c 0x65 0x00
>
> That is what is sent over the wire, through ports and is deposited in
> memory of name servers. Not
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. reco
manning wrote:
> 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 = "ht
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
On 2July2015Thursday, at 16:44, Robert Edmonds 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 URI
> generic sy
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
On 2July2015Thursday, at 18:21, Robert Edmonds 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. No conn
27 matches
Mail list logo
