as recommended by the RFC Editor -- mentions this issue,
but doesn't include instructions.
Thanks,
Amanda,
Gosh that was quick and thank you for the correction. I took away group
and registry, and an avoidance of sub(-sub(-sub))-registry from the work
on RFC8126 and have been guiding authors i
registry by name, as I usually do, I think that from
Section 6
DNSSEC Algorithm numbers
DNSSEC NSEC3 parameters
are groups and not registries whereas
DNSSEC DS RRtype
I have yet to find (but have not yet used the URL)
Tom Petch
Abstract
This document describes the DNS security extensions
ecates TLS1.0 and TLS1.1 and
updates rather a lot of RFC in doing so. Some of these are ISE and the
permission of the ISE Editor was sought, and obtained, before going ahead so I
do not think that any I-D from one stream can update any I-D from another.
Tom Petch
Bob
Hi Dick, Ben,
I'm the (new) developer at NLNet Labs who implemented SVCB in NSD. While
I have no strong opinion on the double escaping matter, I will pitch in
that NSD currently adheres to the draft (as far as I'm aware).
Best,
Tom
On 2021-05-06 22:16, Dick Franks wrote:
On Thu, 6 May
uot; or "use DoH" or otherwise,
> signal this by adding a new canary domain, or a new DHCP option.
> absent new signalling, behaviour should not change.)
>
> --
> Paul Vixie
Would it be ok to allow DNSSEC signed responses from any server? If they’re
signed and verified, does it m
cussed on this list before but the reason we removed
capabilities negotiation was that there’s no real benefit, only perceived. The
capabilities flags add potential delay and another vector for additional bugs
but a client still has to try the feature to
Tim and I have updated the TIMEOUT RR draft to reflect the feedback we’ve
received on this list and added some more description and usage patterns,
including interaction with the EDNS(0) Update Lease option, and a discussion of
absolute vs. relative timeout values.
Thanks,
Tom & Tim
B
. If you have feedback one way
or the other, we’d love to hear it.
Thanks,
Tom & Tim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
> On Mar 8, 2019, at 3:00 PM, 神明達哉 wrote:
>
> At Mon, 4 Mar 2019 19:45:02 -0500,
> Tom Pusateri mailto:pusat...@bangj.com>> wrote:
>
> > Thanks to the great feedback, we were able to update the document to
> > better match the preferences of the working grou
> On Mar 5, 2019, at 8:20 AM, Tony Finch wrote:
>
> Tom Pusateri wrote:
>>
>> Sorry if that freaked you out.
>
> I wasn't freaked out, I just thought the response was directed to the
> wrong place. I didn't bring up the issue for a two-way discussion, I
> On Mar 5, 2019, at 7:18 AM, Tony Finch wrote:
>
> Tom Pusateri wrote:
>>
>> Modify presentation format of date/time to match RRSIG (Mark Andrews)
>
> I got some mail from github about this issue which was weirdly sent to
> me personally rather than to the WG
(partly Tony Finch)
Note: going through the list, I realized that I missed the comment that we need
to explain why individual records need cleaned up and not just the whole RRSet.
We’ll open an issue for this and handle it in the next version.
Thanks,
Tom
> Begin forwarded message:
>
> On Feb 21, 2019, at 10:19 PM, Tom Pusateri wrote:
>
>
>
>> On Feb 21, 2019, at 1:29 PM, Ted Lemon > <mailto:mel...@fugue.com>> wrote:
>>
>> On Feb 21, 2019, at 2:24 PM, Mark Andrews > <mailto:ma...@isc.org>> wrote:
>>> Imp
base
that holds resource records, why create another database type? But if the
consensus is that the TIMEOUT info shouldn’t be stored in the existing resource
record database but instead authoritative servers should create a new database
for this info, then that is fine. This document itself can TIMEOUT. :)
ble
everywhere because TLS 1.3 will be needed everywhere.
I will reopen this issue for discussion but I don’t see yet how this is a
problem.
Thanks,
Tom
> On Feb 18, 2019, at 7:27 PM, Mark Andrews wrote:
>
> I have yet to seen a justification for using SHAKE128 vs any of the exi
on it if you have an opinion
or feel free to open other issues against the document or send comments to the
list.
The TIMEOUT RR is just like any other resource record now with no special
handling.
Issues are on Github:
https://github.com/pusateri/draft-pusateri-dnsop-update-timeout/issues
Thanks,
Tom
.
Thanks,
Tom
1 {
2 "definitions": {},
3 "$schema": "http://json-schema.org/draft-07/schema#;,
4 "$id": "http://dnsdisco.com/rfc8427.json;,
5 "type": "object",
6 "title": “RFC 8427 Schema",
11 "prop
eady USED by DNS. The results
> can be truncated if you are worried about space.
>
> And no it isn’t as easy as just calling OPENSSL. PKCS#11 providers
> also need to support the hash algorithm.
>
Ok, thanks for this extra info. I will look into it.
Tom
Not true. You have PTR records with the same service name from multiple clients
each with different RDATA and unique timeouts as I demonstrated yesterday in
the example.
Tom
> On Aug 27, 2018, at 3:27 PM, Ted Lemon wrote:
>
> For service instance names, there is only one se
> On Aug 27, 2018, at 2:25 PM, Tom Pusateri wrote:
>
>
> Sorting the timeouts is a good idea.
>
Well, maybe sorting timeouts is a good idea. Depending on how they are
represented internally, it makes no difference. I would like to hear from
implementors whether this even m
Because even if you add TYPE, you have multiple PTR records (instance names)
with the same owner name, class, and type that can timeout differently.
Tom
> On Aug 26, 2018, at 11:20 PM, Ted Lemon wrote:
>
> If we do that, why do we need a hash at all?
>
> On Sun, Aug 26, 2018 a
ber of blocks but reduce the number of hashes
needed. This might simplify SRP complexity. Some analysis is required to
determine if this is a net benefit.
Thanks,
Tom
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
I’m not sure I understand your comment.
I believe I just showed you how SRP does work in the existing draft. If I’ve
somehow mis-understood how SRP works, please let me know.
Tom
> On Aug 26, 2018, at 10:48 PM, Ted Lemon wrote:
>
> SRP has to work. We updated the DNS update l
By the way, the SRP case looks messy because SRP chooses to have different
lease lifetimes for KEY records. If the lease lifetimes were all the same, as I
would expect for most UPDATES, everything would be simpler.
Tom
> On Aug 26, 2018, at 10:22 PM, Tom Pusateri wrote:
>
>
>
TIMEOUT 0 0 Tn+Ln
5.0.0.0.0.0.0.0.0.0.0.0.b8.0d.01.20.ip6.arpa. TIMEOUT 0 0 Tn+Ln (using bytes
instead of nibbles for compactness)
Hope this makes things more clear.
Tom
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
> On Aug 26, 2018, at 7:07 PM, Paul Vixie wrote:
>
> Tom Pusateri wrote:
>>
>> There’s no attack vector here. And a collision would have to be
>> another valid RR already in the database with the same owner name and
>> class. This is literally impossible. Prob
> On Aug 26, 2018, at 6:54 PM, Paul Vixie wrote:
>
>
>
> Tom Pusateri wrote:
> ...
>> SHAKE128 as well as other SHA-3 algorithms have been found to be
>> quitecollision resistant.
>
> right. they all are, at first. we're building for our grandkids
> On Aug 26, 2018, at 3:59 PM, Paul Vixie wrote:
>
>> On Sunday, August 26, 2018 5:47:43 PM UTC Tom Pusateri wrote:
>> ...
>> Nice properties of the hash:
>>
>> 1. the length of the output value is consistent across varying input lengths
>
I actually think the hash won’t be needed as much as you think. If the timeout
is the same, even though the record types are different, you still don’t need
the hash.
Is this straightforward?
//
// main.c
// requires OpenSSL 1.1.1 or later
//
// Created by Tom Pusateri on 8/26/18
> On Aug 26, 2018, at 1:47 PM, Tom Pusateri wrote:
>
>
>
>> On Aug 26, 2018, at 12:58 PM, Ted Lemon > <mailto:mel...@fugue.com>> wrote:
>>
>> On Sat, Aug 25, 2018 at 3:09 PM Tom Pusateri > <mailto:pusat...@bangj.com>> wrote:
>>
> On Aug 26, 2018, at 12:58 PM, Ted Lemon wrote:
>
> On Sat, Aug 25, 2018 at 3:09 PM Tom Pusateri <mailto:pusat...@bangj.com>> wrote:
> I think I already agreed with you here.
>
> My main point was that the primary needs a database and it already has one
> and
makes about treating all records the same, it seems logical
to store the lease lifetime information as actual resource records and transfer
them to the secondary.
Thanks,
Tom
> On Aug 25, 2018, at 2:13 PM, Ted Lemon wrote:
>
> Well, okay, but isn't this just for garbage collecti
> On Aug 25, 2018, at 2:53 PM, Paul Vixie wrote:
>
> On Saturday, August 25, 2018 6:11:48 PM UTC Tom Pusateri wrote:
>> ...
>>
>> In most cases, having the primary remember the lease lifetime should be
>> enough. But if the outage is longer than the l
or not they are transferred to the secondary is of secondary
importance. But having them treated as regular records has been recommended so
having them transferred during AXFR/IXFR will be looked upon with favor.
Thanks,
Tom
> On Aug 25, 2018, at 11:11 AM, Ted Lemon wrote:
>
> Right; my
prefixes.
Tom
> On Aug 24, 2018, at 10:53 PM, Ted Lemon wrote:
>
> When would that happen?
>
> On Fri, Aug 24, 2018 at 10:52 PM Mark Andrews <mailto:ma...@isc.org>> wrote:
> Registering slaac derived addresses in the DNS. These are tied to prefix
> lifetimes.
>
&
and NSEC3 records?
I would expect a secondary server to treat them the same as it does any other
record type.
>
> Sources of TIMEOUT Expiry Time
>
> Add matching TIMEOUT records added via UPDATE.
Ok.
Thanks!
Tom
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
> On Aug 24, 2018, at 2:59 PM, Ted Lemon wrote:
>
> On Aug 24, 2018, at 2:43 PM, Tom Pusateri <mailto:pusat...@bangj.com>> wrote:
>> It seems odd to take the position that the authoritative server shouldn’t
>> need to clean up stale entries because
Sorry, I never surveyed the set of inconsiderate DCHP servers.
Thanks,
Tom
> On Aug 24, 2018, at 2:04 PM, Ted Lemon wrote:
>
> Can you give us an example?
>
>> On Fri, Aug 24, 2018 at 1:56 PM Tom Pusateri wrote:
>> Sure. It’s not the thoughtful, well-behaved imple
Sure. It’s not the thoughtful, well-behaved implementations that we worry
about. It’s the ones that aren’t. This is a protection mechanism. (Belt AND
suspenders..)
Thanks,
Tom
> On Aug 24, 2018, at 1:36 PM, Ted Lemon wrote:
>
> The DHCP case isn't actually a problem today. DHC
> On Aug 24, 2018, at 9:54 AM, Ted Lemon wrote:
>
> On Aug 24, 2018, at 9:52 AM, Tom Pusateri <mailto:pusat...@bangj.com>> wrote:
>> Yes, it was intended to be more general than for service registration. It’s
>> directly applicable to name registrati
> On Aug 24, 2018, at 10:11 AM, Joe Abley wrote:
>
> Hi Tom,
>
>> On Aug 24, 2018, at 09:52, Tom Pusateri wrote:
>>
>>> If a zone is signed, are the TIMEOUT records signed?
>>
>> No. The draft says they are skipped.
>
> New RRTypes are su
> On Aug 24, 2018, at 9:11 AM, Ted Lemon wrote:
>
> On Aug 23, 2018, at 11:44 PM, Tom Pusateri wrote:
>> An RRset isn’t granular enough because the components of the set could come
>> from different clients with different timeout values.
>> Therefore, a unique id
I don’t think there is a TTL issue because, as we proposed it, the record is
never returned in a query. The TTL could always be set to 0 for our purposes
since it never leaves the authoritative servers.
Tom
> On Aug 23, 2018, at 11:44 PM, Tom Pusateri wrote:
>
> Paul,
&g
._TIMEOUT.FSI.IO idea is a neat one that we hadn’t thought of but it
isn’t unique to a record with a potentially different timeout value from a
different client and only works if all the members of the RRset have the same
timeout.
We’ll take a look at your TTL concern and your previous draft.
Thanks!
Tom
, we would love to have your feedback as to the
usefulness of this new record type. If you maintain authoritative server
software, we would love to have your feedback on whether this is something you
would consider implementing or taking a pull request for.
Thanks,
Tom & Tim
> Begin fo
> On Aug 21, 2018, at 3:30 PM, Paul Vixie wrote:
>
> this, joyfully, is a very good question.
>
> Tom Pusateri wrote:
>
>> Ok, so as Vladimír said, getting back to DHCP…
>>
>> 1. You obviously don’t need a DoH URI option for DHCP. 2. You’re
>>
> --
> P Vixie
Ok, so as Vladimír said, getting back to DHCP…
1. You obviously don’t need a DoH URI option for DHCP.
2. You’re comfortable with DNS over UDP/53 as long as DNS Cookies are present
and using the existing DHCP DNS options
3. You seem happy with the Android approach of
> On Aug 21, 2018, at 7:33 AM, Tony Finch wrote:
>
> Tom Pusateri wrote:
>
>> Come to think of it, DNSSEC validation in the stub resolver or browser
>> is really a place DoH could shine. Instead of all the round trips
>> required for validating up (
> On Aug 21, 2018, at 3:30 AM, Marek Vavruša
> wrote:
>
> On Mon, Aug 20, 2018 at 11:37 PM, Petr Špaček <mailto:petr.spa...@nic.cz>> wrote:
>> On 21.8.2018 04:38, Tom Pusateri wrote:
>>> Come to think of it, DNSSEC validation in the stub resolver or bro
the validation
quickly for all of the links in a page in an order that the user is most likely
to need based on previous statistics and scrolling position.
Tom
> On Aug 20, 2018, at 10:31 PM, Tom Pusateri wrote:
>
> Sure. My point was that there could be legitimate uses of DoH.
>
> Y
Sure. My point was that there could be legitimate uses of DoH.
You have to move DNSSEC validation from the resolver to the client in order to
really validate the answers if you can’t trust the resolver.
Tom
> On Aug 20, 2018, at 10:28 PM, Ted Lemon wrote:
>
> Of course, the questio
> On Aug 20, 2018, at 10:21 PM, Paul Vixie wrote:
>
>
>
> Tom Pusateri wrote:
>> ... I don’t know if it’s generally accepted that DoH will replace
>> UDP/53 or DoT in the stub resolver or DoH will just end up in the
>> browsers as a way to spe
rowser and DoT is tried and used on all DNS
servers, there’s not a problem to solve.
Tom
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ryone that there was a lot of people agreeing with Ted in
Montréal and so far, Ted appears to be standing all by himself.
Where are all the other folks that shot down this idea earlier? :)
Thanks,
Tom
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
st for operating systems
or stub resolvers to whitelist/blacklist public DNS resolvers.
I tried to summarize it here:
https://dnsdisco.com/reputation-post.html
<https://dnsdisco.com/reputation-post.html>
Or you could go listen to the proceedings of the DRIU BOF.
Thanks,
Tom
_
authentication for the purpose of doing
>> Reconfigure; this authentication is not sufficient to provide assurances of
>> trustworthiness. It's about as secure as a TCP sequence number.
>>
>>>
>>> I'm happy if we say the draft must depend on RFC3315, or discuss the
&
> On Aug 2, 2018, at 11:32 AM, Ted Lemon wrote:
>
> We got some really good review during the IESG last call process. Thanks to
> the IESG members (bcc) who read the document thoroughly and gave so many
> thoughtful comments.
>
> I believe that we have addressed all of the comments that
Ted,
Those clarifications look good.
Thanks,
Tom
> On Aug 2, 2018, at 10:53 AM, Ted Lemon wrote:
>
> On Thu, Aug 2, 2018 at 9:54 AM, Benjamin Kaduk <mailto:ka...@mit.edu>> wrote:
> > We specifically didn’t want to reference DoH since HTTP is unsuitable for
&g
> On Jul 31, 2018, at 3:53 PM, Tom Pusateri wrote:
>
>>
>> If the RCODE is set to any value other than NOERROR (0) or DSOTYPENI
>> ([TBA2] tentatively 11), then the client MUST assume that the server
>> does not implement DSO at all. In thi
gt; Section 7.1.1
>
> It seems like we could consolidate the "equal to" and "greater than" cases
> into "greater than or equal to”.
Noted.
>
> Section 7.2.1
>
> A client MUST NOT send a Retry Delay DSO request message or DSO
> unacknowledged
> On Jun 21, 2018, at 1:40 PM, Shumon Huque wrote:
>
> On Thu, Jun 21, 2018 at 8:05 AM Tom Pusateri <mailto:pusat...@bangj.com>> wrote:
>> On Jun 21, 2018, at 12:19 AM, Vladimír Čunát > <mailto:vladimir.cunat+i...@nic.cz>> wrote:
>>
>> On 06/
> On Jun 21, 2018, at 12:19 AM, Vladimír Čunát
> wrote:
>
> On 06/20/2018 04:59 PM, Tom Pusateri wrote:
>> DNSSEC will tell you the answer you get is correct but it could be a > to a
>> different question or be incomplete.
> Can you elaborate on that point.
d on security as much
in the past as it will in the future, it seems that throwing security measures
off the boat is premature.
Tom
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ool in the toolbox as we move forward into
more private and secure DNS.
Tom
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ent and server for DNS push
notifications which is based on Stateful Operations. This code isn’t public and
I haven’t looked at it for about 6 months. But it did identify some issues
early on in the draft that we corrected for.
Thanks,
Tom
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
> On Jun 7, 2018, at 1:56 PM, Bob Harold wrote:
>
>
> On Thu, Jun 7, 2018 at 1:43 PM Tom Pusateri <mailto:pusat...@bangj.com>> wrote:
> This updated version adds some minor changes requested by Warren including
> anycast clarifcation, a new RFC reference,
This updated version adds some minor changes requested by Warren including
anycast clarifcation, a new RFC reference, and IANA helpers.
Tom
> On Jun 7, 2018, at 1:38 PM, internet-dra...@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
&
I made all of these suggested changes on github except for the Section 3 “same
server instance” pandora’s box.
The authors can discuss how they want to change this one or leave it for later.
If I don’t hear anything in a day or two, I’ll push out another version.
Thanks,
Tom
> On Jun 2, 2
DNS Stateful Operations
>Authors : Ray Bellis
> Stuart Cheshire
> John Dickinson
> Sara Dickinson
> Ted Lemon
> Tom Pusateri
> Filename
it’s new submissions and
feature proposals is not very complex in comparison to routing.
I am not in favor of slowing innovation or slowing the adoption of new work. I
think each submitted proposal should stand on it’s own merits and we should be
able to have discussions about each proposal
tand to be the consensus of the
authors. I don’t mean to speak directly for the other authors and I will let
them correct me if there is disagreement that I am not aware of.
Thanks,
Tom
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
://gitweb.torproject.org/torspec.git/tree/ and a version
identifier. So we're working on this.
-tom
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
repository is probably as
reasonably reliable as any other offsite link.
I support this draft.
-tom
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
:
interface: 0.0.0.0@443
interface: ::0@443
access-control: 0.0.0.0/0 allow
ssl-port: 443
ssl-service-pem: /etc/unbound/unbound_server.pem
ssl-service-key: /etc/unbound/unbound_server.key
-tom
On 1 July 2015 at 06:43, Dan York y...@isoc.org wrote:
DNSOP participants,
Will you be in Prague
what or apparently semantically adds to this,
seems to be a repeat of visually
-tom
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
I've read, I support, I will continue to read and contribute.
-tom
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
come out a little weird... but it seems like the most relevant
place to at least take the idea and discuss it.
-tom
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
to
specifically handle it. Then if .foo gets the same treatment in N
years, no client software changes are needed.
-tom
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
allow other applications to make use of the bundled daemon.
-tom
[0] As mentioned, this is a wholly insecure way to access sites
anonymously, as there are ways to a) get your real IP address b) link
you between TLDs c) correlate your browsing sessions and d)
fingerprint you uniquely.
[1
79 matches
Mail list logo
