. Consistent with [RFC2308],
>resolution failures MUST NOT be cached for longer than 5 minutes.
That's definitely an improvement, yes.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
e. It's a
mild preference though, and if I'm the only one who feels that way, I won't
argue about it further.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ble, and thus need different words for each category?
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ot - it's used internally by name
servers in ways that could be pretty difficult to untangle.
I would lean toward using a newly allocated type code, though, because I'm
100% sure that wouldn't cause any conflict with existing implementations,
and I'm only 99.7% sure that NULL wouldn't.
--
Evan
on with phrases like "acting as a primary" or "acting as a
secondary" and get the point across without much difficulty. But if
that's not acceptable, then maybe "transfer provider" and "transfer
recipient"?
--
Evan Hunt -- e...@isc.org
Internet Systems Consor
ential confusion in the fact that a primary server could meaningfully be
said to "initiate" a transfer operation when it sends a NOTIFY.)
On the other hand, you can say "server A acts as primary for server B",
and it's fairly eas
"Primary server".
BIND added primary/secondary as synonyms for master/slave in our
configuration syntax several years ago and have been progressively updating
our documentation to prefer those terms ever since. The upcoming release
pretty much completes that process.
--
Evan Hunt -- e..
O the transition from "master"
to "primary" and "slave" to "secondary" is far enough under way and well
enough understood at this point that I suspect it would be easier to add
modifiers when necessary than to try to deploy new vocabulary entirely.
-
d without a final answer. The client can start a
new query from where the response left off, but I would expect most to
treat it as a non-answer.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.
hemselves these days; resolvers
sit for years. (A few years ago there were still BIND 4 instances ticking
away out there.)
And, people who want their browsers to work better will have a specific
reason to upgrade. Resolver operators' motiivation is rather less direct.
--
Evan Hunt -- e...@isc.org
r have the problem ANAME was meant to solve,
and I'm content to let it pass into history.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
t slow tonight; can you explain in more detail the
security hole you foresee, and how Wes's suggestion fails to address
it?
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
of inconvenience. I wish I'd added a third file instead, such as
K*.meta, instead of extending K*.private.
However, IMHO, redesigning it now would inconvenience people rather more
than putting up with it does, so for the time being I don't expect it to
change.
--
Evan Hunt -- e...@isc.org
In
e
best if we coordinate our changes to ensure that your extensions are
interoperable with ours.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ing out of bar bof opportunities in Montreal, but I'd be happy
to discuss this further.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
for their Do53 measaurements - and it makes a significant difference.
I don't know, even now, whether the comparison was apples-to-apples or not.
"Do53" is a handy abbreviation, but I'm concerned that using it as a
coequal peer of DoT and DoH will lead to fuzzy thinking.
--
Evan Hunt -- e...
oot zone will adopt one or both.
In the more general case for validating zone transfers, the idea is to have
a sanity check that signatures are good before a secondary starts serving a
zone. This is mostly about preventing self-foot-shooting incidents; ZONEMD
isn't strictly necessary for it.
--
Eva
st a server configuration. At worst, it's a waste of the
time that's been spent talking about it (with the zone transfer code that
fell out of it turning the effort to a net positive, I hope).
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Sat, Jul 06, 2019 at 03:39:53PM -0700, Joe Abley wrote:
> What's the use-case for using the DNS to transfer private key data?
Inline signing, I believe. Witold should be the one to discuss that one,
not me.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium,
Colleages,
Some years ago, Dan Mahoney and I submitted a draft describing a proposed
mechanism for storing confidential zone comments alongside normal zone
data - a NOTE RR, which would be transferrable from primary to secondary
servers, but not accessible to ordinary DNS queries. It generated
in order to solve a problem that I'm not at all sure we have.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
they see
an unexpected extra RRset in the answer section, it would be good to find
out about it. I guess we should do some testing.
Hm, stub resolvers might be stupider than full resolvers. Perhaps it
would be useful to differentiate RD=0 and RD=1?
--
Evan Hunt -- e...@isc.org
Internet Systems Consor
hat. Having a note
in the registry about whether they're still in use might be a kindness for
implementers. It doesn't impact interoperability, though.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
htt
erhaps the document is unclear, or perhaps I've misunderstood you.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
u were trying to make; I didn't get
it immediately because you started off discussing the shortcomings of an
RFC that doesn't seem particularly directly related. So let's get
specific about the problem and discuss requirements for a solution.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortiu
ventually have
broader applications than just local root cache. I think some of the early
work on aggressive negative caching was root-specific as well. I wouldn't
assume an idea is bad just because it's currently focused on the root, it
might not always be.
--
Evan Hunt -- e...@isc.org
Interne
e between HAMMER and the thing you said?
(Which BIND also does, incidentally.)
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
oaches into a standards-compliant, portable bodge.
Elegant it isn't, but if we don't standardize ANAME, the existing bodges
will persist. Browser vendors want the DNS to give them addresses, and
only addresses.
If you can get them to change their minds, though, I wish you all success.
--
t up to date.
Seems like a useful thing to leverage, if possible.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
hat we'll always serve AXFR on F, but I
don't know if that commitment is in writing, nor whether the other roots
that currently support it have made any promises to keep doing so.
IMHO it would be nice if all 13 letters provided AXFR service, but at a
minimum we it's important for *some* of them t
resolvers that do not
> support it?
They're no worse off than they already were. The old methods would still
work just as well or badly as they do today.
If apex CNAME were declared legitimate, then people using legacy resolvers
*would* be worse off than they are now.
--
Evan Hunt --
means that the type may
> co-exist with the CNAME. The resolver adds a positive cache entry for
> the type and returns the fetched answer.
>
> 2.b.iii. If the fetch returns NXDOMAIN, it overwrites the cache for that
> node with a negative cache entry.
>
>
>
> Adding a
, but I do sometimes
wonder what we (or, y'know, our grandchildren) are going to do if we
ever run short of type codes.
The obvious thing would be to expand into the CLASS field. Someone in
the future might be grateful if we avoid making that too difficult.
--
Evan H
idea. I don't see much
benefit, but I also don't see much cost.)
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
l feature, I don't think it's
essential to the problem of verifiable root mirroring. "Nice to have",
but not a requirement.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.o
ne verification hash without it and so could you. SO, ZONEMD only needs
expert review.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
whether
it's a major change to the way the DNS works, or just a thing we can move
forward on with expert review.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
plementation and use of the new RRType in the RFC series.
A good point. Technically, I don't think there's anything in ZONEMD that
couldn't be implemented with TXT; using a dedicated rrtype for the purpose
is mere convenience.
--
Evan Hunt -- e...@isc.org
Internet Systems Con
On Sun, Jul 29, 2018 at 10:55:31AM +0200, Ondřej Surý wrote:
> You need to know the hash is valid before you start the download.
> Therefore the hash has to be signed.
Before you *start* the download? Or before you use what you downloaded?
--
Evan Hunt -- e...@isc.org
Internet S
hem. The code's long-since implemented and
mature and using it doesn't introduce a lot of new moving parts.
However, the inability to verify a the correctness and completeness of a
zone transfer (including the gluey bits) with an in-band signature *is* a
problem. ZONEMD/XHASH solves it.
--
Evan H
-band mechanism. Either way, once
the local copy is obtained, ZONEMD allows it to be verified.
So, yes, ZONEMD does protect zone transmission. It does so regardless of
channel - TLS, AXFR/IXFR, sneakernet, whatever.
--
Evan Hunt -- e...@isc.org
Internet Systems
On Tue, Jul 10, 2018 at 11:08:37PM -0400, John Levine wrote:
> There's over 6000 service names defined for SRV. That's a lot of rrtypes.
But HTTP/HTTPS is the one we have by far the most problems with.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium,
On Fri, Jul 06, 2018 at 08:22:41AM +0200, Matthijs Mekking wrote:
> Me too :)
>
> https://github.com/each/draft-aname/pulls
Yes, sorry, my bad. I'll try to address the pull requests next week.
Should've done ages ago.
--
Evan Hunt -- e...@isc.org
Internet Systems Consor
I think it would be impossible to make that work sanely with legacy
resolvers.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
th side still must be implemented. Possibly even more
of them, since XNAME responses might need to include answers for lots
of different rrtypes, while ANAME is explicitly limited to A and .
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
ime, so I
can't volunteer to run it. If someone else wants to step in, that'd be
great.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
an ANAME, the
auth would need to provide some sort of usable answer, which means it has
to be able to look up addresses for the target name (whether it does that
internally or via resolv.conf). It would be nice if that could be avoided,
but there's no straightforward way.
--
Evan Hunt --
atters
if the different implementations have different defaults, does it?
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
t require the authoritative server
itself to do recursion; it requires it to have access to a reursive
server.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Sat, Apr 14, 2018 at 01:13:30AM +0800, Mukund Sivaraman wrote:
> On Fri, Apr 13, 2018 at 04:31:35PM +0000, Evan Hunt wrote:
> > I could have sworn there was an RFC published several years ago concerning
> > the prevention of cache poisoning, which specified that resolvers had to
eral years ago concerning
the prevention of cache poisoning, which specified that resolvers had to
ignore out of zone CNAMEs and re-query, but I can't find it now. Poor
google skills, or did I dream the whole thing?
--
Evan Hunt -- e...@isc.org
Interne
ll alive and well (for now). However...
> I mentioned my localized DLV idea to Evan Hunt at IETF 101. I feared he
> would think it is too horrible to contemplate :-) but in fact he thought
> the use case is quite reasonable.
I must confess I don't remember the conversation clearly (I may
On Fri, Apr 06, 2018 at 10:09:50PM -0400, Warren Kumari wrote:
> I think I heard that ISC was considering adding support, but was
> planning on waiting till RFC / some sort of LC.
Yes. The work in progress is available here:
https://gitlab.isc.org/isc-projects/bind9/merge_requests/123
--
nted several times, there's
lots and lots of real-world deployment experience. I'd be happy to see an
informational RFC describing it; I'd be confident in its stability.
Relying on old expired drafts would be disappointing.
ECS, though, was published before it was fully cooked, and continuing to
itera
n or off by an intermediate proxy,
so you should never rely on it for much of anything, really.)
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
t
calls for correction in a bis document rather than an erratum.
Errata can be published an awful lot faster, though.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
nknown type otherwise.
4. validators and signers SHOULD treat rdata for obsolete/deprecated types
as opaque with respect to canonical RR ordering and deduplication
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
e experience with interoperation
between servers that implement different sets of rrtypes.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
roup, then my inclination would be to a log a message saying so if you
tried to load them in a zone, same as with SPF. In a future relase I might
start treating them as opague types when rendering to wire format, but
would probably retain the ability
d DNS queries
containing EDNS OPT records indicates that the server is not a DNS
responder. The querier MUST treat this server as nonresponsive, and
MUST NOT retry queries without EDNS.
Or something like that.
--
Evan Hunt -- e...@isc.org
Intern
r depends on whether the originating client is inside or outside of a
network controlled by the server's operator.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
eives (which would make it a full-service resolver), but some
>recursive resolvers might not cache.
>
> That is, "recursive mode" is only barely defined in RFC 1034, and
> "recursive resolver" is defined almost trivially.
>
> Can these be improved on? This is one of the core ideas in the DNS
> protocol and it seems a bit weird that we don't have a crisp set of
> definitions. If there is more text from RFCs to quote, that would
> possibly be a big help.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
an auth server risks cache poisoning. (Not even necessarily
malicious; the auth might simply be serving information that's outdated.)
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
y with with NSEC, ANAME, A,
> and valid RRSIGs for all three RRsets. The recursive server
> implements ANAME and does further processing of it, replacing the A
> RRset. What RRSIGs should it send to clients setting 'DO'?
>
> 2) autoritative server answers an A query with NSEC + ANAME with valid
> RRSIGs, but no A or RRsets. The recursive server implements
> ANAME and does further processing of it, adding an A RRset to the
> answer. What RRSIGs should it send to clients setting 'DO'?
Some thought required, I'll come back to this.
Thanks very much for the comments.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
the word "it"?
> But I'd add "a resolver MUST include ANAME
> RRset in respones to queries for A/".
Yes, I'd been assuming it would. If I forgot to mention it in the
draft, I'll fix that.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
an that; you'd just
overriding the ANAME TTL.
> It seems to me that ANAME gives auth servers resolver-like properties, so
> why wouldn't that apply there as well?
Yes, fair point. I'll try to come up with text to address this.
--
Evan Hunt -- e...@isc.
d then decide whether to serve stale records or not.
However, I guess we can relax this requirement if the auth server is
configured for serve-stale.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Tue, Jan 16, 2018 at 03:33:11PM -0500, Bob Harold wrote:
> That sounds clear and complete to me!
+1
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ose
> required for delegation"?
Up to the comma looks fine. The part after the comma strikes me
as over-wordy, and I suggest "and there is no requirement that
authoritative servers send them".
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
__
n the resolver didn't already
have; resolution can succeed without it."
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
beast, then IMHO that, not the
authority, is the one that's mis-using REFUSED; REFUSED only makes sense on
a hop-by-hop basis.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/li
with upward referral, SERVFAIL,
REFUSED. We already disposed of upward referral. SERVFAIL gets you
spurious retries. REFUSED makes the querant go away for a sensible amount
of time; we have ten years of operational experience with it. I don't see
the problem.
--
Evan Hunt -- e...@is
periodically regardless. If
the SRV record were spoofed, causing the child to send a NOTIFY to the
wrong address, synchronization should still occur, just not as quickly.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailin
ten. REFUSED isn't an exact fit, but it's
legal, sensible in context, and gets the job done.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
.org/html/draft-andrews-dnsop-update-parent-zones-04
The same trick could be used to find the right NOTIFY target.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
d as
nonexistent by servers implementing QNAME minimization.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
a specific term that only refers to the *last*
name, perhaps "QNAME (final)" would be a better choice for that.
Incidentally "CNAME chain as defined in [RFC2308]" is ambiguous. RFC
2308 has a definition of QNAME that includes the last CNAME in a chain,
but it does not
. But
given that there are non-malevolent reasons for wanting to serve stale
data, and solutions are being implemented (including one in BIND), I'm
okay with publishing details of the method, same as with RPZ.
--
Evan Hunt -- e...@isc.org
Internet Systems Con
and here we are.
Just as with RPZ, it seems reasonable to publish guidance on how to
do the kind-of-bad thing in the least bad way.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf
etching goes on the pile with NXDOMAIN redirection, tools that
can be used for censorship, and all the other regrettable things that we
implemented anyway dammit.
(I do like the idea of advertising a separate expiry value though.)
--
Evan Hunt -- e...@isc.org
Internet Systems Con
f you've already got control of the
channel, then I can't see how sending the client "Prohibited" or "Lame"
messages gives you any more of an advantage than you already had. However,
any response that says anything about DNSSEC validity should be presumed
guilty until proven innoc
orgery. The
ones related to validation I wouldn't trust without a signature, though.
This should be spelled out in more detail in the security considerations.
(And, considering I'm listed as a co-author on this draft, maybe it's time
I earn my keep and submit some text...)
--
Evan Hunt -- e...@isc.org
In
least we can
give them an interoperable and standards-compliant way to do the dumb
thing.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
dually,
though. The domain that wants to redirect apex addresses can implement
ANAME, and its clients will get answers. Resolvers that want better
answers can do that too. Forklift not required.
> I understand that's how things work in practice, but I don't like it.
So say we all.
--
Evan
end up
with two servers that both return SERVFAIL on address queries.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ething similar.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
> Then people who want to ask (A + + TLSA) or (A++SSHFP) or
> (A++IPSECKEY) could use the same mechanism. And ANAME would just be
> a regular DNS record without any abnormal processing.
Fine idea but not related. ANAME == CNAME for addresses.
--
Eva
ANAME. They ask for A/, and get an A/
answer, along with an ANAME record so they can go directly to the source
and get a better answer if they support that.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
as it would with a CNAME.
Please have at it.
- Forwarded message from internet-dra...@ietf.org -
From: internet-dra...@ietf.org
To: Evan Hunt <e...@isc.org>, Peter van Dijk <peter.van.d...@powerdns.com>,
Anthony Eden <anthony.e...@dnsimple.com>
Subject: New Version Noti
things to get around to someday in BIND: if auth servers could be
configured to use external resolvers, then security bugs affecting
only the recursive code wouldn't be any risk to them. But I definitely
wouldn't phrase that as "there should not be any code".)
--
Evan Hunt -- e...@isc.org
D.livingood-negative-trust-anchors].
Negative trust anchors are now specified in RFC 7646. This isn't a very
clear description of them; I'll suggest revised text in separate mail.
> REQ9: Mechanisms MUST be provided to inform the DNSSEC Validator a KSK
&g
porary
when RFC 7646 was being written. Please let's just have insecure
delegations?)
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
eed to merge his efforts
with ours. I expect to post it in a few days, stay tuned.)
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
/NSEC3 proving
nonexistence of an answer at one auth server is going be problematic if
there is a positive answer from another.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/m
ed, it'll be provably wrong. I don't think it's
enough to handwave the problem as "not of great concern". At least,
please add some operational advice that BULK is not to be deployed in
any domain unless all auth servers for that domain fully implement it.
--
Evan Hunt -- e...@isc.o
answer. This is a significant problem, and the draft ought to
address it. (Or have I misunderstood something?)
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
his is a convincing argument, and I'm reconsidering my objections in
light of it.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ULK. If not, the primary would have to expand
the BULK data during transfer, same as BIND expands $GENERATE. (I proposed
a similar sort of EDNS signaling mechanism in draft-hunt-note-rr-01 a few
years back.)
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium,
to the force of a "MUST NOT". I
think it should be reduced in force to "OPTIONAL", "NOT RECOMMENDED", or
even "SHOULD NOT". Kill it on the supply side.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
__
Oopsie:
On Tue, Mar 28, 2017 at 02:41:27AM +, Evan Hunt wrote:
> MD5 is known to be breakable, but it's not *as* breakable
as a zone
> that hasn't been signed
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailin
1 - 100 of 197 matches
Mail list logo
