Subject: [DNSOP] discussion for draft-woodworth-bulk-rr-00.txt

From: "Woodworth, John R" <[email-masked]>
Date: Sun, 1 Nov 2015 20:50:12 +0000

All,

Apologies for any procedural missteps as I am new to the group but am trainable.

I am looking to get some traction on a recent I-D my group is working on and
am looking for advice along the way.

We are confident this draft can play a significant role in the future of DNS
especially as it relates to IPv6.  While there are many problems we are
attempting to address with this draft, we believe the biggest among them
are related to IPv6 and the scarcity of IPv4 address space.

If, by contacting this mailing list, we are heading down the wrong path we are
particularly fond of any advice to move this forward as we see the need for it
becoming more and more important as the adoption of IPv6 increases.

The draft announcement is here:

> -----Original Message-----
> Subject: New Version Notification for draft-woodworth-bulk-rr-00.txt
>
>
> A new version of I-D, draft-woodworth-bulk-rr-00.txt has been successfully
> submitted by John Woodworth and posted to the IETF repository.
>
> Name:         draft-woodworth-bulk-rr
> Revision:     00
> Title:                BULK DNS Resource Records
> Document date:        2015-06-30
> Group:                Individual Submission
> Pages:                28
> URL:            https://www.ietf.org/internet-drafts/draft-woodworth-bulk-rr-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/
> Htmlized:       https://tools.ietf.org/html/draft-woodworth-bulk-rr-00
>
>
> Abstract:
>    The BULK DNS resource record type defines a method of pattern based
>    creation of DNS resource records to be used in place of NXDOMAIN
>    errors which would normally be returned.  These records are currently
>    restricted to registered DNS resource record types A, AAAA, PTR and
>    CNAME.  The key benefit of the BULK resource record type is the
>    simplification of maintaining "generic" record assignments which
>    would otherwise be too many to manage or require scripts or
>    proprietary methods as bind's $GENERATE.
>

Thanks and best regards,
John
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 2 Nov 2015 02:40:32 +0000

Process wise, you should seek to have this on the experimental track.  It
has potential but is far from a sure thing.

The idea of being able to send formulas for generating responses,
particularly for address records, reverse map and CNAME is a latent need
in the DNS hosting industry.  These types are special in that way, so it's
no surprise they are singled out.

I'll admit that I read and scanned portions to get an idea of what is
discussed.  I do like that you have the section 7.1, addressing DNSSEC.

One "red flag" to me is the idea of hidden wildcards.  One of the design
principles of DNSSEC is that it exposes the "thinking" process of the
server to the requestor.  That alone isn't a dead end - hidden records and
on-the-fly signing would "work" (but as you note not all name server
implementations have the ability to sign on-the-fly).

Cutting to the chase, there are various elements here that could work
together.  But also combinations that wouldn't work so well.  Simply put,
this is complicated.  For reasons I'll not include here, complicating the
protocol isn't leading in the right direction.

I do get the desire for this.  I also would like to see someway to augment
response synthesis (beyond wildcards).  Perhaps a scaled down version
would be more manageable (like removing the hidden records and answering
with the signed formula plus unsigned result - just as for DNAME).

On 11/2/15, 5:50, "DNSOP on behalf of Woodworth, John R"
<[email-masked] on behalf of [email-masked]> wrote:

>> URL:            
>>https://www.ietf.org/internet-drafts/draft-woodworth-bulk-rr-00.txt
>> Status:         
>>https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/
>This communication is the property of CenturyLink and may contain
>confidential or privileged information. Unauthorized use of this
>communication is strictly prohibited and may be unlawful. If you have
>received this communication in error, please immediately notify the
>sender by reply e-mail and destroy all copies of the communication and
>any attachments.
>_______________________________________________
>DNSOP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Woodworth, John R" <[email-masked]>
Date: Mon, 2 Nov 2015 05:28:28 +0000

See inline comments:

> From: Edward Lewis [mailto:[email-masked]]
> Subject: Re: [DNSOP] discussion for draft-woodworth-bulk-rr-00.txt
>

Edward, Thank you very much for your time.  I will need to research more in
regard to the experimental track, thank you.  Any more advice you could
offer here would be great.

> implementations have the ability to sign on-the-fly).

Good point.  Our reasoning behind this was to avoid undue discrimination.
Many providers, especially in the context of "anti-spam" make seemingly
arbitrary decisions to block or disable huge batches of addresses based
on coin-toss accuracy.  I've personally seen the simple changing of "dyn"
to "static" in a hostname make all the difference and wanted to entirely
avoid this set of circumstances where possible.  By hiding the fact the
records are part of a pattern (i.e. hiding a "BULK" RR request with the
same owner) the generated records are no longer susceptible to this form
of discrimination.  Since one of our primary motivations was in essence to
provide $GENERATES which could AXFR there is a zero externally-identifiable
change to $GENERATEd records (i.e. no change to operational support).

