Subject: [homenet] Reverse DNS

From: james woodyatt <[email-masked]>
Date: Mon, 30 Jul 2012 11:52:22 -0700

everyone--

Before we get too far down the road dreaming up how to register names for hosts on home networks, I'd like to suggest gently that a related problem, i.e. how to register authoritative name services for the subdomains of ip6.arpa corresponding to prefixes delegated to home networks, is a lot more pressing.

For your consideration, my personal home server currently resides at 2001:5a8:4:2290::102.  Here's what dig -x currently returns for that IPv6 host address:

> $ dig -x 2001:5a8:4:2290::102
> 
> ; <<>> DiG 9.8.1-P1 <<>> -x 2001:5a8:4:2290::102
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2427
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;2.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.2.2.4.0.0.0.8.a.5.0.1.0.0.2.ip6.arpa. IN PTR
> 
> ;; ANSWER SECTION:
> 2.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.2.2.4.0.0.0.8.a.5.0.1.0.0.2.ip6.arpa. 86400	IN PTR grymling.conjury.org.
> 
> ;; Query time: 371 msec
> ;; SERVER: 2620:149:5:f09::53#53(2620:149:5:f09::53)
> ;; WHEN: Mon Jul 30 11:43:57 2012
> ;; MSG SIZE  rcvd: 124

The steps I had to go through to be sure that such queries were answerable were not the steps I would want to defend in a feature usability review.

I realize that solving this problem with a standard would involve more working groups than HOMENET, but clearly the effort needs to start here.  Once we have a good idea how to solve this problem, then I think it will be easier to talk about forward DNS coherently.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Ray Bellis <[email-masked]>
Date: Mon, 30 Jul 2012 20:26:07 +0000

On 30 Jul 2012, at 11:52, james woodyatt wrote:

> I'd like to suggest gently that a related problem, i.e. how to register authoritative name services for the subdomains of ip6.arpa corresponding to prefixes delegated to home networks, is a lot more pressing.

<nohat>

Could you explain _why_ you consider it more pressing?

As I understand it, the consensus in groups such as DNSOP is that there's no need for reverse DNS for end-user IPv6 hosts.

Ray

---

From: Ted Lemon <[email-masked]>
Date: Mon, 30 Jul 2012 13:28:15 -0700

> I realize that solving this problem with a standard would involve more working groups than HOMENET, but clearly the effort needs to start here.  Once we have a good idea how to solve this problem,…

The work's already started in the dhc working group:

http://tools.ietf.org/id/draft-lemon-dhc-dns-pd-01.txt

I'd be curious to hear your feedback on this draft.

---

From: Benjamin Kerensa <[email-masked]>
Date: Mon, 30 Jul 2012 13:45:49 -0700

On 07/30/2012 01:28 PM, Ted Lemon wrote:
>> I realize that solving this problem with a standard would involve 
>> more working groups than HOMENET, but clearly the effort needs to 
>> start here.  Once we have a good idea how to solve this problem, then 
>> I think it will be easier to talk about forward DNS coherently.
>
The draft looks good so far

---

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Jul 2012 18:16:08 -0400

>>>>> "Ray" == Ray Bellis <[email-masked]> writes:
    Ray> <nohat>

    Ray> Could you explain _why_ you consider it more pressing?

    Ray> As I understand it, the consensus in groups such as DNSOP is
    Ray> that there's no need for reverse DNS for end-user IPv6 hosts.

I'm not interested in re-opening this debate.
Yeah, the DNS people don't see a need.  
Application people and security people *do* see a need.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works 
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Ted Lemon <[email-masked]>
Date: Mon, 30 Jul 2012 15:26:58 -0700

> As I understand it, the consensus in groups such as DNSOP is that there's no need for reverse DNS for end-user IPv6 hosts.

This isn't actually true.   What's true is that there is no consensus either way.   Whenever we have discussions about this, a dozen people get up to say "no reverse DNS!"   And a dozen other people get up and say "we'd like reverse DNS!"   So the IETF really can't take a position either that there shouldn't be reverse DNS, or that there should.   But standards exist that describe how you would do it if you chose to, up to a point.   The question is, should we specify how to do the missing pieces?

The goal with the dns-pd draft is to provide a mechanism that places this decision firmly in the hands of the operator and knowledgeable users, rather than simply allowing it to fail by default, or requiring that all users, knowledgable or not, accept the same functionality.

---

From: "Howard, Lee" <[email-masked]>
Date: Mon, 30 Jul 2012 18:28:24 -0400

>Application people and security people *do* see a need.

Who?  I've heard a lot of people say, "Them," but I've never heard anyone
say, "Me."

Lee

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: james woodyatt <[email-masked]>
Date: Mon, 30 Jul 2012 16:07:49 -0700

On Jul 30, 2012, at 13:28 , Ted Lemon <[email-masked]> wrote:
>   <http://tools.ietf.org/html/draft-lemon-dhc-dns-pd>
> 

That's a good submission for the DHC group.

I'm thinking I'd much more like to see a specific recommendation that HOMENET gateways implement a site-managed reverse tree, optionally augmented with a zero-configuration method for generating content explicitly managed by a knowledgeable home network administrator.

