Hi Chris,
Thanks for the review!
On 19 Mar 2024, at 03:28, Chris Box wrote:
> It is a little cart-before-horse in having the reasoning occur after the
> conclusion. But I can see the benefit in having a very clear statement up
> front in the document. Some people only read the beginning.
On 1 Mar 2024, at 16:44, Philip Homburg wrote:
>>> Wouldn't that limit the risk of collision?
>>
>> At a price, yes.
>
> Technically only a SHA-2 hash of the key would need to be there. If somebody
> can create a SHA-2 hash collision then the world has bigger problems than
> a DoS on DNSSEC
Op 29 feb 2024 om 09:35 heeft Ralf Weber het volgende
geschreven:
> Bind and and other servers (egg Akamai Cacheserve) already stop/fail when
> having more then two keys with a colliding key tag today. I think what at
> least I want is that every key a validator has to consider has a unique
Hi there,
Op 27 feb 2024 om 19:54 heeft Toerless Eckert het volgende
geschreven:
>> Surely what ICANN is preparing to do is make a decision that an "internal"
>> TLD should never be available.
>
> How did you come to that conclusion. It sounded to me as if ICANN
> is on the road to assign
Hey,
Op 27 feb 2024 om 12:08 heeft Toerless Eckert het volgende
geschreven:
> I would like to see a BCP RFC on the use of the "internal" TLD,
> and ICANN should not finalize availability of the TLD unless that RFC
> exists.
Surely what ICANN is preparing to do is make a decision
Hi Jim,
On 16 Feb 2024, at 14:50, Jim Reid wrote:
> The latest patches to mitigate the keytrap vulnerability are welcome and much
> appreciated. Though IMO they’re a short-term fix. A long-term solution would
> be implementation guidelines as outlined above or to hard-fail validation
>
Op 14 feb 2024 om 13:46 heeft Edward Lewis het
volgende geschreven:
> On 2/14/24, 04:40, "DNSOP on behalf of Petr Špaček" on behalf of pspa...@isc.org> wrote:
>
>> In my mind this is good enough reason to outlaw keytag collisions -
>> without them it would be _much_ easier to implement
On 31 Jan 2024, at 09:04, Vladimír Čunát
wrote:
> On 30/01/2024 07.55, Kazunori Fujiwara wrote:
>> It proposes new name resolution using only information on the parent side.
> Let me just point out a key distinction: the typical use case of DELEG should
> be kind-of child centric. Most people
On 30 Jan 2024, at 17:25, Tim Wicinski wrote:
> I do feel that SVCB is/was the right way to solve having more robust DNS
> records, but it also is/was the thing that may end up destroying DNS.
Destroying DNS sounds like a worthy goal to be honest :-)
But yes, I like the SVCB approach too.
On 30 Jan 2024, at 15:57, Roy Arends wrote:
>> Unless we are certain that there is no benefit from DELEG without DNSSEC,
>> perhaps DNSSEC should not be mandatory.
>
> DNSSEC is not mandatory, it is recommended.
I was responding to the FOR DISCUSSION in section 1.5, which I imagined
referred
Hi all,
I have read draft-dnsop-deleg-00 and have some comments. It seems premature to
offer actual text as well as commentary but I can definitely do that if the
authors would like. I am fully enthusiastic about updating delegations and
referral responses, and anything negative below should
On 18 Jan 2024, at 13:42, Petr Špaček wrote:
> The only piece missing to make it *perfect* is "MUST use QDCOUNT=1", or in
> other words, banning QDCOUNT=0 usage with DNS COOKIES. It's unnecessary
> complexity.
I think these are two different suggestions:
(1) Update the cookies spec to
Hi Warren,
On 15 Jan 2024, at 22:49, Warren Kumari wrote:
> Seeing as the document says you should "expect: flag: aa to be present", it
> does seem like it would be better if it also said: "expect: flag: do to be
> present if an RRSIG is in the response", as that is more inline with what
>
On 4 Jan 2024, at 08:21, Murray Kucherawy via Datatracker
wrote:
> "Recommendations for zone operators and DNS server operators"
For what it's worth, and warning! this is a small thing, I think "zone
operators" is a bit vague.
The presumed intent of the phrase given the recommendations in
On 19 Dec 2023, at 03:34, Paul Wouters wrote:
> On Mon, 18 Dec 2023, Geoff Huston wrote:
>
>> I am in support of adoption by the Working Group. The process of peer review
>> has proved to be highly valuable over the years and the result is generally
>> a more robust framework for critical
Hi Tim,
On 16 Dec 2023, at 14:56, Tim Wicinski wrote:
> Therefore, the chairs seek additional feedback from the working group and
> invite your opinion on its suitability for adoption by DNSOP.
I was a co-author of the document that this one seeks to replace (and, for that
reason, am listed
On 13 Dec 2023, at 18:12, Paul Wouters wrote:
> On Wed, 13 Dec 2023, Joe Abley wrote:
>
>>> On 13 Dec 2023, at 16:37, Paul Wouters wrote:
>>>
>>> It should probably change TCP to “source IP validated transports (dns over
>>> stuff, tcp and udp cooki
On 13 Dec 2023, at 16:37, Paul Wouters wrote:
> It should probably change TCP to “source IP validated transports (dns over
> stuff, tcp and udp cookies)
Since it is possible to imagine networks in which source address spoofing is
not possible, and hence in which queries received over UDP
On 14 Nov 2023, at 14:43, Philip Homburg wrote:
> I don't really know what ECS looks like from an authoritative point of view.
> How is that kind of data distributed from a primary to secondaries?
An authoritative server that receives information about an end-user in the form
of an ECS EDNS(0)
On 10 Nov 2023, at 21:26, Brian Dickson wrote:
> Perhaps the DNSBL operators could individually or collectively operate
> resolvers which do that exact thing?
I'm not sure why the answer isn't "MTAs should run local resolvers configured
in ways that best suit them".
This seems like obvious
On 9 Nov 2023, at 12:12, John R Levine wrote:
> On Thu, 9 Nov 2023, Joe Abley wrote:
>> I don't agree that it's impossible to use an anycast target for this, any
>> more than it's impossible to distribute any service using anycast.
>
> I don't think it's impossible eith
On 9 Nov 2023, at 11:13, John R Levine wrote:
> On Wed, 8 Nov 2023, Brian Dickson wrote:
>> The target for a NOTIFY would necessarily be found in the SOA record of the
>> registrant's zone, not the parent's zone. I think that's where the
>> confusion has arisen.
>
> There's definitely confusion
On 8 Nov 2023, at 19:39, John R Levine wrote:
>
>>
>>
>>> It appears that Paul Vixie said:
-=-=-=-=-=-
None of the above. Do what RFC 2136 does to send updates to the primary
authority, or do what RFC 1996
does to send notifications to all listed authorities. Any new
Hi all,
I am sorry not to be in Prague this week but I'm happy to hear that some of the
ideas that led me to write draft-jabley-dnsop-refer-00 a couple of years ago
have resurfaced, including I think the idea of signalling available transports
for a child along with the delegation which had
On 8 Nov 2023, at 18:50, John Levine wrote:
> It appears that Paul Vixie said:
>> -=-=-=-=-=-
>> None of the above. Do what RFC 2136 does to send updates to the primary
>> authority, or do what RFC 1996
>> does to send notifications to all listed authorities. Any new signaling is
>>
On 1 Nov 2023, at 12:50, Frederico A C Neves
wrote:
> Because of the additive nature of the spec on cascading/concatenating
> error situations I would guess that the authors opted for the shortest
> node name available to fit as much errors as possible.
Also if the only remaining point of
Verified.
> On 31 Oct 2023, at 04:10, RFC Errata System wrote:
>
> The following errata report has been submitted for RFC8806,
> "Running a Root Server Local to a Resolver".
>
> --
> You may review the report below and at:
>
On 25 Oct 2023, at 18:46, Johan Stenstam
wrote:
> I agree. But it is bad to design a system where the key CANNOT be rolled.
I agree. I was just expressing doubt that you can find a single automated
mechanism that is appropriate to use in all possible compromise scenarios.
For a hopefully
On 25 Oct 2023, at 17:31, Johan Stenstam
wrote:
> On 25 Oct 2023, at 11:32, Joe Abley wrote:
>
>> I am not at all familiar with SIG(0), so bear with me. What is the key
>> distribution mechanism for the DNS UPDATE originator's public key? RFC 2931
>> suggests an
On 25 Oct 2023, at 10:10, Johan Stenstam
wrote:
> So now there’s a new draft, that further extends the same core idea (locate
> the target for the information being sent via a DNS lookup in the parent
> zone). However, the new draft
> (draft-johani-dnsop-delegation-mgmt-via-ddns-00) proposes
On 13 Oct 2023, at 17:22, Paul Wouters wrote:
> On Thu, 12 Oct 2023, Tim Wicinski wrote:
>
>> The draft is available here:
>> https://datatracker.ietf.org/doc/draft-bash-rfc7958bis/
>> Here is the diff from RFC7958 itself:
>>
Op 2 okt 2023 om 11:04 heeft libor.peltan het volgende
geschreven:
> I would even rather see a recommendation that firewalls and middleboxes
> don't do any kind of DNS packet handling. Why should they? DNS traffic is for
> DNS servers and they are the most capable entity for handling them,
Op 29 sep 2023 om 00:09 heeft Robert Edmonds het volgende
geschreven:
> noticed that Section 4 of the draft states:
>
> Firewalls that process DNS messages in order to eliminate unwanted
> traffic SHOULD treat messages with OPCODE = 0 and QDCOUNT > 1 as
> malformed traffic. See Section
Hi Tim,
On 28 Sep 2023, at 19:01, Tim Wicinski wrote:
> This starts a Call for Adoption for draft-bellis-dnsop-qdcount-is-one
>
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-bellis-dnsop-qdcount-is-one/
>
> Please review this draft to see if you think it is
Hi Eric,
On 28 Sep 2023, at 18:15, Eric Orth wrote:
> Minor remaining complaints (that I'm not going to fight over, so ignore if
> you really disagree):
> * I think all the stuff now in the appendix would be even better as a
> separate Informational draft. In my mind, appendix is acceptable,
available. It
> is a work item of the Domain Name System Operations (DNSOP) WG of the IETF.
>
> Title: In the DNS, QDCOUNT is (usually) One
> Authors: Ray Bellis
>Joe Abley
> Name:draft-bellis-dnsop-qdcount-is-one-01.txt
> Pages: 7
>
Op 19 sep 2023 om 18:24 heeft David Conrad het volgende
geschreven:
> Joe,
Hello!
>> Domain names existed before the DNS
>
> Well, hostnames did. Not sure domain names did, at least using that term.
All hostnames are domain names, right?
>> I am not convinced that the term "domain name
(I have trimmed the cc list a bit to avoid bothering the other 20,000 people
who would otherwise also receive this.)
Op 19 sep 2023 om 17:19 heeft Shumon Huque het volgende
geschreven:
> I think we need to clearly separate the definition of a domain name with
> the 'domain name space'. A
Op 17 sep. 2023 om 17:40 heeft Murray S. Kucherawy het
volgende geschreven:
> The reason I'm asking, though, is that we had 7719 in 2015, which was
> replaced by 8499 in 2019, and now this revision. Since we consider RFCs
> expensive to produce, I thought it was a reasonable question to ask.
Hi Murray!
Op 17 sep. 2023 om 08:07 heeft Murray Kucherawy via Datatracker
het volgende geschreven:
> I thought the IESG (though maybe not this particular one) had previously
> discouraged publishing "living documents" like this one in the RFC series. So
> why aren't we doing this as a wiki
Op 16 sep. 2023 om 03:02 heeft Salz, Rich
het volgende geschreven:
> On the other hand, spending a week or two repeating a cycle to get an
> important term in the current document seems like a better solution.
For an important omission that does seem like it would be a sensible thing to
do,
Hi Tim,
Op 13 sep. 2023 om 23:06 heeft Tim Wicinski het volgende
geschreven:
> This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis
> "Initializing a DNS Resolver with Priming Queries"
>
> Current versions of the draft is available here:
>
On 21 Aug 2023, at 17:08, Wessels, Duane
wrote:
> You’re right that we have not been especially precise when using the word
> “transport.”
> The authors did intend for DNS over UDP, over TCP, and over TLS, etc to
> essentially
> be treated as separate transports, or separate ways a client can
On 4 Aug 2023, at 10:12, Peter Thomassen wrote:
> A hash over the RRset in question might work, assuming some canonical form is
> used (e.g. as used for RRSIG calculation).
In fact, if the requirement is for a hash whose authenticity can be proven by a
relying party (which seems important in
On Tue, Jul 25, 2023 at 11:56, Abdussalam Baryun
<[abdussalambar...@gmail.com](mailto:On Tue, Jul 25, 2023 at 11:56, Abdussalam
Baryun < wrote:
> IMHO, the doc does make changes to two RFCs which are normative, so this LC
> document should update RFC1035 and RFC 6891. If you agree please
On Wed, Jul 19, 2023 at 11:26, Joe Abley <[jab...@strandkip.nl](mailto:On Wed,
Jul 19, 2023 at 11:26, Joe Abley < wrote:
> Not all TLDs have the same kind of policy boundary (if they did, arguably we
> would
not
> need the PSL).
Whoops.
Joe
On Wed, Jul 19, 2023 at 02:42, George Michaelson <[g...@algebras.org](mailto:On
Wed, Jul 19, 2023 at 02:42, George Michaelson < wrote:
> I know, I could submit these to the PSL website directly.
I think anybody can submit anything they want, but the PSL volunteers have
quite a strict set of
On Mon, Jul 17, 2023 at 21:41, Brian Dickson
<[brian.peter.dick...@gmail.com](mailto:On Mon, Jul 17, 2023 at 21:41, Brian
Dickson < wrote:
> TCP traffic is several orders of magnitude more expensive than UDP.
> Anything that bumps up the proportion of TCP traffic in a statistically
>
Hi Duane,
On Wed, Jul 5, 2023 at 18:32, Wessels, Duane
<[dwessels=40verisign@dmarc.ietf.org](mailto:On Wed, Jul 5, 2023 at 18:32,
Wessels, Duane < wrote:
> On Jun 30, 2023, at 2:32 PM, Joe Abley wrote:
>
>> I wonder whether another subsection of section 2 would be
On Jun 21, 2023, at 11:00, Tim Wicinski wrote:
> This starts a Working Group Last Call for
> draft-ietf-dnsop-caching-resolution-failures
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-caching-resolution-failures/
>
> The Current
ng resinfo in the security
considerations section.
As I said earlier (below, but with a subject that perhaps wasn't very helpful)
I think this needs some more thought.
Joe
------ Forwarded message --
From: Joe Abley
Date: On Fri, May 26, 2023 at 11:34
Subject: Fw: Re: [ietf-wg-dnsop/dra
[This arrived the other day from github, and I don't know what kind of mess I
will make if I just group-reply to it, so I'm following up on the list. List
seems better for general discussion anyway.]
On Tue, May 23, 2023 at 23:25, Dan Wing <[notificati...@github.com](mailto:On
Tue, May 23,
On Sat, May 6, 2023 at 19:10, Havard Eidnes <[h...@uninett.no](mailto:On Sat,
May 6, 2023 at 19:10, Havard Eidnes < wrote:
> So, you're arguing that it would be "causing too much work"(?) for
> the registry to insist on having the registrant stand up a couple of
> public name servers to register
Hi Peter,
On Fri, May 5, 2023 at 04:39, Peter Thomassen <[pe...@desec.io](mailto:On Fri,
May 5, 2023 at 04:39, Peter Thomassen < wrote:
>> Having the delegating party check for service for the requested zone
>> at time of delegation request and refuse to update / register if
>> this check fails
Hi George!
On Thu, May 4, 2023 at 20:34, George Michaelson <[g...@algebras.org](mailto:On
Thu, May 4, 2023 at 20:34, George Michaelson < wrote:
> When people talk about "lame" they're in a sentence with a subject
> (the DNS), and an object(ive) -But there isn't a single parse. Sorry,
> but the
On May 4, 2023, at 14:07, Havard Eidnes wrote:
>> As an example, it's quite common for people to register a
>> domain and point the DNS at some nameservers which they don't
>> control, and have no relationship with.
>
> If this is common, I'm abhorred.
I think these days it's less common than
On Tue, May 2, 2023 at 11:09, Peter Thomassen <[pe...@desec.io](mailto:On Tue,
May 2, 2023 at 11:09, Peter Thomassen < wrote:
> If one of the NS answers non-authoritatively, then it doesn't serve a proper
> NS RRset, so it's not possible for that server's response to agree / be
> identical
On Tue, May 2, 2023 at 11:01, Paul Wouters <[p...@nohats.ca](mailto:On Tue, May
2, 2023 at 11:01, Paul Wouters < wrote:
> If all the parental NS records point to
> properly working nameservers, but the authoritative nameservers claim
> an additional NS record, I would also call the delegation
On Mon, May 1, 2023 at 16:24, Mark Delany <[m...@india.emu.st](mailto:On Mon,
May 1, 2023 at 16:24, Mark Delany < wrote:
> On 01May23, John Kristoff apparently wrote:
>> (usually due to a bad configuration)
>
> Was any "lame" situation defined which wasn't the result of a bad
> configuration?
Hi Benno,
On Thu, Apr 27, 2023 at 16:05, Benno Overeinder <[be...@nlnetlabs.nl](mailto:On
Thu, Apr 27, 2023 at 16:05, Benno Overeinder < wrote:
> 2) Update the definition as proposed by Duane and with the agreement of
> some others (see mailing list
>
On Wed, Apr 26, 2023 at 23:07, Suzanne Woolf <[swo...@pir.org](mailto:On Wed,
Apr 26, 2023 at 23:07, Suzanne Woolf < wrote:
> This email begins a Working Group Last Call for
> draft-ietf-dnsop-zoneversion-02
> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/).
>
> If you've
On Mon, Apr 24, 2023 at 04:04, Éric Vyncke via Datatracker
wrote:
> 1/ I support Paul Wouters' issue with the name "pseudo-TLD", it is both too
> late and a bike-shedding exercice... "ghost-TLD" or "filler-TLD" or
> "dummy-TLD"
> would have been better
This is a part of the namespace
Hi John,
On Mon, Apr 17, 2023 at 02:29, John Levine wrote:
> I think we should adopt it but
Yes, me too.
I have thoughts about the other things you said but it seems better to wait for
that discussion, otherwise we're off the rails in this thread from message 1.
Joe
On Wed, Apr 12, 2023 at 21:33, Patrik Fältström
wrote:
> On 12 Apr 2023, at 20:56, Niall O'Reilly wrote:
>
>> I have, or think I have, always understood the NS RRset at a zone
>> cut to advertise a set of delegations, each to a distinct server.
>
> And if you use anycast, where some of the
Mr Hunt!
On Mon, Apr 10, 2023 at 21:09, Evan Hunt wrote:
> On Mon, Apr 10, 2023 at 02:35:36PM +0000, Joe Abley wrote:
>> I continue to think that if you don't get a response, you can't tell
>> whether the delegation is lame. Lameness (as I use the term) relates the
&
On Mon, Apr 10, 2023 at 16:30, John Kristoff wrote:
> On Mon, 10 Apr 2023 13:39:21 +
> "Wessels, Duane" wrote:
>
>> “A lame delegation is said to exist when one or more authoritative
>> servers designated by the delegating NS rrset or by the apex NS rrset
>> answers non-authoritatively for
On Mon, Apr 10, 2023 at 15:39, Wessels, Duane
wrote:
> Perhaps:
>
> “A lame delegation is said to exist when one or more authoritative servers
> designated by the delegating NS rrset or by the apex NS rrset answers
> non-authoritatively for a zone”.
I like this.
Joe
On Apr 4, 2023, at 11:49, Jared Mauch wrote:
> On Apr 3, 2023, at 4:50 PM, John Kristoff wrote:
>
>> Interesting dilemmas. I'm not sure there are obvious answers. Perhaps
>> lame delegation is the general concept, but specific failure modes need
>> better characterization?
>
> I suspect you
Hi Paul,
On Tue, Mar 28, 2023 at 14:51, Paul Vixie
wrote:
> Viktor Dukhovni wrote on 2023-03-27 18:00:
>>
>> * How compelling is compact DoE?
>
> that may depend on the beholder's eye. for perspective, no root name
> server has deployed this alternative form of Denial of Existence, and i
>
On Mar 7, 2023, at 20:56, Paul Hoffman wrote:
> On Mar 7, 2023, at 3:48 PM, Joe Abley wrote:
>>
>> On Tue, Mar 7, 2023 at 15:56, David Conrad wrote:
>>> 4 weeks for ICANN (which? Organization, Board, Community, all 3?) to
>>> provide feedback? (That feels sort
On Tue, Mar 7, 2023 at 15:56, David Conrad wrote:
> 4 weeks for ICANN (which? Organization, Board, Community, all 3?) to provide
> feedback? (That feels sort of like the ITU asking "the IETF" for feedback on
> an IP-related protocol document in 4 weeks.)
Did the IETF (also which?) provide
Hi George,
On Wed, Mar 1, 2023 at 17:40, George Michaelson wrote:
> My opposition is philosophical and practical.
>
> the philosophical part, is that this is a SIGNED ASSERTION by the zone
> authority. I don't think anything the zone authority says under a
> signature should be called a lie,
On Thu, Feb 23, 2023 at 12:39, Warren Kumari wrote:
> Instead of just having all of these document stuck indefinitely, I'm
> proposing that we:
> 1: Ask the RFC Editor to return the document to the IESG & IETF[1].
> 2: I return it to the WG.
> 3: The authors remove the bits that rely on ESNI
>
On Thu, Feb 23, 2023 at 00:22, Masataka Ohta
wrote:
> 1035 clearly allows QDCOUNT>1 for responses
> to IQUERY and 1034 clearly specifies QDCOUNT=1 for standard
> queries and responses.
It sounds like you agree with the archaeology and the proposed clarification in
the draft.
> There is no
On Wed, Feb 22, 2023 at 21:01, Ted Lemon wrote:
> No, my main objection to the current draft is that it’s dismissing the
> problem I raised.
Could you restate the problem?
You mentioned that you thought the ambiguity in 1035 was a problem; that's what
this draft is addressing. I believe Ray
Hi George,
On Wed, Feb 22, 2023 at 19:37, George Michaelson wrote:
> purely administratively, I'd like to understand how the WG chairs and
> AD intend dealing with fundamentally opposed drafts.
There's only one draft here, as far as I know.
Ted pointed out a DNS implementation in OpenThread
On Fri, Feb 17, 2023 at 15:03, Peter Thomassen wrote:
> I am not sure whether draft expiry impacts the WG document handling process
> in any way.
I would not worry. You can always reset the timer by bumping the version and
the date and resubmitting, if it bothers you. The particular lifetime
On Wed, Feb 15, 2023 at 13:52, Ted Lemon wrote:
> Actually this is exactly the windmill at which I am tilting. If we haven’t
> written it down in a spec, it is unreasonable to expect random implementers
> to learn about it some other way.
Well, it's not like people haven't tried to write it
On Wed, Feb 15, 2023 at 08:51, Ted Lemon wrote:
> It’s hard to see how the way that qdcount >1 was “standardized” (by word of
> mouth without any document) was in any sense healthy, unfortunately.
I'm not convinced that 1034/5 really allow QDCOUNT > 1, even if they left that
door temptingly
Hi Martin,
On Wed, Dec 14, 2022 at 10:08, Martin Schanzenbach
wrote:
> "Developers are wholly responsible for dealing with any collisions"
>
> I think this is an impossible task and as a developer that is addressed
> here I have to say that we cannot do that unilaterally for our
>
On Sat, Dec 10, 2022 at 00:04, Paul Vixie
wrote:
> should be Rdata or RData but never RDATA.
Also it turns out that RFC 8499 is probably not sufficient as a reference since
it doesn't include definitions for most of those RRTypes, or RDATA, or Rdata,
or RData. But I think the general idea
On Fri, Dec 9, 2022 at 23:17, Catherine Meadows via Datatracker
wrote:
> Nits: There are a lot of unexplained acronyms, especially at the beginning:
> RR, SOA, NS RR, RDATA, PTR, and so on. These should be spelled out the first
> time they are used at the document.
Most of these are the formal
On Thu, Dec 8, 2022 at 18:52, Tim Wicinski wrote:
> Some time back Tony Finch proposed a 2317bis -
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc2317bis-00
> which the WG adopted but died for lack of interest.
>
> It would be useful to revise this document
I could help with its
On Wednesday, November 30th, 2022 at 01:46, Mark Andrews wrote:
> > On 30 Nov 2022, at 00:07, Joe Abley jab...@hopcount.ca wrote:
>
> > One question occurs to me after reading your draft: you
> > suggest in a couple of places that it's easy for a
> > nameserver that i
On Tue, Nov 29, 2022 at 15:57, Paul Wouters wrote:
> The main concern at the time was they TLDs didn’t want any kind of triggers
> hitting their production nameservers.
For what it's worth, I this proposal accommodates such concerns. It allows (in
your example) the TLD operator to specify
On Tuesday, November 29th, 2022 at 13:37, Peter Thomassen
wrote:
> At the IETF a few weeks back, Johan and I felt a sudden
> enlightenment when it occurred to us that the same approach
> could be used to reduce scanning cost for CDS/CSYNC scans and
> the like, while maintaining low update
On Nov 7, 2022, at 16:28, Kazunori Fujiwara wrote:
> "in-domain" glue is necessary.
There are cases where that is not true.
> "sibling" glue is not necessary.
There are cases where that is not true too, including the example you gave
after that in that same e-mail:
> However, ".com" name
On Nov 4, 2022, at 15:22, Ben Schwartz
wrote:
>>> I agree; this is about utility, not necessity. For example, records
>>> are almost never "necessary" in glue, but they are useful, so they are glue.
>>
>> Uh, what? For the kazillion peoeple on V6 only mobile networks, the
>>
On Nov 4, 2022, at 10:27, Ben Schwartz
wrote:
> I agree; this is about utility, not necessity. For example, records
> are almost never "necessary" in glue, but they are useful, so they are glue.
"First they came for the v6-only clients, and I did not speak out, because I
was not
Op 24 okt. 2022 om 14:18 heeft David Conrad het volgende
geschreven:
> Given the AS112 approach doesn’t result in code change, would you be ok with
> using it with .alt?
As Brian mentioned, there are two AS112 approaches. One involves some amount of
lame delegation, and the other involves
On Oct 21, 2022, at 12:52, Paul Vixie wrote:
> it's a registry of carve-outs for use inside DNS, which happens to facilitate
> client development by giving agents such as browser plugins a clear
> activation signal that's unambiguous with respect to the DNS.
I think the conversation is easier
Hi Andrew,
On Oct 20, 2022, at 15:57, Andrew Sullivan wrote:
>> On Thu, Oct 20, 2022 at 09:40:01PM +0200, Eliot Lear wrote:
>>
>> They're asking for the registry.
>
> Who is asking for it? And more importantly, what will a registry do? As I
> pointed out already in this thread, the
On Oct 20, 2022, at 08:26, Eliot Lear wrote:
> On 20.10.22 14:14, Jim Reid wrote:
>> 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 of the merits and/or scope of that problem).
Hi Rob,
On Oct 19, 2022, at 08:54, Rob Wilton (rwilton)
wrote:
> The reason for my interjection is only because I’ve seen some comments
> stating that this topic is too hard, we can’t get rough consensus, and hence
> the WG should give up and declare defeat. However, from my reading of the
On 17 Oct 2022, at 10:06, Martin Schanzenbach wrote:
> Technically, GNS celebrated its 10th birthday in 2022 ;)
:-)
> But back to business: You cannot think both that alternative name systems are
> fleeting trends and at the same time are a serious threat to DNS namespace
> consistency.
> That
On Oct 16, 2022, at 23:03, Christian Huitema wrote:
> The main problem with "giraffe.org" and similar is that the subdomains are
> leased, not owned. A glitch in the renewal, and they are grabbed by some
> domain catcher and redirected to "my sexy giraffe" or some such.
On the face of it that
Op 16 okt. 2022 om 15:03 heeft Brian Dickson
het volgende geschreven:
> For example, using a hash function, such as sha2-256, with output encoded as
> base32hex.
> (This is just an example; any suitable function that takes URI as input and
> produces an ASCII DNS-compatible label as output
Hi again,
On Oct 16, 2022, at 13:09, Momoka Yamamoto wrote:
> [...] However, we thought that in theory (but maybe not currently) an
> iterative resolver is the only application that actually needs IPv4 to
> operate.
I'm interested in this perspective.
My feeling is that it's far more
Hi there,
On Oct 8, 2022, at 13: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 out, supposedly short term
Fujiwara-san,
On Sep 22, 2022, at 11:05, Kazunori Fujiwara wrote:
> Thanks. "Path MTU Disovery" API and setting IP_DF API are complex and
> they often don't work as expected.
>
> However, it may be easy to avoid using the Fragment Header on IPv6.
> (limit IPv6 response packet smaller than
1 - 100 of 737 matches
Mail list logo
