Subject: [homenet] DNS and IPV6 within the home

From: "Brzozowski, John" <[email-masked]>
Date: Fri, 9 Sep 2011 17:29:31 +0000

Wanted to share something here to get some feedback and to determine if
this is something that is in scope for HOMENET.

Consider the following:

* dual stack home network
* private IPv4
* global IPv6
* local DNS that resolves local hosts, this data is not available
authoritatively on the Internet

My home router supports RFC5006 (not sure the RFC was revised when the
router firmware was developed).  There is an IPv6 DNS server configured on
the router which is transmitted in the router advertisements.

A host on the network supports RFC5006.

When the host attempts lookups for local resources using the global IPv6
DNS server address it recurses to the Internet and never gets the answer
it expects for the local network resources.  The client resolver also
never attempts to contact the local, private IPv4 DNS server since the
IPv6 DNS is technically responding.  Explicit DNS queries to the local,
private DNS servers work but this not really usable.

Ultimately I had to disable DNS over IPv6 to ensure local and Internet
resources are resolvable.

In this case the local IPv4 DNS server is a separate server, frankly I am
not sure if having them be the same device ie the home router would make a
difference.  I suppose this would depend on the router's DNS capabilities.

It seems to me that this situation is bound to crop more up as IPv6
deployments increase.

John
=========================================
John Jason Brzozowski
Comcast Cable
e) mailto:[email-masked]
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=========================================

---

From: Jari Arkko <[email-masked]>
Date: Fri, 09 Sep 2011 20:58:59 +0300

I'm with you with similar setup. But I think this is mostly about being able to configure your border router with (a) the right DNS server address for DHCPv4 and (b) the right DNS server address for RFC 5006/DHCPv6. Is your problem that you don't get to do (b)? Or do you skip (a) as well, and then rely on local multicast naming discovery?

Jari

On 09.09.2011 20:29, Brzozowski, John wrote:
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

---

From: Teemu Savolainen <[email-masked]>
Date: Fri, 9 Sep 2011 21:07:13 +0300

Are the local names having some specific suffix in use, such as ".local" (or
just names without dots, like "example")? I was thinking if
draft-ietf-mif-dns-server-
select would be of any use, i.e. in this case the DNS server learn with
DHCPv4 could be configured to have knowledge of ".local" private
namespace...

Teemu

2011/9/9 Brzozowski, John <[email-masked]>

---

From: Fred Baker <[email-masked]>
Date: Fri, 9 Sep 2011 11:54:53 -0700

On Sep 9, 2011, at 11:07 AM, Teemu Savolainen wrote:

> Are the local names having some specific suffix in use, such as ".local" (or just names without dots, like "example")? I was thinking if draft-ietf-mif-dns-server-
> select would be of any use, i.e. in this case the DNS server learn with DHCPv4 could be configured to have knowledge of ".local" private namespace...

I believe that ".local" is in common use. Simply using names - are you aware of the proposal in ICANN for simply using names in the root zone? http://www.icann.org/en/topics/new-gtld-program.htm

---

From: Ray Bellis <[email-masked]>
Date: Fri, 9 Sep 2011 19:16:36 +0000

It has been suggested that a possible consequence of the new gTLD programme may be the deprecation of single label "local" hostnames and DNS search suffixes.

There may be no practical way to differentiate a single label hostname from a gTLD with an A (or AAAA) record at its apex.

For example, which should have priority if Canon get ".canon" but I also want a printer named that on my LAN?

I don't personally think that "DNS existence tests" will be sufficient - but ensuring that local nodes have their own private namespace (i.e. ".local") would avoid that.

Ray

Sent from my iPhone

On 9 Sep 2011, at 19:55, "Fred Baker" <[email-masked]<mailto:[email-masked]>> wrote:
I believe that ".local" is in common use. Simply using names - are you aware of the proposal in ICANN for simply using names in the root zone? <http://www.icann.org/en/topics/new-gtld-program.htm> http://www.icann.org/en/topics/new-gtld-program.htm

---

From: Fred Baker <[email-masked]>
Date: Fri, 9 Sep 2011 12:19:49 -0700