For example, after I install a fresh HOMENET gateway in my new house, I expect the following things just to happen correctly without any forethought:

1. The integrated DNS content server should have authority for all of the ip6.arpa corresponding to the IPv6 prefixes delegated by its service provider;

2. The integrated DNS resolving server should answer [on the local network only] for the locally generated ULA prefixes required by RFC 6106.

3. Queries for PTR records in zones for which it's authoritative should always produce a synthesized answer if no explicitly configured records are stored in the content server.

  For examples,

  3a. dig -x fd35:5a4b:92a9:fb::1 ->
	fd35-5a4b-92a9-fb--1.local.

  3b. dig -x 2001:5a8:4:2290:a95f:dd2e:3201:eafc ->
	2001-5a8-4-2290-a95f-dd2e-3201-eafc.subscriber-3021134.example.net.

4. I should be able to override explicitly the domain automatically delegated by my service provider with my own registered FQDN if I want to do so, so that example 3b above becomes:

  3b.(2). dig -x 2001:5a8:4:2290:a95f:dd2e:3201:eafc ->
	2001-5a8-4-2290-a95f-dd2e-3201-eafc.conjury.org.

5. I should be able to override explicitly the automatically generated FQDN for any hosts on my network if I want to do so, so that examples 3a and 3b above become:

  3b.(3). dig -x fd35:5a4b:92a9:fb::1 ->
	zardoz.local.

  3b.(4). dig -x 2001:5a8:4:2290:a95f:dd2e:3201:eafc ->
	zardoz.subscriber-3021134.example.net.

6. I should be able to do both.

  3b.(5). dig -x fd35:5a4b:92a9:fb::1 ->
	zardoz.home.conjury.org.

  3b.(6). dig -x 2001:5a8:4:2290:a95f:dd2e:3201:eafc ->
	zardoz.conjury.org.

Yes, I get that DNSOP people don't like to contemplate this problem.  I don't want to debate about why I think they're wrong to defer it, but my thoughts aren't all that different from those of anyone else in the application/security community.  Can we skip past the part when I enumerate them again?

I guess I had hoped the HOMENET group would more easily find consensus around addressing this promptly, but that may have been wishful thinking.

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 30 Jul 2012 19:13:10 -0400

> > = James
>   = Ted
In message <[email-masked]>
 
> I'd be curious to hear your feedback on this draft.

In most cases where a site has delegation of DNS or rDNS. it is not
negociated using DHCP.  This draft appears to allow that extension.
That is good (IMHO).

I think it would be wonderful if providers offered delegation of rDNS
and making it trivial for them might not hurt.

[Aside: my ISP will not do delegation of rDNS.  You have to put in a
support call (not web page, not email, a phone call) for any change
and that is hugely time consuming for me, and very time consuming and
therefore expensive for them.  My ISP is stupid in some ways.  My IPv6
tunnel provider OTOH has an option on their web page to specify where
the rDNS name servers reside and it all works very nicely.  Native
IPv6 would be better but only if my ISP had a clue about rDNS.]

Back to the original email.

> > The steps I had to go through to be sure that such queries were
> > answerable were not the steps I would want to defend in a feature
> > usability review.

James gave an example and I don't know what his gripe was, other than
getting rDNS to work was not something the home user could tolerate.
I agree with that usability point.

Looking at the practical side, right now there is a good tie in
between ISC dhcpd (DHCP server) and ISC bind (DNS server) for forward
DNS.  I don't think that rDNS is handled by ISC but I could be wrong.
Even so, there is nothing preventing rDNS from being handled.

The issue is then that rDNS (like DNS itself) is hard to configure
with some of today's tools.  ISC tools (for example) are powerful but
hard to configure.  Some low end routers exist that are much easier to
configure, but they lack capabilities.

Some of the prior discussions centered around using a default zone of
local, such that if a host claimed to be host name "foo" and another
claimed to be "bar" then the fqdn would be "foo.local" and
"bar.local".  It would then be a small matter of configuration to
change "local" to "example.com" and have the fqdn reported by rDNS be
"foo.example.com" and "bar.example.com".  For any of this to make
sense some configuration is needed.  Someone has to configure "foo" as
the host name on one host, and "bar" as the host name on the other,
and maybe if they have just one router, they could give it a name too.

This would be simple enough to configure.  No protocol extension is
neede to accomplish this.

This is something that could be mentioned in a homenet arch document
if we decide that the default local domain is a good idea (and get the
appropriate blessings on this use of that TLD) and that dynamic DNS
and dynamic rDNS should be available and enabled by default.  There
are two decisions to be made 1) dynamic DNS and rDNS should be
available, 2) they should be enabled by default with "local" domain,
easily configured to another name.

btw - Even without delegation, accurate rDNS can be provided *locally*
which for some users (like those using the default "local" domain)
would be sufficient.

Curtis

---

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Jul 2012 19:28:21 -0400

>>>>> "james" == james woodyatt <[email-masked]> writes:
    james> 3. Queries for PTR records in zones for which it's
    james> authoritative should always produce a synthesized answer if
    james> no explicitly configured records are stored in the content
    james> server. 

I think you that the answer should come from the Bonjour cache.

    james> For examples,

    james> 3a. dig -x fd35:5a4b:92a9:fb::1 ->
    james> fd35-5a4b-92a9-fb--1.local.

