if HTTPSSVC goes through, i think we can all stop talking about ANAME.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Monday, 8 July 2019 16:42:39 UTC Michael J. Sheldon wrote:
> ...
>
> If a record is requested from an authoritative server, where the zone does
> not exist, generally the response is REFUSED, but *this is not cached* by
> the requesting server. This results in a nearly continuous stream of
> re
On Monday, 8 July 2019 18:02:32 UTC Michael J. Sheldon wrote:
> On 7/8/19 10:56 AM, Paul Vixie wrote:
> > i've always sent back SERVFAIL when the zone isn't loaded, on either a
> > primary or secondary (authoritative, that is) server. and i cache
> > SERVFAIL on the
On Tuesday, 9 July 2019 14:36:50 UTC John Bambenek wrote:
> Below
>
> ...
john, (all,) my own prior review of this proposal was effectively neutral but
actually negative. dns does not permit the kind of rate limiting and logging
needed by individual domain holders around their whois details unl
On Tuesday, 9 July 2019 21:49:50 UTC Mark Andrews wrote:
> Which invariable ends up being needed to be split over multiple machines for
> different protocols. ANAME can’t do that splitting.
>
> ANAME if it continues to exist needs rules like MX. It also needs to be
> explicitly looked for by the
On Tuesday, 9 July 2019 21:56:49 UTC John Bambenek wrote:
> How would having an SRV record and an entirely different (currently
> undeveloped) service help the situation?
whois and rdap servers are a dime a dozen. i can run one for all of my
domains, and put it behind a rate limiter to make life
John Bambenek wrote on 2019-07-09 17:29:>
On July 1st, 2019, my DGA feeds are converting to a CC-BY-NC-SA 4.0
license which means commercial use will require a license. Contact
sa...@bambenekconsulting.com for details
On Jul 9, 2019, at 19:13, Paul Vixie wrote:
whois and rdap servers
Joe Abley wrote on 2019-07-09 17:35:
On Jul 9, 2019, at 20:11, Paul Vixie wrote:
everything other than HTTPS can just use SRV.
ANAME is (should be) toast(ed).
Didn't we get to this point by acknowledging that there was a gap
between now and the glorious future where SRV and un
delivered. all of this is wrong.
william simpson, perry metzger, and paul vixie (me) worked together about ten
years ago to create TCP enhancements which would have permitted an unlimited
number of quiescent but open TCP connections, at a per-connection state cost
precisely equal to the cost of res
On Monday, 8 July 2019 18:36:07 UTC Andy Grover wrote:
> Hi all,
>
> FYI from the ADD list, please post there or to the authors with feedback.
andy, thanks for this, it seems well intentioned and well executed. three
small nits:
> One way to implement content control that does not rely on softw
On Sunday, 14 July 2019 23:09:00 UTC Rob Sayre wrote:
> Paul Vixie wrote:
> > ...
>
> Was DNS intentionally designed to be insecure?
no. nor ip itself, or ncp which preceded it, or tcp, or udp, or icmp, or smtp,
ot http. it was insecure because it evolved in a safe, germ free a
On Monday, 15 July 2019 01:41:10 UTC Rob Sayre wrote:
> Thank you for the elegant response. BCP 61 describes this issue well, too.
>
> https://tools.ietf.org/html/bcp61
>
> DNS seems like it still operates in the clear, and that doesn't seem good.
first we signed transactions with asymmetric key
On Monday, 15 July 2019 13:35:33 UTC Tim Wicinski wrote:
> The chairs felt that fujiwara-san's draft was one that needed in person
> discussion in Montreal.
hopefully kazunori will suggest a bar bof for monday night. i leave tuesday
morning and so will miss the WG meeting. my own concern is more
On Monday, 15 July 2019 02:17:04 UTC Rob Sayre wrote:
> On Sun, Jul 14, 2019 at 6:59 PM Paul Vixie wrote:
> > ...
>
> I'm surprised that you seem to view DoH as a problem. I mean, everyone knows
> that TLS and IPSEC are compromised by determined attackers, ...
if you kno
someone here recently asked why multiple questions are allowed by the DNS
header format but not implemented. this was in the context of performance
comparisons between tcp/53 and udp/53, vs. DoT, vs. DoH.
the reason it's not implemented is that there's only one RCODE in the
response, so if one
On Monday, 22 July 2019 20:45:43 UTC Andrew Campling wrote:
> ...
>
> [AC] This would be helpful given it appears some (all?) DoH resolvers have
> indicated that they will not pass sufficient information to (rival) CDN
> vendors to allow geographic routing. Clearly if this is commonplace then
> p
On Monday, 22 July 2019 21:19:47 UTC Jim Reid wrote:
> > On 22 Jul 2019, at 21:52, Paul Vixie wrote:
> >
> > apparently ECS creates problems for privacy, but _how could we have
> > suspected_?
(that, by the way, was sarcasm.)
> IIRC the ECS privacy issues were reco
fujiwara-san and i will be at an otherwise quiet bar at 21h local time tonight,
here in the neighborhood of ietf Montreal. email me if you want to join us.
Get BlueMail for Android ___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/lis
at the one-hour DNSOP meeting in montreal on monday evening, the authors of
RFC 7706 described some of the use case questions they were hoping to answer
in their -bis document, and one of them hit squarely on a topic i spoke about
frequently between 2005 and 2015. i've attached a copy of the 201
with four of us in attendance monday evening, i presented my appreciation for
fujimora-san's draft and admitted that EDNS0 ought to have required DF and
ought to have used examples which would fit in a then-common MTU 1500 network.
i then asked that numbers like 1220, 1280, 576, and 1500 not be
the route MTU; thus, this should be safe for EDNS
buffer size as well.
paul
re:
On Thursday, 25 July 2019 00:19:18 UTC Paul Vixie wrote:
> with four of us in attendance monday evening, i presented my appreciation
> for fujimora-san's draft and admitted that EDNS0 ought to have required
On Thursday, 25 July 2019 05:44:50 UTC Evan Hunt wrote:
> ...
>
> But, it's Mostly Harmless. The implementation cost can be zero if you want
> it to be; it's just a server configuration. At worst, it's a waste of the
> time that's been spent talking about it (with the zone transfer code that
> f
On Friday, 16 August 2019 13:10:02 UTC Ted Lemon wrote:
> ...
>
> What’s the motivation behind this proposal?
>
> ...
i think it's to reduce the time between a mouse click and an advertising
impression, but i'm not an author so that's not "authoritative". it seems to
me that the web's technica
On Thursday, 5 September 2019 20:48:34 UTC Paul Wouters wrote:
> [DLV] was very useful at the beginning, especially before the root was
signed.
> I used it to get DNSSEC from a number of TLDs and could not have done that
> without DLV.
me too. if the first production use of dnssec had been the da
On Thursday, 5 September 2019 21:46:12 UTC Randy Bush wrote:
> ...
>
> dlv had no particular trust model. ...
as one of its janitors, its trust model was pub-sub. that's why it could never
have scaled. wot is what's actually needed for this. follows-delegation is
neither the best or worst way
a correct implemention of smtp could pick up the a and from additional
data without making any additional queries. it could also ignore cname records
in the a/ response and declare that the a/ owner was wrong.
we can't break working behaviour no matter what the statistics show. a dr
Viktor Dukhovni wrote on 2019-11-18 12:56:> ...
At the end of the day, operating outside the RFC carries some risk,
and one should not be cavalier in deploying creative deviations from
the spec. However, post-MX CNAME indirection is seen to useful by
some to stick to the spec, and since MTAs
Tommy Pauly wrote on 2019-11-19 02:39:
Hello DNSOP,
In the interest of getting this spec ready to go, I want to start our
bikeshed on the RRTYPE name. We need a stable name that we all can live
with.
I'll start. Please chime in!
Since it seems that many people like SVCB, and many don't l
On Thursday, 21 November 2019 06:54:47 UTC Warren Kumari wrote:
> ...
>
> IP Fragmentation Considered Fragile
>draft-ietf-intarea-frag-fragile-17
> https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile/
>
>
> This is currently with the RFC Editor.
can someone who
On Thursday, 21 November 2019 08:32:38 UTC Warren Kumari wrote:
> On Thu, Nov 21, 2019 at 3:54 PM Paul Vixie wrote:
> > On Thursday, 21 November 2019 06:54:47 UTC Warren Kumari wrote:
> > can someone who knows the rfc editor please tell them that the reference
> > in this
On Friday, 22 November 2019 08:26:35 UTC Bill Woodcock wrote:
> ...
>
> Again, this is an argument from principle rather than an argument based on
> the specific case at hand. I just think that we have a well-established
> precedent that all two-letter TLDs are derived from ISO 3166 Alpha-2, and
On Thursday, 28 November 2019 12:15:23 UTC Ted Lemon wrote:
> So let me get this straight: you want us to stay out of ISO’s sandbox by
> jumping right in to ICANN’s? ICANN has not promised never to delegate those
> domains, whereas ISO effectively has, so your reasoning doesn’t make sense.
ISO has
Ralf Weber wrote on 2019-12-03 14:21:
On 3 Dec 2019, at 3:15, Michael StJohns wrote:
...
The way I read this is that setting the bit simply because you
couldn't include diagnostic info is a no-no. Let's not do it.
I disagree. The EDNS0 OPT RRSet is needed and thus if can not be fitted
en
Wessels, Duane wrote on 2019-12-04 14:22:
...
DNS messages over TCP are in no way guaranteed to arrive in single
segments. In fact, a clever attacker might attempt to hide certain
messages by forcing them over very small TCP segments. Applications
that capture network packet
On Monday, 23 December 2019 20:22:01 UTC Eric Orth wrote:
> Maybe it would help if we scoped down any chain limiting:
>
> 1) Any chain limiting only applies to SVCB alias form, not CNAME.
>
> CNAMEs already exist without a standardized limit. Good or bad, too late
> to change that without breaki
On Friday, 27 December 2019 18:25:29 UTC Eric Orth wrote:
> I propose we add the following 4 statements to the spec:
> 1) Alias-form SVCB records SHOULD NOT delegate to names with any form of
> alias record such as alias-form SVCB or CNAME.
> 2) Clients receiving SVCB records MAY limit the length o
in SRV we added a port number to the rdata because the /etc/services file was
painful to keep globally updated. SRV was protocol independent.
HTTPSSVC is protocol specific, and when it copied SRV, it included the port
number in the rdata, which i think is both unnecessary and error-prone.
manag
On Friday, 3 January 2020 20:01:04 UTC Erik Kline wrote:
> I think removing port number flexibility might unduly constrain some data
> center use cases where service reachability might not have the more common
> 443-only limitations.
"think" and "might" are unpersuasive, and "unduly" is subjective
On Sunday, 5 January 2020 01:14:17 UTC Michael StJohns wrote:
> ...
>
> 1) A recommendation for the maximum size of the zone (and for that
> matter the maximum churn rate). This is hinted at in the abstract, but
> missing from the body of the document.
> 2) ...
> 3) ...
> ...
> I think Experimenta
[thread fork; subject changed]
i've brought this up several times including in response to the very first
draft version. i'd like to be sure it's been considered and rejected by the
dns technical community, rather than merely forgotten.
ZONEMD as drafted is not incremental. so to compute it, th
Michael StJohns wrote on 2020-01-15 17:28:
... I think its a co-existence issue here. I don't think you should
have two different (calculation-wise) ZONEMD-like RRSets in the same
zone for the reasons you've mentioned. I don't think that reserving RR
types is the right way of doing things
On Tuesday, 11 February 2020 22:21:05 UTC Linda Dunbar wrote:
> ...
>
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/
>
> During IETF 106, we received comments that the document should cover the
> problems associated with DNS service by different Cloud Operators f
On Wednesday, 12 February 2020 22:43:07 UTC Linda Dunbar wrote:
> Paul,
>
> ...
>
> This document is meant to describe potential problems of utilizing Cloud
> Resources. It is a good idea to document the potential collisions and
> conflicts and recommend Globally unique names. How about adding th
as most dns technologists are aware, ip and tcp have options, and udp does
not. there is a draft:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/
which has been ongoing since 2015, which proposes to add options to udp:
Internet-DraftTransport Options for UDP Septe
On Thursday, 20 February 2020 22:15:17 UTC Evan Hunt wrote:
> On Thu, Feb 20, 2020 at 09:29:31AM +0100, Matthijs Mekking wrote:
> > ANAME was supposed to solve the CNAME at the apex problem and mitigate
> > against DNS vendor lock in. Both SVCB and HTTPSSCV do not fix this
> > problem.
>
> ...
>
On Tuesday, 25 February 2020 00:43:01 UTC Tim Wicinski wrote:
> ...
>
> This starts a Working Group Last Call for Extended DNS Errors
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/
>
> Please review the draft and offer rel
On Wednesday, 26 February 2020 19:01:40 UTC Evan Hunt wrote:
> On Wed, Feb 26, 2020 at 03:34:55PM +0100, Vladimír Čunát wrote:
> > I don't think it's so simple. The current ANAME draft specifies new
> > behavior for resolvers, and there I'd expect even slower overall
> > upgrades/deployment than i
On Monday, 9 March 2020 20:56:39 UTC Ben Schwartz wrote:
> It occurs to me that I hit "publish" on this draft without updating the
> release notes, so I'll mention some of the many changes since -01 here
> instead:
>
> ...
>
> As always, please review and send comments. We also expect to do a
>
On Tuesday, 10 March 2020 02:42:01 UTC Erik Nygren wrote:
> On Mon, Mar 9, 2020 at 10:32 PM Paul Vixie wrote:
> > On Monday, 9 March 2020 20:56:39 UTC Ben Schwartz wrote:
> > > ...
> >
> > i propose that section 6.2 for "port", and all references to same
On Tuesday, 10 March 2020 13:30:53 UTC Patrick McManus wrote:
> another positive feature of ports in this record is that it provides some
> address space independent of the origin security model of the URI. By this
> I mean that https://www.foo.com(implicit :443) and https://www.foo.com:555
> are d
On Tuesday, 10 March 2020 18:25:57 UTC Patrick McManus wrote:
> alt-svc is quite robust to reachability failures of the alternative origins
> should some client find itself on a network that filters full transit.
>
> This process is already existing technology (rfc 7838). From that
> perspective t
On Tuesday, 10 March 2020 19:05:39 UTC Stephen Farrell wrote:
> Paul,
>
> ...
>
> What's the difference between having a port number
> as part of HTTPSSVC (or whatever we call it;-) in
> the DNS and having a web page on 443 that includes
> hrefs with https:// schemed URLs that are not using
> por
since the meeting is now virtual, could we get an extension on the draft
cutoff for updates?
re:
On Wednesday, 4 March 2020 21:05:23 UTC Tim Wicinski wrote:
> The chairs would like to remind everyone that the Draft submission cutoff
> date is this coming Monday, March 9th at 23:59 UTC.
>
> Also
i'm replying to two messages here, one from patrick, one from stephen.
Patrick McManus wrote on 2020-03-10 12:24:
On Tue, Mar 10, 2020 at 2:54 PM Paul Vixie <mailto:p...@redbarn.org>> wrote:
httpssvc is not an alternate service description permitting
fallback to the n
On Saturday, 11 April 2020 13:22:42 UTC Shumon Huque wrote:
> ...
>
> This might also be viewed (correctly) as a corner case in the RRR model
>
> > that doesn't get addressed; it seems to happen most frequently if a
> > registrant changes registrars or if a domain lapses, where the previous
> > r
On Saturday, 11 April 2020 17:02:07 UTC Shumon Huque wrote:
> On Sat, Apr 11, 2020 at 12:33 PM Stephane Bortzmeyer
> wrote:
> > ...
> >
> > I don't think that you answer Brian's idea. The way I've read his
> > idea, he suggested, when a resolver detects a lame server (or when all
> > servers are
today it was proposed that NS2 be added as a new record-set type that
could exist in either the parent or the child, similar to NS, and
reminding several of us about the DS debacle.
DS should never have been placed at the delegation point, and has led to
a decade or longer of bugs and corner c
Jim Reid wrote on 2020-04-14 08:54:
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
Ralf Weber wrote on 2020-04-14 08:57:
Moin!
On 14 Apr 2020, at 17:43, Paul Vixie wrote:
DS should never have been placed at the delegation point, and has led
to a decade or longer of bugs and corner cases and complexity. it
ought to have been a nephew domain of the delegation point, but
On Tuesday, 14 April 2020 17:32:54 UTC Paul Wouters wrote:
> On Tue, 14 Apr 2020, Tim Wicinski wrote:
> > This starts a Call for Adoption for
> > draft-fujiwara-dnsop-avoid-fragmentation
> >
> > ...
> >
> > We are looking for *explicit* support for adoption.
>
> I am in favour of adoption.
>
>
a bit in the parent (DS RRset) to say this delegation point is itself
delegation-only would be more interesting. perhaps a way to assure compliance
with a contract, thus preventing any ambiguity along the lines of
"sitefinder".
but a bit in the apex (DNSKEY RRset) is still interesting, as a dec
first reply:
On Tuesday, 14 April 2020 23:41:46 UTC Mukund Sivaraman wrote:
> One more question:
> > 3. Proposal to avoid IP fragmentation in DNS
> >
> >o UDP requestors and responders SHOULD send DNS responses with
> > IP_DONTFRAG / IPV6_DONTFRAG [RFC3542] options, which will yield
>
Paul Hoffman wrote on 2020-04-15 09:51:
On Apr 15, 2020, at 7:08 AM, Paul Wouters wrote:
Since this is a one line RFC change of an erroneous omission of
text , could it be done as an errata instead?
No. It is not an error in the spec that someone noticed 30 years
later: it is an operatio
On Wednesday, 15 April 2020 15:16:20 UTC John Levine wrote:
> In article <060513e7-742d-6de9-cf16-c367fbb13...@redbarn.org> you write:
> >...
> >
> >so instead of example.com DS, it should have been example._dnssec.com DS.
>
> I take your point but I have a question and a half.
>
> The plan in th
mind if i cut in?
On Saturday, 25 April 2020 06:23:54 UTC Vladimír Čunát wrote:
> Original subject: New draft on delegation revalidation
>
> On 4/24/20 4:49 PM, Shumon Huque wrote:
> > ...
>
> ...
(agreeableness.)
> Still, note that for some consumers the secure transport may be an
> argument
On Fri, Apr 24, 2020 at 6:21 PM Gavin McCullagh wrote:
> ...
> PS How truly intractible is the registry argument? It seems something
> like "When an NS change is made, TTL=3600 for the first N hours, then 2
> days thereafter." would be a major step forward without drastically
> increasing complex
On Tuesday, 28 April 2020 01:02:27 UTC Shumon Huque wrote:
> On Sat, Apr 25, 2020 at 2:57 AM Paul Vixie wrote:
> > ...
>
> The DNSSEC specs have always contemplated validating stub resolvers.
> I think the Kaminsky cache poisoning scare inadvertently focussed our
> efforts
On Tuesday, 28 April 2020 21:57:16 UTC John Levine wrote:
> In article <6.2.5.6.2.20200428121847.081a2...@elandnews.com> you write:
> >I found a WG draft (expired) from 2017 about RPZ. I am not sure why
> >it stalled in DNSOP. There is also a 2018 draft (expired). I
> >vaguely recall looking at
On Wednesday, 29 April 2020 01:17:04 UTC Shumon Huque wrote:
> ...
>
> Paul - I guess I'm missing some background here. In what sense did
> getting DS working throw validating stubs overboard? Do you mean it
> took the focus away from them?
no. i mean that the decision to require a "clear path" f
On Wednesday, 29 April 2020 13:44:12 UTC Shumon Huque wrote:
> On Wed, Apr 29, 2020 at 12:49 AM Paul Vixie wrote:
> > ...
>
> This is by no means a problem unique to DNSSEC. Many new protocol features
> have and continue to face the middlebox challenge: SCTP, TCP fast open,
&
On Wednesday, 29 April 2020 15:54:33 UTC Shumon Huque wrote:
> to the list, after Paul Wouters replied to me privately.
>
> I realize now this was Paul W responding to Paul V. I thought in
> my response below I was replying again to Paul V!
ah. too many pauls, as before. nevertheless i agreed wit
On Thursday, 30 April 2020 02:12:15 UTC Shumon Huque wrote:
> ...
>
> Deployed validator code says Insecure. It can't be Bogus, because the
> validator has determined that the CNAME is a demonstrably insecure zone,
+1.
--
Paul
___
DNSOP mailing list
in tsvwg they are working on packetization layer path mtu discovery for
datagram transports, whose primary audience seems to be quic and sctp.
https://www.ietf.org/rfcdiff?url1=draft-ietf-tsvwg-datagram-plpmtud-19&url2=draft-ietf-tsvwg-datagram-plpmtud-21
noone who believes that DNS's future is
On Monday, 18 May 2020 17:49:04 UTC Tim Wicinski wrote:
> ...
>
> This starts a Call for Adoption for draft-andrews-dnsop-glue-is-not-optional
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-andrews-dnsop-glue-is-not-optional/
>
> Please review this draft to see if you
On Friday, 22 May 2020 00:31:34 UTC Masataka Ohta wrote:
> ...
>
> While I'm not against the clarification, the draft should mention
> that rfc1034 already states:
>
> To fix this problem, a zone contains "glue" RRs which are not
> part of the authoritative data, and are address RRs for t
On Friday, 22 May 2020 00:55:34 UTC George Michaelson wrote:
> My Colleague George Kuo asked me for definitions of public DNS
> service. not "public DNS" but the trigram "public DNS service"
>
> Colloquially we understand this reasonably well. It is in the space of
> what Google, quad9, CloudFlare
On Friday, 22 May 2020 21:59:11 UTC Bill Woodcock wrote:
> > On May 22, 2020, at 3:38 AM, Paul Vixie wrote:
> > ...
> >
> > these services aren't public in any way, and should not be described as
> > public. they are operated privately for private purposes
>
On Monday, 25 May 2020 09:06:17 UTC Vittorio Bertola wrote:
> > Il 22/05/2020 18:59 Tony Finch ha scritto:
> >
> > I think despite what Paul H. said this is already covered in RFC 8499:
> >Open resolver: A full-service resolver that accepts and processes
> >
> > queries from any (o
On Tuesday, 26 May 2020 19:43:27 UTC Eric Orth wrote:
> One of my colleagues recently brought up the idea of suggesting recursives
> add additional HTTPSSVC records into responses for A/ queries as a way
> to make HTTPSSVC more available for cases where a stub is hesitant to make
> additional q
On Tuesday, 26 May 2020 23:56:30 UTC Ben Schwartz wrote:
> On Tue, May 26, 2020 at 7:06 PM Paul Vixie wrote:
> ...
>
> > and the responder knows
> > the additional data (that is, it should not make extra queries to find it
> > just
> > for additional data reasons
On Wednesday, 27 May 2020 19:05:35 UTC Eric Orth wrote:
> I should also note though that Chrome's built-in stub won't do any followup
> queries if the full chain is not in the response from the recursive.
that's correct behaviour. full resolvers iterate (and recurse). stubs do not.
--
Paul
___
On Thursday, 28 May 2020 14:38:11 UTC Petr Špaček wrote:
> On 25. 05. 20 5:23, Shumon Huque wrote:
> > ...
> > Most importantly:
> > - Does the NS affect maximum TTL of _other_ data in the zone?
> >
> > I think there are probably different views on what should happen here.
> > Folks who wa
On Saturday, 30 May 2020 17:13:10 UTC Gavin McCullagh wrote:
> ...
>
> I think Petr's point might be that someone could interpret the draft
> (perhaps especially the simple mechanism) to mean that the NS TTL becomes
> an effective cap on the TTL of all records below the zone cut even where
> the N
On Friday, 5 June 2020 17:37:56 UTC Wessels, Duane wrote:
> ...
>
> There is also the question of in-domain vs sibling-domain glue. RFC 8499
> (Terminology) notes that "Glue records for sibling domains are allowed, but
> not necessary." Should in-domain glue take priority over sibling-domain
> g
On Saturday, 13 June 2020 21:39:05 UTC Geoff Huston wrote:
> ...
>
> I believe that the IETF passed responsibility for the determination of
> policy regarding the DNS namespace to what we now call ICANN some decades
> ago, and in line with that transfer of role and responsibility such
> discussion
On Monday, 15 June 2020 17:58:42 UTC Tim Wicinski wrote:
> (no hats here)
>
> ...
> >
> > The obvious question is if an organization is willing to use
> > example.com.zz, why wouldn't they use zz.example.com with split
> > horizon DNS to keep that subtree on their local network?
>
> or since dom
On Monday, 15 June 2020 22:00:31 UTC Tony Finch wrote:
> Paul Vixie wrote:
> > ...
> >
> > reserving a corner of the namespace for decentralized operations makes
> > sense.
> There are perhaps three contexts that you might want a private namespace:
>
> ..
On Monday, 15 June 2020 22:46:17 UTC Tony Finch wrote:
> Paul Vixie wrote:
> > there are perhaps more than three, and some might not be yet known by
> > those who will want them. the reason why some part of the DNS namespace
> > should be reserved in the form, "shall
On Tuesday, 16 June 2020 06:56:49 UTC Ralf Weber wrote:
> Moin!
>
> On 16 Jun 2020, at 4:23, Davey Song wrote:
> > ...
> > I hope it is helpful to provide information including risk for people who
> > are doing or going to the same thing.
> >
> > There are some existing cases in the discussion:
>
ships are passing in the night on this topic. GOST is what the russian
government has to use for its crypto. if GOST is not a standard, then the
russian federation's government won't be using DNSSEC, or they'll do it with a
pirated code point. neither of those is desirable and there's no third w
On Thursday, 18 June 2020 07:03:23 UTC Petr Špaček wrote:
> ...
> An off-list reply indicates that I was not clear so I'll attempt to clarify
> my previous message. In my mind the document should say:
>
> 1. _If possible_ use a subdomain you own, it will save you headache later on
> (e.g. when you
On Thursday, 18 June 2020 16:13:23 UTC Paul Wouters wrote:
> ...
> It would be very strange to introduce a new algorithm as NOT RECOMMENDED.
> The weakest I think we should introduce something is as MAY.
+1.
--
Paul
___
DNSOP mailing list
DNSOP@ietf.
On Friday, 19 June 2020 01:50:13 UTC Davey Song wrote:
> Dear Paul,
>
> On Wed, 17 Jun 2020 at 00:03, Paul Vixie wrote:
> > as you know, synchronizing the root zone (RFC 7706) solves almost
> > none of the problem of occasional connectivity, since so many other
>
On Thursday, 25 June 2020 18:29:03 UTC Paul Wouters wrote:
> On Thu, 25 Jun 2020, Mukund Sivaraman wrote:
> > For whoever is interested, this is a description of a pattern of queries
> > noticed at busy public resolvers that has led to issues in at least 4
> > different sites in the last 2 months.
On Wednesday, 1 July 2020 09:41:49 UTC Jan Včelák wrote:
> ...
>
> We just opened this discussion internally at NS1 because we serve some
> zones with more than 10 NS records where each NS requires glue and our
> proprietary server by design adds glue only for the first four NS
> records. We are d
On Thursday, 2 July 2020 01:18:16 UTC John Levine wrote:
> In article <9056955.dJ39pTEj9z@linux-9daj> you write:
> >On Wednesday, 1 July 2020 09:41:49 UTC Jan Včelák wrote:
> >> ...
> >
> >i think if you're using round robin or random selection, a subset is fine.
> >if we had to codify this practic
On Thursday, 2 July 2020 07:47:36 UTC Paul Vixie wrote:
> On Thursday, 2 July 2020 01:18:16 UTC John Levine wrote:
> > ...
>
> this is the draft where that issue would be decided, so it's good we're
> talking about it. ...
by the way, this is what kato and i, and late
On Thursday, 2 July 2020 14:50:24 UTC John R Levine wrote:
> On Thu, 2 Jul 2020, Paul Vixie wrote:
> > ... but our goal should be to allow smart initiators to avoid
> > retrying with TCP out of reflex. my recommendation of TC=0 is to suppress
> > reflexive TCP retries.
> I
On Thursday, 2 July 2020 14:50:24 UTC John R Levine wrote:
> On Thu, 2 Jul 2020, Paul Vixie wrote:
> > ... but our goal should be to allow smart initiators to avoid
> > retrying with TCP out of reflex. my recommendation of TC=0 is to suppress
> > reflexive TCP retries.
> I
Joe Abley wrote on 2020-07-07 10:01:
On Jul 7, 2020, at 12:57, Havard Eidnes wrote:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-respsize/
but it was like moving mud with a toothpick, so after eleven
years (2003 to 2014) we gave it up. there are probably some
good ideas in there, eve
101 - 200 of 1068 matches
Mail list logo
