Subject: [DNSOP] NOTE RR type for confidential zone comments

From: Evan Hunt <[email-masked]>
Date: Tue, 27 May 2014 19:29:28 +0000

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 -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 27 May 2014 12:57:01 -0700

> 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,
[email-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: Evan Hunt <[email-masked]>
Date: Tue, 27 May 2014 20:13:27 +0000

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.

---

From: Miek Gieben <[email-masked]>
Date: Tue, 27 May 2014 21:32:07 +0100

[ Quoting <[email-masked]> 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?
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

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 27 May 2014 13:39:22 -0700

> 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.

---

From: Miek Gieben <[email-masked]>
Date: Tue, 27 May 2014 21:54:29 +0100

[ Quoting <[email-masked]> in "Re: [DNSOP] NOTE RR type for confid..." ]
> 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

---

From: Doug Barton <[email-masked]>
Date: Tue, 27 May 2014 16:08:29 -0700

> 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

---

From: Evan Hunt <[email-masked]>
Date: Tue, 27 May 2014 23:49:03 +0000

> 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.

---

From: Doug Barton <[email-masked]>
Date: Tue, 27 May 2014 21:30:57 -0700

> 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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 May 2014 08:23:17 -0400

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?

---

From: Joe Abley <[email-masked]>
Date: Wed, 28 May 2014 16:25:26 +0300

> 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…

Is the use case perhaps the ability to attack comment-like metadata to dynamic updates and IXFRs, to help document data elements in particularly widely-distributed and heterogenous environments?

(I think the proposal is well-written and intelligent, but I also struggle slightly to imagine a use case beyond "work around the fact that the nameserver I'm using likes to throw away my nice comments" :-) 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 BIND9's auto-dnssec maintain).

Joe

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 May 2014 09:33:48 -0400

On May 28, 2014, at 9:25 AM, Joe Abley <[email-masked]> 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 BIND9's auto-dnssec maintain.

Yup, that's what I'm getting at.   Reasonable thing to document through the ISE, of course.   I think this work is out of scope for DNSOP, and that it's not sufficiently needed to justify firing up a working group to do it, nor change the DNSOP charter to make it in scope.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 28 May 2014 09:34:33 -0400

On May 28, 2014, at 8:23 AM, Ted Lemon <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

I was wondering about that as well. 
Then I started thinking about the bigger picture. 

In the beginning we had in the zone file 
	RR’s: SOA NS   ==> loaded into memory 
	Comments:  text ==> not loaded into memory 
	Directives: $ORIGIN, $TTL …. ==> affect how the RR’s are named
	
Then we got Macros:  
	$INCLUDE  ===> read this new file s
	$GENERATE ==> creates lots of records that are similar 

Then we got comments that guide tools :  “; Active …."

Now we are getting request for persistent comments that are not exposed, and only transferred to “connecting adults” 
i think this is normal evolution, but doing this without looking at the whole picture is which includes the RR type code space
there we have 
	normal RR’s  1-127, 256-61439
	meta RR’s: 128-255
	Undefined: 61400-65279
	Private Use: 65280-65279 

At this point I can not  make up my mind if NOTE should be a Meta Type or we cave up the Undefined space to create a block for Note like
records, as we can not assume there will not be an application for more in the future (lets call this: COMMENT TYPES for now )

For example I can see many of the “comments that guide tools” becoming a type like NOTE, thus enabling for example 
signing on the fly by by secondaries. 

For this reason the “Flag/Option” defined to express understanding should cover them all. 
The only ways to do that in a sane way are: 
	List all “comment types you know about” 
    or create a range for comment types. 

Thus the decision on flag vs option depends allocation policy for this comment type and future ones. 

(Sorry Evan for creating an even higher bar for your document but simple useful hacks like this sometimes have consequences 
that flood of new ideas come out) 

	Olafur

---

From: Joe Abley <[email-masked]>
Date: Wed, 28 May 2014 16:48:53 +0300

> Definitely a possibility.   :)

Sorry, I've been teaching people at AfNOG about DNS and reflection attacks for half the day :-) I meant "attach", not "attack".

Joe

---

From: Evan Hunt <[email-masked]>
Date: Wed, 28 May 2014 16:15:52 +0000

> 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 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 allocated.  In geographically dispersed organizations it
can be particularly hard to figure this stuff out.  It would be nice to be
able to leave breadcrumbs in the zone file and have them a) not get stomped
on, and b) be retrievable by an administrator working in a colo cage
somewhere by sending a suitably TSIG-signed query.

2) Over the years I've had to tell a dozen or so BIND operators who'd had
disk failures on their master servers to fetch backup zones from slaves,
and heard sadness at the loss of comments.  (Also file ordering, but
that's not something that NOTE can help with.)

3) Status comments could be added to zones such as "signed by $version
on $host at $date".

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 May 2014 12:20:26 -0400

> 3) Status comments could be added to zones such as "signed by $version

These are all examples of things that are ordinarily addressed by some kind of IPAM user interface.   Stuffing this information into the DNS seems like a layering violation.   By which I don't mean "so you can't do it," but rather "so I'm skeptical that it should be recommended practice."

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 28 May 2014 09:30:05 -0700

- 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

---

From: Evan Hunt <[email-masked]>
Date: Wed, 28 May 2014 16:39:18 +0000

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 zone.
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.

Also, IPAM software isn't necessarily interoperable between different DNS
implementations.

(And there may be use cases I haven't thought of yet.)

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 May 2014 12:57:55 -0400

> this lacuna in the DNS feature set", which doesn't mean it isn't a

Sure, but you could also say that IP leaves out the feature of supporting streaming, and that TCP kludges around this lacuna.

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 architectural standpoint.

If in fact, as you say (and I tend to agree) IPAM solutions don't do this well, then the right thing to do from a standards perspective is to generalize the problem and come up with a way of addressing it using existing tools--e.g., a netconf/yang schema.   It is not to complexify the protocol you are trying to manage by stuffing all the management goop into it in a way that is not standard and won't interoperate with existing management tools.

---

From: 神明達哉 <[email-masked]>
Date: Wed, 28 May 2014 10:39:41 -0700

At Wed, 28 May 2014 12:57:55 -0400,
Ted Lemon <[email-masked]> 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 architectural standpoint.

On a quick read of the draft and the thread discussion, I tend to
agree with this.  If this were just another minor but ordinary RR
type, it may make sense for some people and is probably worth
standardizing to let the market decide.  But the proposal includes a
lot of other technical complexity in the DNS protocol handling, such
as a special rule for DNSSEC or zone transfer and exceptional cases
for negative answers.  It also makes the content of zones even less
public, which might make sense in the era of NSEC3 and dnspriv, but
will certainly require other new considerations such as encrypting
zone transfers (just refusing xfr or normal query for NOTE wouldn't be
enough in terms of security considerations).

So, overall, it seems to me the gain of this proposal is not worth the
added complexity.

--
JINMEI, Tatuya

---

From: Evan Hunt <[email-masked]>
Date: Wed, 28 May 2014 19:35:33 +0000

> extra 32 bits would be in the noise.

The direction of the wind being clear, I have redrafted the NOTE
specification with a NOTE-OK option rather than a NO bit.  (Thereby
strangling in its cradle my secret plan to gradually aquire EDNS
flags until they spelled DO NO TT AU NT HA PP YF UN BA LL, so I
HOPE YOU'RE HAPPY.)

http://www.ietf.org/id/draft-hunt-note-rr-01.txt