okay, so here I think that I disagree.  Is that name valid in the
forward?  

    james> 4. I should be able to override explicitly the domain
    james> automatically delegated by my service provider with my own
    james> registered FQDN if I want to do so, so that example 3b above
    james> becomes: 

    james> 3b.(2). dig -x 2001:5a8:4:2290:a95f:dd2e:3201:eafc ->
    james> 2001-5a8-4-2290-a95f-dd2e-3201-eafc.conjury.org.

I agree.

    james> 5. I should be able to override explicitly the automatically
    james> generated FQDN for any hosts on my network if I want to do
    james> so, so that examples 3a and 3b above become: 

..

    james> 6. I should be able to do both.

..

    james> Yes, I get that DNSOP people don't like to contemplate this
    james> problem.  I don't want to debate about why I think they're
    james> wrong to defer it, but my thoughts aren't all that different
    james> from those of anyone else in the application/security
    james> community.  Can we skip past the part when I enumerate them
    james> again? 

    james> I guess I had hoped the HOMENET group would more easily find
    james> consensus around addressing this promptly, but that may have
    james> been wishful thinking. 

I am 400% behind you, and if buying you beer will help, tell me.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: james woodyatt <[email-masked]>
Date: Mon, 30 Jul 2012 16:54:14 -0700

On Jul 30, 2012, at 16:28 , Michael Richardson <[email-masked]> wrote:
>    james> 3a. dig -x fd35:5a4b:92a9:fb::1 -> fd35-5a4b-92a9-fb--1.local.

I chose a ULA address instead of a LL address because mDNS doesn't handle reverse mappings for the "d.f.ip6.arpa." domain, c.f. section 4 of I-D.cheshire-dnsext-multicastdns-15:

>>      Likewise, any DNS query for a name within the reverse mapping
>>      domains for IPv6 Link-Local addresses ("8.e.f.ip6.arpa.",
>>      "9.e.f.ip6.arpa.", "a.e.f.ip6.arpa.", and "b.e.f.ip6.arpa.") MUST
>>      be sent to the IPv6 mDNS link-local multicast address FF02::FB or
>>      the IPv4 mDNS multicast address 224.0.0.251.

> okay, so here I think that I disagree.  Is that name valid in the forward?  

I could accept a standard that required every reverse mapped name to be resolvable in the forward over unicast DNS, but I would say that's a separable problem from the one I'm suggesting could be taken up now.  One step at a time...

-----
Perhaps my choice of "local." as the default zone for RFC 6106 ULA prefix addresses is unwise as it could be confusing in the presence of mDNS on the same segment as the unicast DNS service.

Suppose a host named "zardoz" is attached to the link at several interface addresses:

	fd35:5a4b:92a9:fb::1001
	2001:5a8:4:2290::1001
	2001:5a8:4:2290:a95f:dd2e:3201:eafc
	fe80::0200:ff:fe00:1

All those addresses will be reverse mapped over mDNS to "zardoz.local." under every implementation that I know about today.  Which makes sense if you think about it.  Every mDNS responder host is responsible for knowing its own name and answering to it.

In the unicast DNS case, the content server probably does not know-- and arguably should not know-- the name of every host in the zone, so that's why it's wise to expect it will be synthesizing host names.  Whether the default zone for ULA reverse mapping names over unicast DNS is "local." or "homenet." or something else is only tangentially relevant here.  It's the same problem no matter what TLD we allocate for this purpose.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 30 Jul 2012 16:59:25 -0700

> In the unicast DNS case, the content server probably does not know-- and arguably should not know-- the name of every host in the zone, so that's why it's wise to expect it will be synthesizing hos…

Maybe I missed it, but why is lack of reverse map a problem, minus the
security desire to show some weak control of the allocated prefix?

Mike

---

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Jul 2012 20:51:13 -0400

>> okay, so here I think that I disagree.  Is that name valid in the forward?  

    james> I could accept a standard that required every reverse mapped
    james> name to be resolvable in the forward over unicast DNS, but I
    james> would say that's a separable problem from the one I'm
    james> suggesting could be taken up now.  One step at a time... 

okay.

    james> -----
    james> Perhaps my choice of "local." as the default zone for RFC
    james> 6106 ULA prefix addresses is unwise as it could be confusing
    james> in the presence of mDNS on the same segment as the unicast
    james> DNS service. 

    james> Suppose a host named "zardoz" is attached to the link at several interface addresses:

    james> fd35:5a4b:92a9:fb::1001
    james> 2001:5a8:4:2290::1001
    james> 2001:5a8:4:2290:a95f:dd2e:3201:eafc
    james> fe80::0200:ff:fe00:1

    james> All those addresses will be reverse mapped over mDNS to
    james> "zardoz.local." under every implementation that I know about
    james> today.  Which makes sense if you think about it.  Every mDNS
    james> responder host is responsible for knowing its own name and
    james> answering to it. 

