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
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
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
. 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
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
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
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
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
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
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
.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
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&#
, 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
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
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
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
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
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
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
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
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...
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
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
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:
. 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
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
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
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
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
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
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
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;
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/
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
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
> 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 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
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
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
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 --
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
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
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
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
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...
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
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
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
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
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
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
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
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
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 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
--
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
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?
--
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
'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
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.
_
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
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
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
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
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.
___
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
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
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
, 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...@
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
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.
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
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
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
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
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://
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
, 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
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
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
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
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
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
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
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 --
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
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
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
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
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
ity, 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
egation. 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...
nably confident
there'll never be a real ::2 address for it to collide with, but for
describing the mechanism in an RFC we should use something in the address
space reserved for documentation, so let's say 2001:db8::1.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
d 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.
___
DN
vidual qtypes anyway), and 2) modestly larger response
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
er conventional ANY responses.
> If we agree that both are acceptable and each server only needs 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 neces
e 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.
_
ht
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
> Is reference to RFC4770 security 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 Con
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
1 - 100 of 229 matches
Mail list logo
