> On Sep 11, 2024, at 14:36, Stephane Bortzmeyer wrote:
> Before I start writing one, I ask your advice. Is it a good idea?
Yes.
> Will managers of resolvers use it?
Sure.
> Or do we assume that any serious resolver validates anyway?
Maybe? But it would certainly be interesting to see mis-ma
> On Jun 29, 2024, at 19:59, Paul Vixie
> wrote:
> It's my hope that CDN support can be added to DNS in a way that allows all
> answers to be identical. Modern clients even mobile ones are powerful enough
> to make application layer routing decisions locally. But we have to move away
> from CN
I am in favor of adoption. If this is standardized, Quad9 would certainly
implement it.
-Bill
> On Jan 22, 2023, at 9:36 PM, Tim Wicinski wrote:
>
>
>
> All
>
> The chairs have received feedback for DNSOP to adopt this document, and I've
> wrestled with this documen
> On Jul 12, 2022, at 6:51 AM, Tim Wicinski wrote:
> This starts a Call for Adoption for Using Service Bindings with DANE
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-rebs-dnsop-svcb-dane/
> Please review this draft to see if you think it is suitable for adoption
> by
> On Apr 25, 2022, at 1:31 PM, Havard Eidnes wrote:
>
>>> On Apr 25, 2022, at 11:20 AM, Petr Menšík wrote:
>>> I think the only good way would be starting considering shorter keys as
>>> insecure in FIPS mode.
>>
>> Agreed. We've been using 2408-bit ZSKs for more than ten years now. It's
> On Apr 25, 2022, at 11:20 AM, Petr Menšík wrote:
> I think the only good way would be starting considering shorter keys as
> insecure in FIPS mode.
Agreed. We’ve been using 2408-bit ZSKs for more than ten years now. It’s
definitely time to sunset acceptance of shorter keys at this point.
> On Mar 25, 2022, at 12:07 AM, Tim Wicinski wrote:
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and send any comments to the list, clearly stating your view.
I have read the draft, corrected one grammatical nit, and fully support its
adoption by DNSOP
Sounds like a good plan to me.
-Bill
> On Mar 10, 2022, at 7:55 PM, Paul Hoffman wrote:
>
> Greetings again. My motivation here is kinda trivial, but I've heard it is a
> common complaint. When writing a about DNSSEC, I need to reference the RFC.
> But it's three RFCs (
> On Oct 20, 2021, at 3:07 AM, Paul Hoffman wrote:
>
> Just noting that no one has said anything about this draft since it was
> published almost 6 months ago, and it is the topic of next week's interim
> meeting.
We like it, will implement it when it becomes a thing, and believe it should
> On Jun 3, 2020, at 2:38 PM, Stephane Bortzmeyer wrote:
>> This starts a Call for Adoption for draft-huque-dnsop-ns-revalidation
>
> I think it addresses a real problem, I think it is a good start for a
> draft, and I'm willing to review it. (In other words: I support
> adoption.)
I agree. Th
> On May 23, 2020, at 4:46 AM, Paul Vixie wrote:
> ibm and pch and the other backers of quad9, and the security industry
> partners who participate, have
> solid personal reasons, just as google and cloudflare and opendns do, for
> running an open recursive name service.
That’s a rhetorical fa
> On May 22, 2020, at 3:38 AM, Paul Vixie wrote:
>
> On Friday, 22 May 2020 00:55:34 UTC George Michaelson wrote:
>> My Colleague George Kuo asked me for definitions of public DNS
>> service. not "public DNS" but the trigram "public DNS service"
>>
>> Colloquially we understand this reasonably
> On Nov 26, 2019, at 11:46 AM, Jim Reid wrote:
>> On 26 Nov 2019, at 10:18, Roy Arends wrote:
>> "Is it safe to use ISO3166-1 Alpha-2 code elements from the User Assigned
>> range as top level domains for my own private use?"
>> It is my understanding that the ISO3166 Maintenance Agency can n
, the rest of us might be able to see
why you feel your case is compelling.
-Bill
> On Nov 22, 2019, at 07:15, Bill Woodcock wrote:
>
> Eberhard:
>
> The principle I’m trying to articulate is that our relationship to ISO 3166
> is that of a standa
the wishes of
> the government concerned might prevail over the wishes of ICANN.
>
> Whether this all is safe enough to write a standard, I don't know.
>
>
> el
>
>
>> On 22/11/2019 10:26, Bill Woodcock wrote:
>>> On Nov 22, 2019, at 12:20 AM, Shane Kerr
> On Nov 22, 2019, at 12:20 AM, Shane Kerr wrote:
> "User-assigned codes - If users need code elements to represent country names
> not included in ISO 3166-1, the series of letters AA, QM to QZ, XA to XZ, and
> ZZ, and the series AAA to AAZ, QMA to QZZ, XAA to XZZ, and ZZA to ZZZ
> respectiv
> On Nov 21, 2019, at 12:18 AM, Brian Dickson
> wrote:
> IMHO, there is *no* reason not to advance .zz
For the record, I think it’s a really bad idea to start re-purposing the ISO
user-assigned codes. Just as bad an idea as if they started re-purposing 1918
space.
> On Jul 8, 2019, at 2:52 PM, Steve Crocker wrote:
> I'm not immediately persuaded the proposed solution, i.e. allowing
> registrants to publish what they want via DNS records, will result in a large
> amount of incorrect data. What's the motivation to publish wrong information
> as opposed
if it’s all taken with the appropriate grain of salt.
> On Jul 8, 2019, at 16:42, Bill Woodcock wrote:
>
>>
>>
>>> On Jul 8, 2019, at 2:38 PM, John Bambenek
>>> wrote:
>>>
>>> All-
>>>
>>> In response to ICANN essentiall
> On Jul 8, 2019, at 2:38 PM, John Bambenek
> wrote:
>
> All-
>
> In response to ICANN essentially removing most of the fields in WHOIS for
> domain records, Richard Porter and myself created a draft of an
> implementation putting these records into DNS TXT records. It would require
> self
> On Jul 6, 2019, at 4:46 PM, Joe Abley wrote:
> TSIG secrets are rarely rolled in practice, in my experience, and
> being able to improve upon that also seems useful.
Very much agreed, whether using this mechanism or other.
-Bill
signature.asc
Description: M
> On Mar 22, 2019, at 12:53 AM, Vittorio Bertola
> wrote:
> If DoH deployment continues this way, I do see some governments - even in
> Europe - trying to go in that direction, either by mandating the use of
> in-country resolvers…
India has already started down that path, and it looks like
> On Aug 20, 2018, at 6:40 PM, Paul Ebersman wrote:
>
>> pusateri> There was general
>> pusateri> agreement in the room that you only should use DHCP in IPv4
>> pusateri> for address/router info and then use trusted sources for
>> pusateri> everything else. In IPv6, SLAAC generally provides thi
> On May 3, 2018, at 4:33 PM, Mark Andrews wrote:
> You see the same with forward zones with domain parking. They set up a ..com
> (or root) zone for all the *.com zones parked on the server and break all
> negative responses as a consequence.
Right, but again, that’s not lameness, per se, it
> On May 3, 2018, at 4:28 PM, David Huberman wrote:
>
>>> On May 3, 2018, at 3:27 PM, David Huberman wrote:
>>> In practical terms, when any type of registry strips away a lame delegation
>>> attached to a real, operating network with users behind it, and things break
>>> as a result…
>
> Woo
> On May 3, 2018, at 4:23 PM, Mark Andrews wrote:
> A “Lame Delegation” can be to a particular machines. These delegation for
> .fj are lame and have been for over a year.
Right, of course, but what breaks if you remove the lame nameservers from the
NS list? What am I not understanding?
> On May 3, 2018, at 3:27 PM, David Huberman wrote:
> In practical terms, when any type of registry strips away a lame delegation
> attached to a real, operating network with users behind it, and things break
> as a result…
But isn’t that, by definition, impossible? What could break as a resul
> On Jul 7, 2015, at 6:43 PM, Dr Eberhard Lisse wrote:
> My recollection is somewhat different from the AC "requesting" the
> revocation.
I meant the Department of the Interior. If I’m remembering correctly.
-Bill
signature.asc
Description: Message signed
As I'm sure our resident bad-idea-fairy can relate in greater detail, .UM was a
delegated ccTLD with SLD subdelegations and at least one user, before the
administrative contact requested that the TLD delegation be rescinded or
deactivated or whatever you want to call it.
Just a little more co
I agree with Ed on this one. If you skip everything that everyone can't
completely agree on, you'll wind up with a content-free, and useless, document.
You don't need to go into a -lot- of detail, but enough to acknowledge the
scope of what's being discussed.
-Bill
> O
> On Apr 30, 2015, at 11:07 AM, Paul Hoffman wrote:
>
> On Apr 30, 2015, at 7:35 AM, Andrew Sullivan wrote:
>>
>> On Wed, Apr 29, 2015 at 07:28:21PM +, Edward Lewis wrote:
>>> #ccTLD -- A TLD that is allocated to a country. Historically, these
>>> #were two-letter TLDs, and were allocated
On Apr 1, 2014, at 5:39 AM, Olafur Gudmundsson wrote:
> Doing these big jumps is the wrong thing to do, increasing the key size
> increases three things:
> time to generate signatures
> bits on the wire
> verification time.
>
> I care more about verification time than bits
On Mar 27, 2014, at 10:14 AM, Matthäus Wander
wrote:
> Here's a small statistic about RSA key lengths of 741,552 signed
> second-level domains (collected on 2014-01-27, counting KSK and ZSKs):
>
> 1024 bit: 1298238
> 2048 bit: 698232
> 1280 bit: 28441
> 4096 bit: 25326
> 512 bit: 8893
> 1536
r bean
> counting..)
Likewise. We don't need it internally, but it seems like a good idea, and I
think we'd be happy to support it, if it were done well. We're happy to work
on it.
-Bill Woodcock
34 matches
Mail list logo