yes, I know... mDNS already has the info, which is why I suggest that
the info come from there.

    james> In the unicast DNS case, the content server probably does not
    james> know-- and arguably should not know-- the name of every host
    james> in the zone, so that's why it's wise to expect it will be
    james> synthesizing host names.  Whether the default zone for ULA
    james> reverse mapping names over unicast DNS is "local." or
    james> "homenet." or something else is only tangentially relevant
    james> here.  It's the same problem no matter what TLD we allocate
    james> for this purpose. 

so, you are suggesting that zardoz's reverse entries does not get
answered by unicast DNS unless I click on "zardoz" in my content
server's UI, and say, "export".

I'm suggesting that the "export" button should be in the UI of zardoz,
and be signaled via mDNS.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Jul 2012 20:54:30 -0400

>>>>> "Michael" == Michael Thomas <[email-masked]> writes:
    Michael> Maybe I missed it, but why is lack of reverse map a problem, minus the
    Michael> security desire to show some weak control of the allocated prefix?

http://www.ietf.org/mail-archive/web/homenet/current/msg01286.html

---

From: Ted Lemon <[email-masked]>
Date: Mon, 30 Jul 2012 17:57:58 -0700

> security desire to show some weak control of the allocated prefix?

This is the wrong way to ask the question.   Let me restate it:

Is there some application for the reverse DNS, aside from the totally useless "security" provided by matching the PTR with the AAAA?

The answer is yes.   There are a number of uses: peer-to-peer rendezvous, a place to publish keys, debugging info are examples.   AFAIK there is no controversy about the fact that that using the PTR record as a confirmation that you are who you say you are is completely useless and should not be done.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 30 Jul 2012 18:15:20 -0700

> The answer is yes.   There are a number of uses: peer-to-peer rendezvous, a place to publish keys, debugging info are examples.   AFAIK there is no controversy about the fact that that using the PT…

Tell that to the maintainers of this mailing list where I was just bitten by not
having a reverse map for a v6 address from my tunnel provider so that my
outbound mail to the list was rejected :) That's SOP for mail these days, not
that I disagree with you.

Mike

---

From: Mark Townsley <[email-masked]>
Date: Tue, 31 Jul 2012 10:01:07 -0700

> I am 400% behind you, and if buying you beer will help, tell me.

One of the primary purposes of homenet's scope being what it is, is to help us make some tough calls that might prove impossible in the context of every conceivable network on the planet, but are within reach given the context of a homenet. I'd like to strongly encourage the WG to work towards consensus of what is right for our problem at hand. We will then have to see if it flies in the broader context, but let's try and figure out what we want for the home first. 

- Mark

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 31 Jul 2012 14:32:39 -0400

In message <[email-masked]>
 
> I guess I had hoped the HOMENET group would more easily find consensus around addressing this promptly, but that may have been wishful thinking.

I agree with 99.8% of this.

s/\.local/.sitelocal/ and allow a home network to be routed and then I
agree with 100% of this.

I think you could add to the above that the provider should offer to
delegate a forward zone and a reverse zone via DHCP extension and
offer to provide DNS secondary for those zones.  Note that
draft-lemon-dhc-dns-pd doesn't go that far (offering a forward zone
name to use), but it would be a useful addition.

It would be nice if the customer router could request that the
provider secondary also pick up a zone allocated to the site by a
registrar.  The provider router can verify this by looking up the NS
records for that zone and determining that the A or AAAA for at least
one of the existing nameservers falls with the static address
allocation of the site.  This would be for advanced users and the
advanced user (or a sufficiently advanced DHCP/nameserver coupling)
could then update the list of NS records adding the provider
secondary.

Again draft-lemon-dhc-dns-pd doesn't go that far.  The provider side
would have to be able to offer to secondary for both a zone offerred
by the provider and offer to accept a zone name in a DHCP response
(with verification against NS records).  No zone name in the response
could imply acceptance of the provider offerred zone or it could be
explicitly accepted.

Given the support for these extensions in a provider side DNS
nameserver and support for these extensions in at least a subset of
home routers, this can all be automated such that there is no real
work for DNS ops.  The worst that can happen is the provider becomes a
DNS secondary for bad-name.example.com but can easily identify the
perpetrator and in a manner of their choosing the provider can
bludgeon said perpetrator with their AUP.

As long as funny-characters+code.example.com or
really-long-name+code.example.com doesn't cause some resolvers to
crash or run code, then there is no harm in bad-name.example.com.

Curtis

---

From: Ted Lemon <[email-masked]>
Date: Tue, 31 Jul 2012 11:48:30 -0700

The problem of secondarying the reverse zone isn't really discussed in the dns-pd draft, and there are a number of operational details I'd like to flesh out, but the specific question of secondarying the reverse zone isn't quite what it seems. 

You secondary a zone so that the contents of the zone will be there when a query happens, but why would a query happen if the CPE device isn't reachable?  What would trigger that query?   So I think you can get away with _not_ secondarying the zone.   But if you do want to secondary it, why would the ISP be responsible for that?   Presumably the customer is pretty savvy; a secondary for their reverse tree would just be another service they'd want to buy or set up, and the ISP could wash their hands of it or sell it, whichever they chose.

---

From: james woodyatt <[email-masked]>
Date: Tue, 31 Jul 2012 11:52:09 -0700