> I don't personally think that "DNS existence tests" will be sufficient - but ensuring that local nodes have their own private namespace (i.e. ".local") would avoid that.

yes

---

From: Mattia Rossi <[email-masked]>
Date: Sat, 10 Sep 2011 09:49:56 +1000

It should be something else than .local, as mDNS is using that (see 
Section 3 of 
http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-14). Use 
of .local in unicast DNS and mDNS creates some problems (see 
http://avahi.org/wiki/AvahiAndUnicastDotLocal)

I have a similar setup like John in the Lab (using FreeBSD machines and 
BIND).
I have two separate DNS severs, one for IPv4 transport and one for IPv6 
transport. Both resolve AAAA and A addresses. Both resolve local hosts: 
The IPv4 DNS resolves all hosts in the Lab, and all names are visible 
form the Internet, while the IPv6 DNS resolves only a few hosts 
(manually entered) using the same domain as the IPv4 hosts, but they're 
not visible from the Internet.
I'm using SLAAC and RFC6106 (obsoletes RFC5006) to advertise the IPv6 
DNS and a DNS search list, which consists of the domain the hosts are 
in. The IPv4 DNS is set up manually, but I've tested it with DHCP 
assigned DNS as well, and it's just the same.
The result is that on my client I have 4 DNS servers, 1 IPv6 and 3 IPv4.

Now if I resolve a host in the Internet, it goes via IPv6 transport to 
my IPv6 DNS which then goes via an other forwarder etc. until the name 
is resolved. No problem there, most of the time.
In unlucky cases the name can't be resolved, and it falls back using the 
IPv4 DNS, until the name can be resolved, or until every DNS server has 
been tried.

If I look up a local host, it goes via IPv6 DNS and if it can't be 
resolved (about 95% of the hosts can't), it will fall back to IPv4 DNS 
and resolve the names.

But I see the problem: I'm using an authoritative BIND, not forwarding 
requests for the "local" domain upstream, John's DNS server might 
forward it.
And I think that's the real problem. I think users might really want to 
use .whatever for their local domain rather than .local or something 
predefined.

And what if a user gets a domain form their ISP, and the ability to 
register one or two hosts via some web-interface, but can't push names 
via local DNS? I'm sure that the user would still set up multiple hosts 
using the very same domain fro local networking, but in that case he'd 
have partial visibility from the Internet, the two hosts registered via 
web-interface are visible, and the rest is not. How to deal with that?

Mat

On 10/09/11 05:19, Fred Baker wrote:
>> I don't personally think that "DNS existence tests" will be sufficient
>> - but ensuring that local nodes have their own private namespace (i.e.
>> ".local") would avoid that.
>
> yes
>
>

---

From: "Frank Bulk" <[email-masked]>
Date: Sat, 10 Sep 2011 08:34:48 -0500

Exactly. If the DNS server(s) handed out by the RG are configurable, then
one should be able to configure the IPv4 and/or IPv6 DNS servers.

Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jari Arkko
Sent: Friday, September 09, 2011 12:59 PM
To: Brzozowski, John
Cc: [email-masked]
Subject: Re: [homenet] DNS and IPV6 within the home

I'm with you with similar setup. But I think this is mostly about being able
to configure your border router with (a) the right DNS server address for
DHCPv4 and (b) the right DNS server address for RFC 5006/DHCPv6. Is your
problem that you don't get to do (b)? Or do you skip (a) as well, and then
rely on local multicast naming discovery?

Jari

---

From: Ray Bellis <[email-masked]>
Date: Sat, 10 Sep 2011 14:29:27 +0000

One should, yes.

Many existing ipv4 RGs don't however let you override the DNS settings correctly.  See RFC 5625 and SSAC035.

Ray

Sent from my iPhone

---

From: "Brzozowski, John" <[email-masked]>
Date: Sat, 10 Sep 2011 14:45:10 +0000

Jari,

(b) happens automatically and the router in my case is *not* the DHCPv4
server I used on the local network, I use a standalone DHCP server which
happens to the DNS server that is authoritative DNS internally.  The only
thing the router is doing for me is omitting router advertisements that
support RFC5006.  I believe I can configure the same meaning I can remove
the IPv6 address of the DNS server or change the IPv6 address.  I will
verify the later and circle back to the list.

John

On 9/9/11 1:58 PM, "Jari Arkko" <[email-masked]> wrote:

>I'm with you with similar setup. But I think this is mostly about being
>able to configure your border router with (a) the right DNS server
>address for DHCPv4 and (b) the right DNS server address for RFC
>5006/DHCPv6. Is your problem that you don't get to do (b)? Or do you skip
>(a) as well, and then rely on local multicast naming discovery?
>
>Jari
>

---

From: "Frank Bulk" <[email-masked]>
Date: Sat, 10 Sep 2011 10:53:30 -0500

Sections 5.1 and 5.3 specifically address the issue JB raised.  Thanks for
writing that up -- do we need a refreshed version for v6?  Hopefully not and
the vendors apply the same principles.

Frank

-----Original Message-----
From: Ray Bellis [mailto:[email-masked]] 
Sent: Saturday, September 10, 2011 9:29 AM
To: <[email-masked]>
Cc: Jari Arkko; Brzozowski, John; [email-masked]
Subject: Re: [homenet] DNS and IPV6 within the home

One should, yes.

Many existing ipv4 RGs don't however let you override the DNS settings
correctly.  See RFC 5625 and SSAC035.

Ray

Sent from my iPhone

---

From: "Brzozowski, John" <[email-masked]>
Date: Sat, 10 Sep 2011 15:57:06 +0000

Not using .local, using my on domain.com.

Unless I am missing something I am not sure the use of .local will resolve
what I am seeing.

I will also take at a look at the draft you mention below.

On 9/9/11 2:07 PM, "Teemu Savolainen" <[email-masked]> wrote:

>Are the local names having some specific suffix in use, such as ".local"
> (or just names without dots, like "example")? I was thinking if
>draft-ietf-mif-dns-server-select would be of any use, i.e. in this
>case the DNS server learn with DHCPv4 could be configured to have
>knowledge of ".local" private namespace...
>
>Teemu
>
>
>o) 609-377-6594 <tel:609-377-6594>
>m) 484-962-0060 <tel:484-962-0060>

