On Tue, Nov 17, 2020 at 09:32:09AM +0100, Vladim??r ??un??t wrote:
> Hello.
>
> I think the draft should also mention glue *addresses*, as that's
> another closely related piece that often comes from the parent side (and
> is also unavoidable to use in some situations).?? Even if that means not
>
It's an error in the specification.
- Original Message -
From: Mukund Sivaraman
Sent: 2018-12-06 - 15:45
To: dnsop@ietf.org
Subject: [DNSOP] RFC 2136 pre-requisite checks before client authorization
checks
> Hi all
>
> Does anyone know why RFC 2136 sequences pre-requisite checks (secti
If additional data is optional, so most resolvers can just pass it through, the
DNS techs will say yes but the HTTP techs will say no.
- Original Message -
From: Brian Dickson
Sent: 2018-11-07 - 18:30
To: "dnsop@ietf.org WG"
Subject: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANA
We did not use get because get does not have a request payload.
On March 1, 2016 6:44:16 PM PST, Davey Song wrote:
>On Tue, Mar 1, 2016 at 11:58 AM, Paul Hoffman
>wrote:
>
>> This document is a good idea, but it has some faults that need to be
>fixed
>> before it goes forwards.
>>
>> - In the In
Existing signers and validators won't know the internal format of future rr
types.
On December 8, 2015 10:09:06 AM EST, Paul Wouters wrote:
>
>Hi,
>
>Section 6.2 of 4034 talks about canonicalization of the RR Form
>
>Item 3 states:
>
>3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG,
To me this is a feature, possibly the most important feature.
On October 25, 2015 6:16:54 AM GMT+11:00, Stephane Bortzmeyer
wrote:
>[Re-reading all emails...]
>
>On Fri, Jul 10, 2015 at 11:53:30AM -0700,
> 神明達哉 wrote
> a message of 62 lines which said:
>
>> Regarding Section 5 (possible side e
Right. Cname does not cross classes.
In original DNS, class was incoherently sometimes an attribute of zone data and
sometimes a namespace selector. In modern DNS it is coherently always the
latter.
On July 5, 2015 8:17:03 AM GMT+01:00, Ray Bellis wrote:
>
>
>On 05/07/2015 01:35, Andrew Sulliv
Delay is expensive for responders since it requires state. Steve's goal of
making some tld strings flaky so as to encourage developers to avoid DNS for
those names could be met statelessly. For example delegate them to localhost.
On July 5, 2015 12:51:08 PM GMT+01:00, Stephane Bortzmeyer
wrote
I'll have extensive comments, mostly positive, after the weekend.
On July 4, 2015 4:06:31 PM GMT+01:00, Tim Wicinski wrote:
>All
>
>I'm hoping to see some discussion on the mailing list on this, or we'll
>
>bring it up in Prague.
>
>This draft has been languishing that was resolved with some dis
On March 17, 2015 7:42:09 AM GMT+09:00, Michael Sinatra
wrote:
>
>
>On 03/16/15 07:23, bert hubert wrote:
>
>> Separately, I fail to see why we actually need to outlaw ANY queries
>when we
>> can happily TC=1 them.
>
>If the public recursives also support TC=1 on all ANY queries, then
>this
>w
On December 16, 2014 9:47:34 AM PST, Mukund Sivaraman wrote:
>Hi Paul
>
>On Tue, Dec 16, 2014 at 09:20:12AM -0800, Paul Vixie wrote:
>> 3 round trips, 7 packets, for an isolated tcp/53 query.
>>
>> s ->
>> <- s+a
>> a ->
>> q ->
>> <- r+a
>> f+a ->
>> <- f+a
>
>It's 2 round tr
On November 9, 2014 2:08:28 PM PST, Ted Lemon wrote:
>On Nov 9, 2014, at 12:01 PM, Paul Ebersman
>wrote:
>> Most ISPs and most email/spam folks find the current v4 pointer usage
>to
>> be functional.
>
>This assertion with respect to spam at least does not seem to match
>what's actually been sa
Ohta-san, like you I would like to see stateless address auto configuration for
ipv6 (SLAAC) die in a fire. Sadly this outcome is beyond our powers. Let's
start from where we are, no matter how unpleasant that place may be. Vixie
--
Sent from my Android device with K-9 Mail. Please excuse my bre
The architectural context of a feature should not be divorced from its
specification. RFC is an imprimatur. With great power comes great
responsibility.
On May 7, 2014 7:18:14 PM CEST, Andrew Sullivan wrote:
>On Wed, May 07, 2014 at 07:12:21PM +0200, P Vixie wrote:
>> Ouch. Well so i
tives exist. The architecture of DNS assumes localized rdns. If we're
going to document client subnet then all that advice will have to go into it.
On May 7, 2014 7:15:04 PM CEST, Joe Abley wrote:
>
>On 7 May 2014, at 13:12, P Vixie wrote:
>
>> Ouch. Well so if a large b
;On Wed, May 07, 2014 at 07:06:34PM +0200, P Vixie wrote:
>
>> If ietf documents client-subnet then it should be an FYI.
>
>Can't do that. https://tools.ietf.org/html/rfc6360, "Conclusion of FYI
>RFC Sub-Series".
>
>A
>
&
I think if we want good engineering then we should recommend on host or on net
validating resolvers.
I think if we want interoperability then we have to standardize anything
anybody is doing.
If ietf documents client-subnet then it should be an FYI. That's hardly a death
sentence... Look what
Mark's right.
Mark Andrews wrote:
>
>In message , P
>Vixie wr
>ites:
>>
>> Note that this is rendezvous information for the management plane and
>has no
>> protocol significance. A distinct name in the child like
>_cds._dnssec.@ could
>> hold
Note that this is rendezvous information for the management plane and has no
protocol significance. A distinct name in the child like _cds._dnssec.@ could
hold a DS record without confusion.
Similarly, the current DS RR should really have been placed at _ds.child
label._dnssec.parentdomain to k
Joe the special clients still have to forward through middle boxes sometimes.
This special rule won't be known there.
Paul
Joe Abley wrote:
>
>On 2013-04-18, at 20:35, Paul Vixie wrote:
>
>> Joe Abley wrote:
>>
>>> There's no protocol meaning at present for an apex DS RRSet, which
>means it
Ns, above and below, was easy to handle even in dnssec, since it was always
part of the delegation and was only signed in the child. Making any other
rrtype above and below would be much harder since it would not automatically be
exposed on every referral.
The boo boo was putting ds at the dele
t;not
>sitting on a plane headed for a beach, I will play with that.
>
>
>Joe
>
>Aue Te Ariki! He toki ki roto taku mahuna!
>
>On 2013-02-22, at 16:53, P Vixie wrote:
>
>Sorry to be late on this, missed it earlier.
>
>Nxd says there is no such name, no matter what
ferred the idea of specifying configuration for
>standard software over custom code (neat though the custom code Warren
>is
>running is). We just couldn't figure out how to do it.
>
>Did we miss something?
>
>
>Joe
>
>Aue Te Ariki! He toki ki roto taku mahuna!
&
Sorry to be late on this, missed it earlier.
Nxd says there is no such name, no matter what the type was, and there are no
children. No data/noerror says there are either other types or children or
both. We know what the truth must be and we know which implications we want the
requestor to foll
I'd like to be able to implement this with a standard authority server, no
special code, just a root zone that's empty other than its apex. So please no
requirements for the soa other than that it be at or above the qname.
Paul
Warren Kumari wrote:
>
>On Feb 22, 2013, at 6:57 AM, Paul Vixie
25 matches
Mail list logo