On Jul 31, 2012, at 11:32 , Curtis Villamizar <[email-masked]> wrote:
> 
> s/\.local/.sitelocal/ and allow a home network to be routed and then I agree with 100% of this.

I consider it a minor oversight that I wrote "local." without remembering that recent developments in the effort to standardize mDNS have strengthened the requirement for the "local." TLD to have an officially special usage.

I was mired by my habit of thinking about the practical consequences of many actual networks in the wild not respecting this proposed special usage.  I suppose HOMENET shouldn't contribute to the ongoing festival of error, so I'm okay with "sitelocal." as the TLD even when home networks are single links.

Also, the reason I proposed constraining the scope of a working group task to handling just reverse DNS is that solving that problem properly will necessarily involve solving a critical subset of the problems that need to be solved to handle forward DNS as well.  Do the reverse DNS case first, then extending that work to cover the forward DNS case will be much easier.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 31 Jul 2012 11:54:06 -0700

> Also, the reason I proposed constraining the scope of a working group task to handling just reverse DNS is that solving that problem properly will necessarily involve solving a critical subset of t…

+1

I'm a bit worried about the security implications of some of the ideas I'm seeing thrown around here, and would like to see us start with the basics and build from there, rather than trying to come up with a slapdash solution that does everything, and turns into a big problem in a few years time when it's deployed on millions of routers.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 31 Jul 2012 14:54:35 -0400

In message <[email-masked]>
Michael Thomas writes:
 
> > In the unicast DNS case, the content server probably does not know--
> > and arguably should not know-- the name of every host in the zone, so
> > that's why it's wise to expect it will be synthesizing host names.
> > Whether the default zone for ULA reverse mapping names over unicast
> > DNS is "local." or "homenet." or something else is only tangentially
> > relevant here.  It's the same problem no matter what TLD we allocate
> > for this purpose. 
> >
>  

Mike,

rDNS answers questions like who is that trying to connect to port X.
If its just misconfiguration or a benign but unexpected behaviour,
then knowing the host name helps.

For a local mailserver having an accurate reverse DNS entry is a real
good idea.  If not some other mail servers will reject your mail, most
often large consumer oriented ISP mail servers.

Some of the same ISPs that won't do rDNS delegation reject mail from
hosts with no rDNS entries or wrong entries.

Curtis

---

From: Mark Andrews <[email-masked]>
Date: Wed, 01 Aug 2012 06:06:55 +1000

In message <[email-masked]>, Ted Lemon writes:
> The problem of secondarying the reverse zone isn't really discussed in the dn
> s-pd draft, and there are a number of operational details I'd like to flesh o
> ut, but the specific question of secondarying the reverse zone isn't quite wh
> at it seems. 
> 
> You secondary a zone so that the contents of the zone will be there when a qu
> ery happens, but why would a query happen if the CPE device isn't reachable? 

Log processing.

>  What would trigger that query?   So I think you can get away with _not_ seco
> ndarying the zone.

It's trivial to secondary a zone.  It's even easier when you can have
the forward and reverse zones be the same.

	<cust-prefix-rev>.ip6.arpa. DNAME <cust-forward>.

		or

	<cust-prefix-rev>.ip6.arpa. DNAME <cust-prefix-rev>.<cust-forward>.

No on the fly setup of zones when a new prefix is allocated.  Just install
a DNAME record.  The second form is for when machines don't have the same
suffix in all prefixes.

The CPE device can make the decision about which form to use.

>  But if you do want to secondary it, why would the ISP be
>  responsible for that?

So they don't get extra request due to the delegated servers being
unreachable.  Giving good answers is cheaper than have to cope with
the effects of the customer's servers being unreachable.

>  Presumably the customer is pretty savvy; a secondary
>  for their reverse tree would just be another service they'd want to buy or s
> et up, and the ISP could wash their hands of it or sell it, whichever they ch
> ose.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Jul 2012 16:12:34 -0400

>>>>> "james" == james woodyatt <[email-masked]> writes:
    james> Also, the reason I proposed constraining the scope of a
    james> working group task to handling just reverse DNS is that
    james> solving that problem properly will necessarily involve
    james> solving a critical subset of the problems that need to be
    james> solved to handle forward DNS as well.  Do the reverse DNS
    james> case first, then extending that work to cover the forward DNS
    james> case will be much easier. 

This is a good approach. +1.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Jul 2012 16:29:02 -0400

>>>>> "Ted" == Ted Lemon <[email-masked]> writes:
    Ted> You secondary a zone so that the contents of the zone will be
    Ted> there when a query happens, but why would a query happen if the
    Ted> CPE device isn't reachable?  What would trigger that query?
    Ted> So I think you can get away with _not_ secondarying the zone.
    Ted> But if you do want to secondary it, why would the ISP be
    Ted> responsible for that?   Presumably the customer is pretty
    Ted> savvy; a secondary for their reverse tree would just be another
    Ted> service they'd want to buy or set up, and the ISP could wash
    Ted> their hands of it or sell it, whichever they chose. 

My suggestion is that the ISP secondary the zone from the CPE, but
actually advertise only their server in the NS delegation.  (The CPE
remains a stealth primary)

