. 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
o objection to mentioning it, but it felt like a MAY to me. 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
Properly Lame™ vs
merely unusable, 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
uld not - 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
saction 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
specific context, there's
potential 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
rver: See "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 H
t IMHO 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 entirel
7;s found so far, and 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 mail
often upgrade themselves 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
longer 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
, I'm a bit 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
ile that isn't publicly readable causes a lot
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
.4, so it would probably be
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
uthors had
used 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 thinkin
ove things
further, and I hope the root 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; ZON
as we'd hoped, either.)
But, it's Mostly Harmless. The implementation cost can be zero if you want
it to be; it's just 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 Consort
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 so
tion complexity
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
are known to choke if 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.or
implementers to do that. 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 m
oses, so
perhaps 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
eful line of
inquiry. I guess that's the point you 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
it will eventually 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 --
s the difference 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
approaches 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 al
in and kept 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
SC folks that 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 impor
X% of 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.
--
Eva
i. If the fetch returns the type, it 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 en
, 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.
--
E
oppose the 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://
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
proxy for 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
gt; implementation 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
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
solvers will overly tax them. 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.
an use ZONEMD with AXFR, too.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
, perhaps via some out-of-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...@
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 Co
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 Syst
is.
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
orkarounds on the auth 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.
___
ble to attend this time, 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
at no browser vendor would ever lift a finger to use that
information no matter how easy we made it for them. *All* of the
finger-lifting will have to be done in the resolver.)
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
what to do with 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 wa
it matters
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 way to
> use slow SIG(0) to establish fast TSIG session keys.
This matches my own intuition. "A clear idea of what to do about it" has
been slow in coming, but I think you're right.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
_
'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
e was an RFC published several 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?
--
col
is still 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
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
--
e: it's been implemented 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 wa
On Tue, Apr 03, 2018 at 04:08:46PM +, Evan Hunt wrote:
> "dig +noends +noadflag" will produce such a query, if you want to try
> it out.
+noedns, rather.
The edns does not justify the means.
--
Evan Hunt -- e...@isc.org
Internet Systems
ily be turned on 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
as wrong thinking, then it
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
ays ago that his test servers
use NULL RR's when they need to construct large responses.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
y if desired, but SHOULD warn if such information
> is received. Compressed records MUST never be re-transmitted.
You use MUSTs where I used SHOULDs, but I think we're both pointing
in the same direction.
--
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
E7 RRset. We do have 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
With respect to BIND, if these types are declared obsolete by the working
group, 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
ay to repeateded 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...
which the
answer 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
to cache the answers it
>receives (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
a chain
returned by 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
ove it because
I don't see where you're seeing that assumption?
> Please solve the following problems:
>
> 1) authoritative server answers an A query 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
xplain further, particularly
with an expansion of 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 --
uldn't want to send a higher TTL than 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
he answers
themselves, and 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
> 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.
__
On Wed, Nov 29, 2017 at 03:06:02PM +, Tony Finch wrote:
> Upward referrals exist, but bare "referral" is short for "downward
> referral". Other things that look like referrals (such as upward
> referrals or implicit referrals) have to have a qualifier.
+1
s no information 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/
had been defined in 1035. Since it wasn't, there are only
three answers that make any sense: NOERROR 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;
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
code didn't
exist when the spec was written. 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
tools.ietf.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
rust anchors are
> configured, bleh.
Fortuantely a negative trust anchor is a longest suffix match too.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
cached 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
have 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 doe
. 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 System
them, 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:
L stretching 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 System
n what any MITM can do. If 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
t an off-path forgery. 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...
a validating recursive resolver
> into any authoritative server.
Once again, the recursive resolver needn't be built in. It only has to be
accessible -- via resolv.conf, for example.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
_
smart thing, at 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
d gradually,
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
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
ust do something similar.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
d do if it got
back a CNAME.
> 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 ==
;t ask for 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 , Peter van Dijk ,
Anthony Eden
Subject: New Version Notification for draft-hunt-dnsop-aname-00.txt
Date: Fri, 07 Apr 2017 11:04:39 -0700
ist of
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 H
Such Keys are known as Negative Trust
> Anchors [I-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: Me
1 - 100 of 229 matches
Mail list logo