Re: [DNSOP] NOTE RR type for confidential zone comments
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 matter of taste. A single bit, which is already being sent though currently undefined, versus 32 bits that wouldn't otherwise need to be sent, and the unavoidable necessity of parsing OPT past the header. It just seems cleaner to me, and in the absence of other considerations it seems the obvious way to design a feature like this. (DNSSEC, by example, is a little bit like this: omitting some response data if a flag bit is not set.) However, other considerations do exist, and I'm not married to it. 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. Doug ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NOTE RR type for confidential zone comments
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 already being sent though currently undefined, versus 32 bits that wouldn't otherwise need to be sent, and the unavoidable necessity of parsing OPT past the header. It just seems cleaner to me, and in the absence of other considerations it seems the obvious way to design a feature like this. (DNSSEC, by example, is a little bit like this: omitting some response data if a flag bit is not set.) However, other considerations do exist, and I'm not married to it. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NOTE RR type for confidential zone comments
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 to disk, but couldn't be read by just anybody with access to "dig". This draft proposes such a beast. Feedback would be lovely. http://www.ietf.org/internet-drafts/draft-hunt-note-rr-00.txt 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. Regarding the idea generally, I would never use it, and I would caution my customers not to use it, for the following reasons: 1. You cannot guarantee that every name server will implement this option correctly, and/or that every name server will correctly implement any transfer ACLs that would need to be in place to keep your information confidential. (The latter being a bit of a consultant's indirect way of saying that the customer themselves could quite possibly mess this up, with potentially disastrous consequences.) :) 2. Zone transfers happen in a well-defined format over what are almost universally unencrypted channels. Thus an even moderately determined attacker would have little or no effort required to grab the transfer in flight and see all your "confidential" comments. Thus, my advice to my customers would be that if they don't feel comfortable putting it in a TXT field it should probably be handled OOB. I'm also moderately concerned about this field breaking the usual canard that "If it's in the zone file, it's public data." I don't _particularly_ agree with that idea, but it's pretty well ingrained in the DNS lore, and changing it at this point will lead us down some interesting roads. Doug ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NOTE RR type for confidential zone comments
[ 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 doesn't know about NOTE and treats them as unknown records? Thats why the EDNS0 signaling is particularly clever in this proposal: A server would have to know about the NOTE record to receive them in a zone transfer, so as long as the source knows what its doing, the recipient will only receive the NOTE records if they know what they are. Ack, and I agree with your suggestion about not allocating a edns0 bit for this. But still, my gut feeling says that NOTE records can leak, for all intent and purposes your *are* putting comments in DNS data. I wouldn't put my database password in an NOTE RR :/ /Miek -- Miek Gieben ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NOTE RR type for confidential zone comments
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 a zone so that they wouldn't get >> obliterated when a dynamic zone was dumped to disk, but couldn't be read >> by just anybody with access to "dig". >> >> This draft proposes such a beast. Feedback would be lovely. >> >> http://www.ietf.org/internet-drafts/draft-hunt-note-rr-00.txt > > Interesting idea! > > What happens if a server get these records and doesn't know about NOTE > and treats them as unknown records? Thats why the EDNS0 signaling is particularly clever in this proposal: A server would have to know about the NOTE record to receive them in a zone transfer, so as long as the source knows what its doing, the recipient will only receive the NOTE records if they know what they are. The only case would be if a server is reading a zone file, not a transfer, in which case it won't know the RRTYPE of "NOTE", so it will fail to load the record. -- Nicholas Weaver it is a tale, told by an idiot, nwea...@icsi.berkeley.edufull of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NOTE RR type for confidential zone comments
[ 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 zone was dumped to disk, but couldn't be read by just anybody with access to "dig". This draft proposes such a beast. Feedback would be lovely. http://www.ietf.org/internet-drafts/draft-hunt-note-rr-00.txt Interesting idea! What happens if a server get these records and doesn't know about NOTE and treats them as unknown records? IOW I wonder if you can ever enforce "can not get a response for a NOTE query" and maybe you should just give up and allow for this (with TTL=0)? /Miek -- Miek Gieben ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NOTE RR type for confidential zone comments
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 turns out to be the group consensus, but I decided to ask for what I want first and get shot down rather than assume in advance that there was no chance. :) At the going rate of 1 EDNS bit allocated per 15 years of EDNS existence, we have enough to last until the year 2239, at which time an EDNS version bump could allocate more of them. So I concur with "rare", but not necessarily with "precious". However, there is no technical reason a flag bit is necessary. I just think it's more elegant. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NOTE RR type for confidential zone comments
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 zone was dumped to disk, but couldn't be read > by just anybody with access to "dig". > > This draft proposes such a beast. Feedback would be lovely. > > http://www.ietf.org/internet-drafts/draft-hunt-note-rr-00.txt > I think the type makes sense, as does the encoding. Using an EDNS0 bit however, does not makes sense to me. Flag bits are rare and precious, while 16b option codes are not. Thus, instead I think "note OK" it should be an EDNS0 option, with a new option code, an option length of 0, and no option data. Especially since bits themselves are not precious (DNS requests are no where near getting near 512b, let alone the ~1500b where fragmentation is an issue), and this is primarily for zone transfer queries anyway, which means the overhead is going to be near zero anyway. -- Nicholas Weaver it is a tale, told by an idiot, nwea...@icsi.berkeley.edufull of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] NOTE RR type for confidential zone comments
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 anybody with access to "dig". This draft proposes such a beast. Feedback would be lovely. http://www.ietf.org/internet-drafts/draft-hunt-note-rr-00.txt -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
