On Thu, Mar 12, 2015 at 11:38:04PM +, Darcy Kevin (FCA) wrote:
> So you're thinking it's more likely that we'll get folks to understand
> this new type, that's designed to frustrate QTYPE=* queries in a
> more-or-less graceful way, than it is to convince them to stop making
> QTYPE=* queries in
So you're thinking it's more likely that we'll get folks to understand this new
type, that's designed to frustrate QTYPE=* queries in a more-or-less graceful
way, than it is to convince them to stop making QTYPE=* queries in the first
place?
Don't get me wrong -- I would actually *applaud* the
In message <3d558422-d5da-4434-bded-e752ba353...@flame.org>, Michael Graff
writes:
> What problem are we specifically trying to solve here again?
A non-problem for most of us.
> Michael
If one really wants to reduce the number of packets required with
SMTP processibg just write a RFC that says
On Mar 12, 2015, at 10:59 AM, Tony Finch wrote:
>
> Patrik Wallström wrote:
>>
>> Glue Name Records are defined as all NS records pertaining to the child
>> domain that are delivered by the nameservers for the parent domain.
>>
>> Glue Address Records are all A or records pertaining to th
Patrik Wallström wrote:
>
> Glue Name Records are defined as all NS records pertaining to the child
> domain that are delivered by the nameservers for the parent domain.
>
> Glue Address Records are all A or records pertaining to the child
> domain that are delivered by the nameservers for th
On 12 Mar 2015, at 16:27, Paul Hoffman wrote:
> On Mar 12, 2015, at 5:07 AM, Niall O'Reilly wrote:
>> In http://www.ietf.org/id/draft-hoffman-dns-terminology-02.txt,
>> "glue" is defined as follows.
>>
>> Glue records -- Resource records which are not part of the
>> authoritative data, and a
* Tony Finch:
> I also tried a stupid hack to send an ANY RR in the response. BIND's
> resolver treats this as a FORMERR and returns SERVFAIL to the client.
What about introducing a new non-meta RR type for this purpose? It
would not increase the response size by much.
_
* Olafur Gudmundsson:
> Title: Standard way for Authoratitive DNS servers to refuse ANY
NOTIMP doesn't do that, it tells resolvers to query another name
server for the zone. The authoriative server part of this proposal
increases the number of upstream ANY queries instead of reducing th
* Ted Lemon:
> On Mar 8, 2015, at 6:31 PM, Ralf Weber wrote:
>> I was told that the difference is that a security aware resolver does
>> not validate, but instead relies on the "Validating Stub Resolver" to
>> protect the user. So it would handle all the DNSSEC processing to the
>> authoritative
Packet size is harder to analyze. ANY often pulls some records that
aren't used, and if the site isn't configured carefully then ANY can
even end up falling back to TCP, costing bytes _and_ packets. On the
other hand, there are a huge number of Internet sites that don't have a
noticeable volume of
On Mar 12, 2015, at 5:07 AM, Niall O'Reilly wrote:
> In http://www.ietf.org/id/draft-hoffman-dns-terminology-02.txt,
> "glue" is defined as follows.
>
> Glue records -- Resource records which are not part of the
> authoritative data, and are address resource records for the servers
> list
On Mar 12, 2015, at 7:47 AM, Phillip Hallam-Baker wrote:
>
>
>
> On Thu, Mar 12, 2015 at 10:42 AM, Paul Hoffman wrote:
> On Mar 12, 2015, at 6:53 AM, Phillip Hallam-Baker
> wrote:
> > Its a bug in the spec.
>
> The terminology document is the wrong place to deal with bugs in the spec. We
>
On Thu, Mar 12, 2015 at 10:42 AM, Paul Hoffman
wrote:
> On Mar 12, 2015, at 6:53 AM, Phillip Hallam-Baker
> wrote:
> > Its a bug in the spec.
>
> The terminology document is the wrong place to deal with bugs in the spec.
> We are happy to list differences of opinion about what a term means if th
On Mar 12, 2015, at 6:53 AM, Phillip Hallam-Baker wrote:
> Its a bug in the spec.
The terminology document is the wrong place to deal with bugs in the spec. We
are happy to list differences of opinion about what a term means if they appear
in different RFCs, but not to try to fix bugs.
--Paul
Its a bug in the spec.
Glue records should never have existed and they have caused nothing but
implementation confusion.
I understand the reasons why people imagine they are justified. But a
mistake is still a mistake.
At this point we cannot get rid of them.
___
I guess glue in the scope of the zone data may be a proper subset of glue in
the scope of "the message". What if zone A has the name server's name "below"
the cut fall in the bailiwick of zone B, and both zones are hosted in one
authoritative name server? If that authoritative name server is al
Paul Wouters writes:
> So if the MX or record has expired from the cache but another
> RRtype with larger TTL (say NS) is still in there, your ANY query will
> fail to find records.
The client is behaving correctly. The ANY query isn't guaranteed to find
the MX, but you're wrong in claiming t
On 3/12/15, 6:31, "Florian Weimer" wrote:
>And does anyone actually use opt out with NSEC3?
Currently twenty-one TLDs use NSEC3 with 0 iterations and no salt.
Nineteen more use no salt with more than 1 iteration.
That's just a count of what's in the root zone delegations. I haven't
asked if th
Hi.
In http://www.ietf.org/id/draft-hoffman-dns-terminology-02.txt,
"glue" is defined as follows.
Glue records -- Resource records which are not part of the
authoritative data, and are address resource records for the servers
listed in the message. They contain data that allows ac
On 03/12/2015 11:36 AM, Jan Včelák wrote:
>> And does anyone actually use opt out with NSEC3?
>
> Yes, .com for example. My impression was that Opt-Out was the selling point
> of
> NSEC3, not the domain name hashing.
Okay. Are they interested in switching to NSEC5?
--
Florian Weimer / Red H
On Thu, Mar 12, 2015 at 7:14 AM, Niall O'Reilly
wrote:
> On Wed, 11 Mar 2015 16:50:07 +,
> Paul Hoffman wrote:
> >
> > >> I'd prefer the simpler "The problem statement is described in ..".
> > >> The term "exposed" in my mind carries a more sensational connotation,
> > >> but I might be nitpi
On Wed, 11 Mar 2015 16:50:07 +,
Paul Hoffman wrote:
>
> >> I'd prefer the simpler "The problem statement is described in ..".
> >> The term "exposed" in my mind carries a more sensational connotation,
> >> but I might be nitpicking.
> >
> > Advice from english writers here?
>
> +1 to Shumon:
On Thursday, March 12, 2015 11:31:37 AM Florian Weimer wrote:
> On 03/12/2015 11:15 AM, Jan Včelák wrote:
> > On Wednesday, March 11, 2015 09:52:55 AM Nicholas Weaver wrote:
> >> Why not just do something simpler? The only thing NSEC5 really differs
> >> in a way that counts is not in the NSEC rec
On 03/12/2015 11:15 AM, Jan Včelák wrote:
> On Wednesday, March 11, 2015 09:52:55 AM Nicholas Weaver wrote:
>> Why not just do something simpler? The only thing NSEC5 really differs in a
>> way that counts is not in the NSEC record but really just the DNSKEY
>> handling, having a separate key used
On Wednesday, March 11, 2015 10:02:31 AM Paul Hoffman wrote:
> Proposal: until there is evidence that there is a community that needs the
> features of NSEC5 that cannot be easily replicated in NSEC3, this WG does
> not consider a protocol change that would require every resolver to be
> updated.
On Wednesday, March 11, 2015 09:52:55 AM Nicholas Weaver wrote:
> Why not just do something simpler? The only thing NSEC5 really differs in a
> way that counts is not in the NSEC record but really just the DNSKEY
> handling, having a separate key used for signing the NSEC* records.
>
> So why def
On Wed, Mar 11, 2015 at 04:39:19PM +, Tony Finch wrote:
> I did a quick test consisting of:
>
> dig any non.terminal # initially empty
> (echo 'update add non.terminal 3600 in txt "braaains"';
> echo send) | nsupdate -l
> dig txt non.terminal
Thank you for being rigorous and running the test
> On Mar 11, 2015, at 9:39 AM, Jan Včelák wrote:
>
> NSEC5 proof is the FDH of domain name.
> NSEC5 hash is SHA-256 of NSEC5 proof.
>
> I will clarify that.
Why not just do something simpler? The only thing NSEC5 really differs in a
way that counts is not in the NSEC record but really just t
On Mar 11, 2015, at 9:02 AM, Stephane Bortzmeyer wrote:
>
> On Wed, Mar 11, 2015 at 12:35:29AM -0400,
> Shumon Huque wrote
> a message of 400 lines which said:
>
>> Are we standardizing on the british spelling of "minimisation" in
>> preference to the americanized "minimization"?
>
> Bikeshed
tl;dr:
I am thinking of the "principle of least surprise", for the use case of
interactive "dig" users.
Here's why:
Asking ANY to a recursive resolver, the expected behavior is "whatever is
in the cache" (which could be a subset of the real RRsets, and possibly
empty even though RRs exist on corre
On Wed, Mar 11, 2015 at 12:35:29AM -0400,
Shumon Huque wrote
a message of 400 lines which said:
> Are we standardizing on the british spelling of "minimisation" in
> preference to the americanized "minimization"?
Bikeshedding is postponed until Working Group Last Call :-)
> I'd prefer the si
On Wed, Mar 11, 2015 at 12:35 AM, Shumon Huque wrote:
> ...
>
> One thing this document doesn't make clear is that the algorithm
> being presented not only minimizes the query name, but also hides
> the query type until it reaches the target zone (by using the NS
> query type rather than the actu
On Mar 11, 2015, at 2:00 AM, Paul Vixie wrote:
> djb doesn't want QTYPE=ANY deprecated in any form.
>
> olafur doesn't want to "do_ANY", under any conditions.
>
> so i'm baffled by why you're offering this alternative?
Neither djb nor Olafur are automatically the consensus of this WG. None of u
Regarding the statement "query type ANY 'matches all RR types CURRENTLY IN THE
CACHE'."
Actually, there's nothing in RFC 1034 that clearly *mandates* this behavior --
Section 3.7.1 says only that a QTYPE of * "matches all RR types", whereas
Section 5.3.3 ("Algorithm") says to return "the answer
On Wed, Mar 11, 2015 at 12:13:42PM +, Tony Finch wrote:
> These are signed zones so the answer has to validate.
... they are? I thought the proposal was to restrict/deprecate
qtype=ANY for all zones, not just signed ones.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
_
35 matches
Mail list logo