---

From: "Howard, Lee" <[email-masked]>
Date: Sat, 10 Sep 2011 13:20:15 -0400

Your problem is that your .local [1] auth server is only available over IPv4?
Or said another way, your problem is that your IPv6 auth server is different
from your IPv4 auth server, and only the IPv4 version is authoritative for
.local?

I'd say this is a too-specific example of a valid problem case.  We should say
that the home gateway should be (by default) authoritative for .local [1] in
both IPv4 and IPv6.  If you want to configure separate resolvers with
different views, or define different auth servers for .local in IPv4 and IPv6,
then your breakage is your configuration problem, not a spec problem.

Lee

[1] Or  whatever, home users with global domain names are a corner case.
Substitute appropriate local zone if .local becomes unusable.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brzozowski, John
> Sent: Friday, September 09, 2011 1:30 PM
> To: [email-masked]
> Subject: [homenet] DNS and IPV6 within the home
>

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: "Brzozowski, John" <[email-masked]>
Date: Sat, 10 Sep 2011 17:24:39 +0000

My IPv6 DNS is currently forwarding to my service providers recursive DNS
servers or some other server on the Internet.

My local IPv4 DNS server privately addressed and will forward for any
request it is not authoritative for, which works fine.

I am going to change the setup so that the RFC5006 DNS server IPv6 address
and the IPv4 DNS server addresses are the same server.  This server will
have forwarding statements for the internal zones to the internal DNS
server.  I imagine this will iron things out.  Alternatively if the IPv4
local DNS servers were also IPv6 transport enabled I could just use it,
however, this is not the case.

The last scenario you describe below is indeed another case that requires
attention.  I have been doing this for years as such I have had to
manually managed two separate DNS systems.  One that is authoritative
globally on the Internet and one that is locally managed.

One thing to note, while both of the above are reasonable for the average
engineer to tackle it is unlikely that a lay person would know how to
manage these situations.

John

---

From: "Brzozowski, John" <[email-masked]>
Date: Sat, 10 Sep 2011 17:30:29 +0000

