Hi all,
Enlightened by Workshop on DNS Future Root Service Architecture in Hongkong,
Dec,2014, we submitted a draft about the DNS cache survey in China.
We hope the survey results may provide some useful information to better
understand the current cache service model.
https://tools.ietf.org
In message , Edward Lewis writes:
>
> On 2/24/15, 17:47, "Mark Andrews" wrote:
> >
> >delegation-centric - a zone which consists mostly of delegations to child
> >zones.
> >the root zone and the com zone are examples of delegation-centric zones.
>
> Not arguing, but to raise a point - my response
On 2/24/15, 17:47, "Mark Andrews" wrote:
>
>delegation-centric - a zone which consists mostly of delegations to child
>zones.
>the root zone and the com zone are examples of delegation-centric zones.
Not arguing, but to raise a point - my response was “all” and Mark’s is
“most.”
There’s a subtly
Delegation centric - for all labels below the apex, each owns an NS set.
(I.e., each is a cut point.)
I’ve never heard the other terms, have no idea what they’d mean (out of
context).
On 2/24/15, 17:21, "Paul Hoffman" wrote:
>Greetings again. People have asked us to define "delegation-centric",
In message , Paul Hoffman writes:
> Greetings again. People have asked us to define "delegation-centric",
> "child-cent
> ric", and "parent-centric" for draft-hoffman-dns-terminology. None of them
> are de
> fined in RFCs, even though "delegation-centric" appears in RFCs 4956, 5155,
> and 7
> 1
Greetings again. People have asked us to define "delegation-centric",
"child-centric", and "parent-centric" for draft-hoffman-dns-terminology. None
of them are defined in RFCs, even though "delegation-centric" appears in RFCs
4956, 5155, and 7129. The terms are used in various places, so they se
On Tue, Feb 24, 2015 at 3:28 PM, Andrew Sullivan
wrote:
> On Tue, Feb 24, 2015 at 12:06:06PM -0800, Joel Jaeggli wrote:
> > Should we consider recommendations with respect to treatment of logging
> or storage of queries or the extent to which such queries should be
> protected?
> >
>
> IMO, No.
On 2/24/15 12:28 PM, Andrew Sullivan wrote:
> On Tue, Feb 24, 2015 at 12:06:06PM -0800, Joel Jaeggli wrote:
>> Should we consider recommendations with respect to treatment of logging or
>> storage of queries or the extent to which such queries should be protected?
>>
>
> IMO, No. The text as it
On Tue, Feb 24, 2015 at 12:06:06PM -0800, Joel Jaeggli wrote:
> Should we consider recommendations with respect to treatment of logging or
> storage of queries or the extent to which such queries should be protected?
>
IMO, No. The text as it stands says, "This could result in logs."
There are
Working group,
I would direct your attention to the current discuss, here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc6304bis/ballot/
Should we consider recommendations with respect to treatment of logging or
storage of queries or the extent to which such queries should be protected?
In message
<49dee35910f1a6438e9805f4debba3070aee3...@038-ch1mpn1-042.038d.mgd.msft.
net>, "Darcy Kevin (FCA)" writes:
> "Asynchronous" makes no sense to me. In what way is an AXFR "asynchronous"?
>
> "Authoritative transfer"? As opposed to what? Non-authoritative transfer?
> "Author
> itative"
On Jan 20, 2015, at 7:56 AM, Declan Ma wrote:
> As for 'DNS Servers', I think we should set aside space for 'Cache-only DNS
> Server' which is pervasive in all kinds of DNS document.
Can you clarify what you think a "cache-only DNS server" is? I'm not seeing how
a server can be cache-only with
On 2/24/15, 12:07, "Shumon Huque" wrote:
> I thought that was clear
> from my earlier paragraph that you didn't quote
Proves that I only read what I want to read. ;)
I didn’t think you seriously wanted to borrow the shovel.
smime.p7s
Description: S/MIME cryptographic signature
_
> Or should A in AXFR be something else, like "Absolute", or "All" or
> "All-Data" which might more correctly differentiate it from
"Incremental".
>
>
> Seriously - in operations land, "what you call something" isn’t as
important as the term’s definition being clear and common.
>
I agree,
On 2/24/15, 11:33, "Shumon Huque" wrote:
> Hmm, does this imply that IXFR is a transfer of data that it not
> authoritative? :-) Or does it need to be renamed to IAXFR.
I have a shovel out back, want to borrow it?
> Or should A in AXFR be something else, like "Absolute", or "All" or
> "All-Data"
Paul Vixie:
>
> however, AXFR was never an acronym, and there is no original meaning
> to be discovered here. in [RFC1035 3.2.3] there is one line of text:
>
> > AXFR252 A request for a transfer of an entire zone
>
>
> and it's the definition of the QTYPE, not the overall transaction th
On Tue, Feb 24, 2015 at 03:08:56PM +, Edward Lewis wrote:
> Okay, before getting too silly on this, IDNA is a convention for
> representing identifiers in non-ascii/latin scripts into DNS labels, for
> the purpose of restricting what can be registered to prevent confusion.
I think that missta
On 2/23/15, 2:52, "Patrik Fältström" wrote:
>
>> On 22 feb 2015, at 20:58, Paul Hoffman wrote:
>>
>> As for Måns original question: converting wire-format IDNA to some
>>encoding of Unicode characters is unstable because some registries use
>>IDNA2003 rules, others use IDNA2008 rules, and some
Sorry, I was reading the mail list asynchronously and found this after I
sent my note on 5936.
;)
On 2/23/15, 10:09, "Paul Hoffman" wrote:
>The relevant RFC, 5936, says that the mnemonic means "Authoritative
>Transfer", both in the abstract and introduction.
>
>--Paul Hoffman
>_
And there’s http://www.rfc-editor.org/rfc/rfc5936.txt. It has
"Authoritative Transfer (AXFR)” in the abstract.
“Asynchronous" does not appear in that RFC.
(In the “not that it matters, but” file: When we had singly threaded name
servers, AXFR wasn’t very asynchronous in practice.)
(Sorry, I can
20 matches
Mail list logo