On Sat, 20 Apr 2024, Peter Thomassen wrote:
The authors certainly don't insist, but we'd need to pick a suitable
replacement for the "_signal" label.
John proposed "_dnssec-signal" elsewhere in this thread.
The authors would like to note that adding "_dnssec-" eats up 8 more bytes,
> Just a ping on this; thank you.
>
> Best regards,
>
> David Dong
> IANA Services Sr. Specialist
>
>> On Sat Apr 13 01:24:13 2024, pe...@desec.io wrote:
>> Hi Paul,
>>
>>> On 4/12/24 22:36, Paul Wouters wrote:
>>> However, I would urge the au
On Fri, 12 Apr 2024, David Dong via RT wrote:
Dear Frederico A C Neves and Paul Wouters (cc: dnsop WG),
As the designated experts for the Underscored and Globally Scoped DNS Node
Names registry, can you review the proposed registration in
draft-ietf-dnsop-dnssec-bootstrapping-08 for us
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-dns-error-reporting-08: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-dns-error-reporting-08: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
On Mar 4, 2024, at 14:04, Paul Vixie wrote:
>
>
>
> this means a zone will always be reachable through at least one in-zone data
> path (name server name and associated address records.) the result would be
> that a full resolver would never have to pause its current lookup while
>
On Feb 29, 2024, at 20:33, Arnold DECHAMPS wrote:
>
>
> Is it still a concern enough that they justify continuing using those tags
> instead of the full key?
The full key is not there. There is only a key tag. Are you proposing a wire
format change to DNSSEC that puts the full key there?
> On Feb 29, 2024, at 07:52, Edward Lewis wrote:
> (If no action is taken, malicious activity might follow now that it is
> described, but I have not heard of a historical case of it.)
This attack was more or less described five year ago:
https://essay.utwente.nl/78777/
They didn’t get to
On Feb 27, 2024, at 17:48, Mark Andrews wrote:
>
> If you forbid in the protocol
But part of this is not “in” the protocol. Eg if two dns hosters happen to
arrive at the same key tag for a single zone in concurrent offline ways. Or if
that happens when KSK and ZSK are managed differently.
em to be a consensus for that at
the moment.
I'm sure other folks will chime in with their views. But I want to ping Paul
Wouters specifically - since you are one of
the expert reviewers for this registry and an author of domain-verification,
could you express your opinion on the
specific request related to ACME (
On Feb 16, 2024, at 12:17, Petr Špaček wrote:
>
>
> It does not handle collisions in any special way. It simply does not validate
> and the resolver has no way to tell if the crypto thingy is wrong or if it
> just tried a wrong key. Any such failure is counted towards fail-budget (1
>
On Thu, 15 Feb 2024, Ralf Weber wrote:
There is a difference between what a lot of people on this thread did to keep
the Internet alive
Resolvers would have disabled dnssec to remain alive. Also not at all
something nice to happen, but the Internet in fact would not have died.
I am super
On Thu, 15 Feb 2024, Ralf Weber wrote:
So to put some real numbers out there. I recently for testing did download all
the zone data I could get from ICANN CZDS and tried to get DNSKEYs for every
domain. So that data set had 256479639 domains (256 million) and out of those
18726163 (18
On Feb 15, 2024, at 04:37, Petr Špaček wrote:
>
> If you think colliding keys should be allowed, please propose your own limits
> for sensible behavior.
I do think they need to be allowed because they have always been allowed so
far. Reasons for not allowing them seems to be implementation
On Wed, 14 Feb 2024, Roy Arends wrote:
It is recommended that the client (the resolver) sets the DNS COOKIE. The
benefit of using cookies is for the client. It is to make sure that the
response is genuine.
Does it? Not for an on-path attacker that sees the COOKIE in the clear.
So what
On Tue, 13 Feb 2024, Roy Arends wrote:
Based on this, I assume the error report query is of qtype TXT, but this is not
specified anywhere in the document. Someone could use a qtype of CNAME or ANY
or just A or . Can this be stated explicitly ?
It is explicitly specified in section 3:
On Wed, 14 Feb 2024, Roy Arends wrote:
1. There is a recommendation to use DNS COOKIEs [RFC7873] over UDP (PS), but no
statement about how to mitigate the effects when these are not used. What ought
someone to do when this is not done?
It is recommended that the client (the resolver) sets the
I don't think I saw any response to this from the authors or dnsop, so let
me reply to your DISCUSS points (as individual DNS enthousaist only):
On Tue, Jan 2, 2024 at 2:44 PM Martin Duke via Datatracker
wrote:
> Martin Duke has entered the following ballot position for
>
I tried to nudge this document on by filing a PR:
https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-avoid-fragmentation/pull/40
While I can confirm it addresses my concerns raised, all proposed changes should
be vetted by the authors, dnsop and the related IESG / Directorate members
before
On Thu, 1 Feb 2024, Paul Hoffman wrote:
Maybe we should add to the second paragraph:
Note, however, the root server addresses are not glue records, so setting the
TC bit in truncated responses from
the root servers is not required by RFC 9471.
Does this solve your and Warren's issues?
On Wed, 31 Jan 2024, Paul Hoffman wrote:
On Jan 31, 2024, at 15:15, Paul Wouters wrote:
Can they write a draft with why they are going against the RFC?
Yes, that is possible. However, I think it would be unfair to the DNS community
to hold up draft-ietf-dnsop-rfc8109bis waiting
On Wed, 31 Jan 2024, Paul Hoffman wrote:
Nope. The tone is because some root server operators want the ability to
continue to not set the TC bit due to root server operational independence. We
have to be honest about what is happening, and what the rules are.
The rules are defined in the
On Jan 31, 2024, at 09:56, Ralf Weber wrote:
>
> Moin!
>
> While this is true, there are a lot of players from different part
> of the ecosystem that want to work on DELEG (see contributors)
I am not saying don’t do it. I am saying we need to understand the cost and
benefits. For example, do
On Wed, 31 Jan 2024, Philip Homburg wrote:
Something I wonder about, certainly after the interim, is how do we discuess
with the wider DNS community the trade-offs that are available in de design
of DELEG such that we get good feedback about priorities.
For example, the current design used two
On Tue, 30 Jan 2024, Roy Arends wrote:
One motivation behind DELEG is the ability to use “Aliasmode” to point to an
SVCB record elsewhere, which contains a DS record. This way, DS records in
various top level domains can be federated under a single operator. This works
solely if both the
On Tue, 30 Jan 2024, Roy Arends wrote:
DNSSEC is not mandatory, it is recommended.
One motivation behind DELEG is the ability to use “Aliasmode” to point to an
SVCB record elsewhere, which contains a DS record. This way, DS records in
various top level domains can be federated under a single
On Jan 30, 2024, at 01:14, Ralf Weber wrote:
>
>
> I agree that future extensions will require code changes, but having a
> record type that is extensible from the start might make it easier to
> deploy new parameters then it is to do a full RRTYPE, at least that is
> the hope.
I took a step
> On Jan 27, 2024, at 16:42, Paul Marks wrote:
>
> pick .lan
> instead? It seems that a lot of people are already using this abbreviation
> on their internal networks, which happen to be local in
> area.
LAN implies local area network. So an organization with multiple locations
would have
On Jan 17, 2024, at 05:15, Bellebaum, Thomas
wrote:
>
> 1. Caching of unrequested RRs would actually be fine, if they are
> properly signed. At worst, a resolver would cache irrelevant records.
This is not entirely true. By tailoring someone’s cache you might be able to
track them. There is
On Mon, 15 Jan 2024, Warren Kumari wrote:
dig +nocookie +edns=0 +noad +norec +dnssec soa $zone @$server
expect: status: NOERROR
expect: the SOA record to be present in the answer section
expect: an OPT record to be present in the additional section
expect: DO=1 to be present if an RRSIG is in
On Mon, 15 Jan 2024, Warren Kumari wrote:
Subject: [DNSOP] Dealing with some open Errata:
[ + Dave Crocker (author), Paul Wouters, Frederico Neves (registry experts)]
Hi there all,
As part of the Great Errata Cleanup of 2024, I'm going through reported Errata
and trying to close them.
I'm
On Jan 10, 2024, at 20:55, Paul Vixie wrote:
>
> i think you mean RPZ here.
Yes I did. Thank you.
Paul
>
> Paul Wouters wrote on 2024-01-10 07:01:
>>> On Wed, 10 Jan 2024, Lanlan Pan wrote:
>>> I have submitted a new draft to discuss the faked answer re
On Wed, 10 Jan 2024, Lanlan Pan wrote:
I have submitted a new draft to discuss the faked answer returned from the
recursive resolver.
Your comments are appreciated.
As I've said during the discussions on RBL and an updated version for
RBL, if these things are done "for the user", the best
On Mon, 8 Jan 2024, Tim Wicinski wrote:
Subject: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis
From my previous comments (still unaddressed, were my comments rejected?)
there are 13 root servers.
I would really like to see this changed. We keep trying to tell
On Jan 7, 2024, at 05:02, Paul Vixie wrote:
>
>
> i think as long as we keep adding features that are only necessary because
> dnssec lacks certain features or is not universally deployed or both, then
> dnssec will lack certain features or not be universally deployed or both.
> please be
On Fri, 29 Dec 2023, Paul Wouters wrote:
I've missed these calls, my apologies.
I think the document is almost ready to proceed, but contains some
markers of [[unresolved discussion]] that obviously needs resolving
(and should have been resolved before doing a WGLC? :)
Obviously I made
On Thu, 28 Dec 2023, Paul Hoffman wrote:
On Dec 28, 2023, at 13:34, Tim Wicinski wrote:
All,
We wrapped up the second working group last call for
draft-ietf-dnsop-rfc8109bis with no comments pro or con.
The chairs can only assume the working group is not interested in moving this
work
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 elements of the DNS infrastructure.
I agree, but also
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 cookies)
Since it is possible to imagine networks in which source address spoofing is
not possible, and hence
It should probably change TCP to “source IP validated transports (dns over
stuff, tcp and udp cookies)
Sent using a virtual keyboard on a phone
> On Dec 13, 2023, at 10:14, Zaheduzzaman Sarker via Datatracker
> wrote:
>
> Zaheduzzaman Sarker has entered the following ballot position for
>
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-dns-error-reporting-07: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please
On Wed, 29 Nov 2023, Warren Kumari wrote:
So, the IANA has a question:
IANA Question --> What about the registrations that currently reference RFC5933?
Should the registrations currently referencing RFC5933 be marked "OBSOLETE,"
"DEPRECATED," changed in
some other way, or left alone?
If
On Nov 17, 2023, at 12:04, Ray Bellis wrote:
>
>
>
>> On 17/11/2023 10:41, Paul Wouters wrote:
>>
>> I think it would be unwise to make assumptions on how people will use
>> this feature. They might want to ask for many more records along with
>>
On Fri, 17 Nov 2023, Ray Bellis wrote:
Last time this came around I also suggested instead of n times QT
entries, to use the same method as NSEC does for conveying which RRtypes
are covered using a single bitmap:
https://datatracker.ietf.org/doc/html/rfc3845#section-2.1.2
Speaking
On Tue, 14 Nov 2023, internet-dra...@ietf.org wrote:
Internet-Draft draft-bellis-dnsext-multi-qtypes-08.txt is now available.
Last time this came around I also suggested instead of n times QT
entries, to use the same method as NSEC does for conveying which RRtypes
are covered using a single
On Sat, 11 Nov 2023, John R Levine wrote:
work(ed) fine without minimization and I don't think it is reasonable
to expect every mail system in the world to change their configuration
to work around our performance bug.
It is totally reasonable for protocols and software and configurations
Subject: Re: [DNSOP] Working Group Last Call for
draft-ietf-dnsop-dnssec-bootstrapping
On 9/19/23 21:48, Tim Wicinski wrote:
>
> This starts a Working Group Last Call for
draft-ietf-dnsop-dnssec-bootstrapping
>
> Current versions of the draft is available
On Nov 10, 2023, at 21:02, John Levine wrote:
>
>>
>> A bit misleading subject :P
>
> It seems to have done the trick.
You need to trick people with exaggerations to read your emails? The industry
term for that is “clickbait”. I urge everyone not to engage in that in the IETF.
>
> DNSBLs
On Fri, 10 Nov 2023, John R Levine wrote:
Subject: [DNSOP] QNAME minimization is bad
Well, not always bad but sometimes.
A bit misleading subject :P
I'd like to write a draft that updates RFC 9156 by describing situations like
this that caches could recognize and avoid useless churn, added
On Nov 7, 2023, at 17:34, Erik Nygren wrote:
>
> As discussed at the mic, we should encourage people add labels to the dns
> node names registry:
>
> https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names
>
So I am one of the Delegated
On Oct 31, 2023, at 19:17, Frederico A C Neves wrote:
>
> Dear David,
>
> Section 7 of the draft is sufficiently clear, precise, and complete.
>
> This registration at the time it is approved by the IESG, taking in
> account the fact that currently there is no other request for TXT _er
> on
On Oct 25, 2023, at 13:14, Johan Stenstam
wrote:
>
>
> To begin with it works equally well with or without DNSSEC.
That statements seems a little odd?
> Furthermore it is a cleaner solution than what we currently have (i.e. child
> zone published CDS and/or CSYNC and parent at some future
On Fri, 27 Oct 2023, Johan Stenstam wrote:
Scanners are, of course, inefficient, and notifications are a way to improve
that. I just think that as we are making comparisons, with arguments whose
strength is (in part) based on the number of queries needed, we should get the
order of magnitude
> On Oct 26, 2023, at 21:51, Mark Andrews wrote:
>
> 'flag: do’ is just the way ‘dig’ displays ‘DO=1’ in the EDNS flags.
I had even sent a patch in a decade ago for dig to take +do as alias for
+dnssec but it got rejected
> I would leave this as editorial. I would accept this but I
On Oct 25, 2023, at 10:11, Paul Vixie wrote:
>
[speaking as individual]
> i am uncomfortable using the UPDATE RCODE for a purpose unrelated to zone
> modification. perhaps propose a new RCODE having the same message form as
> UPDATE?
I agree.
>> 2. No requirement for DNSSEC. Great as
> On Oct 22, 2023, at 15:56, Paul Hoffman wrote:
>
> On Oct 22, 2023, at 10:28, Paul Wouters wrote:
>>
>> I thought we all agreed the IESG would mark the old GOST RFCs Historic and
>> then the new RFCs don’t have to obsolete anything ?
>
>
> Define &
I thought we all agreed the IESG would mark the old GOST RFCs Historic and then the new RFCs don’t have to obsolete anything ?PaulSent using a virtual keyboard on a phoneOn Oct 22, 2023, at 13:24, Boris Makarenko wrote:
Eliot and Warren,
As I remember, the idea was
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:
https://author-tools.ietf.org/iddiff?url1=rfc7958=draft-bash-rfc7958bis-01=--html
Please review this draft to see if you think
On Oct 9, 2023, at 10:02, Ben Schwartz wrote:
>
>
> This is fun to think about, but it seems to me that these networks should
> avoid any reliance on the ICANN DNS tree. I doubt that any network of space
> probes on Io can accept the risk of a technical or governance issue on .io.
>
>
works for me, thanks!
Paul
On Wed, Sep 20, 2023 at 7:47 PM Wessels, Duane
wrote:
>
>
> > On Sep 20, 2023, at 2:23 PM, Paul Wouters wrote:
> >
> >
> >>> To prevent such unnecessary DNS traffic, security-aware resolvers
> >>>
On Tue, 19 Sep 2023, Wessels, Duane wrote:
Section 4.7 of RFC 4035 talks about the “BAD cache” where an implementation can
cache data with invalid signatures. It says:
o Since RRsets that fail to validate do not have trustworthy TTLs,
the implementation MUST assign a TTL. This TTL
On Mon, 18 Sep 2023, Von Johnson wrote:
Hello. Any updates?
There will be no updates from this list. This mailing list is about
designing protocols. Other people and vendors implement these. So
if you have a device problem with any application, please contact
the device vendor or
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-rfc8499bis-09: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https
On Sun, 17 Sep 2023, Salz, Rich wrote:
[ speaking as individual only ]
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.
If the WG agrees that this is an important term, sure.
Well, if the IETF has
On Sep 7, 2023, at 19:28, Mark Andrews wrote:
>
>
>
> The server shouldn’t be caching the RRset and it’s RRSIGs unless they validate
> successfully. This is a requirement of DNSSEC. This is also why recursive
> servers need to validate responses so that garbage is not cached.
Ah, so just
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-caching-resolution-failures-07: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please
On Tue, 8 Aug 2023, Ben Schwartz wrote:
If this is correct, then I'm not sure the complexity of solving the ENT problem
is worthwhile.
At $dayjob, I had to add bogus TXT records to our zones because of ENT
issues with Amazon Route53, which Amazon knows about and has refused to
fix for years.
On Jul 19, 2023, at 01:54, Paul Vixie wrote:
>
>
>
> George Michaelson wrote on 2023-07-18 22:41:
>> ...
>> my concerns with the PSL governance aren't relevant either. I am sure
>> it was purposeful. I don't have to like things for them to provide
>> upsides.
>
> when we've tried to talk
On Jul 18, 2023, at 20:42, George Michaelson wrote:
>
> I know, I could submit these to the PSL website directly. I am asking
> a meta question: do we think that operationally, if a PSL exists, that
> all ccTLD and TLD should be on it?
ccTLDs are mostly general registration so probably yes.
On Jul 17, 2023, at 22:50, Paul Vixie wrote:
>
>
>
>> Agreed, but that horse had already left the barn when we published the first
>> SPF RFC 4408.
> RFC 4408 was folly. TXT in a subdomain (RFC 5507 s3.2) would suit domain
> verification well (wildcards aren't a factor) and would in no way
On Jul 17, 2023, at 20:10, John Levine wrote:
>
>> I’m sure there are still plenty of tools crafting dns packets or using
>> simplistic tools that are not able to do TCP or DNSSEC.
>
> I'm sure there used to be, but in 2023? Really? An example or two would be
> intersting.
As most of the
On Jul 17, 2023, at 15:50, Joe Abley wrote:
>
>
> I see UDP as a legacy transport, required for backwards comparability but
> that's about it.
I think you will be proven wrong QUICly
Paul
___
DNSOP mailing list
DNSOP@ietf.org
On Jul 17, 2023, at 14:12, John R Levine wrote:
>
>
> In view of the wide use of DNSSEC and DoT and DoH, I think the argument that
> triggering TCP is bad stopped being persuasive a while ago. (Don't we hope
> people sign the DNS responses with the tokens?)
I’m sure there are still plenty
On Mon, 17 Jul 2023, Florian Obser wrote:
The entire discussion of response size seems like a throwback to the
1990s and I would remove it. These days if your DNS doesn't handle
yeah, that might be best.
TCP, you already have worse problems, like DNSSEC doesn't work.
Triggering TCP is
On Jul 16, 2023, at 15:53, Viktor Dukhovni wrote:
>
>
> I should perhaps have stated the technical criteria on which I consider
> the proposal non-viable. To whit:
>
>- The proposed protocol lacks all downgrade resistance.
>- Without a signed delegation from the parent, the existence
Abstract (and Section 2):
Please remove the acronym DRO and just use "operator".
Section 3 (Introduction):
The first two paragraphs of the Introduction can be removed.
Section 4 (Time Recommendations)
This section repeats a lot and could be cut.
But a real issue I have is with
On Jun 20, 2023, at 16:40, Dick Franks wrote:
>
>
> WGLC is supposed to be a review, nit-picking and clarification process.
A “review” can have results requiring major changes. But your use here seems to
imply “only small changes”. This is incorrect.
Documents in WGLC could be found to
On Tue, 20 Jun 2023, Peter Thomassen wrote:
My thoughts on this as in how to decide who does what, is...
in EPP, there is a section that I've coded to look like...
The usual drop downs are Yes/No and may require a reason
Create a new action, "DS Managed by", give it three options
On Tue, 20 Jun 2023, Matthijs Mekking wrote:
If there are different targets for different children of the same parent,
then a generic NOTIFY record like below won't work anyway.
parent. IN NOTIFY CDS scheme port scanner.parent.
Why a new RRtype ?
Why more stuff in the APEX?
Why not:
On Tue, 20 Jun 2023, John Levine wrote:
It appears that Matthijs Mekking said:
Hi,
I like this draft because of it tackles the issues of wasteful CDS
polling and it uses NOTIFY, a mechanism that is well known, already
exists in implementations, and actually feels like a good fit (as
opposed
On Jun 10, 2023, at 15:42, Tim Wicinski wrote:
>
>
> All
>
> The chairs have been looking at two different drafts discussing the use of
> using DNS NOTIFY to update DNSSEC information.
Interesting, as the reason for using CDS et. all was because TLD operators
didn’t want to receive and
On Thu, 8 Jun 2023, Kazunori Fujiwara wrote:
It may be too late, but the word "lame" may have a discriminatory meaning.
Then, how about we stop using "lame delegation"
That was one of my suggestions, don't define it or declare it obsolete.
It will ofcourse take time for people to stop
On Wed, 31 May 2023, Tim Wicinski wrote:
Subject: Re: [DNSOP] Call for Adoption: draft-klh-dnsop-rfc8109bis
This call for adoption ends: 7 June 2023
In favour of adoption.
Paul
___
DNSOP mailing list
DNSOP@ietf.org
On Mon, May 22, 2023 at 5:49 PM wrote:
> Dear DNSOP WG,
>
> My company has developed a domain verification technique using DNS, it
> fits the abstract of draft-ietf-dnsop-domain-verification-techniques.
>
> I am writing to ask the WG's opinion on whether our technique is within
> the scope of
On Tue, 2 May 2023, Frederico A C Neves wrote:
On Mon, May 01, 2023 at 04:43:11PM +, Wessels, Duane wrote:
My preferred definition is the one originally given by Paul Vixie, amended by
myself, and further amended by Peter Thomassen:
A lame delegation is said to exist when one or more
On Tue, 2 May 2023, Peter Thomassen wrote:
This, so far, was my understanding of the definition that was given in the
other thread, and which Benno labeled (2) in the original post of this
thread:
"A lame delegation is said to exist when one or more authoritative
servers designated by
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-alt-tld-23: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https
On Wed, 19 Apr 2023, Benjamin Kaduk via Datatracker wrote:
[co-author hat on]
Reviewer: Benjamin Kaduk
Review result: Has Issues
# SecDir review of draft-ietf-dnsop-domain-verification-techniques-01
Thanks for the review!
On the whole the content is reasonable, but read on for some
On Tue, 18 Apr 2023, Ralf Weber wrote:
[speaking as individual]
On 18 Apr 2023, at 13:11, Benjamin Schwartz wrote:
The draft's opening words are "DNS filtering is widely deployed for network
security". This is true, but by far the "widest" deployment of DNS
filtering is for authoritarian
On Sun, 16 Apr 2023, Tim Wicinski wrote:
(as individual)
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.
In favour of adoption.
Please also indicate if you are willing to contribute text,
No one proposed to retire the term? If unclear and additionally inappropriate
from an inclusive language point of view, why not document the term as is, with
a note explaining it is incomplete (without trying to fix it) and calling the
term historic?
Paul
Sent using a virtual keyboard on a
On Tue, 28 Mar 2023, Alex Stuart wrote:
I am employed by a SAML metadata registrar and we require verification that a
registrant has effective control over a fully-qualified domain name. We have
developed our own DNS TXT based method for verification and are in the process
for reviewing it.
On Fri, 17 Feb 2023, John R Levine wrote:
Surely we know people who run services that use DNS validation. How about
talking to some of them and finding out what kind of user errors they run
into?
The insinuation here is that we didn't talk to them. One of the authors
is at salesforce, who
On Fri, 17 Feb 2023, John Levine wrote:
That makes no sense. Why is it harder to copy a string to the name field
in a cruddy web GUI than to the data field? It's copy and paste either way.
For one, if the zone data presented to you is like a sorted zone file.
Second, because LHS entries
John Levine wrote:
While I think it would be good to publish some best practices in this area,
this draft still seems scattered and makes some assertions that seem to me
to be somewhere between unsupported and mistaken.
I think we agree that the goal is there are two parties, call them
owner
On Feb 9, 2023, at 16:27, Tim Wicinski wrote:On Thu, Feb 9, 2023 at 12:19 PM Paul Wouters <p...@nohats.ca> wrote:On Thu, 9 Feb 2023, Tim Wicinski wrote:
>> I have a deeper question on using "ext" for extension - it feels like an
> abbreviation which doesn't feel u
On Thu, 9 Feb 2023, Tim Wicinski wrote:
Big fan of this document and feel it is good. I have only one small nit:
See also "domain name" in [RFC8499].
Should this not be "Domain name" (per 8499) ?
I have a deeper question on using "ext" for extension - it feels like an
abbreviation
On Thu, 9 Feb 2023, Willem Toorop wrote:
Or it could use “_catalog.example.com” ?
Yes, if we add a sentence that the fictional organization producing this
catalog is "example.com", then we could use that too yes.
That would imho be the best solution.
Paul
On Feb 9, 2023, at 06:33, Willem Toorop wrote:
>
> Op 07-02-2023 om 16:45 schreef Paul Wouters:> I find the valid use of the
> name "invalid" to be pretty horrible. An
>> engineer looking at a catalog might quickly believe
>> the invalid is a bug where it sh
On Wed, Feb 8, 2023 at 3:33 AM Kees Monshouwer wrote:
> Hi Paul,
>
> On 2/7/23 16:45, Paul Wouters wrote:
>
> On Tue, Feb 7, 2023 at 8:53 AM wrote:
>
> Why must a catalog server / zone only support one version at most? Eg if
> version "3" come
1 - 100 of 787 matches
Mail list logo
