On Tue, May 27, 2014 at 09:30:57PM -0700, Doug Barton wrote:
> On a purely stylistic level I agree with you. :) However this signal
> would only have to be sent when requesting a zone transfer, and the
> extra 32 bits would be in the noise.
The direction of the wind being clear, I have redrafte
At Wed, 28 May 2014 12:57:55 -0400,
Ted Lemon wrote:
> What you are proposing is essentially a management function, not a
> naming function. Using the DNS to provide that function can work,
> and may even make sense in some cases, but I don't think it's the
> right thing to do from an architectur
On May 28, 2014, at 12:39 PM, Evan Hunt wrote:
> But another way of saying that is: "software exists that kluges around
> this lacuna in the DNS feature set", which doesn't mean it isn't a
> lacuna.
Sure, but you could also say that IP leaves out the feature of supporting
streaming, and that TCP
On Wed, May 28, 2014 at 12:20:26PM -0400, Ted Lemon wrote:
> These are all examples of things that are ordinarily addressed by some
> kind of IPAM user interface.
True, for the first two, at least, and the third could be solved on
an implementation-specific basis by storing metadata outside the zo
- I don't think we should lose a bit from the header for this. If we just
discovered the "need" for this, it is not important enough to burn a bit on.
- EDNS0 seems fine for it, but it feels much more like a Meta type
--Paul Hoffman
___
DNSOP mailing l
On May 28, 2014, at 12:15 PM, Evan Hunt wrote:
> 1) In the places I've worked, there have often been emails going around
> asking who's in charge of a particular machine or a particular IP address,
> that information having apparently been misplaced since the machine was set
> up or the address al
> So not to put too fine a point on it, but where is the use case for this
> proposal? It seems like something that is more of someone's cool hack
> than a standard people ought to implement. What am I missing?
The first three I thought of when the Dan suggested the feature:
1) In the places
On 28 May 2014, at 16:33, Ted Lemon wrote:
> On May 28, 2014, at 9:25 AM, Joe Abley wrote:
>> Is the use case perhaps the ability to attack comment-like metadata
>
> Definitely a possibility. :)
Sorry, I've been teaching people at AfNOG about DNS and reflection attacks for
half the day :-)
On May 28, 2014, at 8:23 AM, Ted Lemon wrote:
> So not to put too fine a point on it, but where is the use case for this
> proposal? It seems like something that is more of someone's cool hack than
> a standard people ought to implement. What am I missing?
>
>
On May 28, 2014, at 9:25 AM, Joe Abley wrote:
> Is the use case perhaps the ability to attack comment-like metadata
Definitely a possibility. :)
> If this is really something that's mainly useful for BIND9, then you'd think
> a private RRType would suffice, similar to the use of TYPE65534 in
On 28 May 2014, at 15:23, Ted Lemon wrote:
> So not to put too fine a point on it, but where is the use case for this
> proposal? It seems like something that is more of someone's cool hack than
> a standard people ought to implement. What am I missing?
Is the use case perhaps the ability
So not to put too fine a point on it, but where is the use case for this
proposal? It seems like something that is more of someone's cool hack than a
standard people ought to implement. What am I missing?
___
DNSOP mailing list
DNSOP@ietf.org
https
On 05/27/2014 04:49 PM, Evan Hunt wrote:
On Tue, May 27, 2014 at 04:08:29PM -0700, Doug Barton wrote:
I'm interested in why you think a flag bit is more elegant than an
option, as I agree with Nicholas that the latter is preferable.
As with any argument that resorts to "elegance", it's a matte
On Tue, May 27, 2014 at 04:08:29PM -0700, Doug Barton wrote:
> I'm interested in why you think a flag bit is more elegant than an
> option, as I agree with Nicholas that the latter is preferable.
As with any argument that resorts to "elegance", it's a matter of
taste. A single bit, which is alre
On 05/27/2014 12:29 PM, Evan Hunt wrote:
One of our operations staff made what I thought was a clever suggestion
the other day: That it would be nice, from an operational standpoint,
to have a way to encode comments into a zone so that they wouldn't get
obliterated when a dynamic zone was dumped
[ Quoting in "Re: [DNSOP] NOTE RR type for
confid..." ]
On May 27, 2014, at 1:32 PM, Miek Gieben wrote:
[ Quoting in "[DNSOP] NOTE RR type for confidenti..." ]
http://www.ietf.org/internet-drafts/draft-hunt-note-rr-00.txt
Interesting idea!
What happens if a server get these records and
On May 27, 2014, at 1:32 PM, Miek Gieben wrote:
> [ Quoting in "[DNSOP] NOTE RR type for confidenti..." ]
>> One of our operations staff made what I thought was a clever suggestion
>> the other day: That it would be nice, from an operational standpoint,
>> to have a way to encode comments into
[ Quoting in "[DNSOP] NOTE RR type for confidenti..." ]
One of our operations staff made what I thought was a clever suggestion
the other day: That it would be nice, from an operational standpoint,
to have a way to encode comments into a zone so that they wouldn't get
obliterated when a dynamic
On Tue, May 27, 2014 at 12:57:01PM -0700, Nicholas Weaver wrote:
> Using an EDNS0 bit however, does not makes sense to me. Flag bits are
> rare and precious, while 16b option codes are not.
I was expecting this feedback, and am entirely prepared to redraft
using an EDNS option if (when?) that tur
On May 27, 2014, at 12:29 PM, Evan Hunt wrote:
> One of our operations staff made what I thought was a clever suggestion
> the other day: That it would be nice, from an operational standpoint,
> to have a way to encode comments into a zone so that they wouldn't get
> obliterated when a dynamic
One of our operations staff made what I thought was a clever suggestion
the other day: That it would be nice, from an operational standpoint,
to have a way to encode comments into a zone so that they wouldn't get
obliterated when a dynamic zone was dumped to disk, but couldn't be read
by just anyb
21 matches
Mail list logo
