> On 14 Dec 2017, at 11:31 am, Joe Abley wrote:
>
> Hi Ted,
>
>> On Dec 13, 2017, at 17:14, Ted Lemon wrote:
>>
>> Can you point to the actual ambiguity? The reason we said "one or more
>> black hole servers" was to leave it up to the operator of .arpa to decide
>> which black hole server
On Dec 13, 2017, at 7:31 PM, Joe Abley wrote:
> The ambiguity is (for example) that "point to" is not a well-defined phrase,
> given that we have two documented ways of doing this in the AS112 project,
> and neither is "black hole server" which from the examples seems it refers to
> servers mad
From: Lanlan Pan
Date: 2017-12-13 18:25
To: Stephane Bortzmeyer
CC: zuop...@cnnic.cn; dnsop; bert hubert
Subject: Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling
Stephane Bortzmeyer 于2017年12月13日周三 下午5:58写道：
On Wed, Dec 13, 2017 at 05:31:06PM +0800,
zuop...@cnnic.cn wro
Hi Mark,
[I'm typing this on a phone. It's going to look horrible in a real
mail client. Sorry about that.]
On Dec 13, 2017, at 20:19, Mark Andrews wrote:
> Looks like we need to open a ticket for those. But the ones people actually
> have internal zones in are correct. Check the RFC 1918 de
Looks like we need to open a ticket for those. But the ones people actually
have internal zones in are correct. Check the RFC 1918 delegations. I know
these started out being delegated to blackhole servers before the parent zones
were signed by this isn’t rocket science.
[rock:bin/tests/syst
Hi Mark,
> On Dec 13, 2017, at 17:09, Mark Andrews wrote:
>
> Section 7 says:
Yes, I know. I read it.
> RFC 6303 has similar requirements and IANA was able to co-ordinate those
> delegation.
Apart from the zones originally delegated to the AS112 project, I couldn't find
a zone specified in
Hi Ted,
> On Dec 13, 2017, at 17:14, Ted Lemon wrote:
>
> Can you point to the actual ambiguity? The reason we said "one or more
> black hole servers" was to leave it up to the operator of .arpa to decide
> which black hole servers and how many of them. That was a deliberate
> choice, not
feels like a concrete example in a.b.c.example.com terms would help
define both in-baliwick, and out-of-baliwick, for the cases.
On Wed, Dec 13, 2017 at 9:42 PM, wrote:
> Thanks.
>
> terminology-bis-08:
> | In-bailiwick: An adjective to describe a name server whose name is
> |either subordin
On Dec 13, 2017, at 4:46 PM, Joe Abley wrote:
> The document actually specifies quite clearly that the delegation "MUST NOT
> include a DS record" which seems to be different from what you are saying. It
> also specifies that the delegation "MUST point to one or more black hole
> servers", whic
Section 7 says:
"In order to be fully functional, there must be a delegation of 'home.arpa' in
the '.arpa' zone [RFC3172]. This delegation MUST NOT be signed, MUST NOT
include a DS record, and MUST point to one or more black hole servers, for
example BLACKHOLE-1.IANA.ORG and BLACKHOLE-2.IANA.OR
On 11 Dec 2017, at 19:50, Ted Lemon wrote:
> On Dec 11, 2017, at 11:17 AM, Joe Abley wrote:
>> Note though that the homenet document specifically requests a delegation.
>
> Please do not read more into the document than was intended. What Mark is
> saying looks to me like an accurate represe
Thanks.
terminology-bis-08:
| In-bailiwick: An adjective to describe a name server whose name is
|either subordinate to or (rarely) the same as the zone origin.
Ok, In-bailwick in terminology-bis-08 may be restrictive because "the
zone origin" is unclear. I intended that "the zone origin" is
On Mon, Dec 11, 2017 at 03:16:46PM -0800,
Kim Davies wrote
a message of 22 lines which said:
> the delegation to AS112 was considered as the best short-term
> approach even if it is not without its own difficulties.
Interesting information, thanks.
But the original question was about privacy
Stephane Bortzmeyer 于2017年12月13日周三 下午5:58写道：
> On Wed, Dec 13, 2017 at 05:31:06PM +0800,
> zuop...@cnnic.cn wrote
> a message of 130 lines which said:
>
> > (2) RFC2782 requires browser's support;
>
> Client support. This is even worse, there are much more HTTP clients
> than browsers.
>
> >
On Wed, Dec 13, 2017 at 05:31:06PM +0800,
zuop...@cnnic.cn wrote
a message of 130 lines which said:
> (2) RFC2782 requires browser's support;
Client support. This is even worse, there are much more HTTP clients
than browsers.
> Using this method, a browser has no idea about weighted AX/A
On Wed, Dec 13, 2017 at 05:36:32PM +0800, zuop...@cnnic.cn wrote:
> so far as i know, many CDNs already use similar methods as you mentioned in
> PowerDNS 4.1.1
> but i think only the Authoritative Server change is not enough, support
> on the recursive server is also very important .
> b
On Wed, Dec 13, 2017 at 09:18:23AM +0100, Stephane Bortzmeyer wrote:
> > For example, a CDN provider can’t schedule 70% of traffic to node A
> > and 30% of traffic to node B [...] adding a “weight” attribute
>
> First, the obvious question: why reinventing RFC 2782?
Implementing this worthwh
> From: bert hubert
> 3) Serve up multiple copies of the same A record, and weigh like this:
> www IN A 1.2.3.4
> www IN A 1.2.3.4
> www IN A 10.11.12.13
> And hope that record shuffling will deliver the 2:1 ratio
Same RDATA is not allowed by RFC 2181.
| 5. Resource Record Sets
|
| Each DNS Re
thanks for your comments!
According to my understanding, here are 2 main differences between RFC2782 and
this idea :
(1) RFC2782 does not solve the problem of using multi-CDN (multiple CNAME
cannot coexist);
here we can use multipile weighted CNMAEXs (need to coexist with CNAME) to
accomp
On Wed, Dec 13, 2017 at 09:18:23AM +0100, Stephane Bortzmeyer wrote:
> > For example, a CDN provider can’t schedule 70% of traffic to node A
> > and 30% of traffic to node B [...] adding a “weight” attribute
>
> First, the obvious question: why reinventing RFC 2782?
Implementing this worthwhile
On Wed, Dec 13, 2017 at 03:40:50PM +0800,
zuop...@cnnic.cn wrote
a message of 1343 lines which said:
> For example, a CDN provider can’t schedule 70% of traffic to node A
> and 30% of traffic to node B [...] adding a “weight” attribute
First, the obvious question: why reinventing RFC 2782?
21 matches
Mail list logo