The problem is the router is handing out a separate recursive name server
for IPv6 via IPv6 router advertisements.  And the DHCP server for IPv4 and
IPv6 is *not* the router.  The issue is different configuration
information which happened automatically.

Like I said in an earlier post I think having the DHCP server and the
router advertisements point to the same server may address the issue.

Assuming the router in this case where an authoritative DNS server and it
was a DHCPv4/DHCPv6 server I imagine this would make life easier.  Some
routers are simply forwarder which would not really improve the situation.

John

On 9/10/11 1:20 PM, "Howard, Lee" <[email-masked]> wrote:

>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: "Brzozowski, John" <[email-masked]>
Date: Sat, 10 Sep 2011 17:31:08 +0000

John

---

From: Wouter Cloetens <[email-masked]>
Date: Mon, 12 Sep 2011 01:32:18 +0200

> however, this is not the case.

Indeed. This works fine in the setup I made for my company. Public 
lookups go upstream through my provider's IPv6 DNS server, local lookups 
go through the intranet's DNS server. Local lookups are defined as 
*.company.com and all the private IPv4 subnets. The IPv6 DNS server 
itself is authoritative for IPv6 until we merge the two some day.

> globally on the Internet and one that is locally managed.

One might think there's a need to merge those...

> engineer to tackle it is unlikely that a lay person would know how to

One might think the situation would improve if dual-stack RGW's were to 
have dual-stack DNS servers embedded in them...

bfn, Wouter
-- 
Architect Core Gateway   SoftAtHome R&D RGW  http://www.softathome.com/
http://www.linkedin.com/in/wcloetens  Vaartdijk 3/B701, B-3018 Wijgmaal
Tel: +32-16-852010      Mobile: +32-492-277790       Fax: +32-16-852099

This message and any attachments are confidential, intended solely for
the addressees and are SoftAtHome’s ownership.
Any unauthorized use or dissemination is prohibited. If you are not the
intended addressee of this message, please cancel it immediately and
inform the sender.

---

From: "Brzozowski, John" <[email-masked]>
Date: Wed, 14 Sep 2011 03:31:35 +0000

The RG is sending RFC5006 but another device, in my case, in the local
network is the DHCPv4 and local DNS server.

John

On 9/10/11 9:34 AM, "Frank Bulk" <[email-masked]> wrote:

>able

---

From: "Brzozowski, John" <[email-masked]>
Date: Wed, 14 Sep 2011 03:36:49 +0000

>itself is authoritative for IPv6 until we merge the two some day.

[jjmb] Interesting, certainly not the case for me.  The resolver never
tries a different DNS server once it gets responses from the IPv6.  Just
confirming, the DNS server (IPv6 transport) is authoritative for
*.company.com right?  If yes, this would explain why it works for you.
>have dual-stack DNS servers embedded in them...
[jjmb] this is one way to address the matter.

>the addressees and are SoftAtHome¹s ownership.

---

From: Mattia Rossi <[email-masked]>
Date: Wed, 14 Sep 2011 14:10:17 +1000

On 14/09/2011 13:36, Brzozowski, John wrote:
> On 9/11/11 7:32 PM, "Wouter Cloetens"<[email-masked]>
> wrote:
>
>

Hmm, I've gone through this again, and it seems just weird to me, that 
once you're not able to resolve the names via IPv6, you're client is not 
falling back and trying the IPv4 DNS server, in case the one listed 
first in your client is the Ipv6 one. If the first one listed is the 
IPv4 one, you should be able to resolve the name immediately (via IPv4).

On a side note:
In FreeBSD they just recently implemented RFC5006/RFC6106 following the 
lines of OpenResolv. The cool thing it does on the client, is to set up 
different DNS servers for different domains, so in your case it would 
point to your local DNS if you want to resolve any *.company.com, and to 
the other DNS for everything else (with fallback to the local DNS 
eventually)