The CPE will have multiple addresses, usually at least two, as it has at
least two interfaces.  The CPE address which the ISP most knows about
and is most easily reachable is the outside address (the ISP facing
one).  That address, if auto-configured, could trivially change if
the CPE is replaced (or replugged into a different port), or if the CPE
used privacy extensions.  So we'll need a low TTL on that NS/AAAA
record.

If we use the internal address from the CPE, which is likely in the
prefix that was delegated, and therefore very unlikely to change (and I
think some people have even proposed to make the host part well-known!),
it is possibly more stable, but it instantly introduces an exception to
the CPE firewall rules.

Out of these two choices, neither is particularly bad, but as you
indicated, when the customer is down, the data is inaccessible.

If the ISP has a copy (and might keep some history of it), then the ISP
is in a position to indicate to the customer what host is what.
Consider an ISP that has detected a home system infected with some
malware.  Said ISP has either quaranteed or has disconnected that
customer. Customer will not understand
"host 2001:DB8:0001:1234:0234:45fe:ff01:4567 is infected"

but, might understand:
"host suzie-derkins is infected"

this could also be done if the ISP actually recorded the mapping from
..:4567->susie-derkins at the time the event occured, and maybe that's
really the answer here.

I'm thinking that ISPs might want to have more control over what's in
the reverse.  (I don't really like that myself, but...)

Perhaps there are privacy concerns if the ISP has this mapping recorded,
and it would be better if the CPE was the only place with the info.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 01 Aug 2012 06:31:31 +1000

> This is a good approach. +1.

DH key exchange over DHCPv6 for the border CPE to get a TSIG key to install
NS / DNAME records for the assigned prefixes using secure dynamic DNS update.

All this requires is an appropriate DHCPv6 option to be allocated.

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

---

From: "Howard, Lee" <[email-masked]>
Date: Tue, 31 Jul 2012 16:36:04 -0400

>remains a stealth primary)

I need to see an internet-draft problem statement.  I still don't believe
there is one, and I have no plans to provide IPv6 reverse DNS for
residential subscribers.  Any ISPs planning to do this?

Lee

---

From: Ted Lemon <[email-masked]>
Date: Tue, 31 Jul 2012 13:37:07 -0700

> Log processing.

Maybe, but I think only the customer is really going to care about this, so if they want it to work, they'd be responsible for setting it up.

> the forward and reverse zones be the same.

No, it's *technically* trivial to secondary a zone.   There's a lot of extra business stuff that goes on top of that, plus the problem of dealing with customer brokenness, so it makes sense to charge money to secondary your customers' reverse tree, if you decide to do it at all.   Of course it's hard to know how this will play out in practice, but I think it's naive to think that there won't be issues.

> the effects of the customer's servers being unreachable.

Extra SOA or NS requests?   Or just customer traffic to a CPE that's not connected?   Either way, I think the additional load, if it exists at all, is trivial.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 31 Jul 2012 13:40:57 -0700

> and it would be better if the CPE was the only place with the info.

I think the overall strategy you described is a valid one, but probably not the only valid one.   And when I've had conversations with people about this in the past, there has definitely been concern about publishing _every_ IP address in a public-facing zone.   But likely the answer to that is split-horizon (shudder) DNS with some out-facing information either anonymized or elided.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 31 Jul 2012 13:41:58 -0700

> All this requires is an appropriate DHCPv6 option to be allocated.

You could probably piggyback this on the CGA key if we start doing this.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 31 Jul 2012 16:44:32 -0400

Ted,

I'm agreeing with you that there are other uses for PTR records than a
misguided notion of security.

Every log file that tries to record host names becomes much more
readable if it is successful in recording host names than if it
records IP addresses.  In some cases for performance reasons the log
files have to record IP addresses, but that would not be expected to
be the case for home use.  It is even worse if the log files record IP
addresses and the person reading the logs has no reverse map.

The example cited by Michael in
http://www.ietf.org/mail-archive/web/homenet/current/msg01286.html is
a good one.  Particularly the "double use case" in that example.
Since a home user is not likely to know to consult DHCP logs or
dynamic (m?)DNS logs, that use case where the provider logs had DNS
names is a good example.

Curtis

In message <[email-masked]>
Ted Lemon writes:

--===============3943190178831859519==
Content-Type: multipart/alternative; boundary="Apple-Mail=_9BAA1259-B71E-4867-8EF8-F0FF03A0821C"

--Apple-Mail=_9BAA1259-B71E-4867-8EF8-F0FF03A0821C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Is there some application for the reverse DNS, aside from the totally =
useless "security" provided by matching the PTR with the AAAA?

The answer is yes.   There are a number of uses: peer-to-peer =
rendezvous, a place to publish keys, debugging info are examples.   =
AFAIK there is no controversy about the fact that that using the PTR =
record as a confirmation that you are who you say you are is completely =
useless and should not be done.

