> On 8 Aug 2022, at 11:16, Independent Submissions Editor (Eliot Lear)
> wrote:
>
> I caution against those approaches that would set such a high bar that they
> would require researchers to fork out hundreds of thousands of dollars on
> application fees alone plus who knows how much else fo
Wes, I'm all for killing SHA1. Though the mechanism might need a rethink. We
probably should have a simpler way to add/remove DNSSEC crypto algorithms. IIRC
Paul Hoffman explained the problem a year or so ago when new code points were
needed for the latest GOST algorithms: something about that c
> On 13 Aug 2022, at 13:48, Mark Andrews wrote:
>
> 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.
Neither. I said the I-D needs to say something about not using crypto re
> On 14 Aug 2022, at 04:55, Wes Hardaker wrote:
>
> Something like:
>
> # Deprecating SHA-1 algorithms in DNSSEC
>
> The SHA-1 {{RFC3685}} algorithm MUST NOT be used when creating DS records.
> Validating resolvers MUST treat DS records as insecure. If no other DS
> records of accepted cryp
> On 17 Oct 2022, at 13:00, Independent Submissions Editor (Eliot Lear)
> wrote:
>
> I don't want to adjudicate names, but I have no problem adjudicating naming
> systems, including transparent attempts to get vanity names. Since none of
> those are naming systems, they would all get the of
> On 17 Oct 2022, at 15:12, Joe Abley wrote:
>
> Since it's not clear, my favoured approach to this entire subject is to do
> whatever is the quickest way to resolve the conversation so that this working
> group can get on with work that, in my opinion, no disrespect intended, is
> less poin
> On 20 Oct 2022, at 13:01, Eliot Lear wrote:
>
> ducking that says that when the IETF faces tough problems, others must step
> in.
IMO, it doesn’t say that at all Eliot. A fairer PoV here would be when the IETF
gets handed non-IETF problems, it keeps well away (perhaps after a discussion
o
> On 14 Dec 2022, at 16:28, Eliot Lear wrote:
>
> We're off in the woods again. Let's keep these two principles in mind:
>
> • The DNS resolution mechanisms are not expected to resolve, let alone
> secure names ending in .ALT.
> • How other resolution mechanisms secure names is t
> On 20 Jan 2023, at 15:20, Paul Hoffman wrote:
>
> Given the long list of things in this document that ISC has thought about and
> actively decided not to do, is it a good idea that we call it a "best current
> practice"?
Maybe. Though a BCP should go beyond documenting what BIND9 does.
In
> On 23 Feb 2023, at 22:36, Ted Lemon wrote:
>
> How much DNS traffic is even still inspectable these days?
Depends on the definition of DNS traffic Ted. DNS-OARC has many TB of pcaps and
query logs from the DITL project. Whether that data could be good enough to
meaningfully measure the inc
> On 14 Oct 2023, at 08:41, Vladimír Čunát via Datatracker
> wrote:
>
>
> I've already posted about -15, though not with dnsdir hat. So, I see nothing
> wrong with the current version. (The complaint about DF=1 in current
> implementations has been addressed.)
Many thanks for the prompt rev
> On 30 Oct 2023, at 13:00, Johan Stenstam
> wrote:
>
> But let’s ensure that we have identified the correct scope of the problem
> rather than cherry-picking the two simplest cases.
+1
IMO the discussion of this I-D has lost focus. Let’s find it and get back on
track. :-)
___
> On 5 Nov 2023, at 14:04, David Lawrence via Datatracker
> wrote:
>
> Hi Roy and Matt, this is my review on behalf of the DNS Directorate.
Many thanks!
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
> On 29 Nov 2023, at 12:43, Nicolai Leymann via Datatracker via dnsdir
> wrote:
>
> I found no major or minor issues and think the draft is in a good
> shape and can be progressed.
Great stuff Nic! Many thanks.
___
DNSOP mailing list
DNSOP@ietf.or
> On 10 Dec 2023, at 22:28, James Gannon via Datatracker via dnsdir
> wrote:
>
> I have reviewed 07 against the feedback on both the -04 and -06 and the
> document seems to be in good shape to move forward at this time. Thank you for
> the comprehensive feedback to all the reviewers and god e
> On 17 Jan 2024, at 20:42, Matt Brown via Datatracker via dnsdir
> wrote:
>
> Reviewer: Matt Brown
> Review result: Ready
>
> I have been selected as the DNS Directorate reviewer for this draft.
> The draft itself is clear and understandable. Both the language and the
> substance of th
> On 14 Feb 2024, at 14:47, Edward Lewis wrote:
>
> I raise the key tag issue in the sense of "let's not do this again" and not
> to try to change what it is now. Clearly, changing it (to avoid collisions)
> would be difficult. And, given the relative rarity of any problem stemming
> from
> On 14 Feb 2024, at 15:17, Paul Hoffman wrote:
>
> On Feb 14, 2024, at 07:10, Jim Reid wrote:
>> That said, I think a minor tweak to the core DNSSEC specs would be a good
>> idea. For instance, whenever a validator comes across a key tag collision,
>> it MUST
> On 16 Feb 2024, at 12:35, Edward Lewis wrote:
>
> The potential for abuse does exist, but the potential isn't addressed by
> documenting "key collisions should not allowed."
Indeed.
> I do agree that key collisions should be avoided, for the sake of key
> management, but given the diffic
> On 16 Feb 2024, at 15:19, Joe Abley wrote:
>
> Resolvers are routinely managed in order to safeguard local resources, harden
> themselves against attacks, etc. Not every query gets answered. Seems to me
> that limiting the time a validating resolver spends churning its organs over
> a part
> On 16 Feb 2024, at 16:17, Paul Hoffman wrote:
>
> I keep hoping that this group will focus more on those who go through the
> effort to sign their zones than those who write the software.
Hmmm. If it wasn’t for those who write the software, there would be nothing for
those who sign their z
> On 4 Mar 2024, at 19:14, Paul Wouters wrote:
>
> It means every registrant, who doesn’t know about DNS, has to create host
> objects for glue and whenever the ISP changes nameserver names (eg gets
> bought, sold or merges), or IP address
Er, no. It’ll be the registant’s registrar who will
> On 18 Mar 2024, at 12:50, David Lawrence via Datatracker
> wrote:
>
> Reviewer: David Lawrence
> Review result: On the Right Track
>
> Early review of draft-ietf-dnsop-dnssec-automation.
Thanks *very* much for such a detailed review Tale. I’m sure the authors will
appreciate your comments
> On 18 Apr 2024, at 15:36, Scott Rose via Datatracker via dnsdir
> wrote:
>
> Reviewer: Scott Rose
> Review result: Ready
>
> I believe the draft is ready, with a minor typo/nit that don't change the
> document:
>
> In Section 5.1 second paragraph has "Signaling Zone" while other instances
> On 19 May 2024, at 18:21, Steve Crocker wrote:
>
> No: I don't think the scheme is quite right.
>
> In my view, an algorithm moves through seven phases during its lifecycle.
>
> 1. Experimental – defined and included in the IANA registry
> 2. Adopted – begin inclusion in validation suite
>
> On 29 Jun 2024, at 18:10, Ray Bellis wrote:
>
> The DNS was never designed intended to deliver different answers to different
> users. DNSSEC solidified that and the practise IMNSHO should be discouraged,
> not standardised.
While this is undoubtedly true Ray, that ship sailed a *long* ti
> On 4 Jul 2024, at 07:45, Nicolai Leymann via Datatracker via dnsdir
> wrote:
>
> Overall I think the document is ready for publication.
Thanks Nic. Though the LC comments today suggest we’re not yet done with this
doc, :-(
___
DNSOP mailing list
> On 10 Jul 2024, at 14:27, Philip Homburg wrote:
>
> So the question becomes, do we want some limits in an RFC that everybody
> agrees on or do we want to keep the current informal system where limits
> are not fixed and people can get unlucky if they exceed limits they didn't
> know exist.
I
> On 17 Jul 2024, at 15:38, Mirja Kuehlewind
> wrote:
>
> I just wanted to point out our upcoming MAPRG agenda to you as we have an
> interesting talk on Post-Quantum DNSSEC (see below)
There’s also a side meeting on this topic on Monday:
https://wiki.ietf.org/meeting/120/sidemeetin
> On 2 Jul 2019, at 19:12, Matthijs Mekking wrote:
>
> I think it is time to move the protocol to Historic status as a clear signal
> to
> everyone that it should no longer be implemented or deployed.
Agreed. Kill it with fire!
___
DNSOP mailing l
On 8 Jul 2019, at 22:38, John Bambenek
wrote:
>
> 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-disclosure which m
> On 9 Jul 2019, at 15:15, Bjarni Rúnar Einarsson wrote:
>
> I think having a technical specification like this would be quite interesting
> from the point of view of automatically updates to existing Whois databases,
> without requiring the registrant directly (or indirectly) interact with
> On 9 Jul 2019, at 15:50, John Bambenek
> wrote:
>
> I'm not married to any name, I chose WHOIS for historical reasons. We can
> call it _hamsandwich if it builds consensus.
The concern here isn't what the label is called. Prepending a label won't work
with absurdly long domain names beca
> John Bambenek wrote:
>
> > Why? GDPR applies to IP addresses that, doesn't impact DNS yet.
GDPR applies to *any* data which identifies a living European citizen.
If you think it only applies to IP addresses you are very badly mistaken. GDPR
will also apply to anything in the DNS which happ
On 9 Jul 2019, at 17:43, John Bambenek
wrote:
>
> I guess I'm not understanding the risks of people accidentally disclosing
> what they don't intend to.
I suggest you learn more about GDPR. The penalties for non-compliance can hurt
- up to 4% of global turnover.
Some CIOs are learning this t
> On 9 Jul 2019, at 17:26, Steve Crocker wrote:
>
> I would strongly support an effort within the IETF to create and maintain a
> dictionary of registration data elements. This would probably be in the form
> of an IANA-maintained registry, with oversight from DNSOP.
Hmmm. That might be a b
> On 10 Jul 2019, at 14:24, Philip Homburg wrote:
>
> As far as I know, there is no issue with whois and the GDRP when it comes
> to voluntarily publishing information in whois.
Nope. It’s OK for you to publish your Personal Data. For anything else, you
need to get informed consent first. And
> On 22 Jul 2019, at 21:52, Paul Vixie wrote:
>
> apparently ECS creates problems for privacy, but _how could we have
> suspected_?
IIRC the ECS privacy issues were recognised at the time. They lost out to the
argument that CDNs were already doing (or about to do) ECS and it would be
bette
> On 1 Aug 2019, at 18:04, Paul Wouters wrote:
>
> In favour of adoption. Simple, short and clear document.
+1
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
> 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 not re-assign
> codes from the User Assi
> On 14 Apr 2020, at 16:43, Paul Vixie wrote:
>
> so instead of example.com DS, it should have been example._dnssec.com DS.
Sadly, that wouldn’t work for
thisisaveryveryveryveryveryveryveryveryveryveryveryveryverylong.domain.name
Which really exists. :-)
_
> On 16 Jun 2020, at 15:51, Mats Dufberg
> wrote:
>
> I support the adoption and I am willing to review the document.
Me too!
I wish everyone else commenting on this thread just indicated if they supported
adoption (or not).
Too much of the discussion that’s taking place at the moment seem
> On 18 Jun 2020, at 16:30, Paul Hoffman wrote:
>
> It might be better, and faster, for this WG to adopt a one-paragraph draft
> that makes the DS registry "RFC required", like the other DNSSEC-related
> registries.
+1
signature.asc
Description: Message signed with OpenPGP
___
> On 18 Jun 2020, at 16:01, Joe Abley wrote:
>
> On Jun 18, 2020, at 16:48, Paul Hoffman wrote:
>
>> Why is this WG considering making this document Standards Track instead of
>> Informational? Also, why is the WG considering putting the document in our
>> work stream at all? Can the WG ca
> On 14 Sep 2020, at 17:07, Paul Hoffman wrote:
>
> On Sep 14, 2020, at 2:33 AM, Peter van Dijk
> wrote:
>> In general, this document appears to suffer from a disconnect between
>> 'information published by an auth about itself' and 'information published
>> in a zone'.
>
> You and others
> On 4 Jan 2021, at 15:27, Stephen Farrell wrote:
>
> On 04/01/2021 14:23, Paul Wouters wrote:
>> On Mon, 4 Jan 2021, Stephen Farrell wrote:
>>> WRT GOST, we're not really talking about an algorithm but
>>> rather a national crypto standards scheme that selects sets
>>> of algorithms. For such
> On 4 Jan 2021, at 16:18, Paul Wouters wrote:
>
> You want to see a Status column at the IANA registry for marking
> something "NOT RECOMMENDED" / "DEPRECATED" etc ?
Yes!
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/
> On 6 Jan 2021, at 20:48, Ben Schwartz
> wrote:
>
>> > Telling validators to "insist" that all signatures are valid would resolve
>> > this dilemma. Zone owners could add algorithms without weakening anything.
>>
>> How do you deploy a new signing algorithm alongside an established one
>>
> On 1 Mar 2021, at 13:29, Ulrich Wisser
> wrote:
>
> 100% signed would mean unsigned zones do not get delegated, going insecure is
> no longer an option.
> I would like the protocol to be able to handle that case.
Ulrich, that seems to be a (registry-specific?) policy matter => probably ou
> On 11 Mar 2021, at 15:38, Paul Hoffman wrote:
>
> The size of the namespace isn't all that relevant in that, for any namespace,
> if it is filling up "too fast", one can quickly change the requirements to be
> more stringent. I'm pretty sure that has happened in the thousands of IANA
> reg
> On 15 Mar 2021, at 04:16, fujiw...@jprs.co.jp wrote:
>
> Dear DNSOP participants,
>
> Thanks very much for good comments for draft-ietf-dnsop-avoid-fragmentation.
>
> These are my proposal of Section 3.3. Default Maximum DNS/UDP payload size.
>
> I'm not sure what to do with "MAY, "SHOULD"
On 19 Mar 2021, at 02:42, Viktor Dukhovni wrote:
>
> On Mon, Mar 15, 2021 at 05:38:40PM +0000, Jim Reid wrote:
>
>> Measuring the MTU to well-known locations on the Internet won’t be
>> appropriate for some use cases. For instance inside private nets that
>> aren’t c
> On 28 Apr 2021, at 13:24, Roy Arends wrote:
>
> The working group can (after a potential clarification from the ISO about the
> future status of code elements) decide if a subset suffices and if so, the
> composition of the subset.
I agree with this approach.
IMO it’s reasonable for the W
> On 27 Jul 2021, at 01:56, Donald Eastlake wrote:
>
> Looks like initial query from IAB to ISO is
> https://datatracker.ietf.org/liaison/1720/
>
> Maybe I'm blind but I don't see a response...
It can take a day or so for inbound Liaison Statements from other SDOs to make
their way to the d
> On 1 Dec 2021, at 18:49, Andrew Sullivan wrote:
>
> Wouldn't that create a vicious circle in which the only way to start
> operating DNSSEC is already to have operated DNSSEC?
I think we’ve been in that vicious circle (or downward spiral) for several
years now.
___
> On 21 Mar 2022, at 09:19, Ben Schwartz
> wrote:
>
> Personally, I favor #3. What do you think?
Ben, I think 2 (Expert Review) is the right approach. This would hopefully
ensure any specifications are complete/valid and raise the threshold to
discourage bad or frivolous SrvParamValues "
> On 21 Mar 2022, at 14:12, Masataka Ohta
> wrote:
>
> No implementation or code is necessary to say DNSSEC is
> fundamentally hopeless.
That might or might not be true. But where's your draft and code for an
alternative?
___
DNSOP mailing list
D
> On 21 Mar 2022, at 14:36, Masataka Ohta
> wrote:
>
> How can you say I must provide some draft for some protocol by
> myself even though an alternative of DNS cookie already is an rfc?
Modulo the IETF's code of conduct, I can say whatever I like - as can you or
anyone else.
If you're say
> On 11 Apr 2022, at 14:01, Masataka Ohta
> wrote:
>
> I can't see any as discussion is still ongoing.
There is no discussion, just you arguing with yourself. Please stop.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo
> On 22 Jul 2017, at 23:58, Woodworth, John R
> wrote:
>
> How exactly does a hide-the-body scheme solve the issue?
I don’t understand the question and have no information/contaxt that would
allow me to give a meaningful answer.
What do you mean by “hide-the-body”? And what is “the issue”?
> On 4 Sep 2017, at 07:12, Walter H. wrote:
>
> by the way: why are you discussing about DNSSEC for names that are used
> only locally?
Why do you seem to assume there are never, ever any DNS security issues on the
local net?
Why would someone want to deliberately configure things to prevent D
> I'd say: "either you trust the local net or not"
I'd say trust but verify. Everywhere. => In this context always doing DNSSEC
validation.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
> On 21 Sep 2017, at 08:08, Davey Song(宋林健) wrote:
>
> In another word, we are facing the fragmented and uncooperative Internet.
> What should we do ?
Switch it off? Hand it over to ITU control? :-)
The Internet was designed from the outset to work around breakage. Packet
fragmentation issue
> On 21 Sep 2017, at 14:12, Shumon Huque wrote:
>
> On Wed, Sep 20, 2017 at 11:45 PM, Andrew Sullivan
> wrote:
>
> To address this potential confusion, it is helpful to distinguish
> between two meanings:
>
> QNAME (original) The name actually sent in the Question
>
> On 12 Mar 2018, at 17:37, Paul Hoffman wrote:
>
> If the use case here is to be able to issue certificates for TLS servers
> based on the IP address instead of the domain name, creating something new in
> the DNS may be overkill. That is, why even have Section 4.1 of
> draft-ietf-acme-ip a
> On 12 Mar 2018, at 23:27, Paul Hoffman wrote:
>
> For which other protocols did you want certificates with IP addresses as
> identifiers?
I think these may be needed for SIP, particularly roving (nameless) clients.
And quite possibly for P2P applications.
> If your list is longer than zer
> On 13 Mar 2018, at 00:07, Paul Hoffman wrote:
>
> How could you use ACME to validate the IP address of a roving client or a P2P
> application that has no fixed IP address?
In pretty much the same way as ACME tokens would/could be used to validate
clients that have (fixed) names.
Or perhap
> On 19 Mar 2018, at 17:47, Paul Hoffman wrote:
>
> Some folks had reservations about the current definition of "split DNS":
> "Where a corporate network serves up partly or completely different DNS
> inside and outside
> its firewall. There are many possible variants on this; the basic po
> On 19 Mar 2018, at 18:09, Artyom Gavrichenkov wrote:
>
> Another issue here is that, for some enterprises at least, there's no
> single "internal network" anymore.
We don't need to enumerate every potential split DNS scenario (or how it's
implemented). The original text says "there are many
> On 24 Mar 2018, at 13:48, Joe Abley wrote:
>
> But I think brushing the grains RRType parsing dust off the
> camel is not going to do much for its posture.
+1.
IMO there’s no need to do this in the protocol unless there is convincing proof
that nobody anywhere is using a now-obsolete RRtyp
On 24 Mar 2018, at 20:20, Ondřej Surý wrote:
>
>> It might be a different story if one of those zombie RRtypes required
>> additional processing. None spring to mind though.
>
> But (most of) those I picked actually *DO*:
>
> a) compression is allowed, so compliant and non-compliant servers ca
> On 28 Mar 2018, at 18:02, Phillip Hallam-Baker wrote:
> ... long rant snipped ...
> Well that is how I plan to go forward at any rate.
Good for you. Please come back to the IETF once you've figured it all out and
have running, interoperable code.
> On 18 Jul 2018, at 00:43, Shane Kerr wrote:
>
> I took some random notes at the meeting. Apologies for any errors or
> misstatements.
Many thanks Shane!
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
> On 27 Jul 2018, at 12:17, Tony Finch wrote:
>
> Ah, the obvious solution is to deprecate zone files and just ship update
> journals instead!
Why not go for distributed hash tables? :-)
Says he running away to watch the fireworks from a safe distance...
On 21 Aug 2018, at 16:23, Vittorio Bertola
wrote:
>
> And I have yet to see a statement from the DoH community that Mozilla's idea
> of making DoH the default and disregarding whatever resolver is being
> configured in the system via DHCP is not a good one.
Why would/should the DoH community
On 30 Oct 2018, at 22:31, Mark Andrews wrote:
>
> Ultra frequent key rolls are not necessary. It takes years the latest
> releases of name servers to make it into shipping OS’s.
So what? Key rollover policies cannot and should not be driven by vendor OS
release schedules. Or the BIND/whatever
> On 31 Oct 2018, at 00:27, Mark Andrews wrote:
>
> Bootstrap is still a issue. Over fast TA rolling makes it more of a issue.
Indeed. And that's the underlying problem that needs to be fixed IMO - for
instance when/if there's an emergency rollover.
> On 5 Nov 2018, at 15:38, Ray Bellis wrote:
>
> The cost to the DNS community of *trying* my proposed HTTP record is pretty
> negligible. Worst case, as Brian put it, is we burn a code point, add a
> trivial amount of code to DNS servers, but the browsers don't adopt it. It
> wouldn't be
> On 21 Jan 2019, at 10:26, Ondřej Surý wrote:
>
> We can’t be removing EDNS workarounds and at the same time slap another
> workaround into the DNS.
+1
I think the WG should drop this draft.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.
On 14 Feb 2019, at 06:36, zuop...@cnnic.cn wrote:
>
> i think both DNSSEC and DoH(or DoT) can protect DNS data
It depends on your definition of “protect”. For some threats/attacks, DoH or
DoT by themselves can’t protect DNS data - for instance a DoH or DoT server
that intentionally or accidenta
> On 14 Feb 2019, at 08:58, zuop...@cnnic.cn wrote:
>
> the premise is the recursive server should completely trust an Authenticated
> server
You’ve already made that clear. The problem with that premise is it’s a false
one. It represents a naive/unrealistic view of how the DNS is used.
Your
> On 15 Feb 2019, at 09:02, Stephane Bortzmeyer wrote:
>
> I really think it is important to make the difference between:
>
> * I blocked your request because that's _my_ policy
> * I blocked your request because I'm compelled to do so, don't
> complain, it would be useless.
Why? From the c
> On 12 Mar 2019, at 15:49, Stephane Bortzmeyer wrote:
>
> the case of a commercial
> Internet access provider is clear in the other direction: a client is
> not an employee, and is entitled to a free, open and neutral Internet
> access.
Stephane, that’s simply not true. A client of an Interne
> On 12 Mar 2019, at 16:01, Stephane Bortzmeyer wrote:
>
> I still do not understand why people have a problem with DoH whch did
> not already exist before with my-own-name-resolution-protocol-over-HTTPS.
It’s a question of scale/ubiquity. These “alterate” resolution tricks have up
until now
> On 21 Mar 2019, at 22:29, Brian Dickson wrote:
>
>> On Thu, Mar 21, 2019 at 3:03 PM Jacques Latour
>> wrote:
>> Plus!
>> Is anyone looking at adding DoH and DoT servers as part of DHCP/SLAAC? So
>> the local resolver and apps and browsers can go the _appropriate_ name
>> resolution reso
On 13 May 2019, at 05:06, Ondřej Surý wrote:
>
> But I do have a question for the WG - should we add a text that would allow
> the “Expert Review” to formally DEPRECATE (as defined in this I-D) other
> RRTYPEs?
I'm not sure an expert reviewer could or should be in a position to make that
dete
> On 13 May 2019, at 09:22, Joe Abley wrote:
>
> I would prefer documented agreement about what is obsolete and what is not.
+1
Though a definition of what is meant by obsolete might be needed too: "no
longer seen in the wild but could still be alive in closed environments",
"deader than E
> On 15 May 2019, at 12:55, Shane Kerr wrote:
>
> This seems like the most non-controversial document ever in the history of
> documents.
A non-controversial DNS doc at the IETF? That’ll be a first. :-)
___
DNSOP mailing list
DNSOP@ietf.org
https:/
> On 14 Jun 2019, at 03:18, Nick Johnson
> wrote:
>
> I'm working on a system that needs to authenticate a TLD owner/operator in
> order to take specific actions. We had intended to handle this by requiring
> them to publish a token in a TXT record
This assumes someone who is able to update
> On 14 Jun 2019, at 14:13, Dr Eberhard W Lisse wrote:
>
> Would (GPG encrypted) email to the registered address to the authority
> not be sufficient? That would make sure the recipient is authorized and
> must then cause the token to be 'delegated' as the second factor.
If there was a secure
> On 18 Jun 2019, at 11:13, Bjarni Rúnar Einarsson wrote:
>
> The SOA record for a TLD contains two DNS names which should be
> under the control of the NIC ...
> People on this list can probably comment on whether my above
> assumption is correct, and whether those are good candidates for
> wh
> On 18 Jun 2019, at 14:56, Shane Kerr wrote:
>
>> Being able to control a zone’s SOA record (or whatever) means just that. No
>> more, no less. It doesn’t mean someone who has that ability also has the
>> authority to change the zone’s delegation even though they can manipulate
>> the zone
On 16 Jul 2015, at 14:14, Suzanne Woolf wrote:
> We have been through extensive review and a Working Group Last Call on this
> draft. The next revision should go ahead to the IESG.
+1
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailma
On 18 Sep 2015, at 17:19, Joe Abley wrote:
> Whether or not we should call an onion or mdns name a "domain name" or
> something else is just a detail. I don't think agreeing on the answer is
> going to solve any of the problems that we actually have
+1
___
> On 10 Nov 2015, at 21:11, Paul Hoffman wrote:
>
> On 10 Nov 2015, at 12:43, Mark Andrews wrote:
>
>> Perhaps we should be getting Jari, Suzanne and Andrew to push this
>> at IGF meetings.
>
> Or perhaps we should not.
+1
___
DNSOP mailing list
DN
> On 10 Mar 2016, at 12:54, ac wrote:
>
> who knew that on dnsop you would learn and get free entertainment :)
What other reasons are there to be here? :-)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
> On 17 Mar 2016, at 04:06, Rob Austein wrote:
>
> MIT's Chaosnet ended up sticking with host tables until we shut it
> off, so we never did implement this in JEEVES or CHIVES. Symbolics
> may have gotten as far as using CH A RRs as one of the many inputs to
> their Namespace system, but that w
> On 29 Mar 2016, at 15:46, Paul Hoffman wrote:
>
> Fully agree. That's why, when thinking about .alt, we need to consider two
> different cases:
> - Add .alt to the 6761 registry
> - Add .alt to the 6761 registry and close the registry
> To me, the second gives a much clearer picture to both
> On 22 Jun 2016, at 11:13, Stephane Bortzmeyer wrote:
>
> It is not "fun", it is the only way to have broken implementations
> (Akamai, djbdns) fixed. If we do not name them, they will continue
> forever.
I doubt that will help Stephane. djbdns has been broken for ~20 years -- no
AXFR, no EDN
> On 20 Jul 2016, at 06:19, Mark Andrews wrote:
>
>> That's not who DDos work. If attacker would only do what the specs say
>> we wouldn't have any DDos. But an attacker can just create an UDP packet
>> with that bits and a spoofed address and fire it off (or get a botnet to
>> fire it off).
>
1 - 100 of 227 matches
Mail list logo
