Sent from my iPhone
> On Mar 22, 2016, at 00:16, Stuart Cheshire wrote:
>
>> On 21 Mar 2016, at 20:02, Paul Wouters wrote:
>>
>> Our document is in AUTH48 already, so making those kind of changed there
>> might be very difficult.
>
> I didn’t realise that. I agree, it’s too late to make su
On 21 Mar 2016, at 20:02, Paul Wouters wrote:
> Our document is in AUTH48 already, so making those kind of changed there
> might be very difficult.
I didn’t realise that. I agree, it’s too late to make substantive changes at
this point.
> Also, if you are so idle that you might run into tcp i
Our document is in AUTH48 already, so making those kind of changed there might
be very difficult.
Also, if you are so idle that you might run into tcp issues timing out, you
probably should be nice to the other end and close your tcp session.
Sent from my iPhone
> On Mar 21, 2016, at 22:54, St
Dear Keepalive authors,
Draft-ietf-dnssd-push-06 (see below) references
draft-ietf-dnsop-edns-tcp-keepalive.
However, at present, a more accurate title might be
“draft-ietf-dnsop-edns-tcp-idle-timeout” instead of
“draft-ietf-dnsop-edns-tcp-keepalive”, because while it tells the client how to
George Michaelson wrote:
What did I mis-understand? The APNIC 1x1 is a random sample over
users, and it sees significantly more than 75% EDNS0. More like 93%.
by query volume, or by rdns ip?
By query volume. And, we're at authority where I suspect you see the edge.
Once the query is covere
On Tue, Mar 22, 2016 at 12:07 PM, Paul Vixie wrote:
>
>
> George Michaelson wrote:
>>
>> I'm confused. DO bit implies EDNS0, and we think DO bit in the field
>> is north of 75%.
>>
>> What did I mis-understand? The APNIC 1x1 is a random sample over
>> users, and it sees significantly more than 75%
George Michaelson wrote:
I'm confused. DO bit implies EDNS0, and we think DO bit in the field
is north of 75%.
What did I mis-understand? The APNIC 1x1 is a random sample over
users, and it sees significantly more than 75% EDNS0. More like 93%.
by query volume, or by rdns ip?
--
P Vixie
__
I'm confused. DO bit implies EDNS0, and we think DO bit in the field
is north of 75%.
What did I mis-understand? The APNIC 1x1 is a random sample over
users, and it sees significantly more than 75% EDNS0. More like 93%.
-George
On Tue, Mar 22, 2016 at 11:55 AM, Paul Vixie wrote:
>
>
> Mark Andr
Mark Andrews wrote:
In message,
=?UTF-8?Q?Marek_Vavru=C5=A1a?= writes:
I see the point but I don't really want to go down the EDNS route.
Why not? It is cleaner as it deals with A-only, A and , and
-only sites without a second lookup once support is deployed.
It is supportable on a
At Tue, 22 Mar 2016 01:15:48 +0530,
Mukund Sivaraman wrote:
> > > (1) Section 7.2.1. Authoritative Nameserver:
> > I'm confused about the revised Section 7.2.1 regarding overlapping
> > prefixes. The 07 version of the draft now states:
> >
> >[...] Because it can't be guaranteed that quer
On Mon, 21 Mar 2016, Marek Vavruša wrote:
What happens with the Answer Count for QTYPE=A when there are no A
records and only records? And can the examples also clarify this?
That's an example 5.3
The use case is, but I still have no idea what the ANCOUNT should
be. Neither t
In message
,
=?UTF-8?Q?Marek_Vavru=C5=A1a?= writes:
>
> I see the point but I don't really want to go down the EDNS route.
Why not? It is cleaner as it deals with A-only, A and , and
-only sites without a second lookup once support is deployed.
It is supportable on a hop by hop basis.
I see the point but I don't really want to go down the EDNS route.
So presuming that this draft catches on and Alexa 1M NSs publish at least
one record,
there would be no need for two queries in most cases and no need for
additional signalisation.
If they don't publish records, then the r
On Mon, Mar 21, 2016 at 5:14 PM, Paul Wouters wrote:
> On Mon, 21 Mar 2016, Marek Vavruša wrote:
>
> there was an interest in reducing latency for address record lookups. Me
>> and Olafur wrote a draft on adding records to A answers and treating
>> them as authoritati
>> ve. This fixes laten
Or we could defined the "aaa" (A and ) {E}DNS bit where the
server guarantees that the response contains both the A and
answers for A or queries if aaa=1 in the response.
Recursive servers would lookup A/ records if cache is missing
them before returning a response.
If the A /
Who wants to get rid of A lookups? "A" is going to be here for a while and
using it as a generic mean to get all addresses of given protocol
(regardless of version) gives servers a way to smoothly transition over
versions.
If the A was updated to have a variable address length, then it could be
use
On Tue, 22 Mar 2016, Mark Andrews wrote:
Well we really want to get rid of A lookups. Why don't we just
recommend that we publish mapped A records in RRsets and have
master servers update RRsets if they are inconsitent with the
A RRsets.
We also need a way to signal that there are n
On Mon, 21 Mar 2016, Marek Vavruša wrote:
there was an interest in reducing latency for address record lookups. Me and
Olafur wrote a draft on adding records to A answers and treating them as
authoritati
ve. This fixes latency issues with NS A/ discovery in resolvers and
improves cac
Marek Vavruša wrote:
...
https://datatracker.ietf.org/doc/draft-vavrusa-dnsop--for-free/
+1. we ought to have done this from the get-go.
--
P Vixie
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Well we really want to get rid of A lookups. Why don't we just
recommend that we publish mapped A records in RRsets and have
master servers update RRsets if they are inconsitent with the
A RRsets.
We also need a way to signal that there are no A records in the
RRset. :::255.
Hi,
there was an interest in reducing latency for address record lookups.
Me and Olafur wrote a draft on adding records to A answers and
treating them as authoritative. This fixes latency issues with NS
A/ discovery in resolvers and improves caching for clients (
already cached by the
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 of the IETF.
Title : DNSSEC Roadblock Avoidance
Authors : Wes Hardaker
Olafur Gudmundsson
Dear colleagues,
Thanks for the many helpful comments. I've updated the DNS Is Not
Classy I-D to close the registry. The new draft is at
https://datatracker.ietf.org/doc/draft-sullivan-dns-class-useless/.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
Hi Jinmei
On Mon, Mar 21, 2016 at 11:38:35AM -0700, 神明達哉 wrote:
> At Mon, 21 Mar 2016 19:21:59 +0530,
> Mukund Sivaraman wrote:
>
> > (1) Section 7.2.1. Authoritative Nameserver:
> >
> > > When deaggregating to correct the overlap, prefix lengths should be
> > > optimized to use the minimum nec
DNSOP members,
Today a group of us submitted a draft starting to document the operational
steps (and issues) around deploying new crypto algorithms within DNSSEC. This
builds off of a couple of sessions we've had at DNSSEC Workshops at ICANN
meetings as well as various mailing list discussion.
At Mon, 21 Mar 2016 19:21:59 +0530,
Mukund Sivaraman wrote:
> (1) Section 7.2.1. Authoritative Nameserver:
>
> > When deaggregating to correct the overlap, prefix lengths should be
> > optimized to use the minimum necessary to cover the address space, in
> > order to reduce the overhead that res
Davey,
Thanks! Some expanded comments from me, inline below...
At 2016-03-21 18:43:02 +0800
Davey Song wrote:
> We have updated the draft as follows:
>
> * fixed typos
> * made "transport:" always required
We had it implicitly optional if a client was using the protocol
directly (rather than
On Mon, 21 Mar 2016, Rose, Scott wrote:
This draft should also serve to obsolete RFC 6944.
Just submitted -01 which does that, and also adjusts the levels for GOST
and ECDSAP384SHA384.
https://tools.ietf.org/rfcdiff?url2=draft-wouters-sury-dnsop-algorithm-update-01.txt
https://tools.ietf.org
Shane,
Yes. The chairs fondly hope that the WG will be able to adopt a problem
statement in the near future, which will in turn make it a bit easier to
explain what problem alt-tld is solving when we look for WG and IETF
consensus on it.
Suzanne
On 3/21/16 11:05 AM, Shane Kerr wrote:
Warr
Warren,
So, um... what's the status here? Is this basically just on hold
waiting for RFC 6761 movement? Or...?
Cheers,
--
Shane
At 2016-03-21 14:35:08 +
Warren Kumari wrote:
> Nothing to see here, move along.
>
> (this is just a version bump to keep it alive - sorry)
> W
> On Mon, Mar 21
Nothing to see here, move along.
(this is just a version bump to keep it alive - sorry)
W
On Mon, Mar 21, 2016 at 10:31 AM wrote:
>
> 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 of the IETF.
>
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 of the IETF.
Title : The ALT Special Use Top Level Domain
Authors : Warren Kumari
Andrew Sulli
On Sat, Mar 19, 2016 at 10:57 AM, Paul Hoffman
wrote:
> On 19 Mar 2016, at 10:51, internet-dra...@ietf.org wrote:
>
> 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 of the
>> IETF.
>>
>>
This draft should also serve to obsolete RFC 6944.
Scott
On 19 Mar 2016, at 15:43, Paul Wouters wrote:
> Hi,
>
> there was an interest in deprecating some DNSSEC related algorithms.
> Ondrey and I wrote a draft that tries to introduce and depricate
> DNSSEC algorithms similar to how it has been
Hi all
On Mon, Mar 21, 2016 at 06:08:39AM -0700, internet-dra...@ietf.org wrote:
> 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 of the IETF.
>
> Title : Client Subnet in DNS Qu
Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-edns-client-subnet-07: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Pleas
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 of the IETF.
Title : Client Subnet in DNS Queries
Authors : Carlo Contavalli
Wilmer van der Ga
We have updated the draft as follows:
* fixed typos
* made "transport:" always required
* mentioned the possibility to use DNS over HTTP in a browser, if you
really want to
* made the language stronger when talking about the 2-byte length label in
TCP
* expanded the security considerations. We go
38 matches
Mail list logo