--Apple-Mail=_9BAA1259-B71E-4867-8EF8-F0FF03A0821C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div><div>On Jul 30, 2012, at 4:59 PM, Michael Thomas =
wrote:</div><blockquote type=3D"cite"><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; font-family: Helvetica; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: 2; text-align: -webkit-auto; =
text-indent: 0px; text-transform: none; white-space: normal; widows: 2; =
word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Maybe I =
missed it, but why is lack of reverse map a problem, minus =
the<br>security desire to show some weak control of the allocated =
prefix?<br></span></blockquote></div><br><div>This is the wrong way to =
ask the question. &nbsp; Let me restate it:</div><div><br></div><div>Is =
there some application for the reverse DNS, aside from the totally =
useless "security" provided by matching the PTR with the =
AAAA?</div><div><br></div><div>The answer is yes. &nbsp; There are a =
number of uses: peer-to-peer rendezvous, a place to publish keys, =
debugging info are examples. &nbsp; AFAIK there is no controversy about =
the fact that that using the PTR record as a confirmation that you are =
who you say you are is completely useless and should not be =
done.</div><div><br></div></body></html>=

--Apple-Mail=_9BAA1259-B71E-4867-8EF8-F0FF03A0821C--

--===============3943190178831859519==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============3943190178831859519==--

---

From: Ted Lemon <[email-masked]>
Date: Tue, 31 Jul 2012 13:50:39 -0700

> addresses and the person reading the logs has no reverse map.

Yes.   Of course, it's important to have a clear understanding of the recipient of the data—if you are using it to communicate with the customer, as in Michael's example, then it makes sense to log it.   It's useless for law enforcement or copyright tattling.

Anyway, I think there's a case to be made for a system like the one Michael is describing; I just don't think every ISP will want to do that.

---

From: Wouter Cloetens <[email-masked]>
Date: Tue, 31 Jul 2012 22:53:38 +0200

>> 3. Queries for PTR records in zones for which it's authoritative should always produce a synthesized answer if no explicitly configured records are stored in the content server.

[...]

> name to use), but it would be a useful addition.

Covered in:
  http://www.ietf.org/id/draft-mglt-homenet-naming-delegation-00.txt

This also covers security considerations.

> could then update the list of NS records adding the provider

Covered in a completely different way in:

http://www.ietf.org/id/draft-mglt-homenet-front-end-naming-delegation-00.txt

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Jul 2012 16:54:54 -0400

>>>>> "Curtis" == Curtis Villamizar <[email-masked]> writes:
    Curtis> Every log file that tries to record host names becomes much more
    Curtis> readable if it is successful in recording host names than if it
    Curtis> records IP addresses.  In some cases for performance reasons the log
    Curtis> files have to record IP addresses, but that would not be expected to
    Curtis> be the case for home use.  It is even worse if the log files record IP
    Curtis> addresses and the person reading the logs has no reverse
    Curtis> map.

the machines recording the addresses/names are not in the home.
They are the web servers that the home user talks to.

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 31 Jul 2012 14:13:15 -0700

> residential subscribers.  Any ISPs planning to do this?

I see no reason for it in mobile networks. I do not support it in my
current 3gpp network for ipv6, no plans for future.

CB

>
> This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject to
copyright belonging to Time Warner Cable. This E-mail is intended solely
for the use of the individual or entity to which it is addressed. If you
are not the intended recipient of this E-mail, you are hereby notified that
any dissemination, distribution, copying, or action taken in relation to
the contents of and attachments to this E-mail is strictly prohibited and
may be unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any copy of
this E-mail and any printout.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 31 Jul 2012 14:35:36 -0700

> remains a stealth primary)

Do you mean (in bind parlance at least) the CPE is the master, and the
ISP is the slave even though it's authoritative?

Mike

---

From: Ray Bellis <[email-masked]>
Date: Tue, 31 Jul 2012 21:49:23 +0000

> ISP is the slave even though it's authoritative?

To the outside world, all published name servers are equally "authoritative".

The master/slave (or "primary / secondary") relationship only matters for distribution of zone content between those servers.

Ray

---

From: Mark Andrews <[email-masked]>
Date: Wed, 01 Aug 2012 07:50:53 +1000

> ISP is the slave even though it's authoritative?

All listed nameservers for a zone are presumed to be authoritative
for the zone.  slave/master (primary/secondary) are only relevent
w.r.t. the zone transfer graph between these servers and where
update requests are forwarded to.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 31 Jul 2012 14:51:28 -0700

> ISP is the slave even though it's authoritative?

I mean that the CPE is the primary and the ISP is the secondary, yes.   The CPE is in a much better position to maintain the contents of the zone—the ISP doesn't have access to the information necessary to do this.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 31 Jul 2012 15:14:21 -0700

> The master/slave (or "primary / secondary") relationship only matters for distribution of zone content between those servers.

I'm probably going to get myself in trouble for ignorance, but if my
CPE's dns is not listed as an NS from the root servers, I don't think it's
authoritative. It may be supplying the zone via some master/slave
arrangement with the ISP, but that's only how the ISP getting its brains
for the home zone, and is just using zone transfers to affect that.

Sorry if this is a rathole.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Tue, 31 Jul 2012 15:21:01 -0700

> for the home zone, and is just using zone transfers to affect that.

Doing the primary/secondary relationship this way is an operational choice; you are correct that the primary in this case wouldn't be listed as authoritative, but it would respond as if it were authoritative if queried—it would set the 'A' bit.   But it would never receive a query other than a zone transfer from a secondary.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Jul 2012 20:35:16 -0400

