gt; R's,
> John
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET:
You don’t perform a verify if the time window is invalid. The same as you don’t
perform a verify if the tag doesn’t match. Mind you it’s completely pointless
to have multiple time ranges. The RRset and it’s signatures travel as pairs.
All the key rollover rules depend on that.
--
Mark
ou partition the ID space among multiple signers.
> That would be (other than the grease kludge) an elegant way out.
>
> R's,
> John
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listi
> On 29 Feb 2024, at 08:44, John R Levine wrote:
>
> On Thu, 29 Feb 2024, Mark Andrews wrote:
>>> If it is forbidden in the protocol, it might still happen.
>>
>> Ed, your reasoning is off. The point of forbidding is to allow the
>> validator to
ied -> specified). The hardest part is getting
vendors to fix their products. That was the most important work in 2019.
After that there was a very rapid reduction in broken servers out there. It is
not impossible to do.
Mark
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> htt
happen.
Ed, your reasoning is off. The point of forbidding is to allow the validator
to safely stop as soon as possible when it is under attack.
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark
the DNS in the past.
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 I
> On 28 Feb 2024, at 09:09, John Levine wrote:
>
> It appears that Mark Andrews said:
>> The current “fixes” still leave validators more vulnerable to cpu exhaustion
>> attacks than eliminating colliding key tags in the signer does. This is a
>> protocol bug that
3 records due
to CPU exhaustion. What is the difference with fixing this with DNSKEYs? Is
it "I don’t want to touch my code”?
> Best,
> Peter
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> http
> On 28 Feb 2024, at 05:50, Peter Thomassen wrote:
>
>
>
> On 2/15/24 22:53, Mark Andrews wrote:
>> But we can state that they should be avoided when generating new DNSKEYs.
>> BIND has been avoiding key tag collisions for 2 decades now when generating
>>
hich show my ignorance, not yours. I
> thank you for the gentle clue-stick hit, it was educational.
>
> -G
>
> On Tue, Feb 27, 2024 at 12:24 PM Shumon Huque wrote:
>>
>> On Tue, Feb 27, 2024 at 12:01 AM Mark Andrews wrote:
>>>
>>>
>>>> On 2
as is mentioned in the draft, has been testing this for
years now. You don’t need to speculate. You can go view the behaviour
patterns.
> Nice, small draft.
>
> -G
> On Tue, Feb 27, 2024 at 10:29 AM Shumon Huque wrote:
>>
>> Hi folks,
>>
>> M
llision
> set. That’s why I keep raising the key management angle.
> From: Ted Lemon
> Date: Tuesday, February 20, 2024 at 09:48
> To: Edward Lewis
> Cc: Mark Andrews , Paul Wouters ,
> "dnsop@ietf.org"
> Subject: Re: [DNSOP] Detecting, regeneration and avoidance
to reserve the new key tag. Repeat
if necessary.
We could even use the DNS and UPDATE to do that. Records with tuples of
algorithm, tag and operator. Grab the current RRset. Add it as a prerequisite
with a update for the new tag.
--
Mark Andrews
> On 17 Feb 2024, at 05:47, Paul Wout
__
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas V
The RRL code also sends BADCOOKIE if there isn’t a server cookie instead
of setting TC=1.
> On 15 Feb 2024, at 10:27, Mark Andrews wrote:
>
>
>
>> On 15 Feb 2024, at 03:03, Paul Wouters wrote:
>>
>> On Wed, 14 Feb 2024, Roy Arends wrote:
>>
>
NAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 287badf367f9a396010065cd4b21b108c8b316f0d5cc (good)
;; QUESTION SECTION:
;. IN SOA
;; ANSWER SECTION:
. 426 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2024021302 1800 900
604800 86400
;; Query time: 0 msec
;; SERVER: ::1#53(::1) (UDP)
;; WHEN: Thu Feb 15 10:22
> On 13 Feb 2024, at 00:56, Edward Lewis wrote:
>
> On 2/9/24, 22:05, "Mark Andrews" wrote:
>
>> The primary use of the key tag is to select the correct key to validate the
>> signature from multiple keys.
>
> Yes - which is great if 1) you nee
The primary use of the key tag is to select the correct key to validate the
signature from multiple keys.
--
Mark Andrews
> On 10 Feb 2024, at 12:38, Wellington, Brian
> wrote:
>
>
>
>> On Feb 8, 2024, at 6:41 AM, Edward Lewis wrote:
>>
>> ..
> On 7 Feb 2024, at 09:57, Brian Dickson wrote:
>
>
>
> On Thu, Feb 1, 2024 at 12:03 PM Mark Andrews wrote:
> There is nothing to prevent us saying that responses to priming queries
> SHOULD/MUST set TC if all of the addresses of the root servers won’t f
if not otherwise there.
--
Mark Andrews
> On 2 Feb 2024, at 06:15, Wessels, Duane
> wrote:
>
>
>
>>> On Jan 31, 2024, at 5:57 PM, Paul Hoffman wrote:
>>>
>>> As Mark just clarified. This isn't glue, so perhaps the text just needs
>>> updating.
>
were written.
>
> RFC8109 was published 7 years ago, and I'm hoping that rfc8109bis will
> survive at least that long.
>
> I don't know how we address my concern, but it feels like, in e.g 6 years,
> this text will have aged poorly...
> Can you see about some more massaging
at least partly because I'm always wary
> about predicting the future.
>
>
> Joe
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742
th, otherwise I'll
>> do what's above.
>
> That seems fine with me. Maybe mention that "@$server" refers to an
> authoritative server, and not a recursive server, as well ?
See section 8
>
> Paul
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
It an educated guess that should prevent a undetected rollover occurring.
--
Mark Andrews
> On 2 Dec 2023, at 08:29, Warren Kumari wrote:
>
>
>
>
>
>
>> On Fri, Dec 01, 2023 at 4:03 PM, Mark Andrews wrote:
>> It’s stopping the serial changing
It’s stopping the serial changing too fast.
--
Mark Andrews
> On 2 Dec 2023, at 06:43, Warren Kumari wrote:
>
>
>
> Dear DNSOP (and Wes),
>
> I was wading through my mailbox and realized that I hadn't seen any
> discussion of this.
>
>
> I'm q
cfaf3-313273af-454445554331-59fe69e8caa22cd0=1=1354aa29-d843-42fc-b4ff-49c1392f75f5=https%3A%2F%2Fmailman.irtf.org%2Fmailman%2Flistinfo%2Fmaprg
>
> <https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-59fe69e8caa22cd0q=1e=1354aa29-d843-42fc
party
>> will log in to change the status and edit the report, if necessary.
>>
>> --
>> RFC8906 (draft-ietf-dnsop-no-response-issue-23)
>> --
>> Ti
it approximately 2
decades ago. The original policy set had “self”. We added sub domains of the
key a little later. We added record count restrictions by type later still.
commit 6e373c502584f9292e964378411d296c8259026b
Author: Mark Andrews
Date: Thu Feb 16 01:34:24 2006 +
1983
Please make a understandable request.
--
Mark Andrews
> On 16 Sep 2023, at 05:24, Von Johnson wrote:
>
>
> Please help me return this to normal
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.or
er being favoured for use. Why not just remove this part?
>
>To prevent such unnecessary DNS traffic, security-aware resolvers
>MUST cache DNSSEC validation failures, with some restrictions.
>
> What are these "some restrictions" ?
>
>
>
> On 8 Aug 2023, at 11:27, Shumon Huque wrote:
>
> On Mon, Aug 7, 2023 at 9:20 PM Mark Andrews wrote:
>
> You can’t query for NSEC3 records. NSEC3 names do not prevent wildcard
> matches nor are NSEC3 records or their RRSIGs returned for * queries at the
> hashed
SEC3 (5155), where an
> empty non-terminal name (or rather the hash of it) does solely own an NSEC3
> record.
You can’t query for NSEC3 records. NSEC3 names do not prevent wildcard matches
nor are NSEC3 records or their RRSIGs returned for * queries at the hashed
name. They are pure metadata
it is or is not the value
> proposition)
>
> clue-stick hits welcome. Avoid the stomach.
>
> -G
>
> _______
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
&g
em not to deploy
DNS COOKIE today other than vendors not implementing it. Time for vendors to
pull their fingers
out.
DNS COOKIE is standards track. It is a security fix. Deploy it.
>
> Brian
> ___
> DNSOP mailing list
> DNSOP@ietf
servers the other day
that where answering UDP in ms but TCP was taking 10s of seconds to answer.
They appear to have fixed whatever the issue was but it still happened.
> Regards,
> -drc
>
> ___
> DNSOP mailing list
> DNSOP@ietf.o
r substantial issues, but the above is sufficient to stop
> looking for more reasons why this is a dead-end.
>
> --
>Viktor.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
I concur. This is a horribl
sages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they shoul
Well don’t put an IPv4 stack on the device. Use mapped addresses over IPV6
sockets and map those addresses to the PREF64 prefix in use in the stack.
--
Mark Andrews
> On 8 Jul 2023, at 05:20, Ted Lemon wrote:
>
>
> John, that's simply not an option on networks that only suppor
modern desktop boxes. If the box you
want to run the DNS64
nameserver on doesn’t support 464XLAT install one that does.
Mark
> Please, adopt Momoka's draft at least somewhere (I am not sure v6ops or
> dnsop).
> Eduard
> -Original Message-
> From: v6ops [mailto:v6ops-bo
tocol should not be
published.
Mark
> Op wo 5 jul 2023 om 21:10 schreef Mark Andrews
> I’ll repeat that it is a bad idea to make this an RFC. I’m saying this
> despite adding
> this to named.
>
> It is perpetuating DNS64 which does not work with DNSSEC. It sends th
ic. I look forward to fruitful and
> enlightening discussions.
>
> Best regards,
>
> Momoka Yamamoto
> momoka@gmail.com
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> _
ttings.html#dnssec-disabled-algorithms
> [4]:
> https://nlnetlabs.nl/documentation/unbound/unbound.conf/#harden-algo-downgrade
> [5]: https://www.google.com/search?q=%22harden-algo-downgrade:+yes%22
> [6]: https://forums.gentoo.org/viewtopic-p-8563219.html
> [7]:
> https://www.redd
. There are timing constraints between DS and DNSKEY that allow
determination of what the zone is signed with that are impossible to achieve
with DNSKEY alone unless you pre publish signatures.
--
Mark Andrews
> On 4 Jul 2023, at 04:25, Peter Thomassen wrote:
>
> Dear DNSOP,
>
>
m.
> ** Section 2.4. Machine produced tool output is provided in this section
> (from
> dig). Please formally cite what generated it.
>
> Good suggestion. I'm not sure what the formal citation for the dig tool is.
> So let's ask our co-author from ISC.
>
> Mark (Andre
Read
it in “perverse” mode (client will be stupid).
> --
> Petr Špaček
> Internet Systems Consortium
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
EDNS option code point. It really is not backwards compatible with EDE
the way it is currently specified.
> Best,
> Tommy
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
__
> On 12 May 2023, at 11:35, John Levine wrote:
>
> It appears that Mark Andrews said:
>>> Oh, I completely agree. My point was just that even in the root which is
>>> small and you
>>> would hope would change slowly, it's still a challenge to track what
rs have stood out like sore thumbs the entire
time. It only takes
a couple of minutes to generate that report and that isn’t trying to go as fast
as possible.
> R's,
> John
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https:/
already difficult. Perhaps we can just become comfortable
> with the idea that at any time the DNS contains bits that work and bits that
> don't work, and that is just the way of things.
>
> Joe
>
>
> ___
> DNSOP mailing list
&
... alternates
> is going to cover what people patently have been saying "is lame" for
> some time, not aligning to a single meaning.
>
> I liked the proposed paragraph because it had the ".. or not at all"
> -And yet some people seem determined to say thats the "wrong
rm that warrants considered
> clarification, surely it has a very specific value that we can all act on,
> right? So what is that very specific value?
> Mark.
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
> ___
recursive server”.
> On 15 Apr 2023, at 11:01, Mark Andrews wrote:
>
> Somehow saying MUST include a SOA record in the negative response
> isn’t enough.
>
> 3 - Negative Answers from Authoritative Servers
>
> Name servers authoritative for a zone MUST include the
- Special Handling of No Data)
> suggests sending type 2 instead of type 1 responses but is silent
> about type 3 responses.
>
> On Fri, Apr 14, 2023 at 8:46 PM Puneet Sood wrote:
>>
>> On Fri, Apr 14, 2023 at 8:26 PM Mark Andrews wrote:
>>>
>>> RFC 20
sation
>>> in some cases, given how poorly maintained it is it seems to cause more
>>> problems than it solves.
>>>
>>
>> I'd like to remind folks that the scope of this draft when it was adopted by
>> the working group was very narrow. Mainly to s
he NIC in
the file NETINFO:DOMAIN-CONTACTS.TXT
4. Complain to the parent domain authorities.
5. Ask the parent authorities to excommunicate the domain.”
As an industry we have ignored the need for there to be checks and
balances. RFC 1033 says that they should be there.
>
ng list for updates and
> announcements.
> Thanks,
> James Mitchell
> IANA
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW
John it won’t work with chained validators.
--
Mark Andrews
> On 15 Mar 2023, at 07:59, John Levine wrote:
>
> It appears that Peter Thomassen said:
>> So I take it that when the EDNS signal is there, compact DoE responses get
>> an NXDOMAIN code.
>>
>>
cated 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 Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
--
Mark Andrews, ISC
1 Seymour St
rs to be no collision with
> usage in the NSEC type bitmap, and IMHO it appears to be a very natural meta
> type fit. ("This is NULL, There Really Is Nothing Underneath.")
NULL is type 10. This was assigned in RFC 1035.
--
Mark Andrews, ISC
1 Seymour St., Dundas
s are also available by rsync at rsync.ietf.org::internet-drafts
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> ___
> DNSOP mailing lis
> On 16 Feb 2023, at 15:40, Masataka Ohta
> wrote:
>
> Mark Andrews wrote:
>
>> The only part of RFC 1035 that actually mentions a value is 4.1.2 and no
>> it doesn’t prohibit other values.
>
> No, of course.
t explicitly.
>
> Wrong.
>
> Masataka Ohta
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Austral
il of the thread.
>
> Masataka Ohta
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St.,
esn't boot.
>
> In that case, if the NTP client would request DNS resolution over Do53 for
> its initinal lookup of pool.ntp.org, then the proxy can return a DNS reply
> and the system can boot normally.
>
>
> ___
> DNSOP mai
p-generalized-
> dns-notify (https://github.com/peterthomassen/draft-thomassen-dnsop-
> generalized-dns-notify). The most recent working version of the
> document, open issues, etc. should all be available there. The
> authors (gratefully) accept pull requests.
>
>
be
> used/abused by others. Have you thought about whether there are any similar
> considerations for these new uses of NOTIFY? I guess one answer is that (just
> like conventional NOTIFY) local policy could override the SRV-published
> (NS-published) targets.
>
>
> Joe
>
ve leaked queries and respond with
> NXDOMAIN. Techniques such as qname minimization, aggressive NSEC caching,
> and root-on-loopback can reduce the amount of leaked queries received by
> root name servers.
>
> ==========
>
> DW
>
>
>
> On 8 Nov 2022, at 10:56, Peter Thomassen wrote:
>
>
>
> On 11/8/22 10:33, Mark Andrews wrote:
>> Filtering .alt in recursive servers should be a MUST NOT.
>
> Whenever SHOULD or MUST (NOT) is used, or we're making a promise for the
> indefinite future, or
Filtering .alt in recursive servers should be a MUST NOT.
Mirror zones (copies of the root zone) and aggressive negative
caching will reduce the traffic to the root and not break downstream
validating clients.
AS112 is not needed.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117
ot do the equivalent of happy eyeballs behaviour.
BIND doesn’t race queries but it does bias the selection of IPv6 servers over
IPv4 servers. This went into BIND 9.11.0. The CHANGES note was dated
2015-09-28.
4222. [func] Bias IPv6 servers when selecting the next server to
> On 9 Oct 2022, at 04:58, Momoka Yamamoto wrote:
>
>
> re: Mark Andrews 's comments
> > this is yet another example of why DNS64 should be made historic.
> > This is requesting even more support to work around problems introduced by
> > DN64, a poorly thought o
y
>authoritative servers.
>
>
>
>
> The IETF Secretariat
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
The word ‘deleted’ does not appear in RFC8749. The errata makes no sense. I
suggest that this errata is REJECTED.
--
Mark Andrews
> On 14 Sep 2022, at 06:30, RFC Errata System wrote:
>
> The following errata report has been submitted for RFC8749,
> "Moving DNSSEC Lookasid
>
> With best regards,
> Tobias
>
>
> _______
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742
Well anyone using RedHat Enterprise Linux 9 / Oracle Linux 9 already has
RSASHA1 / NSEC3RSASHA1 disabled.
BIND will automatically disable these algorithms as of the September releases
if they are not supported by the crypto provider. So it will no longer require
named.conf changes.
--
Mark
ings. But it will be unpopular strings because the popular
> ones are taken or reserved.
>
> Paul
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dund
So you are ready to replace SHA1 in NSEC3 and do a second algorithm renumber
which is what is required to actually get rid of SHA1 or do you mean retire
RSA-SHA1.
People are much too imprecise in the terminology.
--
Mark Andrews
> On 13 Aug 2022, at 18:50, Jim Reid wrote:
>
>
;
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
> On 16 Apr 2022, at 05:24, Blacka, David
> wrote:
>
> RFC 4955
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
DNSOP mailing list
DNSOP@ie
> On 11 Apr 2022, at 17:57, Mark Andrews wrote:
>
> I don’t see why APL (RFC 3123) can’t be used for CRC give you need to
> construct an
> owner name anyway and have well known label to seperate the components of the
> name.
> I see no reason to re-
to partner applications
> E. Description of the proposed RR type.
> CRC contains a limited list of authorized networks for a particular
> application
> F. What existing RRTYPE or RRTYPEs come closest to filling that need
> and why are they unsatisfactory?
> TXT RRTYPE allow
synthesise using an OPTOUT
NSEC3 record. Zone operators can turn off OPTOUT today.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
> On 30 Mar 2022, at 14:29, Brian Dickson wrote:
>
>
>
> On Tue, Mar 29, 2022 at 1:31 PM Mark Andrews wrote:
>
>
> > On 30 Mar 2022, at 00:28, Peter Thomassen wrote:
> >
> >
> >
> > On 3/28/22 20:34, Mark Andrews wrote:
> >&
-94 which are replacements for
SHA256, SHA-384 and GOST R 34.11-94 respectively that support pre-publishing DS
for PRIVATEDNS and PRIVATEOID.
> On 29 Mar 2022, at 08:08, Mark Andrews wrote:
>
> Note you can’t prepublish a DS to roll keys you need to publish the DNSKEY
> first.
>
> On 30 Mar 2022, at 00:28, Peter Thomassen wrote:
>
>
>
> On 3/28/22 20:34, Mark Andrews wrote:
>> About the only part not already specified is matching DS to DNSKEY using
>> PRIVATEDNS but as you can see it is obvious to anyone with a little bit of
>
Note you can’t prepublish a DS to roll keys you need to publish the DNSKEY
first.
--
Mark Andrews
> On 29 Mar 2022, at 05:33, Mark Andrews wrote:
>
>
>
>> On 29 Mar 2022, at 01:34, Paul Hoffman wrote:
>>
>>> On Mar 27, 2022, at 6:23 PM, Mark Andrews
> On 29 Mar 2022, at 01:34, Paul Hoffman wrote:
>
> On Mar 27, 2022, at 6:23 PM, Mark Andrews wrote:
>> There is zero reason to reserve any ADDITIONAL space for experimentation.
>
> Assume that you want to experiment with creating responses that have multiple
> as-
applies to OIDs.
--
Mark Andrews
> On 28 Mar 2022, at 19:49, Nils Wisiol wrote:
>
> On Mon, 2022-03-28 at 12:23 +1100, Mark Andrews wrote:
>> Please quote where it is stated that “private is not for
>> experimentation”.
>>
>>
>>
>> Private is priv
sk vendors to do and
is unlikely to cause real problems. If you want you can actually keep the
name DNSKEY and DS records as a constant if you are too scared that vendors
will muck up the minor change of removing an identifying name.
There is zero reason to reserve any ADDITIONAL space for experiment
considered bogus. We are looking
> for a way to make this work.
>
> I admit, the problem is not trivial, but I have faith in DNSOP! ( Please
> don’t prove me wrong. Pretty please!)
>
> /Ulrich
>
>
>
>
>> On 22 Mar 2022, at 00:59, Mark Andrews wrote:
&
put requirements on data or data generators
> (registries) than we have to spell out that even a server that follows this
> draft/RFC might not be able to serve answers according to the draft/RFC when
> the data is not correct.
>
> So long
> -Ralf
> ——-
> Ralf Weber
>
&
gt;> that basically the entire range will be empty for centuries.
>>
>> --Paul Hoffman
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> --
> deSEC e.V. · Kyffhäusers
>> It would also cause the paradox and indeed creepy security quirk, that
>> if you sign your zone with one more algorithm, which is
>> cryptographically strong but poorly adopted (perhaps experimental), it
>> will result in _less_ security. Hardly anyone does this, but if they do,
>> they will
> On 15 Feb 2022, at 10:47, Mark Andrews wrote:
>
>>
>> On 15 Feb 2022, at 06:50, Klaus Frank wrote:
>>
>> Hi,
>>
>> yes there was discussion on the mailing list already. It wasn't however that
>> clear on what side should implemen
bility issues and resolutions
>>>between DNS64 and SPF records for mail transfer agents. This
>>>document also aims to simplify the IPv6 migration for mail transfer
>>>agent operators.
>>>
>>>This documen
Isn’t it about time we updated DH support in DNS to not use MD5? Currently
there is
no FIPS compatible DH key exchange in DNS. I suspect it would be relatively
straight
forward by defining a new TKEY mode which does DH w/o using MD5.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley
ts a side effect of using OPTOUT. You can’t prove or disprove the lack of a
delegation at “x.lindforslaw.se”.
OPTOUT was designed for delegation heavy zones like COM, ORG, NET. It was not
intended to be used in enterprise,
home and similar zones. It is also not the default.
> vixie
>
misation is on by default.
Actually they still can. Just wait until the A response expires while
there are still cached NSEC present. This will happen naturally with a
big enough client pool. Incorrect negative proofs lead to intermittent
“incorrect” responses with aggressive synthesis.
Mark
1 - 100 of 1036 matches
Mail list logo