This, of course, is negated where pre-signed DNSSEC records are used and
supplemental "NPN" records are required.  In this case, hiding the wildcards
would prove moot for this purpose.  However, the NPN record provides a
level of transparency for DNSSEC's "thinking" process while also offering
some additional protection against would-be attackers probing DNS for a
zone's internal organizational structure a la NSEC.

> protocol isn't leading in the right direction.

Before continuing let me state your opinion is greatly respected and
appreciated and my enthusiasm should not be taken as disrespect toward you
or your comments in any way.

While I wholeheartedly agree this adds a fair amount of complexity to the
authoritative side of the equation, disregarding DNSSEC the burden on the
recursive side is unaffected.  Where DNSSEC is required and on-the-fly is
available, the recursive side is just as unaffected.  Where DNSSEC is
required and on-the-fly is unavailable, we feel this complication is
unavoidable.

When placed into a similar context as DNSSEC and the complexity of
recursively chained cryptographic validation the added complexity supporting
these records would add is relatively trivial.

> with the signed formula plus unsigned result - just as for DNAME).

Definitely worth a discussion should we get the opportunity.  I had no
expectation of a first draft making it through the process intact.
Thanks again for your prompt response and invaluable insight.

Best regards,
John

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sun, 8 Nov 2015 12:20:42 -0500

> On Nov 2, 2015, at 12:28 AM, Woodworth, John R <[email-masked]> wrote:
> 
> See inline comments:
> 
>> From: Edward Lewis [mailto:[email-masked] <mailto:[email-masked]>]

This is a quite interesting proposal, too early to tell what track the document should be on,
for now Standards track is fine. 

>> discussed.  I do like that you have the section 7.1, addressing DNSSEC.

+1

> change to $GENERATEd records (i.e. no change to operational support).

I understand you want the way to minimize the zone transfers, and not expose to the world
your auto generate rules. IMHO this limits your operational to 3 options  
a) no DNSSEC 
b) on-line signing DNSSEC 
c) delegate to zones that are either a) or b) 

The option of modifying resolvers is likely to hinder the deployment of the proposal as the community that your
are trying to trick are <rant suppressed> . 

One way is that your document can be simplified is by dropping any attempt to support off-line signed zones. 
I do not see this as operational complication as in most cases BULK records will be interpreted by servers that are under a
single administrative control. 

> required and on-the-fly is unavailable, we feel this complication is

A big compliment to you for thinking about how to support DNSSEC 
IMHO on-line signing is the only realistic way forward, as the there is little  
motivation by resolvers operators that you want mostly to affect to run
modern stuff. 

> these records would add is relatively trivial.
This is not a question of complexity, it is about inertia.
<snip> 

> John

Olafur

---

From: "Woodworth, John R" <[email-masked]>
Date: Mon, 9 Nov 2015 17:26:48 +0000

From: Olafur Gudmundsson [mailto:[email-masked]]
Subject: Re: [DNSOP] discussion for draft-woodworth-bulk-rr-00.txt
> This is a quite interesting proposal, too early to tell what track the document
> should be on, for now Standards track is fine.
>

Olafur, First thanks for the feedback.  As advised I have done some research
regarding the experimental track and being new to the process it seems to me
it could be the "kiss of death" for this proposal.

> I understand you want the way to minimize the zone transfers, and not
> expose to the world your auto generate rules. IMHO this limits your
> operational to 3 options
>
> a) no DNSSEC
> The option of modifying resolvers is likely to hinder the deployment
> of the proposal as the community that your are trying to trick
> are <rant suppressed> .
>
> One way is that your document can be simplified is by dropping any
> attempt to support off-line signed zones.
>
> I do not see this as operational complication as in most cases BULK
> records will be interpreted by servers that are under a single
> administrative control.

Very true.  The off-line signed zones are definitely the most complex
part of our proposal.  We originally thought this feature (NPN) should
be broken out separately but did not want to leave this obvious
condition unaccounted for and felt a self-contained solution would
be best.

I will revisit breaking the NPN out of this document and into its
own (my gut tells me experimental track).  This way, at least the
solution is available for where pre-signed zones may make more sense.
The NPN also seems to fit better as a DNSSEC specific feature and
will most definitely find a very dedicated opposition.

> This is not a question of complexity, it is about inertia.

I had not thought of it this way.  This makes a lot of sense, thanks again.

Best regards,
John