On Wed, 15 May 2019, Paul Hoffman wrote:
I don't understand why you create a specific RRtype with "information to
be filled in by other documents", yet feel the need to have one for
resolvers, maybe another one for authoritative servers,
See above. If a stub asks a question for its resolver,
>> Also, for those who would like to use DNS queries, size does matter.
>>
>> What to do if the inventory is too large for a DNS reply.
>
>DNS replies can be arbitrarily large.
A single RR can only be 64K since there's a 16 bit length field.
This reinforces my belief that this data belongs in
On May 15, 2019, at 1:23 PM, Paul Wouters wrote:
>
> On Tue, 30 Apr 2019, Paul Hoffman wrote:
>
>> Also note that this is explicitly only for resolvers; we might later do a
>> second protocol for authoritative servers who want to give information about
>> themselves (such as if they do DoT,
On Wed, May 15, 2019 at 1:00 PM John Levine wrote:
> In article <064ba295-f3dd-46e4-86a9-e03cf68eb...@sinodun.com> you write:
> >-=-=-=-=-=-
> >
> >Hi,
> >
> >In the spirit of deprecating things I have submitted a draft to deprecate
> the status opcode.
>
> RFC 1034 says it's "To be defined" so
In article you write:
> 3. Retrieving Resolver Information by Well-Known URI
>
>You offer a non-DNS method that can deliver (channel) authenticated
>answers, but you don't allow DNSSEC (data origin) authenticated answers?
It's information about the resolver. What's the data origin for
On Tue, 30 Apr 2019, Paul Hoffman wrote:
Also note that this is explicitly only for resolvers; we might later do a
second protocol for authoritative servers who want to give information about
themselves (such as if they do DoT, if that moves forward in DPRIVE). The
reason for the split is
In article <064ba295-f3dd-46e4-86a9-e03cf68eb...@sinodun.com> you write:
>-=-=-=-=-=-
>
>Hi,
>
>In the spirit of deprecating things I have submitted a draft to deprecate the
>status opcode.
RFC 1034 says it's "To be defined" so this seems a little premature.
Other than that, go for it.
Once again in the long tradition of IETF nitpicking, should the term
"deprecating" be used throughout, rather than "depreciating" ?
Baden
On Wed., 15 May 2019, 8:06 pm John Dickinson, wrote:
> Hi,
>
> In the spirit of deprecating things I have submitted a draft to deprecate
> the status
On May 15 2019, Jim Reid wrote:
On 15 May 2019, at 12:55, Shane Kerr wrote:
This seems like the most non-controversial document ever in the history
of documents.
A non-controversial DNS doc at the IETF? That'll be a first. :-)
Well, I am sure some nit-picking can be organised. As well as
On Wed, May 15, 2019 at 2:06 PM John Dickinson wrote:
> Hi,
>
> In the spirit of deprecating things I have submitted a draft to deprecate
> the status opcode.
>
> A new version of I-D,
> draft-dickinson-dnsop-deprecating-status-opcode-00.txt
> has been successfully submitted by John Dickinson
Hi John
On Wed, May 15, 2019 at 11:06:03AM +0100, John Dickinson wrote:
> Hi,
>
> In the spirit of deprecating things I have submitted a draft to deprecate the
> status opcode.
In your support, there's atleast the "precedence" RFC deprecating
IQUERY. :)
Mukund
On Wed, May 15, 2019 at 01:55:48PM +0200, Shane Kerr wrote:
> John,
>
> On 15/05/2019 12.06, John Dickinson wrote:
> > In the spirit of deprecating things I have submitted a draft to deprecate
> > the status opcode.
>
> This seems like the most non-controversial document ever in the history of
On 15 May 2019, at 13:01, Joe Abley wrote:
> On 15 May 2019, at 07:55, Shane Kerr wrote:
>
>> On 15/05/2019 12.06, John Dickinson wrote:
>>> In the spirit of deprecating things I have submitted a draft to deprecate
>>> the status opcode.
>>
>> This seems like the most non-controversial document
On 15 May 2019, at 07:55, Shane Kerr wrote:
> On 15/05/2019 12.06, John Dickinson wrote:
>> In the spirit of deprecating things I have submitted a draft to deprecate
>> the status opcode.
>
> This seems like the most non-controversial document ever in the history of
> documents.
:-)
Can
> On 15 May 2019, at 12:55, Shane Kerr wrote:
>
> This seems like the most non-controversial document ever in the history of
> documents.
A non-controversial DNS doc at the IETF? That’ll be a first. :-)
___
DNSOP mailing list
DNSOP@ietf.org
John,
On 15/05/2019 12.06, John Dickinson wrote:
In the spirit of deprecating things I have submitted a draft to deprecate the
status opcode.
This seems like the most non-controversial document ever in the history
of documents.
Cheers,
--
Shane
Hi,
In the spirit of deprecating things I have submitted a draft to deprecate the
status opcode.
A new version of I-D, draft-dickinson-dnsop-deprecating-status-opcode-00.txt
has been successfully submitted by John Dickinson and posted to the
IETF repository.
Name:
On Tue, May 14, 2019 at 10:32 AM zuop...@cnnic.cn wrote:
>
> configure several CNAME records to use multi-CDN service is also widely used
> in industry, though this is not allowed by DNS standards.
> shall we support this on protocal level? like defining new CNAMEx record
> which contains
18 matches
Mail list logo
