A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations Working Group
of the IETF.
Title : DNS query name minimisation to improve privacy
Author : Stephane Bortzmeyer
Tim Wicinski wrote:
>
> This starts a Working Group Last Call for draft-ietf-dnsop-5966bis
I have re-read the draft and it looks good to me.
A couple of suggestions for section 7:
For the avoidance of future doubt, this requirement is clarified.
Authoritative servers and recursive resolve
> On 10 Oct 2015, at 17:34, Stephane Bortzmeyer wrote:
>
Joe, Stephane, (and I just saw Tim too)
Many thanks for the detailed reviews.
>
> In the mean time, the issue I see is in section 7 "Since pipelined
> responses can arrive out-of-order, clients MUST match responses to
> outstanding que
On Mon, Oct 12, 2015 at 01:09:38PM +0100,
sara wrote
a message of 107 lines which said:
> So under normal circumstances matching on just the Message ID should
> be sufficient for TCP, which was the reason the QCLASS+QNAME+QTYPE
> part was removed when changing the ‘must' here to ‘MUST' in the
> On 12 Oct 2015, at 13:36, Stephane Bortzmeyer wrote:
>
> On Mon, Oct 12, 2015 at 01:09:38PM +0100,
> sara wrote
> a message of 107 lines which said:
>
>> So under normal circumstances matching on just the Message ID should
>> be sufficient for TCP, which was the reason the QCLASS+QNAME+QTYP
I spent some time reviewing this document and I have one point I would
like some clarification on,
is there any supporting documentation that outlines recommendations on
how a recursive server can identify expected clients?
"Operators of recursive servers are advised to ensure that they only
ac
Visweswaran, Gowri wrote:
> I spent some time reviewing this document and I have one point I would
> like some clarification on, is there any supporting documentation that
> outlines recommendations on how a recursive server can identify expected
> clients?
Do you mean something like http://www.
Hi Tony,
I was looking for guidelines similar to the link you sent below in an IETF
document,
and if anyone knows of any other documentation on the policies of the
current major recursive servers.
Gowri
On 10/12/15, 9:49 AM, "Tony Finch" wrote:
>Visweswaran, Gowri wrote:
>
>> I spent some tim
On Mon, Oct 12, 2015 at 01:23:27PM +,
Visweswaran, Gowri wrote
a message of 51 lines which said:
> is there any supporting documentation that outlines recommendations
> on how a recursive server can identify expected clients?
Don't think it is written down somewhere. The most common metho
Visweswaran, Gowri wrote:
>
> I was looking for guidelines similar to the link you sent below in an
> IETF document,
There isn't anything AFAIK. Even the Open Resolver Project doesn't have
any helpful guidance, as I thought it might.
> and if anyone knows of any other documentation on the
> poli
For de-multiplexing the responses off the socket the *only* field
you should be using is the ID field. There are error conditions
that result in only the DNS header being returned. All responses
are *supposed* to be constucted in the DNS. Setting rcode to
formerr/notimp and setting qr to 1 does
New text added following review by Evan Hunt (on this list) and David
Lawrence (at dns-oarc in Montréal, I think).
Forwarded message:
From: internet-dra...@ietf.org
To: Marek Majkowski , Joe Abley
, Olafur Gudmundsson
Subject: New Version Notification for
draft-jabley-dnsop-refuse-any-01.tx
12 matches
Mail list logo
