Re: [DNSOP] Coming soon: WG interim meeting on the definition of "lame delegation"
Paul Hoffman wrote: Greetings again. A bunch of you have opinions in this area. In advance of our WG interim meeting on Tuesday, it would be grand if people with opinions would review those opinions and review the threads on the list where other peoples' opinions were expressed. This will make our time together in the interim meeting more valuable. I can't see any problem with "lame" delegation than a "secondary" or "slave" server, because of the history of racial discrimination in US. Both "lame" and "secondary" has negative meaning and, according to google search, "secondary" means "less important than", which is how colored people was and still is treated in US. The fact is that, for about 100 years after slavery was illegalized in US, colored people in US had been legally treated as "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 "secondary". Same for "lame". Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QDCOUNT > 1 (a modest proposal)
Joe Abley wrote:
1035 clearly allows QDCOUNT>1 for responses
to IQUERY and 1034 clearly specifies QDCOUNT=1 for standard
queries and responses.
It sounds like you agree with the archaeology and the
proposed clarification in the draft.
Even though my statement above is made against:
> RFC 1035's ambiguity on the matter needs clarification.
???
That is not a sincere response.
There is no ambiguity.
That you see no need for any clarification while others say
differently is
Because others ignore 1034.
IMHO, those mentioning ambiguity of 1035 without reading
1034 can 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.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QDCOUNT > 1 (a modest proposal)
Ray Bellis wrote:
Notwithstanding an implementation apparently getting by in the DNSSD
space, I remain convinced that QDCOUNT > 1 has no place in the global
DNS and that RFC 1035's ambiguity on the matter needs clarification.
No, not at all. 1035 clearly allows QDCOUNT>1 for responses
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
Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue
Viktor Dukhovni wrote:
> The draft states that in rare cases sibling glue could be useful, as a
> result of cyclic dependency loops.
Interesting. Such dependency existed between two TLDs (IIRC
"edu" and "org") 20 or 30 years ago and I thought and still
think there are redundancy issues.
That is, the example in the draft is insufficient
and, at least, the following should be an additional
example:
bar.test. 86400 IN NS ns1.foo.test.
bar.test. 86400 IN NS ns2.foo.test.
foo.test. 86400 IN NS ns1.foo.test.
foo.test. 86400 IN NS ns1.bar.test.
foo.test. 86400 IN NS ns2.bar.test.
in which case, without sibling glue, if ns1.foo.test goes
down, name resolutions of both zones become impossible,
which should not satisfy minimum required redundancy
of DNS.
If zones have local redundancy policy to allow two or more (N)
name servers simuntaneously go down, which should be the cases
with zones having (N+1) name servers, more examples can be
constructed. For example:
bar.test. 86400 IN NS ns1.foo.test.
bar.test. 86400 IN NS ns2.foo.test.
bar.test. 86400 IN NS ns1.bar.test.
foo.test. 86400 IN NS ns1.foo.test.
foo.test. 86400 IN NS ns1.bar.test.
foo.test. 86400 IN NS ns2.bar.test.
suffers, if two in-zone name servers go down.
In late 2021 the authors analyzed zone file data available from
ICANN's Centralized Zone Data Service [CZDS] and found 222 out of
approximately 209,000,000 total delegations that had only sibling
domain NS 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
Re: [DNSOP] QDCOUNT > 1 (a modest proposal)
Dick Franks wrote: >> So, there is no specification to mention queries with >> QDCOUNT>1, either informatively, optionaly or normatively. >> Then, 3425 titled "Obsoleting IQUERY" updated 1035. >> As such, after 3425, QDCOUNT nomatively must always be 1. The last statement is informatively and normatively mistaken. The counterexample is to be found in RFC8490(5.4): Not up to date. OK. Thanks. But, my statements are enough to deny the original statement by Ted as if 1034 had admitted standard queries with QDCOUNT>1 and another statement by Joe: > But we know that those are old documents that lack normative > clarity. w.r.t. normative status of standard queries. As Mark and I stated: It does not prohibit extended query forms be they a different QDCOUNT for QUERY, a new opcode which supports multiple queries. > Nor does it 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>1. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QDCOUNT > 1 (a modest proposal)
Benno Overeinder wrote:
We would like to point out that discussions should be respectful
which is about the people and the most common and annoying
disrespectful behaviour in IETF is to make meaningless
comments without reading strongly related rfcs, IDs or
mails which is why we have been saying "Read the draft"
against people lacking proper respect to others.
Without such respect, discussions can not be technical.
In this case, people not reading 1034/5, even
after I quote releavant parts of them, totally
lack respect for pioneering contributers (I'm
not) to DNS in 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.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QDCOUNT > 1 (a modest proposal)
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.
And the question by Ted, which was quoted by you in your first
mail, is:
: I'm not seeing the place in RFC 1034 where it explicitly specifics any
: value at all for QDCOUNT.
which is already answered by my second mail.
It does not prohibit extended query forms be they a different QDCOUNT for
QUERY, a new
opcode which supports multiple queries.
Nor does it prohibit protocol extentions to allow standard queries
have QDCOUNT>1, both of which are totally abstract nonsense for
this subthread.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QDCOUNT > 1 (a modest proposal)
Mark Andrews wrote: It advises against a new QTYPE that returns multiples types and gives the reasoning behind the decision. That is not the same as prohibiting QDCOUNT > 1. That's in my first mail. But, we are in subthread on my second mail. All of you should learn to read the rfcs 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
Re: [DNSOP] QDCOUNT > 1 (a modest proposal)
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 list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QDCOUNT > 1 (a modest proposal)
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
Re: [DNSOP] QDCOUNT > 1 (a modest proposal)
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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QDCOUNT > 1 (a modest proposal)
Joe Abley wrote:
I'm not convinced that 1034/5 really allow QDCOUNT > 1,
1034 specifies standard queries and responses must have
QDCOUNT=1 but 1035 explicitely allows responses to
inverse queries have QDCOUNT>1. Inverse queries must
have QDCOUNT=0.
even if they left that door temptingly open. But we know that > those are old
documents that lack normative clarity.
In this case, quite normatively, 1034 states:
Of the possible 16 values,
one (standard query) is part of the official protocol, two (inverse
query and status query) are options, one (completion) is obsolete, and
the rest are unassigned.
but status query is not specified.
So, there is no specification to mention queries with QDCOUNT>1,
either informatively, optionaly or normatively.
Then, 3425 titled "Obsoleting IQUERY" updated 1035.
As such, after 3425, QDCOUNT nomatively 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
Re: [DNSOP] QDCOUNT > 1 (a modest proposal)
Ted Lemon wrote: Oh, I’m sorry, I thought you were referring to something else. You’re quite correct about inverse queries! And IP options and DNS queries matching multiple RR types. I really hope you learn something from the so healthy standardization process to recognize them meaningless. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QDCOUNT > 1 (a modest proposal)
Ted Lemon wrote:
Clearly it is not meaningless, or someone wouldn't have done it! :)
Simply wrong. Having running code is important to have
operational experiences on ideas to know whether they
are meaningful or not, with which, DNS was improved by
removing meaningless ideas such as inverse queries.
Similarly, IPv4 options are obsolete, allowing
512B DNS messages carryied over UDP with 8B
header over 576B IPv4 with not 60B but 20B
header.
But, the princile was forgotten resulting in
poor protocols like IPv6 not improved from the
original ones through operational experiences.
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@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QDCOUNT > 1 (a modest proposal)
Ted Lemon wrote:
FWIW, I don't think it precludes doing queries with QDCOUNT > 1 to
the cache
1034:
3.7.1. Standard queries
A standard query specifies a target domain name (QNAME), query type
(QTYPE), and query class (QCLASS) and asks for RRs which match.
which *DID* not preclude 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.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QDCOUNT > 1 (a modest proposal)
On 2023/02/09 22:54, Ted Lemon wrote: > We've been talking elsewhere (Thread) about a small issue that comes up in > constrained networks that if we want to do service discovery, and we get a > PTR record for a service, then the next thing we need is the SRV and TXT > records for the service instance, and that's two queries. Then, proper thing to do is to have a new unified RR type, which was not the case with . See below why MX was introduced. Now, in general although there is no RFC that expressly forbids QDCOUNT > 1 (or if there is, I couldn't find it, please clue me in), we don't generally support it (my code returns REFUSED, and so does BIND9). 1035 is clear about meaninglessness of the idea: For example, the original form of mail exchange binding used two RR types one to represent a "closer" exchange (MD) and one to represent a "less close" exchange (MF). The difficulty is that the presence of one RR type in a cache doesn't convey any information about the other because the query which acquired the cached information might have used a QTYPE of MF, MD, or MAILA (which matched both). The redesigned 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] List conduct (was: Re: DNSSEC as a Best Current Practice)
Warren Kumari wrote:
I will point out that the DNSOP chairs are not SAA, and that this is
not the main list.
Irrelevant.
As Suzanne Woolf wrote:
: As some of you have noted, the thread under the subject "DNSSEC
: as a Best Current Practice" has included some inappropriate posts,
: not consistent with the IETF Code of Conduct or guidance on keeping
: the WG mailing list professional and productive.
we are discussing whether some behavior is considered to be
"not consistent with the IETF Code of Conduct or guidance" by
IETF consensus or not, which is not specific to DNSSEC WG.
RFC 3934 says: "As in face-to-face sessions, occasionally one or more
individuals may engage in behavior on a mailing list that, in the
opinion of the WG chair, is disruptive to the WG process. Unless the
disruptive behavior is severe enough that it must be stopped
immediately, the WG chair should attempt to discourage the disruptive
behavior by communicating directly with the offending individual. If
the behavior persists, the WG chair should send at least one public
warning on the WG mailing list."
So, interpretation of the RFC3934 published in 2004 is essentially
important, which is why I wrote in 2019:
: IPv6 with unnecessarily lengthy 16B addresses without valid
: technical reasoning only to make network operations prohibitively
: painful is a garbage protocol.
: LISP, which perform ID to locator mapping, which is best
: performed by DNS, in a lot less scalable way than DNS
: is a garbage protocol.
I hope you, now, can interpret the rfc properly,
also, RFC2418 says:
Whatever the rfc says, interpretation on it against "the
freedom of speech" is wrong.
> In any case, this particular discussion is not helping us make
> progress 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
Re: [DNSOP] List conduct
Paul Vixie wrote:
we should make the best case we can for the positions we hope the WG
will adopt, and answer any questions or misunderstandings of those
positions during any subsequent debate.
OK.
for example, here is my
statement on the quality and utility of DNSSEC, along with others':
https://dnssec.net/why-deploy-dnssec
That page is dated before diginotar (2011), when almost all, if not
all expect me, believed PKI were cryptographically secure.
That is, that a false statement of "PKI is cryptographically secure"
was a reason acceptable by most why DNSSEC should be deployed.
Note that, that page titled as "DNSSEC Advantage: Reasons for
deploying DNSSEC" is rather an operational proof that most people
did not and still are not interested in DNSSEC, primarily because
its operational complexity caused by lack of cryptographic security.
here, you demonstrate a commitment to nonconstructive commentary
> ("obviously impossible for poor IPv6 and LISP")
As I wrote to Suzanne Woolf;
: Recognizing unproductive protocols such as DNSSEC as unproductive
: protocols is, though may be to your surprise, productive.
nonconstructive commentary on nonconstructive protocols is rather
constructive.
Moreover, that IPv4 with NAT is better than IPv6 is a constructive
statement.
Similarly, in my first message of the thread, I wrote:
> Constructive thing to do to make DNS secure is to totally abandon
> DNSSEC and 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
Re: [DNSOP] List conduct
Paul Vixie wrote: such destructive statements as IPv6 with unnecessarily lengthy 16B addresses without valid technical reasoning only to make network operations prohibitively painful is a garbage protocol. and LISP, which perform ID to locator mapping, which is best performed by DNS, in a lot less scalable way than DNS is a garbage protocol. is protected by "the freedom of speech" and is not "unprofessional" and is fully acceptable. i think the code of conduct may be inadequately worded. Code itself? Then, you should discuss it not here but other appropriate places. the above snippets in which ipv6 and lisp are designated "garbage protocols" have a productivity error in that neither is actionable. Action by IETF becomes possible only after some IETF consensus is reached, which is obviously impossible for poor IPv6 and LISP, because there are certain amount of people disparately acting for them. But, it does not mean arguments against IPv6, LISP and DNSSEC are prohibited in the main and other mailing lists as if they were "unprofessional". to use community resources and to take time and attention from other participants for no reason other than to publish invective is an abuse of position. Which position? It should be noted that "freedom of speech" of people without any position always assumes > to use > community resources and to take time and attention from other > participants So? Or, are you saying chairs are abusing their position? we should make the best case we can for the positions we hope the WG will adopt, As we, including chairs, are talking about "the IETF Code of Conduct". you MUST make the best case not for this WG but for the entire Internet. and answer 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 mail. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC as a Best Current Practice
Mukund Sivaraman wrote: : Third, all the CAs, including TLDs, pursuing commercial : success have very good appearance using such words as : "HSMs" or "four eyes minimum". That is, you can'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. (From your posts in this thread, you appear well convinced that cryptography is broken due to operational weaknesses in securing access to signers. So I don't know if this will convince you differently.) I'm afraid you miss my point that intermediate zones between the first and the second parties are the third parties having no knowledge of required security on transactions between the first and the second parties. That DNSSEC is not cryptographically or end-to-end secure means third parties must be absolutely secure, which is, as was demonstrated by diginoar, impossible. OTOH, with the end-to-end security where secret information is shared directly between the first and the second parties, the parties know the degree of the required security. HSMs don't have anything to do with DNSSEC's security guarantee. If so, feel free to put private keys accesible from general public. An operational decision leading to weakness doesn't mean that the cryptographic foundation of DNSSEC is broken or cannot be secured. Of course. DNSSEC, certainly, has some components which is cryptographically secure. But, as you should know, security of a system depends on the weakest components of the system. As such, that some secure components are secure do not mean the system is secure. On the topic of leak of private key or access to signers by rogue parties, there have been experiments to use threshold cryptography with DNSSEC where the actual private key is not present in any > single form, but distributed as "key shares" among N parties, and "signature shares" are generated separately by M out of N parties > and combined to make the final signature. Relying on two or more third parties is no better than relying on single third party, when all of them are not cryptographically but physically secure. As was demonstrated by diginotar, "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
Re: [DNSOP] List conduct (was: Re: DNSSEC as a Best Current Practice)
Suzanne Woolf wrote: As some of you have noted, the thread under the subject "DNSSEC as a Best Current Practice" has included some inappropriate posts, not consistent with the IETF Code of Conduct or guidance on keeping the WG mailing list professional and productive. A DNSOP mailing list participant has been warned about their posts and asked to stop. As a person who have fought against SAAs in the main IETF mailing list about interpretations of "the IETF Code of Conduct" several times, sometimes followed by resignations of some SAAs, I feel I should give you chairs some advice on how to and how not to mention the code. As is documented in https://github.com/ietf/saa/blob/main/sop.md Level 0: Initial suggestion An SAA team member sends an off-list message to the individual on behalf of the SAA team. This message clearly identifies the concern, offers assistance with re-framing language, and identifies consequences for continued inappropriate postings. you should mention the code with "clearly identifies the concern" or you are against the due process. Maybe, you think the requirement is satisfied. But, see below. As a reminder to the list: people here can be vigorous and intense in their arguments and tone, but generally stay to the civil and constructive side, and the chairs don't like stepping into substantive technical discussions. That's simply wrong. As I, to confirm the freedom speech in IETF, explicitly confirmed destructive harsh criticisms are not "unprofessional" (w.r.t. the code) in https://mailarchive.ietf.org/arch/msg/ietf/lBs5-1u3asjocT56PoQEdnv1m2g/ without resulting in SAAs' actions. There was no one who argued against me that the statement were "unprofessional". There was no one who argued against me that the statement were "inappropriate" nor "impolite", which means such destructive statements as IPv6 with unnecessarily lengthy 16B addresses without valid technical reasoning only to make network operations prohibitively painful is a garbage protocol. and LISP, which perform ID to locator mapping, which is best performed by DNS, in a lot less scalable way than DNS is a garbage protocol. is protected by "the freedom of speech" and is not "unprofessional" and is fully acceptable. So, your post utterly violate due process and should be revoked. Though you may disagree with the current interpretations on the code in IETF, you must obtain IETF consensus not here but, maybe, in the mail IETF list or you can't act based on your disagreement. In general, DNSOP has done pretty well at keeping things professional and productive. It's part of the chairs’ job to keep it that way. Recognizing unproductive protocols such as DNSSEC as unproductive protocols is, though may be to your surprise, productive. So, 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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC as a Best Current Practice
Paul Wouters wrote: I can't see any reason why you think the root zone is more secure than TLDs, especially because, as I wrote: Because I am informed about their operational procedures and I contributed to the technical design as one of the for the DNS Root Zone Key-Signing-Key of the Root Zone Rollover advisory group. So, you mean the root zone is secure because of "operational procedures", which is not cryptographic. Thank you very much to have confirmed my point that DNSSEC is not cryptographically secure. Your point is, surely, conclusive. > I was also responsible for the design and implementation of a large TLD > fully implementation redundant DNSSEC signer solution. So, the root and TLD zones are as secure as diginotar. > I talked to a lot of TLD operators at ICANN during my term as the > IETF Liason to the ICANN Technical Expert Group. I'm sure none of them were aware that PKI is not cryptographically secure. So? >> : Third, all the CAs, including TLDs, pursuing commercial >> : success have very good appearance using such words as >> : "HSMs" or "four eyes minimum". That is, you can'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. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC as a Best Current Practice
Paul Wouters wrote:
In your
favourite terms, diginotar as DNSSEC entity would have only
been able to mess up .nl and not any other TLD, if it had been
a "DNSSEC CA" instead of a "webpki CA". The hierarchical space
offers better security than the flat webpki.
I can't see any reason why you think the root zone is
more secure than TLDs, especially because, as I wrote:
: Third, all the CAs, including TLDs, pursuing commercial
: success have very good appearance using such words as
: "HSMs" or "four eyes minimum". That is, you can't
: compare actual operational/physical strength from
: their formal documents.
and
: A false sense of security that DNSSEC were
: cryptographically secure motivates the operators
: ignore DNSSEC operation rules, which are very
: complicated and hard to follow, for relatively
: strong physical security, which might be what
: happened in diginotar.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC as a Best Current Practice
Paul Wouters wrote:
First, "CA" is terminology not specific to WebPKI, whatever it
means, but PKI in general including DNS. That is, a DNSSEC TLD is a
CA.
This is incorrect.
First, thank you very much for an evidence that discussion is
still continuing.
Anyway,
https://en.wikipedia.org/wiki/Public_key_infrastructure
In cryptography, a PKI is an arrangement that binds public
keys with respective identities of entities (like people
and organizations). The binding is established through a
process of registration and issuance of certificates at
and by a certificate authority (CA).
Do you still insist that CA is terminology specific to WebPKI
not PKI in general?
In your favourite
terms, diginotar as DNSSEC entity would have only been able to mess
up .nl and not any other TLD,
The fact is that diginotar actually supported government PKI of NL,
which is why the problem is so serious.
As for DNSSEC, we can be sure that national TLDs are not so secure.
You keep conflating operational security with protocol security, and
insisting protocol security is not needed because operational
security is always the weaker link.
Your previous statement:
: At the TLD level
: and higher, this involves HSMs and physical access restrictions
: using a "four eyes minimum" approach.
is an evidence that operational security is required because
DNSSEC is not secure merely by protocol security.
I don't deny DNSSEC has some protocol security, but the
problem is that it is not complete and useless without
operational security.
But you are not offering any alternative ("larger plaintext cookies"
is not a security protocol)
Cookies and DNSSEC, subject to active MitM attacks, are
equally secure.
So please tell me why you use TLS at all? Why not force your browser > into
only using port 80? You can also use extra long HTTP header
cookies.
With compromised intermediate CAs and ISPs, TLS and plain http with
long enough cookies are equally secure against active MitM attacks.
The difference 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
Re: [DNSOP] [Ext] DNSSEC as a Best Current Practice
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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC as a Best Current Practice
Brian Dickson wrote: Are there anyone who still think DNSSEC were cryptographically secure or had protected TLDs more securely than diginotar? I'm not sure why "thinks" enters into the conversation. You may replace it with "dreams". The facts are what matters here: The important facts are that: DNSSEC is not cryptographically secure. DNSSEC "at the TLD level and higher", which include root zone, is only as trustworthy as diginotar. Taken together, this means that as long as there exists any CA which is weaker than some TLD, that automatically means that as a global system, DNSSEC is more cryptographically secure than WebPKI. First, "CA" is terminology not specific to WebPKI, whatever it means, but PKI in general including DNS. That is, a DNSSEC TLD is a CA. Second "any CA which is weaker than some TLD" means not "cryptographically weaker" but "operationally/physically weaker". As such, your conclusion can only be "DNSSEC is more operationally/physically secure than WebPKI" Third, all the CAs, including TLDs, pursuing commercial success have very good appearance using such words as "HSMs" or "four eyes minimum". That is, you can't compare actual operational/physical strength from their formal documents. Remember: At the TLD level and higher, this involves HSMs and physical access restrictions 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
Re: [DNSOP] DNSSEC as a Best Current Practice
Bjorn Mork wrote:
Are there anyone who still think, with reasons, DNSSEC were
cryptographically secure or had protected TLDs more securely
than diginotar?
Does DNSSEC make the TLD operators less trustworthy in your eyes?
Good point.
A false sense of security that DNSSEC were
cryptographically secure motivates the operators
ignore DNSSEC operation rules, which are very
complicated and hard to follow, for relatively
strong physical security, which might be what
happened in diginotar.
With proper recognition that DNSSEC is not cryptographically
secure, operators won't violate rules 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
Re: [DNSOP] DNSSEC as a Best Current Practice
Paul Wouters wrote:
Are there anyone who still think DNSSEC were cryptographically secure
or had protected TLDs more securely than diginotar?
Yes, everyone but you who participated in this thread.
That's simply wrong.
Are there anyone who still think, with reasons, DNSSEC were
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
Re: [DNSOP] DNSSEC as a Best Current Practice
As I wrote: Such an individual would have to get access, create the records, give them to others, who then have to on-path attack you. At the TLD level and higher, this involves HSMs and physical access restrictions using a “four eyes minimum” approach. Not surprisingly, diginotar 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 https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC as a Best Current Practice
Paul Vixie wrote: If some CA between you and your peer is compromised, communication between you and your peer is compromized. About 10 years ago, diginotar demonstrated that attack on intermediate CAs possible. i consider that your arguments about PKI CAs apply to DNSSEC in the form of static and dynamic trust anchors, those being the root key, and the set of DS RRsets in a validation chain. it is always the case that if a CA is compromised then security is compromised An important question is how the CA is protected. Physically or cryptographically? As the CA is not cryptographically protected, DNSSEC is not cryptographically secure. i think the specific reliance on physical security is irrelevant. But it is relied by DNSSEC, which is why not me but Paul Wouters wrote: : At the TLD level : and higher, this involves HSMs and physical access restrictions : using a "four eyes minimum" approach. i know of secure digital vaults, and i know of insecure physical vaults. You don't have to use metaphor of vaults because diginotar successfully demonstrated that a CA with physical security by HSMs and physical access restrictions using a "four eyes minimum" approach. can be compromised. i think there are two assumptions in the DNSSEC design which go to your assertion of meaninglessness. first, birthday attacks of the kind you describe are essentially hop by hop (transactional), and any defense against only hop by hop attacks will necessarily leave open data integrity vulnerabilities in the end to end data path. "hop by hop (transactional)"??? Do you mean "transaction by transaction"? Or, do you mean hops over routers, which is not "transactional" at all. for example, if we had larger message IDs we would still be vulnerable to data modification attacks by RDNS operators, or by BGP injections They are not "birthday attacks". DNS is subject to MitM attacks on ISP chain, CA chain and software distribution chain. which change the identity of an IP address. therefore pure hop by hop security features were out of scope for the DNSSEC effort. I'm afraid DNSSEC prevents MitM attacks on ISP chain. second, a general and effective prohibition against end to end attacks can be made proof against hop by hop attacks also. I'm afraid there is no such thing as "end to end attacks". > however, "security theater" is not an unalloyed failure: > > https://healthguardsecurity.com/bruce-schneier-ted/ > https://www.cnet.com/culture/bruce-schneiers-new-view-on-security-theater/ You should just say "diginotar". > accordingly, DNSSEC admits to the inevitability of "security > theater" but considers it, along with the inevitability of compromise > in any PKI CA system, to be design inputs and not design constraints. > more "below". No PKI is cryptographically secure. So? >> So, let's recognize that DNSSEC is not cryptographically secure not >> worth its so high cost and move on to make DNS with longer message >> IDs even though DNS must, with or without DNSSEC, be subject to >> various MitM attacks. > > this proposal is out of scope for the reasons described above. Certainly, the proposal to obsolete DNSSEC is out of scope for DNSSEC. So? >> Which of my points, if any, are you saying, can not be understood >> by you not so clealy? > > we (you and i) have discussed this on the record several times in the > last 25 years, and i think i have always understood your concerns. > in fact i share your concerns, but not your conclusions. Thanks. >> DNSSEC's focus is on end to end data integrity, Note that "end to end data integrity" is applied on ends of not only ISP but also CA and software distribution chains. > DNSSEC expects PKI CA > compromise but makes such compromises transparent and observable. No, as I wrote to Ted Lemon: : If a parent zone administrator or some employee of it is : compromised and forged zone delegation (with an IP address : of a forged nameserver using forged public/secret keys) : is signed by a valid key, it will not be noticed easily. > RFC > 3833 should clarify any misunderstandings as to DNSSEC's intent and > utility. It was before diginotar. At that time most people did not think PKI cryptographically insecure. > "below": > > 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://sockpuppet.org/blog/2015/01/15/against-dnssec/ In it, I can't find a concern that CAs can be compromised. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC as a Best Current Practice
I wrote: Ohta-san is using the term MiTM in an unusual way. Wrong. See, for example, https://www.eff.org/deeplinks/2011/09/post-mortem-iranian-diginotar-attack More facts have recently come to light about the compromise of the DigiNotar Certificate Authority, which appears to have enabled Iranian hackers to launch successful man-in-the-middle attacks against hundreds of thousands of Internet users inside and outside of Iran. Sorry, this is not a good reference because it mentions MitM attack on ISP chain is enabled by diginotar. A proper reference is: https://www.thesslstore.com/knowledgebase/ssl-support/explaining-the-chain-of-trust/ Intermediate Certificate – Intermediate certificates branch off of root certificates like branches off of trees. They act as middle-men between the protected root certificates ^^ and the server certificates issued out to the public. ^^^ Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC as a Best Current Practice
Ted Lemon wrote:
Ohta-san is using the term MiTM in an unusual way.
Wrong. See, for example,
https://www.eff.org/deeplinks/2011/09/post-mortem-iranian-diginotar-attack
More facts have recently come to light about the compromise
of the DigiNotar Certificate Authority, which appears to have
enabled Iranian hackers to launch successful man-in-the-middle
attacks against hundreds of thousands of Internet users inside
and outside of Iran.
There are a lot of other examples. For example, both plain DNS and
DNSSEC are subject to MitM attacks on software distribution chain
to forge root zone information of IP addresses of root servers
or public key of the root zone.
Normally we mean an on-path attack.
Exactly, MitM attack means on-path attack on some chain including
but not limitedvto ISP chain. So?
Ohta-san is talking about attacks on root and intermediate
zone keys
That is, well known MitM attack, in this case, on zone/CA chain.
using the term "man-in-the-middle," that's all.
Your denial of the term of MitM can not deny a fact that PKI
including DNSSEC is not cryptographically secure, diseparate
attempt against 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.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC as a Best Current Practice
Dr Eberhard W Lisse wrote:
>> Which of my points, if any, are you saying, can not be
>> understood by you not so clealy?
Every single one, actually.
I understand that you don't understand, at all, DNSSEC
almost all details of which to make DNS and PKI precisely
match are 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
Re: [DNSOP] [Ext] Call for Adoption: DNSSEC as BCP: draft-hoffman-dnssec
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 Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC as a Best Current Practice
Dr Eberhard W Lisse wrote:
I am also struggling finding your point.
More than 20 years ago, I noticed that PKI, including DNSSEC is, not
at all, cryptographically secure subject to MitM attacks on CA or
zone chain, whichI pointed it out for every several years in this ML.
Initially, I was puzzled why PKI is operationally so complicated
with a lot of parameters without any theory to properly determine
proper values for the parameters, which turned out to be that
there can not be any proper values for the parameters because
PKI is not cryptographically secure.
If some CA between you and your peer is compromised, communication
between you and your peer is compromized.
About 10 years ago, diginotar demonstrated that attack on
intermediate CAs possible.
Another evidence for my point is that, DNSSEC assumes actually-not-
so-strong but too costly physical security of intermediate zones,
which means DNSSEC relies on too costly physical security of
intermediate zone and is not cryptographically secure.
Diginotar also demonstrated that costly physical security similar
to DNSSEC TLDs can be compromised and is not secure at all.
It is true that plain DNS is not so secure because birthday
attacks from anyone, not necessarily MitM, can be successful
because of too short (16bits) message IDs.
However, that DNSSEC is not cryptographically secure subject
to MitM attacks means operating costly DNSSEC only to keep
it subject to MitM attacks is not only meaningless but also
harmful to let society give false sense of security as if
DNSSEC were cryptographically secure.
So, let's recognize that DNSSEC is not cryptographically
secure not worth its so high cost and move on to make
DNS with longer message IDs even though DNS must, with
or without DNSSEC, be subject to various 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
Re: [DNSOP] DNSSEC as a Best Current Practice
Paul Wouters wrote:
If a parent zone administrator or some employee of it is
compromised and forged zone delegation (with an IP address of a
forged nameserver using forged public/secret keys) is signed by a
valid key, it will not be noticed easily.
Such an individual would have to get access, create the records, give
them to others, who then have to on-path attack you. At the TLD level
and higher, this involves HSMs and physical access restrictions using
a “four eyes minimum” approach.
First, such impressively strong in depth security as strong
as those for nuclear reactors at Fukushima demonstrates a
fact that PKI is not cryptographically secure.
Not surprisingly, diginotar was equally strongly secure.
https://roselabs.nl/files/audit_reports/Fox-IT_-_DigiNotar.pdf
The main production servers of DigiNotar, including the
CA servers and the accompanying hardware security module
(netHSM), were located in a physically highlysecured
room and in the Secure-net network segment.
When a request was approved using the four-eye principle,
In order for the CA software to automatically sign the
certificate request, the appropriate private key
needed to be activated in the netHSM. This was done
by authorized employees by entering a smartcard
into the netHSM combined with a PIN code.
So, DNSSEC TLDs are as secure as diginotar.
At this point, it is easier to obtain physical access to the enduser
device and compromise the OS, browser or webpki stack - DNS attack is
not needed.
According to your theory, diginotar should not have been attacked.
It's like guaranteeing nuclear reactors protected by in depth
security never meltdown, proven by so many experts.
But, real security experts including bad guys are not hyped
by mere impression of security, which is merely not very
strong obscurity, which caused meltdown of diginotar.
So, may I volunteer to write a WG ID to obsolete DNSSEC
because it is only as secure as diginotar?
Merely because message ID is short, which can be improved, which is
a lot easier than deploying so costly DNSSEC.
You did not answer my earlier question on how you obtain this alleged
secure IP address of all DNS nameservers you plan to talk to with
"extra strong message ID".
I can't understand your question because upgrading all the
nameservers and resolvers operated by security aware
operators longer message ID capable is not so difficult.
> Note also the same employee from above can tcpdump their nameserver
> or read the RAM and give the extra strong message ID to the attacker.
> So all attacks you attribute to DNSSEC apply to msg ID too.
So, just accept the reality that DNS, relying on zone chain,
which is subject to MitM attacks on intermediate zones, can not
be so secure regardless of whether you use DNSSEC or not.
If a resolver has some knowledge on contents of an attacked zone,
such as IP addresses of some servers or some DNSSEC keys, it can
detect a DNS (both resolver and DNSSEC) attack by comparing,
unless an attacker knows IP addresses of detecting resolvers and
return unforged answers to them. So?
Forged answers require access to a private key. As stated those tend
to be in HSMs or offline,
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://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC as a Best Current Practice
Ted Lemon wrote:
Brian, what you said about the crypto is right but there are definitely
opportunities to compromise trust at the tlds. I don't think it's wise to
ignore this type of attack. However, in order to make such an attack, you
have to do things which can be noticed (e.g. signing a zone delegation with
a forged key).
If a parent zone administrator or some employee of it is
compromised and forged zone delegation (with an IP address
of a forged nameserver using forged public/secret keys)
is signed by a valid key, it will not be noticed easily.
So the threat model for a viable DNSSEC attack is quite a bit different
than for a recursive resolver attack, and is not something that could be
easily effected by a small entity.
Merely because message ID is short, which can be improved,
which is a lot easier than deploying so costly DNSSEC.
> And unlike
> a resolver attack, it is possible to detect a DNSSEC attack by
> comparing known keys to detect a compromise.
If a resolver has some knowledge on contents of an attacked zone, such
as IP addresses of some servers or some DNSSEC keys, it can detect
a DNS (both resolver and DNSSEC) attack by comparing, unless
an 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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC as a Best Current Practice
Brian Dickson wrote:
The difference between this model (client to server transport
security using IDs) and DNSSEC, is that DNSSEC is resistant to any
MITM attacks, so long as the resolver's root trust anchor is the same
as the one published by ICANN/IANA and used to sign the root zone.
Wrong.
If a TLD with its key signed by the root is compromised, which
is a MitM attack, child zones under the TLD are easy victim
of the attack.
Or, if your theory is that we can blindly trust any entity
blessed by ICANN/IANA through some chain as an trustworthy
TTP, then, according to your theory, we can blindly trust
all the ISPs as trustworthy TTPs, because they are blessed
by ICANN/IANA through RIRs, which means there can be no MitM
attacks on ISP chains.
> I think this is where your argument fails. The trust in DNSSEC is
> not blind. The validation which is done by a resolver can be
> confirmed by an end-host, along the entire chain (tree) from root to
> leaf.
You are totally confused, because I never assumed any compromised
resolver.
> The validation which is done by a resolver can be
> confirmed by an end-host, along the entire chain (tree) from root to
> leaf.
"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 adversary (e.g. state)
would need to compromise every software stack on every host and every
resolver, and block access to every external place that could provide
contradictory results.
Given that the root trust anchor is public, and published on the
IANA's web site with all the appropriate protections, this means
anyone can publish the same information on their own web site, e.g.
protected by TLS.
The only way this would not be available to someone under the control
of that adversary, would be the compromise of every CA's cert, or
publishing competing certs for every TLS cert in existence, or to
prevent any access to external sites entirely.
The notion that a state exercising that level of control would also
permit the long-enough ID communication to enable your alternative to
function, does not seem credible.
This devolves down to two possibilities: your method is not viable if
the efforts needed to block use of the Root Trust Anchor are
undertaken; or if the efforts needed to block the Root Trust Anchor
are not undertaken (in their entirety), attempts to replace the Root
Trust Anchor are detectable, which also means the real Root Trust
Anchor can be obtained and validated, and once the latter is done,
DNSSEC continues to be cryptographically secure.
The actual real root trust anchor is not feasible to compromise, nor
are the signing mechanisms involved for signing the root zone. A
secured root zone and root trust anchor makes it impossible to
compromise any zone protected by its parent, with the root zone
anchoring those protections.
DNSSEC is not blind trust. The ability to compromise via spoofing
requires compromise of a parent. The root zone cannot feasibly be
compromised. Therefore DNSSEC is secure.
I concur with the rest of the folks on this thread, this subject
thread is effectively concluded.
This message is mostly for your (Ohta-san's) benefit to understand
why DNSSEC is not in the same category as WebPKI in terms of the
trust model and trust mechanisms.
There is an analogy in infinities: The rational numbers and real
numbers are both infinite, but the infinity of the real numbers is
"uncountable", a larger infinity than the infinity of the rational
numbers, which are "countable".
Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] DNSSEC as a Best Current Practice
Paul Hoffman wrote:
My reading of this thread is that one person thinks that there is a
better way to achieve what DNSSEC is designed to achieve, and no one
else agrees with him. Thus, I'll leave the text in the document alone
unless I see more support for that lone opinion.
I'm afraid you 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".
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC as a Best Current Practice
Paul Wouters wrote: Wrong. DNSSEC as PKI is not cryptographically secure subject to MitM attacks on CA chains, which is not more difficult than MitM attacks on ISP chains. I think at this point we have reached a point where your repeated claims lack any merit So, you ignore diginotar 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC as a Best Current Practice
Joe Abley wrote:
As I wrote "rely on DNS cookie or something like that", an example
is in rfc7873.
Could I perhaps summarise what you're saying as follows?
1. The cost of DNSSEC signing is high, e.g. due to increased
complexity, brittleness of the DNS, perhaps as shown by relatively
low demonstrated system-wide deployment;
No, cost of DNSSEC is high because PKI, in general, is against
the end to end principle, which automatically means that
it is not cryptographically secure, actually because it blindly
depends on untrustworthy TTPs.
If we can be secure by just declaring some third parties not
under control of the first or the second party are trustworhy,
we can just declare that all the third parties of ISPs between
the first and the second, even with BGP route attacks, parties
are trustworthy.
2. The threats that DNSSEC protects against are not high-probability
threats, especially following the adoption of various
resolver-hardening techniques adopted following the late Dan
Kaminsky's various observations;
Partially yes, because DNSSEC is not cryptographically secure.
3. The threats that DNSSEC protects against are not high-impact
either since they affect one layer amongst many for most
applications;
No, MitM attacks on CA chains has as high or low impact as
MitM attacks on ISP chains.
4. Protocols and applications that depend on cryptographic assurances
in the DNS (DNS as PKI)
Wrong. DNSSEC as PKI is not cryptographically secure subject to
MitM attacks on CA chains, which is not more difficult than
MitM attacks on ISP chains.
5. The cryptographic assurances in DNSSEC
No, there is no such assurances.
6. Better to avoid the cost of DNSSEC deployment
For no security improvement beyond plain DNS with long enough message
IDs? Yes.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC as a Best Current Practice
Bjorn Mork wrote:
Sorry for being slow, but you'll have to explain a lot more than that if
you want to convince me that DNS cookies and DNSSEC are equivalent
alternatives.
In a sense, they are equivalent, because both plain DNS with
long enough message IDs and DNSSEC are subject to MitM attacks,
naturally with similar difficulties.
The point is that DNSSEC, or PKI in general, is not cryptographically
secure merely blindly trusting untrustworthy intermediate systems,
which means it is against the end to end principle, improperly
called TTPs (Trusted Third Parties).
In another sense, they are not equivalent because attack vectors
are different. MitM attacks can be on ISP chains, CA chains
or software distribution chains. The last example is applicable
to browser or DNSSEC resolver software containing some certificates
or public keys.
> I was asking specifically for your alternative BCP. "Go figure it
> out by yourself with DNS cookie or something like that" just doesn't
> make it.
That's your problem not to able to understand that DNSSEC is *NOT*
cryptographically secure, which I have been pointing out for these
20 years, because it is subject to MitM attacks 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
Re: [DNSOP] DNSSEC as a Best Current Practice
Bjorn Mork wrote:
Plain DNS with long enough message ID is secure enough.
Hello!
Can you please point me to the set of RFCs (or draft) which describes
this "secure enough" alternative to DNSSEC?
As I wrote "rely on DNS cookie or something like that",
an example is in rfc7873.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC as a Best Current Practice
Brian Dickson wrote:
If a resolver correctly knows an IP address of a nameserver of a
parent zone
The statement is not more demanding for resolvers to be configured
with correct certificates.
I'm presuming you mean "DNSSEC ICANN/IANA Root Trust Anchor", which is a
public key, not a certificate per se.
OK.
I presume you're comparing two models, one using DNSSEC, and one where no
DNSSEC validation is done ever (replaced with TLS,
No, TLS is overkill. Plain DNS with long enough message ID is
secure enough. Though it is vulnerable to active MitM attacks,
where packets are not only spoofed but also dropped, modified
and/or generated, such attacks are as likely/unlikely as
having a fake root trust anchor through social attacks
(including legal order by some government).
As for DoS, IMO, anycast is the only practical protection.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC as a Best Current Practice
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.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC as a Best Current Practice
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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC as a Best Current Practice
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 Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC as a Best Current Practice
Paul Wouters wrote:
You claim DNS can be secured if we somehow securely know all the IPs
of all nameservers of parent zones, for which the only source is DNS.
How do you propose to fulfill your own stated requirement without
DNSSEC?
Securely configuring IP addresses of root servers, which can
recursively assure data origin security of child servers, is
as easy/difficult as securely configuring root certificates.
So?
Are you saying connecting to an IP address secured by DNSSEC is
safe even under BGP attacks?
Yes. Obviously the attacker can deny the actual real DNS content but
sending their own made up DNS data is ignored due to data origin
protection.
Wrong.
With BGP attacks, your packet with an DNSSEC secured destination IP
address is delivered elsewhere.
Please refrain from ad hominem attacks if you wish to continue to
discuss.
I'm afraid it is you who want to discontinue discussion.
Country X legally forcing people to install government provided
root certificates can freely spoof PKI, including DNSSEC, data of
country Y.
No they cannot. I can give you root access to a nameserver for
nohats.ca and you still can't create a "proof.nohats.ca"
It is trivially easy with root zone certificate recognized by
end users to forge RRs of "nohats.ca" and "proof.nohats.ca".
If you only handwave your claims,
I'm afraid it is you who is handwaving with such unfounded
statement:
it just
indicates that the value of deploying DNSSEC is often considered
lower than the cost.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC as a Best Current Practice
Paul Wouters wrote:
"Using a rogue AS known as AS9457, on February 3, the attackers
began advertising that they owned the IP addresses that served
developers.kakao.com,"
It is as easy as compromising developers.kakao.com.
You can define every technical hack as a social problem because it
involved humans.
Yup.
The problem of DNSSEC, or PKI in general, is that, assuming such
attacks, it is equally easy to socially compromise a zone with
DNSSEC signature.
Yet that has never happened, unlike BGP attacks.
You miss my point that DNSSEC to produce correct IP addresses
is powerless against BGP attacks.
It's pretty easy to forge certificates.
Never rely on untrustworthy TTPs.
Yet I don’t hear you say to abandon TLS ?
TLS is no better than DH, which is subject to MitM attacks,
though you might hear it from me for the first time.
Because security by PKI including DNSSEC is not end to end
With TRRs in browsers like Firefox, it practically is.
Wrong.
Because it is not end to end, it is subject to MitM attacks
on software distribution chain.
Or, can you improve DNSSEC to instantly invalidate compromised
zone information, which is impossible with slowly acting CRLs.
DNSSEC has no CRLs, only TTLs. I think you meant PKI here, not
DNSSEC?
That CRLs are very slow to react against attacks because
PKI is not end to end makes CRLs totally useless for
PKIs including DNSSEC, which is why I stated "instantly
invalidate".
Socially, having long enough message IDs is as secure as DNSSEC.
“Socially” makes no sense from a protocol level.
BCP is not at the protocol level.
That is because authors of the original specification of DNSSEC
ignored my comments
It was not ignored, it was rejected.
It was ignored and rejected but later, with some implementation
efforts, was recognized resulting in specification changes in
the worst possible way, because recognition occurred to late.
So?
> Please submit a draft with enough details for an implementer and/or
> sample code so the IETF can objectively evaluate your claims.
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
Re: [DNSOP] DNSSEC as a Best Current Practice
Ted Lemon wrote:
Ohta-san, I think the points you are making in response to what I have said
are that
(1) it's easier for a government to fake a DNS delegation than to MiTM an
IP connection, and
(2) if it's a government that's faking your DNS, they can jail you for
noticing.
You miss my point that compromising employees of ISPs or zones by, say,
kidnapping their children.
I think these are both valid points. However, I don't think they lead to
the conclusion you are drawing. First, if the government really cares about
censorship,
Censorship? Fake news are obviously better.
To the second question, this is also absolutely true, but at the same time,
as we can see, just because something is illegal doesn't mean that it's not
useful. E.g., the government in Russia has made it illegal to protest the
war in Ukraine, and yet we see people protesting in the streets. Their goal
is pretty clearly to bypass a government restriction on communication.
Be also aware of fake news produced against Russia by some governments.
Having a watchdog in software that notices when a certificate has been
replaced by one that isn't valid isn't that hard, and while it might be
made illegal after the fact, officially making it illegal would be a public
act that would have to be announced by the government in order to be
enforceable—otherwise software vendors would have no reason to know they
were violating the law.
The point is what, if any, can DNSSEC do against it.
By announcing it, the government in question is
disclosing the status of your security, which is the whole point.
But, justice defined by the government is the justice for those
who are under control of the government.
> Absent
> such a disclosure, citizens can continue to run such software, and
> 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
Re: [DNSOP] DNSSEC as a Best Current Practice
Paul Wouters wrote:
If a resolver correctly knows an IP address of a nameserver of a
parent zone
This statement seems a recursion of the original problem statement?]
What?
The statement is not more demanding for resolvers to be configured
with correct certificates.
This would not help for on-path attackers (without DoT, DoH)
See below.
How would this be safe against the current BGP attacks we are seeing?
Are you saying connecting to an IP address secured by DNSSEC
is safe even under BGP attacks?
As for MitM attacks, PKI, in general, is insecure against
them as was demonstrated by diginotar. So, don't bother.
DNSSEC is more hierarchical than the "bag of CAs", so a failure
like this would be more contained. Regardless, I do not understand
how PKI failures relate to DNS?
Are you saying you don't understand DNSSEC is a form of PKI?
IETF can do nothing if some government legally force
people to install some government provided certificates
to some PKI, including DNSSEC, which is as easy as
MitM attacks on ISP chain may be by government order.
With DNSSEC, a government in country X cannot spoof data of
country Y, they can only block it.
Country X legally forcing people to install government provided
root certificates can freely spoof PKI, including DNSSEC, data
of country Y.
Again, I think perhaps you should write this up in a draft, so
we can see how your proposal would cover everything that DNSSEC
covers.
Before diginotar, maybe. After that, I don't think it necessary
any more.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC as a Best Current Practice
Ted Lemon wrote:
If a resolver correctly knows an IP address of a nameserver of a
parent zone and the resolver and the nameserver can communicate
with long enough ID, the resolver can correctly know an IP
address of a nameserver of a child zone, which is secure enough
data origin security.
It's pretty easy to intercept all packets destined for a particular IP
address and spoof the responses.
Technically, yes, but, socially, no, not at all.
It can be practically possible only if ISPs employees are socially
compromised, which is criminal, or the ISP is ordered to do so
by government.
The problem of DNSSEC, or PKI in general, is that, assuming such
attacks, it is equally easy to socially compromise a zone with
DNSSEC signature.
It's pretty easy to forge certificates.
Never rely on untrustworthy TTPs.
IETF can do nothing if some government legally force
people to install some government provided certificates
to some PKI, including DNSSEC, which is as easy as
MitM attacks on ISP chain may be by government order.
Attacks of this nature are in principle detectable.
Technically, maybe, but, socially, it is not detectable at
least legally, if such detection is defined to be (may be
criminally) unlawful.
The way to detect them
is to notice these forcibly injected certificates based on the public keys
presented in them.
And you can be arrested.
It should be noted that google's attempt to statically install
some certificate in their browser is subject to MitM attacks
on employees of google or distribution chain of the browser.
Moreover, such software may be legally banned by some government.
Of course, you need to have a source of truth, and
nothing is perfect, but also, the best is the enemy of good enough. There's
been plenty of discussion and research on the topic of how to notice that
forged certificates are being presented. What I don't see happening (maybe
I'm missing it) is this stuff being deployed in the real world.
Because security by PKI including DNSSEC is not end to end, it is
impossible to detect security breach so quickly.
Or, can you improve DNSSEC to instantly invalidate compromised zone
information, which is impossible with slowly acting CRLs.
As for using "something like cookies" to secure the communications channel,
this is functionally the same problem as noticing that certificates have
been forged, but gets you a lot less benefit in practice, because you have
to have a secure channel to each thing you want to be able to validate, or
else you have to have a server that is able to do such validation for you
and a secure channel to it (which amounts to the same thing).
Socially, having long enough message IDs is as secure as DNSSEC.
So although DNSSEC is complicated,
That is because authors of the original specification of DNSSEC
ignored my comments (at that time, I was not aware of fundamental
lack of security of PKIs), as a DNS expert having enough knowledge
on PKI, to make it highly 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.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC as a Best Current Practice
Paul Wouters wrote:
Constructive thing to do to make DNS secure is to totally
abandon DNSSEC and rely on DNS cookie or something like that.
DNS cookies provide no data origin security, only a weak transport
security against non-onpath attackers.
If a resolver correctly knows an IP address of a nameserver of a
parent zone and the resolver and the nameserver can communicate
with long enough ID, the resolver can correctly know an IP
address of a nameserver of a child zone, which is secure enough
data origin security.
As for MitM attacks, PKI, in general, is insecure against
them as was demonstrated by diginotar. So, don't bother.
IETF can do nothing if some government legally force
people to install some government provided certificates
to some PKI, including DNSSEC, which is as easy as
MitM attacks on ISP chain may be by government order.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC as a Best Current Practice
Paul Hoffman wrote: In the meantime, anyone interested can make suggestions on how to improve the draft so that it is nice and shiny when it come to the WG for adoption. it just indicates that the value of deploying DNSSEC is often considered lower than the cost. is just wrong. 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/dnsop
Re: [DNSOP] Is DNSSEC a Best Current Practice?
Tim Wicinski wrote:
I have been thinking the same thing this evening about 1034 and 1035.
Thanks for bringing it up.
They do not need to have BCP status, but for several years now I have felt
those two need to be republished with all
the updated text from the many updates (28 for 1035, 18 for 1034) in new
documents. This does not include any other
changes, and it feels like a thankless task.
Given that, here in this ML, I repeatedly correct wide spread
misunderstandings on the original rfcs 1034 and 1035, not
extensions to them, every several years, the task can be
performed properly 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 list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: Deprecating infrastructure .INT domains
Kim Davies wrote: I'm afraid (1) should be documented by a separate rfc maybe titled as "Relationship between IETF and IANA", which should clarify semantics of "IANA considerations" section of not only this but also other rfcs, which was not a problem when both of the 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? These are fair points and hopefully the language can be tweaked to make it a little clearer. No, they are my comments on a possible separate document definitely *not* *against* your ID. So, don't modify your ID for them only to introduce weasel wording, please. I merely think your draft can be better if it better clarifies that the decisions are made by not IETF but IANA/ICANN, which should be *already* accepted by the Internet community including IETF. (RFC 2860 does define the relationship between IETF and IANA But, the rfc says deprecation of some domain under "int" must be decided by not IANA but IETF, which the Internet community including IETF is not practical, which should result in your ID. but the role of .INT was modified as a consequence of RFC 3172) Rfc3172 certainly, though silently, assumes such consequences, rfc2860 requires IETF, not IANA, should make them loudly explicit. But, as the issues are highly operational for which IETF do not and should not have much to do with, if something is wrong, it should be rfc2860. Moreover, as IETF is not governing the operational reality of the Internet, I don't think it necessary to modify rfc2860 before making your ID an up-to-date informational 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, which, for formality, requires modifications to rfc2860. But, don't interpret it as my objection to your ID. We must move on. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Deprecating infrastructure .INT domains
Joe Abley wrote:
The operational decisions relating to these things have already been
made, as I understand it -- the delegations no longer exist. Kim and
Amanda's document seems to have two purposes: (1) to document this
operational reality, and (2) to update protocol specifications to
reflect that operational reality.
I'm afraid (1) should be documented by a separate rfc maybe titled
as "Relationship between IETF and IANA", which should clarify
semantics of "IANA considerations" section of not only this but
also other rfcs, which was not a problem when both of the 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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Deprecating infrastructure .INT domains
Kim Davies wrote:
Datatracker link: https://datatracker.ietf.org/doc/draft-davies-int-historic/
It’s a short document, but at its heart we’ve identified the
following domains that are referenced in places but seem to be obsolete:
That's fine. As the decision is made by IANA/ICANN, not IETF, it is
appropriate that the intended status is not BCP but informational.
But, abstract and introduction should make it explicit that it
is decided by IANA and/or ICANN. Merely stating "IANA shall" in
latter IANA considerations is too late and should confuse most
readers.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] partial glue is not enough, I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
Mark Andrews wrote: See RFC 1034, Section 4.3.2. Algorithm. More explicit explanation on difference is in 1035: NS records cause both the usual additional section processing to locate a type A record, and, when used in a referral, a special search of the zone in which they reside for glue information. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] partial glue is not enough, I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] partial glue is not enough, I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
Paul Hoffman wrote:
RFC 1035 and RFC 2181 are unclear about whether an RRset that is
required in a reply can be partial.
1035 is clear:
- When several RRs of the same type are available for a
particular owner name, the resolver should either cache them
all or none at all. When 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://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional
Tim Wicinski wrote:
This starts a Call for Adoption for draft-andrews-dnsop-glue-is-not-optional
The draft is available here:
https://datatracker.ietf.org/doc/draft-andrews-dnsop-glue-is-not-optional/
Please review this draft to see if you think it is suitable for adoption
by DNSOP, and comments to the list, clearly stating your view.
While I'm not against the clarification, the draft should mention
that rfc1034 already states:
To fix this problem, a zone contains "glue" RRs which are not
part of the authoritative data, and are address RRs for the servers.
These RRs are only necessary if the name server's name is "below" the
cut, and are only used as part of a referral response.
^
which means the glue RRs are necessary for a referral response.
Though not very obvious, it logically 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
Re: [DNSOP] Privacy and DNSSEC
Vladimír Cunat wrote:
Still, note that for some consumers the secure transport may be an
argument to drop validating DNSSEC themselves.
Or, drop any PKI, because PKI is only weakly secure subject to
MitM attacks on CAs.
If they choose some DNS
provider that they trust with privacy (it might be their ISP), it seems
not a huge leap to trust them with DNS integrity as well (say, the
provider doing DNSSEC validation).
The problem of PKI including DNSSEC is that trusted third
parties of CAs are actually untrustworthy.
> Especially as today "regular users"
> don't get that 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 mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SVCB chain lengths
Eric Orth wrote:
CNAMEs already exist without a standardized limit. Good or bad, too late
to change that without breaking things.
According to rfc1034:
Domain names in RRs which point at another name should
always point at the primary name and not the alias.
CNAME chain 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 Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?
Mark Andrews wrote:
A single anycast server DOES NOT and never can provide diversity from the
client’s perspective.
Additionally multiple servers in the same /24 (IPv4) or same /48 (IPv6) should
be treated as a
single server for diversity testing as these are accepted longest accepted
prefixes.
This WG should conclude that IPv6-style anycast is useless and
tell IESG obsolete it.
RFC 7108 describes the implementation of a method that includes a single
point-of-failure by design (see discussion of IDENTITY.L.ROOT-SERVERS.ORG in
section 5).
In short, this is an operational question 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 mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?
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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] ALTSRV
I changed Subject.
Let me clarify confusions on SRV and ALTSRV.
On 2018/11/07 7:05, Mark Andrews wrote:
On Sat, Nov 3, 2018 at 4:12 PM Erik Nygren wrote:
How does draft-schwartz-httpbis-dns-alt-svc-02 with some changes to >> make it more DNS-aligned (e.g. the name as a separate field in the>>
record) not help here?
I'm afraid you (Erik) are not aware of the most important
changes of ALTSRV from SRV, which is necessary to make SRV
implementable on browsers.
One is that, instead of _, _ is used. OW,
browsers need most recent /etc/services and we are still at
a loss if port numbers do not have IANA assigned names.
Another important change is removal of _ replaced
by _. Browsers know , but may
be known only by add on modules for .
They are good changes.
However,
It comes from the HTTP world and is aligned with the
existing AltSvc feature
that is a fatal mistake.
It MUST come from WWW, *NOT* HTTP, world.
What is necessary for browsers is translation mechanism of
URLs in general, which is *NOT* HTTP specific.
Thus, proposed features specific to HTTP/HTTPS should be
removed entirely.
Wouldn’t be better to pre-parse the fields in the record?
Yes, of course.
From URLs including ,
://[@][:][?]
_._. NEWSRV
or, if optional is not specified,
_._. NEWSRV
should be looked up and the original URLs should be rewritten as:
://[@]:[?]
or, if is 0,
://[@][?]
That's all necessary.
As multiple (anycast) addresses ( may have multiple
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.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Character encoding of URI Target RDATA?
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 mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Character encoding of URI Target RDATA?
Robert Edmonds wrote:
> Actually, I don't really see how zone files are relevant to my question.
Then, as the only case DNS perform character encoding/decoding
is when it read/write the zone files, you are asking a wrong
questions in a wrong ML.
> What I'm asking is how the octet sequences 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
Re: [DNSOP] Character encoding of URI Target RDATA?
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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Character encoding of URI Target RDATA?
Robert Edmonds wrote:
> What character encoding should be used when decoding the Target field of
> a URI RR?
It depends on part of URI, which decodes the URI.
How non-ASCII characters in zone files of a name server are
represented is a local issue to the name server.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] relax the requirement for PTR records?
Lee Howard wrote:
> (I think we generally agree that PTRs for servers are good).
>
> Is there consensus now that ISPs don't need to provide PTRs for their
> customers?
You are effectively saying that ISPs can forbid their customers
run good servers.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-root-loopback-01
Kato san;
> The current root zone size in the wire format is 539,248 byte. Provided
> if MTU is 1500, it consists of 367 fragments in UDP. Even if AXFR over
> UDP is allowed, it may not be practical to assume such number of fragments
> get delivered without any packet loss especially over a satellite 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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] MIXFR: Smaller IXFR in the DNSSEC case
Edward Lewis wrote:
> I think examining live IXFR flows found in real operations would be very
> helpful in tuning the implicit delete heuristics that can be employed.
If only the primary purpose of IXFR were to reduce traffic.
But, the purpose is to reduce CPU load of nameservers serving huge
zones.
Thus, IXFR over UDP is a good thing to do.
However, implicit deletions may increase CPU load if there is
nothing to delete, though reduction of TCP traffic may reduce
CPU load more.
Depending on database structure, wildcard deletions may also
increase CPU load.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] MIXFR: Smaller IXFR in the DNSSEC case
Paul Vixie wrote:
> my proposal at the time IXFR was being worked on back in DNSEXT was to use the
> UPDATE encoding, which allows RRset deletion or replacement without
> transmitting
> the old RRset. i still think that's a good plan, and if...
As conditions to update a zone supported by UPDATE is limited, my
proposal at that time is:
1) a client gets the current serial number from the primary
of the zone.
2) the client check the current zone content satisfies
certain conditions for update, including those which
are not supported by UPDATE (e.g. some RR does not exist)
the conditions can be arbitrary complex.
3) the client gets the serial number again, to confirm
that other clients haven't changed the zone content
4) the client send IXFR style update and if it fails,
it should be because of race condition with other clients
so, try again
which is still a good thing to do.
Then, IXFR syntax may be extended with wildcard styles of UPDATE,
if bandwidth consumed by DNS administration is a so severe problem.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] MIXFR: Smaller IXFR in the DNSSEC case
Matthijs Mekking wrote:
> IXFR with DNSSEC is suddenly not so small anymore. Do you recognize
> this?
That is a problem of DNSSEC and, worse, even with the proposal,
neither AXFR nor IXFR won't be so small.
So, if the point of the proposal is to make IXFR with DNSSEC
small, the proposal is wrong.
Even if it is not and something should change, it should be done
only after DNSSEC specification stabilizes (e.g. no new NSEC*
proposals any more for considerable amount of time and most
of NSEC* is obsoleted).
> Olafur and I have some ideas on keeping those zone transfers
> small.
Wrong. With DNSSEC, you can't keep them small.
The conventional wisdom widely deployed by many operators is
not to use DNSSEC, which is not very secure.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
Randy Bush wrote:
>> What problem are we specifically trying to solve here again?
>
> not break things that are working
Yup. Qmail or any software produced by djb adhering the existing
standards of the Internet.
Paul Vixie wrote:
> everything is broken, depending on whom you ask.
The worst broken thing in DNS is DNSSEC.
As a person who have been saying DNSSEC has been broken from the
beginning, after which, as certain amount of operational experiences,
it was revised several times along ways to fix some (but not all),
IMHO, broken parts, may I volunteer to fix not ANT but DNSSEC entirely?
Before replying me, remember that you have been saying, from the
beginning, that DNSSEC was OK if it were properly implemented.
I may temporally ignore fundamental operational impossibility of
DNSSEC and try to make it least harmful w.r.t. DDOS.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
Paul Vixie wrote:
>>> Right, NXDOMAIN returned by some broken implementation to empty
>>> non-terminals MUST NOT be interpreted that the terminals does not
>>> exist.
>
> i disagree with this. broken implementations who emit NXDOMAIN for
> empty non-terminals cannot be used as an excuse not to develop and
> deploy correct protocol and software enhancements.
My suggestion is just for robust minimization without sacrificing
the correctness as NXDOMAIN for full domain name is interpreted
as is.
> the internet has
> hundreds of years to run yet, and these broken implementations are
> (a) shrinking not growing, and (b) subject to rapid replacement when
> they start to encounter problems with correct enhancements to their
> habitat.
How widely is EDNS deployed?
IIRC, about 20 years ago, you said 2KB DNS message of DNSSEC
was not a problem because EDNS takes care of it.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
sth...@nethelp.no wrote:
> For our residential customers, we provide IPv4 PTRs which indicate
> that this is a dynamic address. We *don't* plan to provide IPv6 PTRs
> for those same customers.
That's fine.
But, what we need is opinions of ISPs which are allowing customers
supply PTRs for IPv4, doesn't it?
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Mark Andrews wrote:
> For in-addr.arpa you already have a PTR records. Allowing the end
> user to set its content does not increase the amount of data you
> are serving. It does increase the amount of churn in the zone. A
> matching TCP source address is a good enough authenticator to permit
> the update.
It may be better to carry domain names in DHCP discover/request.
DHCP servers is less complicated than name servers that
it is safer to use it as the place to let end users
inject their information.
sth...@nethelp.no wrote:
> Putting my ISP hat on, I'd have to agree with the security/stability
> reasons (and several others I can think of). As of today, I have zero
> incentive to let my residential customers create their own PTR records.
> Better tools and systems may change this, but it would in any case be
> *way* down on the priority list.
Considering that PTRs generated by ISPs are too often useless,
are you saying you won't provide PTRs?
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Andrew Sullivan wrote:
> Especially in the absence of strong anti-spoofing mechanisms, like
> the DNS Security Extensions, a check for matching reverse DNS mapping
> should be regarded as an extremely weak form of authentication.
Considering that DNS Security Extension provides weak
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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
P Vixie wrote:
> Ohta-san, like you I would like to see stateless address auto
> configuration for ipv6 (SLAAC) die in a fire. Sadly this outcome is
> beyond our powers.
Not necessarily.
> Let's start from where we are, no matter how unpleasant that place
> may be. Vixie
>From where we are, fix broken part of the stack, not elsewhere, never.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
Paul Vixie wrote: > william simpson was right in 1996. we should have moved "get host > name corresponding to IP" to ICMP. the problems described by lee > howard's draft are proof that our whole model is wrong. Wrong. What's wrong is SLAAC, which is stateful in the worst possible fashion with distributed state maintenance, which is why extra overhead of DAD is mandated. The proper solution is to ban SLAAC or, better, entire ND, which purposelessly depends on multicast, complexity of which is causing a lot of problems. > william simpson's icmp idea came with the observation that only a > host can reliably report its own name, and only while it's up, > because it might have a new name from time to time. You are right if we need reverse look up only. However, as "it might have a new name from time to time" means that the host must interact with DNS for updating forward look up, 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
Ray Bellis wrote:
> To me, that _clearly_ indicates that the name exists (given that the
> “label” is a property of the node, which clearly does exists) and
> therefore that NXDOMAIN is inappropriate.
Yes, it is, even for those who debated a lot here without reading
rfc1034 or those who read the rfc so long ago that they don't
remember its content, but only after the text is presented to them.
The problem is that, for those who don't fully understand/remember
DNS, empty non terminals can be a pitfall with high probability,
against which new proposals should be protected.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
Ray Bellis wrote:
>> Right, NXDOMAIN returned by some broken implementation to
>> empty non-terminals MUST NOT be interpreted that the
>> terminals does not exist.
>
> Can we name and shame these broken implementations?
I don't know about a specific example.
But, considering that people here was having lengthy debates
on how should the response to empty non-terminals until I pointed
out relevant part of rfc1034 means there should have been, and,
more importantly, will again be, some.
> It would be a massive shame if this important and useful
> clarification to DNS semantics couldn't be used just 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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible slower response with minimization
Doug Barton wrote:
>> Consider “www.host.group.department.example.com
>
> Your analysis is correct, but only for a cold cache. Once the
> resolver has cached the NS records for group.department.example.com
> the penalty no longer applies.
As the choice between privacy and latency is on resolver side,
moderate latency is not harmful.
Note that DNSSEC with cold cache should mean prohibitively
long initial latency, which means those who try to use DNSSEC
must give up security of privacy.
> FWIW, I also have some concerns about empty non-terminals,
Right, NXDOMAIN returned by some broken implementation to
empty non-terminals MUST NOT be interpreted that the
terminals does not exist.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Anycast and DNS questions
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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Anycast and DNS questions
Antoin Verschuren wrote:
> Question is: Why do you anycast in the first place.
> I think for DNS, primary reason is redundancy and resilience, which is
> why spreading capacity is the primary goal.
Then, your reason has little to do with anycast.
See, for example, draft-ietf-dnsop-ohta-shared-root-server...
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Anycast and DNS questions
Toerless Eckert wrote:
> c) Any example in which the DNS servers utilizing a single shared
> IP address (anycast address) are run by different operators ? Any
> documents describing this ?
draft-ietf-dnsop-ohta-shared-root-server-00.txt
This memo proposes a mechanism of policy based selection of a root
server sharing an IP address (anycast IP address) with other root
servers and discusses operational issues related to it.
Because the selection is policy based, domain administrators have
some control over the selection of the best root server among root
servers sharing an IP address.
Note that operations similar to that described in this memo are
possible today locally without global coordination by any operator
who may be irritated by the lack of his control on (sufficiently
many) root servers, which may be a source of some operational
problems. This memo is an attempt to document the way to solve the
problem in a least harmful manner.
> (RFC3258 seems to focus on single operator
> anycast group of DNS servers.
Hardie insisted on his original proposal, even though I
gave a proof that it is not necessary.
Masataka Ohta
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
Mark Andrews wrote: >>> So? Fragmented packets *do* get through the network. Where >>> they don't it slows up DNS resolution and the firewall usually >>> gets fixed to allow fragments. >> >> Yes, hopefully within a decade or two, some firewall maybe fixed. >> So? > > Actually the firewalls get fixed pretty quickly in most cases. If you are thinking of ideal world with relatively new firewalls, maybe. The problem is that, in the real world, there are a lot of firewalls with maintenance period expired. >> But, even today, how much, in your opinion, is the assured-to-be- >> safe DNS message size over IPv6 with 1280B of MTU? > > Well we have space for around 700 bytes of additional header space > before EDNS@512 will fail due to fragments being dropped. Now I'm > sure one could artificially consume those 700 bytes but for the > moment I'm not worried. You haven't answered my question. How much, in your opinion, is the assured-to-be-safe DNS message size over IPv6 with 1280B of MTU? Without such size, statements like: > BIND 9.10 changes the first state to do variable-size probing: it > will try 512, 1232, 1432, and 4096, starting at the bottom and > working up and down depending on what works. 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) reasonable limit on the extension header length with an explanation that applications such as DNS need some limit was formally rejected by IPv6 WG (in Danvers meeting in 1995, IIRC) that you should expect more. IPv6 is produced by collective stupidity. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
Mark Andrews wrote:
>> But, the problem of current IPv6 specification allows for very
>> long extension headers (more than 60KB is allowed), some of
>> which are automatically inserted not under transport/application
>> layer control.
>
> So? Fragmented packets *do* get through the network. Where they
> don't it slows up DNS resolution and the firewall usually gets fixed
> to allow fragments.
Yes, hopefully within a decade or two, some firewall maybe
fixed. So?
> As for 60K headers, I'll worry about them when they start happening.
I know most of you have been short sighted to expect too
much 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 still have IPv4, I wonder what's "the plan" for the IPv6 case
>>> (at some point, we'll have to rely on whatever such plan is).
>>
>> The first thing to do is to obsolete extension headers 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
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
David Conrad wrote:
>> The IPv6 net has decreed “No, really, FRAGMENTS DO NOT WORK”.
>
> This could be a bit of an issue when the DNSSEC root key is rolled.
It is not, if separate RR types are used for different set of
authentication algorithms and, during roll over, separate RR
types are used 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/dnsop
Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers
Tony Finch wrote:
> BIND 9.10 changes the first state to do variable-size probing: it
> will try 512, 1232, 1432, and 4096, starting at the bottom and
> working up and down depending on what works. 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.
Your assumption is that there is no extension headers exist.
But, the problem of current IPv6 specification allows for very
long extension headers (more than 60KB is allowed), some of
which are automatically inserted not under transport/application
layer control.
So, as Fernando Gont wrote:
> While this issue/question may be currently masqueraded by the fact
> that we still have IPv4, I wonder what's "the plan" for the IPv6 case
> (at some point, we'll have to rely on whatever such plan is).
The first thing to do is to obsolete extension headers 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
Re: [DNSOP] Masataka Ohta's 2004 draft...
Francis Dupont wrote: >> >> Does "several thousands of queries per second during normal >> >> operations" with TCP matter? >> > >> > => yes because it is at the limit current OSs can do on cheap stock >> > hardware... >> >> Are you saying real root servers are using cheap stock hardware? > > => current real root servers no but if Read the draft, before repeatedly demonstrating your stupidity in public. It is about the current configuration. Moreover, > we'd like to run 100 or 100 > times more we have first to lower requirements on the hardware. then, even though you haven't read the draft, it is obvious that 100 times more root servers means 100 times less load. > And the argument applies to not root servers too. The argument in the draft is on the root servers. >> Aren't you arguing that the server should close connections >> only after a timeout because the server can not accept so >> many new connections? > > => no, I am arguing the requirement on TCP DNS to close at the server > side only after a timeout It is because someone (Paul Vixie, perhaps) thought that several thousands new connection per second was harmful. Thus, today, the timeout can be 5, 1 or 0 seconds, if longer 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Masataka Ohta's 2004 draft...
Francis Dupont wrote: > In your previous mail you wrote: > >> Does "several thousands of queries per second during normal >> operations" with TCP matter? > > => yes because it is at the limit current OSs can do on cheap stock > hardware... Are you saying real root servers are using cheap stock hardware? > PS: I wrote OS because the first reached perf limit is in the kernel, > not in the DNS server. And if you argue Web servers support far more, > the TCP DNS issue is the server should close connections only after > a timeout... Aren't you arguing that the server should close connections only 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
Re: [DNSOP] Masataka Ohta's 2004 draft...
Paul Vixie wrote:
Hi,
> this author isn't in toronto so i'll answer here-- i had not and have
> not compared -lee-dnsop-scalingroot- to -ohta-shared-root-.
Security consideration section of my draft explains why
allowing all the ISPs run their own anycast root servers
does not make plain DNS less 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
Re: [DNSOP] Masataka Ohta's 2004 draft...
Hector Santos wrote:
> What has been crossing my mind regarding this NULL MX setup, was the
> possible privacy issue with NULL MX root domain "Traceability" aspect
> with legacy MTAs performing SMTP "Implicit MX" (No MX record, Fallback
> to A record) logic. What will the A query IP resolved to when the
> exchange points to the root?
If millions of anycast root servers without a centralized
administrator are distributed world wide, it makes it
difficult for NSA monitor queries to all the root servers,
because of massive number of them.
And, it's not just for NULL MX. Many queries go to the root
servers.
Masataka Ohta
PS
OTOH, queries to 8.8.8.8 administrated by google are easy
victims of NSA.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Masataka Ohta's 2004 draft...
David Conrad wrote:
> I asked if the authors had compared their draft
> (http://tools.ietf.org/html/draft-lee-dnsop-scalingroot-00) to yours.
Hm, the draft inappropriately assumes having a lot of
anycast addresses is better even though several ones are
enough.
But, the following statement in the draft:
> However, the costs of using TCP rather than
> UDP, in terms of system and network resources, are much higher and
> can have significant impact on systems such as name servers that may
> receive several thousands of queries per second during normal
> operations.
is more disturbing to me.
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
Re: [DNSOP] Masataka Ohta's 2004 draft...
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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
Klaus Malorny wrote: >> OK. If it is acceptable for you, allow 1 variant per name and we >> are done. >> >> That people around you are happy with at most 5 or 20 variants >> does not mean other people needing more variants may suffer >> from the trade-off. >> >> A better solution is never use IDN. That, even within European >> (French) context, capital form of 'y' with diaeresis can be 'Y' >> or 'Y' with diaeresis is already bad enough for case insensitive >> DNS. > What's the purpose of this comment? Are you saying that you don't care > about real world problems? I'm saying you should accept the real world problems of: other people needing more variants may suffer from the trade-off. and That, even within European (French) context, capital form of 'y' with diaeresis can be 'Y' or 'Y' with diaeresis is already bad enough for case insensitive DNS. > Get rid of IDNs? Yes. As it is obvious from the beginning that IDN is not practical, I have been saying so. > Learn English or die? No, as can be seen names on passport, internationally, every country have a scripting system to represent their language in ASCII. Though some European country may insist that their passport may include Latin-1, it is not fair for the rest of the people who can't use their traditional script. > Internet back to its roots as an academic, non-commerical network? This > all would be fine to me, but unfortunately not to many people out there. A commercial network can not support something operationally impossible or, at least, impractical. Masataka Ohta PS As I repeatedly state, so called IDN is not internationalized at all and actually is localized DN, whereas ASCII DN is, like ASCII names in passports, fully internationalized. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