Ted> You secondary a zone so that the contents of the zone will be
    Ted> there when a query happens, but why would a query happen if the
    Ted> CPE device isn't reachable?  What would trigger that query?  So
    Ted> I think you can get away with _not_ secondarying the zone.  But
    Ted> if you do want to secondary it, why would the ISP be
    Ted> responsible for that?  Presumably the customer is pretty savvy;
    Ted> a secondary for their reverse tree would just be another
    Ted> service they'd want to buy or set up, and the ISP could wash
    Ted> their hands of it or sell it, whichever they chose.

    >> My suggestion is that the ISP secondary the zone from the CPE,
    >> but actually advertise only their server in the NS delegation.
    >> (The CPE remains a stealth primary)

    Michael> Do you mean (in bind parlance at least) the CPE is the
    Michael> master, and the ISP is the slave even though it's
    Michael> authoritative?

Yes, and when I first started this thread, I had forgotten that
draft-mglt-front-end-naming-delegation-00.txt, says something very
similar.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 31 Jul 2012 21:26:08 -0400

In message <[email-masked]>
Ted Lemon writes:
 
> The problem of secondarying the reverse zone isn't really discussed in
> the dns-pd draft, and there are a number of operational details I'd
> like to flesh out, but the specific question of secondarying the
> reverse zone isn't quite what it seems.
>  
> You secondary a zone so that the contents of the zone will be there
> when a query happens, but why would a query happen if the CPE device
> isn't reachable?  What would trigger that query?  So I think you can
> get away with _not_ secondarying the zone.  But if you do want to
> secondary it, why would the ISP be responsible for that?  Presumably
> the customer is pretty savvy; a secondary for their reverse tree would
> just be another service they'd want to buy or set up, and the ISP
> could wash their hands of it or sell it, whichever they chose.

Anything DNS related should be reliable.  Therefore a secondary would
be preferable to not having one.

For example, someone looking at logs that store only IP address for
performance reasons (this is common for http logs) would have only an
IP address.  Using the example in
http://www.ietf.org/mail-archive/web/homenet/current/msg01286.html an
email reporting a compromised host would have Mary-Perkins-Laptop" in
the email rather than a:b:c:d::123 in the email.

Yes.  I agree that ISPs won't even give you the time of day without
wanting to charge you for it.  [Ever ask about NTP service?  :)]
That doesn't mean we shouldn't define protocols that support doing
useful things, even if later an ISP may try to charge for it.

There are a few places where you can still get a free DNS secondary.
Definitely not at my ISP (not free or even for a fee).

Curtis

---

From: Michael Thomas <[email-masked]>
Date: Tue, 31 Jul 2012 18:55:12 -0700

> Doing the primary/secondary relationship this way is an operational choice; you are correct that the primary in this case wouldn't be listed as authoritative, but it would respond as if it were aut…

Ok, thanks. I have it my head that "primary/secondary" means something
else wrt DNS zone transfers, but I guess I'm just confusing it with bind's
terminology.

Mike

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 31 Jul 2012 23:47:46 -0400

In message <[email-masked]>
Michael Richardson writes:
 
>  
> >>>>> "Ted" =3D=3D Ted Lemon <[email-masked]> writes:
>     Ted> their hands of it or sell it, whichever they chose.=20
>  

The ISP is not doing dyndns, the CPE router is doing that and the
provider is secondary to that zone.  The zone should have a short TTL
(less than lease duration) and a long expire time to make it likely
that the secondary is giving accurate answers and keeps giving answers
for a while after the primary has gone away.

> the reverse.  (I don't really like that myself, but...)

But not the forward?  If the forward is
<host>.<site-email>.site.<provider-fqdn> -> <addr> and the reverse is
<inaddr>.arpa -> <host>.<site-email>.site.<provider-fqdn>, why is one
OK and the other not OK.

> and it would be better if the CPE was the only place with the info.

If its published in global DNS, recording it should not be a privacy
concern.

> Michael Richardson <[email-masked]>, Sandelman Software Works=20

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 01 Aug 2012 00:01:04 -0400

In message <[email-masked]>
Michael Richardson writes:
 
> >>>>> "Curtis" =3D=3D Curtis Villamizar <[email-masked]> writes:

Yes.  I know that.  Or a mail server, etc none of which is not in the
home.

If a problem is reported to the home user, then having a mapping of
address in the logs to host name would be a real good idea.

http logs on heavily loaded servers always record just the IP address
because the overhead of the rDNS lookups is too high.  I mentioned
that in prior email.

Very rarely is an end customer ever contacted, except perhaps an
automated mail from postmaster on an email server or a rare note from
a provider saying their host is compromised and is attacking others.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 01 Aug 2012 00:09:29 -0400

In message <[email-masked]>
 
> residential subscribers.  Any ISPs planning to do this?

Lee,

IMO IPv4 residential customer use is different than IPv6 use.

With IPv4 residential customers the only externally visible address is
the address of the NAT and that is dynamically allocated.

For IPv6 residential customers there is no reason not to statically
allocate a /64.  Each host can have a persistant globally routable
IPv6 address and then rDNS starts to make sense.

btw- How about SoHo customers and small business customers paying more
for their service and demanding static addresses?

Curtis

>  proprietary information, [ ...]

redirect to /dev/null please.