ity.
We can and should kill MD5 key generation and signing (and I'll add this to
the ticket about updating defaults in BIND) but I'm uncomfortable killing
MD5 validation until I'm sure there aren't any legacy keys floating around.
Your other point about never-used code being uneploded ordnance is well
t
dy deployed; it was introduced as "mimimal-any" in BIND
9.11.0 using the pick-one-RRset method, and cloudflare has been using the
HINFO method for over a year. I haven't heard reports of anything being
broken.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
se for the working group to take
it on. If it turns out, however, that everyone who might like NSEC5 is also
reasonably satisified with NSEC3, then we'd be wasting time on an academic
exercise. It's clever, but it's only necessary if we broadly agree that
NSEC3 isn't meeting our needs. I'm not sold
for it to be legal.
> Not to mention the difficulties in writing so-called clarification
> documents. They aren't all that pleasant...
Well, that's why I started with an email thread...
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
__
ke is to be able to send FORMERR with a clear conscience.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
nyone have a problem
with the idea of clarifying the protocol here, saying that the order of
records in the answer section of a chaining response is significant, and in
particular, that a DNAME MUST precede the corresponding synthesized CNAME?
--
Evan Hunt -- e...@isc.org
Internet Sys
On Fri, Jan 06, 2017 at 06:43:30PM +, Wessels, Duane wrote:
> When a server receives the option from a non-whitelisted client, it
> MUST return a FORMERR response.
+1
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
invented a useful tool to help address it, and I'm
in favor of documenting it.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
en which is not, in my opinon, anywhere near as
obvious as it is to you) are considerations here.
If you wish to consider a physical analog, there may be a general principle
that one should not interfere with postal mail, but this is challeged by
the existence of the unabomber or the anthrax atta
t
malware domains don't exist.
The ethical conundrum having been resolved, we can now carry on with
documenting the mechanism I used to tell my resolver to do this.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP
g/html/draft-wijngaards-dnsext-trust-history-03
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
t's being answered, that's
legit under RFC 6840 sections 5.7 and 5.8.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Sun, Apr 10, 2016 at 12:52:39PM -0400, Olafur Gudmundsson wrote:
> I have read the draft and support its adoption
+1.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mail
D
signer; it's going to be a long, long time before validators can start
ignoring it.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
he general case
instead of the root-only solution.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
lways
> false.
Yes, it should have that qualifier.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Sun, Feb 07, 2016 at 02:16:15PM +, Tony Finch wrote:
> Is this sensible, and if do should it be suggested by the draft?
Yes. I haven't looked in the draft recently, but I thought I mentioned that
when I originally described this trick. Choose an arbitrary (preferably
determinate) rrset to
osal requires.
>
> I disagree with this characterization that "the entire ecosystem" needs
> to be upgraded. Yes a non-key-tag-aware recursive won't know to forward
> the option, but this is true for all EDNS options.
But it isn't true for query names.
--
Evan Hunt -- e.
ain state for all those active queries, which adds a fair
bit of complexity. I would expect it to be a lot more straightforward to
code a stub validator using CHAIN.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing l
ject; empty non-terminal nodes are
mentioned under "no data" rather than "name error".
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
RL, are referenced in the draft.
I've had no significant involvement in the catalog zones design, so
I can't tell you why the metazone format wasn't used, but I'm pretty
sure there were reasons for the decision.
--
Evan Hunt -- e...@isc.org
Internet Syste
On Wed, Oct 14, 2015 at 09:49:59AM +0100, Ólafur Guðmundsson wrote:
> Sorry for the typo : RFC4470
>
> Minimally Covering NSEC Records and DNSSEC On-line Signing
Ah, thanks. Yes, the first and second points mentioned in the security
considerations there are both applicable.
--
Evan
, are not possible.
* I'm not completely certain DNAME needs to be mentioned in the first
bullet point, but I'm concerned there may be unintended consequences
if it's present but omitted.)
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP
to be explicit.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ty considerations good enough ?
Sorry, which RFC? "vCard Extentions for Instant Messaging" doesn't
seem likely to be what you meant here, but my brain is failing to
figure it out from context.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
__
to support
> one of the two then that is fine with me.
Both are acceptable as long as we don't break the DNS.
I cannot support a proposal that does break the DNS.
If we do what's necessary to avoid breaking the DNS, then I don't
believe there's any practical advantage to the HINFO approach, bu
on. NS and glue records don't have a place to put a
port number, so static-stub zones don't allow you to configure one.
It should be easy enough to create a local alias address for the purpose
though. "ifconfig lo inet6 add ::2 alias", salt to taste.
--
Evan Hunt -- e...@isc.org
Intern
be mentioned in security considerations.
The pick-one-RRset mechanism doesn't have this problem, because
the covering RRSIG will already exist for whichever RRset is
returned.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailin
onse
size (but still a lot better than unminimized ANY responses).
Perhaps both approaches should be described in the draft.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
though. Unless I'm
overlooking something, the NONCE field in Mukund's proposal becomes
unnecessary if cookies are in use. Otherwise it seems like a very good
idea.
(It's a pity there's no version field in the COOKIE option format;
COOKIE version 1 could have been extended to include a checksum.)
--
, the cached data at and below
that name can also be discarded, so TTLs aren't a major concern when the
cache and the validator are coresident, and it hasn't been a factor with
BIND. But if validating forwarders and stubs support NTAs they may have
a different experience.
--
Evan Hunt -- e...@isc.org
not
alter the deal any further.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
run than ensuring that ICANN never
sells anybody a TLD called .onion.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
of
distressingly wiggly worms.
However, I can imagine a mechanism in which a query for some.tld/FAKE
instructs the local resolver to use an alternate resolution mechanism for
some.tld, with the DNS protocol being used only for that first hop.
This might be suitable for things like .onion.
--
Evan
fine.
There were a couple of review comments that I'll need to dig out and
address if the draft is coming back to life.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman
that operators are not surprised when
this happens.
Just added. Seem good?
I'd have gone with MAY instead of SHOULD, but that's a quibble:
it's fine.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP
opinion between A and B, but I'd like this
document to be clear on this. And, if it means A, I'd use an RFC2119
keyword (it's probably a SHOULD).
With respect to the precedence rule, I would use MUST rather than SHOULD.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc
configuration, that would be sensible to
warn about; it's the sort of oddity that might have been unintentional.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
that trust anchor, effectively
disabling it. Implementations MAY issue a warning when this occurs.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
of adding the TC=1 response to the
protocol specification as a MAY.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
text to the document stating that.
This matches the BIND implementation.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
just as well in almost every scenario, so it doesn't justify the cost in
additional complexity.
Thanks,
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
required
for authoritative responses (RFC 2308 section 3), but optional for
recursive.
Might also add that DNSSEC-signed zones will include a signed NSEC/NSEC3
to prove the nonexistence of the qtype.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc
;
modifying the option format wouldn't be a huge problem. (I suspect it'll
be more of an annoyance to change the name from SIT to COOKIE.)
Would it be reasonable to leave space in the option for error reporting,
but leave it up to the implementor to decide whether to bother doing so?
--
Evan Hunt
of them returns and another one MX, etc. However, it can't
possibly be any worse of a leak than merely running an old server that
doesn't implement ANY minimization, so on balance I agree with Paul that
it would be an overspecification.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium
draft) but not as much and what gets
leaked would be trivial to acquire by other means anyway.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
worthwhile. :)
PS: I tend to use NXRRSET as slightly more expressive than NODATA,
though it is an extended rcode for dynamic update. Worth mentioning
along with the NODATA definition, or am I pretty much solo in using
the term this way?
You're not the only one.
--
Evan Hunt -- e...@isc.org
turns out not to commonplace,
then I say let's run with it.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
definition of the word.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Wed, Mar 11, 2015 at 12:13:42PM +, Tony Finch wrote:
These are signed zones so the answer has to validate.
... they are? I thought the proposal was to restrict/deprecate
qtype=ANY for all zones, not just signed ones.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc
still resolve.
I like this better than any of the prior suggestions. (It doesn't
address qmail's problem, but that's a lost cause no matter which method
is chosen.)
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
, I'm
guessing it was talked to death before I ever started working with the DNS
and there were good reasons not to do it, but I don't actually know what
they were.)
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
that :-)
I wasn't thinking of obscuring anything, just mentioning my one major
concern about including diagnostics with SERVFAIL responses: I fear
it will be a tempting target for someone to attempt misguided cleverness.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc
to a policy decision, such
as ignore DNSSEC failures due to expired signatures or something,
because the diagnostic messages would be trivial to spoof.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
in the CNAME chain separately.
(I vividly remember a thread about this three or four years ago, but I'm
having poor luck with the grepping.)
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https
strictly need to be.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
there.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
to characterize
it as a disadvantage.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
. :)
With a single view, if you're authoritative for a zone, then you're
the authority, period. You *know* the corect answer. Validating yourself
to find out whether you're lying to yourself would be somewhat silly.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc
, but org/DS wasn't.)
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
again.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
, it would *only* be because I was deploying a local root instance
on my own network or on the local host. If I weren't going to deploy it
myself, then I'd stick to the traditional roots. I may not be typical
in that respect, but if I am, then there's no need for unowned anycast
anyway.
--
Evan
are willing to contribute text, review, etc.
+1 for adoption, and I can review.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
queries... but as long as one of them still supports transfers,
you'd be okay. I'm confident that f-root, operated by ISC, will always
support them.
(Honestly, I don't know why it isn't a requirement for all the root
ops. It's not like the zone contents are a secret.)
--
Evan Hunt -- e
at lower cost.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Mon, Nov 10, 2014 at 05:27:08PM +, Evan Hunt wrote:
Attached is a sample named.conf configuration which implements this using a
root view for the root zone slave, and a recursive view for recursion.
DNSSEC validation works correctly and the root zone will sync correctly.
One
address, and you'll get
answers for addresses that aren't in use... but those kind of seem like
features, not bugs. Also, it's cheap.
So, are there technical reasons not to do this, or is it just conceptual
inertia from the use of $GENERATE for v4?
--
Evan Hunt -- e...@isc.org
Internet Systems
haven't hit any obvious problems.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
typical PTR checks look for existence or matching?
Matching could work, too, if they were able to compare prefixes rather
than full addresses, but that's obviously a bigger leap.
I suspect John is correct and the idea isn't practical. Alas. Thanks
for the education, carry on.
--
Evan Hunt -- e
On Tue, Oct 07, 2014 at 01:27:40PM -0400, Tim Wicinski wrote:
The documents are:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-chain-query/
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/
I support both, and will review if needed.
--
Evan Hunt -- e...@isc.org
utility that ships with BIND 9.10 is an example.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
get enough data, but should have, then the
validation failed and the answer is bogus. Your proposal effectively
promotes all bogus answers to insecure.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
(and will be in BIND in
a future release).
I do not believe your stated problem is one that needs addressing.
+1
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo
at $date.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
.)
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
the NOTE
specification with a NOTE-OK option rather than a NO bit. (Thereby
strangling in its cradle my secret plan to gradually aquire EDNS
flags until they spelled DO NO TT AU NT HA PP YF UN BA LL, so I
HOPE YOU'RE HAPPY.)
http://www.ietf.org/id/draft-hunt-note-rr-01.txt
--
Evan Hunt -- e
anybody with access to dig.
This draft proposes such a beast. Feedback would be lovely.
http://www.ietf.org/internet-drafts/draft-hunt-note-rr-00.txt
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
version
bump could allocate more of them. So I concur with rare, but not
necessarily with precious.
However, there is no technical reason a flag bit is necessary. I just
think it's more elegant.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc
, by
example, is a little bit like this: omitting some response data if a
flag bit is not set.)
However, other considerations do exist, and I'm not married to it.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP
Finch has a nifty idea to replace ntpdate with a quorum of tlsdate
responses; it might still be subvertible but it would be a much harder
nut to crack. https://git.csx.cam.ac.uk/x/ucs/u/fanf2/temporum.git)
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc
validating. If you get
SERVFAIL, *then* you try with CD=1, and if the result validates, you
know it was the resolver that was broken rather than the data.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP
integrated...
My apologies for not sending feedback directly. (That's something
we really need to work on.) IIRC, we opted to clarify the documentation
rather than add a warning to dig itself. There's also a knowledge base
article on this topic at http://tinyurl.com/o37rpgm.
--
Evan Hunt -- e
and analyzed,
but have decided for some reason to use 8.8.8.8 anyway, be sure they're
talking to the real 8.8.8.8? :)
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman
,
with the same solution?
Oh, I didn't realize it was an option. Yes, that sounds excellent,
please do that.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
not sure any realistic defense is possible anyway.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
, but the truth is, any adversary with the resources to
pull this off would certainly have cheaper alternatives.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo
the clock an
hour forward and try again; on success, use NTP to fine-tune. Klugey! :) )
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
and not rebooted for a few months or years, and then
no longer works and can't recover.
Unfortunately, none of these concerns get smaller if we wait longer.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https
On Fri, Apr 13, 2012 at 05:43:42PM +, Paul Vixie wrote:
i'm opposed to negative trust anchors, both for their security
implications if there were secure applications in existence, and for
their information economics implications.
+1
--
Evan Hunt -- e...@isc.org
Internet Systems
).
You've got a chicken-egg problem there: How does the parent know it
should trust the key that signed the CDS?
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo
hashes. However, NSEC records are sometimes returned in response to
DO=0 queries,
Wouldn't that be an implementation bug?
Not if it was an ANY query. Otherwise, yes.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP
on similar
qualities.
+1 except for the if. It is mathematically possible for collisions to
occur with one approach and not the other, and it would be irresponsible
not to make note of the fact, even if we agree that the chances of this
occurring in nature are negligible.
--
Evan Hunt -- e...@isc.org
of actually
being *true*, and I think that's what the draft should say.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
mechanisms are usually
referred to by the names of their corresponding RR types.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
recommendations with that tradeoff in mind; a
ZSK may be as long as a KSK, or it may be shorter if it's rolled over more
frequently. (I think 4641bis already says something along those lines.)
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc
network configuration that used to be fiddly and arcane and
have since become simple; you seem to be arguing that DNSSEC won't follow
suit, but I see no technical reason why it shouldn't.
--
Evan Hunt -- [EMAIL PROTECTED]
Internet Systems Consortium, Inc
-source
software, constitutes a conflict of interest?
Should Rob recuse himself from *any* matter that Paul's sent an email
about? What about opinions Paul may have discussed with Rob privately?
Or just things he's vaguely thought about, without saying anything?
--
Evan Hunt -- [EMAIL PROTECTED
101 - 197 of 197 matches
Mail list logo
