ot;secondary"
citizens, which was what Martin Luther King protested against.
That the discrimination, though somewhat but not sufficiently
illegally, still continues, as is demonstrated by BLM, is the
problem not addressed but rather obfuscated by not saying
"slave" or &qu
n have no opinion on the matter.
If people feel some ambiguity of 1035 merely because they
ignore 1034, there is no point to publish yet another RFC
for disambiguation, because the new RFC, either, won't
be read.
Read the RFCs.
Masatak
ponses
to IQUERY and 1034 clearly specifies QDCOUNT=1 for standard
queries and responses.
There is no ambiguity.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
RRs in a cyclic dependency as above.
"only sibling domain NS RRs"?
If my examples above are considered, there should be more cases.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
t
prohibit protocol extentions to allow standard
> queries have QDCOUNT>1,
modifying 1034/5 is fine but possibility/existence of such
modifications can not be a supporting fact for a false
statement that 1034 had admitted standard queries with
QDCOUNT>
early days.
> Note that the DNSOP WG Chairs ensure that the IETF Guidelines for
> Conduct, RFC 7154, are adhered to.
With proper interpretation of "respect", yes.
Note that meaning of "respect" was discussed in main IETF
list several months ago.
Mark Andrews wrote:
The only part of RFC 1035 that actually mentions a value is 4.1.2 and no
it doesn't prohibit other values.
No, of course. See my second mail of the thread.
Masataka Ohta
Your second message describes a standard query
fcs and, then,
mails you are responding, before writing huge amount
of abstract nonsenses.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Mark Andrews wrote:
The only part of RFC 1035 that actually mentions a value is 4.1.2 and no
it doesn’t prohibit other values.
No, of course. See my second mail of the thread.
Masataka Ohta
___
DNSOP mailing
Ted Lemon wrote:
Again, it does not say that explicitly.
Wrong.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Ted Lemon wrote:
I'm not seeing the place in RFC 1034 where it explicitly specifics any
value at all for QDCOUNT. Can you point to it?
See my second mail of the thread.
Masataka Ohta
___
DNSOP mailing list
ively must always be 1.
> It will be interesting to find out whether using QDCOUNT > 1
> in practice is useful.
Meaninglessness of queries matching multiple RR types
is already documented by 1035. See my first mail of the
thread.
.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
.
In this case, however, as the meaninglessness,
known from operational experiences on early
DNS, is already documented in 1035, you don't
have to reinvent a wheel such as IP options.
Masataka Ohta
___
DNSOP mailing list
DNSOP
ude inverse queries with QDCOUNT=0 and responses
to them with QDCOUNT>1 as is stated in 1035:
When the response to an inverse query contains one or more QNAMEs,
Anyway, w.r.t. letency, it is meaningless to have standard
queries with QDCOUNT>1.
Masa
d
service used a single type (MX) with a "preference" value in the RDATA
section which can order different RRs. However, if any MX RRs are found
in the cache, then all should be there.
Masataka Ohta
ogress on any of our work.
Recognizing DNSSEC hopeless and stop operating DNSSEC is a progress
on our work of DNS operations.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
nd rely on DNS cookie or something like that.
That is, "totally abandon DNSSEC and rely on DNS cookie or something
like that." is a constructive proposal.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
wer any questions or misunderstandings of those
positions during any subsequent debate.
I'm fine to continue such debate.
for example, here is my
statement on the quality and utility of DNSSEC, along with others':
Let me respond for or against it later in a separate
tar, "four eyes minimum" is not
so secure. So are six or more eyes.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
o, before mentioning the code, be aware of the relationship
between "the freedom of speech" and the code.
Masataka Ohta
PS
This message is sent after several days of "cooling off" period
as a proof that I'm not responding in rage.
an't
>> : compare actual operational/physical strength from
>> : their formal documents.
>
> This is an anecdote, that a logical reasoned argument.
That's your anecdote to mention "HSMs" or "four eyes minimum"
proven to be useless by diginotar.
ch might be what
: happened in diginotar.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ence is that, unlike cookies, TLS is safe against passive
MitM attacks of packet snooping.
So?
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Paul Hoffman wrote:
I see a very strong consensus in this thread against the proposals
from Ohta-san,
I can't see any as discussion is still ongoing.
Masataka Ohta
___
DNSOP mailing list
ons using a "four eyes minimum" approach. > Not surprisingly,
diginotar was equally strongly secure.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
for physical security
of DNSSEC and, instead, stop operating DNSSEC.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
cryptographically secure or had protected TLDs more securely
than diginotar?
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
was equally strongly secure.
Are there anyone who still think DNSSEC were cryptographically secure
or had protected TLDs more securely than diginotar?
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
;
> i think your primary argument is that DNSSEC solves the wrong
> problem,
No, my primary argument is that DNSSEC is not cryptographically
secure. It prevent MitM attacks on ISP chain but not on CA chain.
> and the best formulation of that concern that i have seen is
> here:
>
> https
^^
and the server certificates issued out to the public.
^^^
Masataka Ohta
___
DNSOP mailing list
DNSOP
inst which is to make intermediate intelligent
entities of CAs physically secure, which was demonstrated
by diginotar not secure at all.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.o
of my design, through which I puzzled by
too complicated operational practices of PKI.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Paul Hoffman wrote:> Given the higher level of scrutiny that BCPs garner,
Such a false sense of security is quite harmful to reduce
the end to end security of the Internet.
Masataka O
MitM attacks.
Which of my points, if any, are you saying, can not be
understood by you not so clealy?
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
fline,
HSMs? See above.
so "attacker knowing IP address" is
insufficient to forge answers.
I'm afraid you completely miss my point.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://
attacker knows IP addresses of detecting resolvers and
return unforged answers to them. So?
Unlike that, birthday attacks on resolvers are trivially detectable
by the resolvers.
Masataka Ohta
___
DNSO
eaf.
"The validation which is done by a resolver" is not compromised.
I merely mean MitM attacks on some part of the zone chain is
effective both to the resolver and the end-host.
Masataka Ohta
In order to achieve complete compromise, the ad
miss, among others, my point that:
it just
indicates that the value of deploying DNSSEC is often considered
lower than the cost.
is just wrong.
which has nothing to do with "better way".
Mas
to have demonstrated that PKI to
blindly trust untrustworthy TTPs is cryptographically
insecure.
Note again that browsers with some public key information
configured is subject to MitM attacks on software
distribution chains.
Masataka Ohta
e
IDs? Yes.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ttacks on CA chains, which
was demonstrated by diginotar about 10 years ago.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
xample is in rfc7873.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
protection.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Jim Reid wrote:
If you're saying DNS cookies are the answer,
As I said "DNS cookie or something like that", no, not necessarily
"the answer". But it certainly is an alternative.
Paul Wouters wrote:
I tried to substantiate the discussion
I'm afraid you didn't, from the beginning, to have stated:
it just
indicates that the value of deploying DNSSEC is often considered
lower than the cost.
Masataka Ohta
Jim Reid wrote:
That might or might not be true. But where's your draft and code for an
alternative?
How can you say I must provide some draft for some protocol by
myself even though an alternative of DNS cookie already is an rfc?
Masataka
ing DNSSEC is often considered
lower than the cost.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
No implementation or code is necessary to say DNSSEC is
fundamentally hopeless.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
continue to detect such attacks.
Though it can be a criminal offense against local justice.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
er that, I don't think it necessary
any more.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
compatible with existing DNS.
As a result, DNSSEC was modified to be so complicated trying to
incorporate my earlier comments in ugly manners.
and it's easy to talk about simpler
solutions,
For me, it was, has been and still is easy.
Mas
.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
.
Constructive thing to do to make DNS secure is to totally abandon
DNSSEC and rely on DNS cookie or something like that.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo
only by PVM, the original author of the
rfcs, as an active editor, I'm afraid.
Masataka Ohta
PS
It should be a lot more productive to totally revise DNS which
should be a thankful task.
___
DNSOP mailing
l
rfc to reflect the operational reality.
Masataka Ohta
PS
To accommodate operational reality, I think, IANA functionalities
should be divided by three, one for domain name under ICANN, another
for IP addresses under operators community of RIRs and remaining
inoperational ones for IETF/ISOC, whic
rfc
editor and IANA was the same person.
Is the "IANA considerations" section just a recommendation from
IETF/ISOC to IANA/ICANN or approved by IANA/ICANN during *modified*
standardization process of IETF?
Masataka Ohta
___
st
readers.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
for glue information.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Paul Hoffman wrote:
RFCs 1035 and 2181 give mixed messages about incomplete RRsets.
They don't.
You should misunderstand 2181. Putting glue is not additional
section processing.
Masataka Ohta
a response is truncated, and a
resolver doesn't know whether it has a complete set, it should
not cache a possibly partial set of RRs.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https
means that they MUST be
included as part of a referral response, because it is the only
reason to make them necessary.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
hat much benefit from validation, mostly relying on
> https/tls.
Though validation by https is no better/worse than DNSSEC
or any other PKI, https may offer some amount of privacy.
Masataka Ohta
___
DNSOP
is prohibited, though, according to the robustness
principle, the rfc says chains should be followed.
> aliasing apex names, are new and thus currently limited to zero.
Seems to be a reasonable restriction.
Masataka O
with multiple answers and I don't
like the idea of formalising an over-simplistic restriction in the protocol
specification.
How do you do IPv6 anycast with L servers?
Masataka Ohta
___
DNSOP
Petr Spacek wrote:
Subject: [Technical Errata Reported] RFC1035 (5626)
I don't think errata is necessary.
5. At least one NS RR must be present at the top of the zone.
At least two.
Masataka Ohta
le
addresses, which may be anycast ones) take care of load
distribution and fault tolerance, I don't think complications
by priority or weight necessary. As they are not very harmful,
they may be added, if someone insists, but, won't be used.
M
bert hubert wrote:
How do we encode this in a zonefile? The checkmark is Unicode 0x2713, but
encoded as UTF-8 it is 0xe2 0x9c 0x93, or 226 156 147.
See my first response.
Masataka Ohta
___
DNSOP
Robert Edmonds wrote:
This is the *en*coding of characters in a zone file into wire
data octets.
I'm afraid you are totally confused.
How should a receiver decode the wire data octets?
Into a zone file? Or?
Masataka Ohta
provided by the URI RR RFC
The RFC does not provide the octet sequences. Zone files do.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
link
which is an use case of the draft. Retries could also be fail in this
case.
Are you talking about jumbogram capable satellite link with
link layer fragmentation?
Then, the fragmentation mechanism should support SACK like
mechanism.
Masataka Ohta
security only blindly relying on untrustworthy TTPs,
it is better to say;
Especially in the absence of strong anti-spoofing mechanisms,
a check for matching reverse DNS mapping
should be regarded as a weak form of authentication.
Masataka Ohta
, doesn't it?
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
of it.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
broken part of the stack, not elsewhere, never.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
, an additional interaction (with different authority, in
general) for reverse look up is not bad.
It should be noted that, with DHCP, if a host is up, its DHCP
server, which have the authority for host's address, is
almost certainly up.
Masataka Ohta
because
of a few broken implementations.
It is clearly specified in rfc1034:
The domain name space is a tree structure. Each node and leaf
on the tree corresponds to a resource set (which may be empty).
Masataka Ohta
.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Guangqing Deng wrote:
I am interested in the topic of the redundancy and resilience of the
DNS system, and are there any specific documents about this topic,
such as how to achieve that goal?
rfc1034 section 4.1.
Masataka Ohta
-server...
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
. The middle numbers come
from the minimum IPv6 MTU minus space for headers, and the ethernet
MTU minus v4 and v6 headers to allow for tunneling.
can not be made.
Masataka Ohta
PS
It should be noted that my modest proposal to have some
(e.g. 256B
for the current most and the second (and third
or more, if necessary) current information, as I mentioned
decades ago.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo
in the future.
But, even today, how much, in your opinion, is the assured-to-be-
safe DNS message size over IPv6 with 1280B of MTU?
Masataka Ohta
So, as Fernando Gont wrote:
While this issue/question may be currently masqueraded by the fact
that we
and
related gotcha in IPv6 specification.
Even a fragmentation header has annoying requirement.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
secure.
That is, their is no reason to use DNSSEC for anycast root.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
after a timeout because the server can not accept so
many new connections?
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
timeout is a problem (it is not, see below).
makes most kernel improvements for HTTP servers
useless for TCP DNS.
Don't you know that, with HTTP/1.1, TCP connection is kept
open even after a single query?
I wonder how you can say I wrote OS.
Masataka Ohta
David Conrad wrote:
Since I mentioned it and some folks said where is it?:
http://tools.ietf.org/html/draft-ietf-dnsop-ohta-shared-root-server-03
In what context, did you mention it?
Masataka Ohta
.
Does several thousands of queries per second during normal
operations with TCP matter?
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
cname.example.com
misunderstanding that they are to
MX 2 mx.example.com
It is not a problem if mail software properly recognize host
identity including aliases.
Masataka Ohta
___
DNSOP mailing list
mentions), not CNAME pointing to MX (rfc1123).
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
serverX.hoster.net
serverX.hoster.net A
serverX.hoster.net
will motivate the hoster deploy SRV. Right?
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman
is exponential.
Thus, the only solution against it is to give it up.
Masataka Ohta\
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ASCII character for hostnames, have?
Thus, the only solution against it is to give it up.
Not yet ;-)
Even before the beginning, yes, it has been.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https
DNS, rewrites an email
address?
Can you provide some specific examples, because a possible use
of SRV:
_smtp._tcp.example.com. SRV ... mx.example.com.
can cause a similar problem.
Masataka Ohta
PS
Does someone support
to
think about it any more.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
1 - 100 of 197 matches
Mail list logo