Maybe we should push for that method to become standardised (if it 
hasn't been done yet).

Mat

---

From: "Brzozowski, John" <[email-masked]>
Date: Wed, 14 Sep 2011 04:16:39 +0000

>IPv4 one, you should be able to resolve the name immediately (via IPv4).
[jjmb] the IPv6 DNS server addresses are listed first and tried first. Why
would it try the others if there was not a failure?  No data is an
acceptable reply.  Agree if the IPv4 addresses are listed first this would
not be an issue, however, this is not how IPv6 behaves similar to how AAAA
are preferred over A.
>Maybe we should push for that method to become standardised (if it
[jjmb] now this seems interesting, is this available for testing yet?

---

From: Mattia Rossi <[email-masked]>
Date: Wed, 14 Sep 2011 14:25:32 +1000

On 14/09/2011 14:16, Brzozowski, John wrote:
> On 9/14/11 12:10 AM, "Mattia Rossi"<[email-masked]>  wrote:
>
>

Crap! Right! So you really need to have either a single server or to 
have authoritative entries in both. Or the solution below.

> [jjmb] now this seems interesting, is this available for testing yet?

It is already in FreeBSD 9.0: http://opal.com/jr/freebsd/rdnss/
Unfortunately it has not been backported to FreeBSD 8 yet, afaik.

A FreeBSD based LiveCD running 9.0-BETA2 can be obtained here: 
http://www.pcbsd.org/

Mat

---

From: Mattia Rossi <[email-masked]>
Date: Wed, 14 Sep 2011 14:32:27 +1000

> A FreeBSD based LiveCD running 9.0-BETA2 can be obtained here:

Oh, and of course: http://roy.marples.name/projects/openresolv

It might currently not be able to do what is actually needed in this 
case, it's pointing in the right direction, I think.

Mat

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 13 Sep 2011 22:59:36 -0700

> Maybe we should push for that method to become standardised (if it

There is still resistance that Split DNS occurs in real life.

However, draft-ietf-mif-dns-server-selection is somewhere that could
be useful to consider adding such support.

-d

---

From: Teemu Savolainen <[email-masked]>
Date: Wed, 14 Sep 2011 09:32:08 +0300

Cool!

So this behavior is as already described in
draft-ietf-mif-dns-server-selection Appendix A.2:
--

A.2.  Search list option for DNS forward lookup decisions

   A node can learn the special DNS suffixes of attached network
   interfaces from DHCP search list options; DHCPv4 Domain Search Option
   number 119 [RFC3397] and DHCPv6 Domain Search List Option number 24
   [RFC3646].  The node behavior is very similar as is illustrated in
   the example at section 5.  While these DHCP options are not intended
   to be used in DNS server selection, they may be used by the nodes as
   hints for smarter DNS server prioritization purposes in order to
   increase likelihood of fast and successful DNS query.

   Overloading of existing DNS search list options is not without
   problems: resolvers would obviously use the DNS suffixes learned from
   search lists also for name resolution purposes.  This may not be a
   problem in deployments where DNS search list options contain few DNS
   suffixes like 'example.com, private.example.com', but can become a
   problem if many suffixes are configured.

--
except that the MIF draft should also reference to RFC6106 (5006 does not
specify search list option). Adding for -05 version..

Anyhow, I recall comments that search list option should not be "overloaded"
with such use, but that it would be better to use explicit options to define
preferred DNS servers for specific domains and networks.

Best regards,

Teemu
2011/9/14 Dan Wing <[email-masked]>

---

From: Mattia Rossi <[email-masked]>
Date: Thu, 15 Sep 2011 14:06:02 +1000

Now, this is great.

Have to read the complete draft though.

Mat

On 14/09/11 16:32, Teemu Savolainen wrote:
>     suffixes like'example.com  <http://example.com>,private.example.com  <http://private.example.com>', but can become a
>
> except that the MIF draft should also reference to RFC6106 (5006 does
> not specify search list option). Adding for -05 version..
>
> Anyhow, I recall comments that search list option should not be
> "overloaded" with such use, but that it would be better to use explicit
> options to define preferred DNS servers for specific domains and networks.
>
> Best regards,
>
> Teemu
> 2011/9/14 Dan Wing <[email-masked] <mailto:[email-masked]>>
>
>      > On a side note:
>      > point to your local DNS if you want to resolve any *.company.com
>     <http://company.com>, and
>      > to
>     [email-masked] <mailto:[email-masked]>