Subject: [DNSOP] DNS names for local networks - not only home residental networks ...

From: "Walter H." <[email-masked]>
Date: Fri, 01 Sep 2017 21:39:12 +0200

Hello,

in the draft
https://tools.ietf.org/html/draft-ietf-homenet-dot-14

I read this line

"The domain name 'home.arpa.' is to be used for naming within
residential homenets."

when this draft becomes an RFC - hopefully this year 2017 - then there 
exists
an RFC, which gives you a domain name you can use in a home network/LAN
without conflicting to other things ..., the domain name 'home.arpa'

but there still doesn't exist any for company networks, they most 
commonly use
the domain name 'local', which I already noticed, that this conflicts to 
RFC 6762 ...

Thanks,
Walter

>> On 01.09.2017 20:47, Ted Lemon wrote:
>>> On Sep 1, 2017, at 2:46 PM, Walter H. <[email-masked]> wrote:
>>>> but there still doesn't exist any for company networks, they most commonly use
>>>> the domain name 'local', which I already noticed, that this conflicts to RFC 6762 ...
>>> That problem is not within the scope of the homenet working group to address.   You might consider raising it in the dnsop working group.
>

On 01.09.2017 19:47, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Home Networking WG of the IETF.
>
>          Title           : Special Use Domain 'home.arpa.'
>          Authors         : Pierre Pfister
>                            Ted Lemon
> 	Filename        : draft-ietf-homenet-dot-14.txt
> 	Pages           : 11
> 	Date            : 2017-09-01
>

---

From: Tony Finch <[email-masked]>
Date: Fri, 1 Sep 2017 20:47:35 +0100

Walter H. <[email-masked]> wrote:
>
> but there still doesn't exist any for company networks,

The point of the homenet name is to provide a zero-configuration namespace
for consumer devices.

Corporate environments are a somewhat different matter, since you can
expect them to own their own domain name and have people who can set up
devices to use it. Internal networks should either use a subdomain of the
company's public domain, or register a second domain for internal use.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Fastnet: Variable becoming southwest 3 or 4, then backing south 5 or 6 later.
Slight or moderate, becoming rough later in west. Rain later. Good, becoming
moderate or poor later.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 1 Sep 2017 15:58:25 -0400 (EDT)

> the domain name 'local', which I already noticed, that this conflicts to RFC 6762 ...

If you are a company and you are using a hardcoded domain of "local",
then you have been and still are, completely broken. The only fix is to
rename your network.

I think you might be confused, and see "local" domain stuff on your
enterprise network, eg mdns stuff. That is its own realm.

Paul

---

From: "Walter H." <[email-masked]>
Date: Fri, 01 Sep 2017 22:01:38 +0200

On 01.09.2017 21:47, Tony Finch wrote:
> Walter H.<[email-masked]>  wrote:
ACK
> devices to use it.
BUT this need not necessarily be a public domain ..., just think of 
Active Directory Domains ...
>   Internal networks should either use a subdomain of the
such a registry where you can register domains for internal use doesn't 
exist ...
not one registry is willing to give me a domain - even when I pay for 
this - which I only use in a LAN,
and the authoritativ DNS servers would then just be  127.0.0.1 or ::1

there is a security reason why companies often use .local for this case 
..., but since RFC 6762 this conflicts ...
so there is the need of a TLD a company can use without conflicting ...

---

From: "Walter H." <[email-masked]>
Date: Fri, 01 Sep 2017 22:05:09 +0200

> then you have been and still are, completely broken. The only fix is to
ACK and which non public domain name I can use for this
    that doesn't conflict now and will not conflict in the future?

---

From: Tony Finch <[email-masked]>
Date: Fri, 1 Sep 2017 21:06:35 +0100

Walter H. <[email-masked]> wrote:

> exist ... not one registry is willing to give me a domain - even when I
> pay for this - which I only use in a LAN, and the authoritativ DNS
> servers would then just be 127.0.0.1 or ::1

You don't need to get funny with nameserver addresses. If you are using a
subdomain of your public domain you can just not serve the zone to the
public Internet (which is what we do for private.cam.ac.uk). If you are
using a second domain name, you can just host an empty zone somewhere
public, separate from the real internal zone.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Malin, Hebrides: West backing south 4 or 5, then backing southeast 5 to 7
later. Slight or moderate, becoming rough later in west. Rain later in west.
Mainly good.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 1 Sep 2017 16:14:01 -0400 (EDT)

>   that doesn't conflict now and will not conflict in the future?

Something that's yours and not squatted. For example internal.mathemainzel.info.

Please see the last three years of dnsops and homenet working group list
archives.

Paul

---

From: Warren Kumari <[email-masked]>
Date: Sat, 2 Sep 2017 20:29:22 -0400

> Please see the last three years of dnsops and homenet working group list

... perhaps the other way of looking at the last thirty three years of
DNS is that people *do* actually want something like this, and that
perhaps it is time to actually create something specifically for it.
Our smacking people on the nose with rolled up newspapers and saying
"no, bad operator" ignores the fact that people still want this, and
still do this, and there ain't nothing we can do to stop them...

And so: https://tools.ietf.org/html/draft-wkumari-dnsop-internal-00

This asks for a Special Use Name, specifically for this sort of thing
(and, yes, for building test networks, and for labeling devices which
have no Internet connection, etc). The desire and need for something
like this has been identified / discussed for a long time - the most
recent was probably when we decided that .alt would only be for
non-DNS contexts, and that someone should go make something like this
for the DNS - think of it like RFC1918 for names.
 It will require an unsecured delegation, for which we currently have
no process, and this (if people think it is a good idea!) will require
process to be created -- which A: will take many many years, and B: if
at least somewhat unlikely to happen -- but, if we don't at least ask,
we certainly won't get it...

And yes, this is somewhat of a straw-man.
W

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

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Ralph Droms <[email-masked]>
Date: Sat, 2 Sep 2017 20:36:50 -0400

> On Sep 2, 2017, at 8:29 PM, Warren Kumari <[email-masked]> wrote:
> 

Warren - I've only read part of your draft, and I'll comment on that part of it...

I was immediately struck by the parallel between <something-internal> and home.arpa.  How are the two cases different?  Can you explain why this text from section 3.2 of your doc applies to internal.arpa and not to homenet.arpa?  

   It may also cause issues when server operators
   override part of the .arpa domain in order to instantiate
   something.arpa.

- Ralph

---

From: Warren Kumari <[email-masked]>
Date: Sat, 2 Sep 2017 20:54:31 -0400

On Sat, Sep 2, 2017 at 8:36 PM, Ralph Droms <[email-masked]> wrote:
> I was immediately struck by the parallel between <something-internal> and
> home.arpa.  How are the two cases different?  Can you explain why this text
> from section 3.2 of your doc applies to internal.arpa and not to
> homenet.arpa?

Honestly, not really. Well, more fully, I don't have a very concrete
answer, but I *do* have a lot of handwaving if you'd like?

This text made me uncomfortable when I wrote it, for a number of
reasons. Firstly, I am somewhat concerned that some set of people will
manage to break arpa when they put in magic for home.arpa, but I also
feel that the deployments scenarios are likely to be somewhat
different - for home.arpa I'm assuming that this will be added to
name-server distributions, and the names that *do* exist will be
automatically created, and answered from homenet devices. If there
were an "internal.arpa", I'm assuming that it would be much more
likely that some admin behind a keyboard will be editing zonefiles and
fiddling with the config, and so more likely to break it.

As I said, this is a very hand-wavey argument, fully divorced from
rigor. But, whatever the case, much of the purpose of this is for
internal namespaces, where users will be seeing and interacting with
the names (and not using automated UIs) -- and so I think that
internal.arpa fails the "does this look nice" test (which is also
hand-wavey :-))

W

---

From: Paul Vixie <[email-masked]>
Date: Sat, 02 Sep 2017 19:23:30 -0700

Warren Kumari wrote:
> On Fri, Sep 1, 2017 at 4:14 PM, Paul Wouters<[email-masked]>  wrote:

i think what people want is bigger than this, and that as a part, this 
part is small. one of the big differences between internet and its early 
competitors such as appletalk or decnet or the rest is that while the 
networks that died so that the internet could live did not scale -- they 
worked in a building or a network or a campus or a corporation, but not 
globally. whereas the internet works globally, but not locally.

we do not have well defined automation for making local names work when 
the internet connection is down. at a very modest level of necessary and 
inevitable complexity, one's own in-perimeter recursive servers can't 
find one's own in-perimeter authority servers. so if your internet 
connection goes down, then way more stuff becomes effectively 
unreachable than what's on the far side of the disconnection point.

mark andrews faced disconnections of this kind as a daily part of his 
work about 30 years ago when he developed the "stub zone" feature and 
contributed it to BIND4. but we have yet to automate it. and this rat 
hole is a deep one, because sometimes the disconnection is "all the 
links connecting my city / state / island / country to the rest of the 
global internet" and sometimes it's just your laptop, or one vm, or your 
LAN, or your house or office or campus.

in other words the necessary automation isn't going to benefit from 
static hints. it's a pity we can't rely on multicast for this kind of 
thing, although that often will work at the campus level.

in any case what "people *do* actually want" here is that naming always 
works for the devices and services one can reach and wishes to reach by 
name, for a network of arbitrary diameter, from a single container all 
the way up to interplanetary scope.

figuring out what names to reserve for which magnitude of diameter is a 
fool's errand, and so i've been ignoring homenet and all of its DNS 
related work.

we've been making people edit a "hosts" file for local naming and that's 
crazy. apple did something slightly more marketable by using multicast 
but that doesn't scale either. we've been making rfc1918 networks run a 
fake root zone that contains delegations to local servers. this is all 
wrongthink. it's not what the internet should be or how it should feel 
to use. we have PnP for devices now, but hardly for networks, unless all 
of the devices on the network come from apple, and none of them are 
outside the local (corporate? campus?) multicast domain.

DNS was a necessary first step and we took it. but we've known for at 
least the last 25 years that its architecture was too rigid when it 
comes to reachability by packet or of naming systems. if it's time to 
think about what people actually want to be doing, let's start there.

> And so: https://tools.ietf.org/html/draft-wkumari-dnsop-internal-00

...not here.

-- 
P Vixie

---

From: Måns Nilsson <[email-masked]>
Date: Sun, 3 Sep 2017 06:32:02 +0200

> BUT this need not necessarily be a public domain ..., just think of Active
> Directory Domains ...

AD is DNS, and it follows the same rules. A sub-domain, a separate domain
or two-face (using the same domain name as you public-facing resources
but a different set of authoritative servers and some careful setup of
full-service resolvers), all work. The single thing that does not work
is to use name-space you do not own (like LOCAL or a domain name from a
non-existent TLD, like "web". Ooops. It does now...) and hope it doesn't
escape. Or that somebody registers the name and tries to impersonate you.

I've run two-face, and the results were excellent. But watch out with
DNSSEC; you need to have the same keys signing both zones.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE           SA0XLR            +46 705 989668
Our father who art in heaven ... I sincerely pray that SOMEBODY at this
table will PAY for my SHREDDED WHAT and ENGLISH MUFFIN ... and also
leave a GENEROUS TIP ....

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 3 Sep 2017 03:21:19 -0400

Hi,

On Fri, Sep 01, 2017 at 10:01:38PM +0200, Walter H. wrote:
> not one registry is willing to give me a domain - even when I pay for this -
> which I only use in a LAN,

I respectfully disagree.  You could register any domain you like today
and fence it off just as effectively as you might wish.  Please
provide an example where you cannot.

> there is a security reason why companies often use .local for this case ...,

Any company that uses .local for any security reasons is one that I
want as my competitor.  I'd love to know the names of such companies!

Best regards,

A
-- 
Andrew Sullivan
[email-masked]

---

From: "Walter H." <[email-masked]>
Date: Sun, 03 Sep 2017 20:47:30 +0200

On 03.09.2017 06:32, Måns Nilsson wrote:
> AD is DNS, and it follows the same rules.
yes and no; AD is more, and so many companies got the advice to use a 
domain name,
that is NOT public, because it is not internet ...
>   A sub-domain, a separate domain
even if I fully ACK this, but 15 years ago, nobody said, that  ".local", 
... would conflict one day ...
and also the company I work for has decided at these times to use a 
".local" as internal domain and AD;
now it is impossible to change this ...

I for myself use a ".home.arpa" as internal name (I'm no company just a 
citizen),
and for IPv6 connections I use a subdomain of my public domain,
which is only used to get resolved correctly ...
e.g.  the IPv6 of my proxy resolves to  proxy.sub.example.com and 
proxy.sub.example.com resolved to this IPv6 ...
and router (firewall) blocks the whole prefix to be connected from 
outside (internet) ...

Greetings,
Walter

---

From: "Walter H." <[email-masked]>
Date: Sun, 03 Sep 2017 21:07:22 +0200

> perhaps it is time to actually create something specifically for it.
just a simple question: why hadn't there been such at the very beginning,
which could have prevented situations like the following:

"a company gets the advice to use a ".local" as the internal domain and 
Active Directory;
at these times nobody would have thought, that this could be a 
conflicting problem in the future ...;
and now it is impossible to change this ..."

now telling an admin not to use ".local" is easy, but 15 years ago ...

---

From: Mark Andrews <[email-masked]>
Date: Mon, 4 Sep 2017 07:38:53 +1000

> ]On 4 Sep 2017, at 4:47 am, Walter H. <[email-masked]> wrote:
> 
> even if I fully ACK this, but 15 years ago, nobody said, that  ".local", ... would conflict one day ...
> and also the company I work for has decided at these times to use a ".local" as internal domain and AD;

Why would anyone tell you that “.local” would conflict when you were supposed
to register a name *before* using it.  That’s been the case since the very beginning.
No one ever said there would not be new TLD’s registered.  You gambled and you
lost.

If you are doing AD correctly you should be able to register you machines wherever
they connect to the Internet and that requires a public registration.

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

---

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 03 Sep 2017 14:51:51 -0700

On 3 Sep 2017, at 14:38, Mark Andrews wrote:

> to register a name *before* using it.

Because some vendors gave bad advice in their documentation, 
particularly in examples.

> That’s been the case since the very beginning.

If an end-user follows advice from vendors, and the vendors turn out to 
be wrong, maybe statements like that are inappropriate.

> they connect to the Internet and that requires a public registration.

And that is what Microsoft has suggested in all their documentation for 
many years.

--Paul Hoffman

---

From: "Walter H." <[email-masked]>
Date: Mon, 4 Sep 2017 08:12:39 +0200

> to register a name *before* using it.

NAK: because there are two points:
the 1st: uniqueness is not a requirement here
the 2nd: global knowledge of locally used names might raise a security
problem ...

> they connect to the Internet and that requires a public registration.

you could that also say the other way round: if the folks had done their
job correct and made a DNS-pendant to RFC1918, many enterprises wouldn't
have the problems now, which are unresolveable ...

by the way: why are you discussing about DNSSEC for names that are used
only locally?

---

From: Jim Reid <[email-masked]>
Date: Mon, 4 Sep 2017 09:26:14 +0100

> On 4 Sep 2017, at 07:12, Walter H. <[email-masked]> wrote:
> 

Why do you seem to assume there are never, ever any DNS security issues on the local net?
Why would someone want to deliberately configure things to prevent DNSSEC-aware applications and resolvers from working on the local net?

---

From: "Walter H." <[email-masked]>
Date: Mon, 4 Sep 2017 10:54:44 +0200

> Why do you seem to assume there are never, ever any DNS security issues on

when there are troubles on the local net, DNS security issues are the less
problem ...

I'd say: "either you trust the local net or not";

> Why would someone want to deliberately configure things to prevent
> DNSSEC-aware applications and resolvers from working on the local net?

because of its strange signature procedure: a zone doesn't have to be
resigned, when it changes ...

---

From: Mark Andrews <[email-masked]>
Date: Mon, 04 Sep 2017 18:58:40 +1000

In message <[email-masked]>, "Walter
> the 2nd: global knowledge of locally used names might raise a security

Except you misses the entire point of getting a registered name,
that is to be able to use it safely without anyone trampling on its
use.  'home.arpa' is in the process of being registered so that it
can be used safely in the environment it is designed to be used in.

Yes, 'home.arpa' will be registered.  It's a different type of
registration to the one that is normally done by talking to your
friendly DNS registrar but it is a registration.

> have the problems now, which are unresolveable ...

Names are not addresses.  They have different properties.
 
> by the way: why are you discussing about DNSSEC for names that are used

I'm discussing about putting names through the DNSSEC validator and
not having the fail validation.  It is also possible to use DNSSEC
within home.arpa.  It requires more care especially if you have a
mobile device but it is possible.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Mon, 04 Sep 2017 19:04:55 +1000

In message <[email-masked]>, "Walter
> resigned, when it changes ...

And no one said you have to use DNSSEC to sign any zone.  The
discussion is around making DNSSEC validating software work without
having to update all of it to support people using home.arpa.  That's
starts by having a delegation for home.arpa.

Mark

---

From: Jim Reid <[email-masked]>
Date: Mon, 4 Sep 2017 10:10:00 +0100

> I'd say: "either you trust the local net or not"

I'd say trust but verify. Everywhere. => In this context always doing DNSSEC validation.

---

From: "Walter H." <[email-masked]>
Date: Mon, 4 Sep 2017 11:50:03 +0200

> use.

where there anyone who said: "don't use it", 15 years ago?

> 'home.arpa' is in the process of being registered so that it

yes, but commonly for residental networks, not company/enterprise networks,
they want/need something shorter like ".corp", ".lan", ".local", ...

> friendly DNS registrar but it is a registration.

exact such a name but a TLD is needed for companies/enterprises in order
to prevent new ones doing the mistakes of old ones ..., and having the
safety not having a conflict in the future ...

> Names are not addresses.  They have different properties.

that is not the point,
the point is, that in those days where these companies decided to use
.local, .corp, ... such a paper prevented these decisions and now it could
have been expanded with DNSSEC features ...

just guess what would have happened when there was no RFC1918; by the way,
I would not have any problem changing my internal IPv4 addresses from e.g.
10.x.x.x to let's say 52.x.x.x - it is only a thought;

companies that use .local as their internal domain name and/or Active
Directory have no problem as long as there is no system that insists on
using mDNS for .local as specified in RFC6762

---

From: Måns Nilsson <[email-masked]>
Date: Mon, 4 Sep 2017 12:41:57 +0200

Subject: Re: [DNSOP] DNS names for local networks - not only home residental networks ... Date: Sun, Sep 03, 2017 at 08:47:30PM +0200 Quoting Walter H. ([email-masked]):
> yes and no; AD is more, and so many companies got the advice to use a domain
> name,

A lot of Microsoft -focused consultants have, say, a very confused view
of what the Internet is, and especially what DNS is. Consequently,
a lot of FUD is propagated about the AD implementation.  Reading the
TechNet whitepapers and combining that data with some testing  soon
reveals that the only strange thing in AD DNS is the use of GSSAPI to
secure updates. This has seen 3rd party implementation, and is used in
both commercial and open-source software to provide DNS to AD. It is
only DNS, well thought out and used do a lot of things.

> would conflict one day ...

Nobody said that it would be conflict-free forever either. The best
available strategy was, and is, to use names within a domain you have
some control over.

> now it is impossible to change this ...

Bad advice does not improve with aging. 
 
> and router (firewall) blocks the whole prefix to be connected from outside
> (internet) ...

Practical operational experience suggests that firewalls leak. Not in the expected
ways, but in new unforseen trickles. 

The best available strategy was, and is, to use names within a domain
you have some control over. It seems I'm repeating myself. My
apologies. I'll quit now.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE           SA0XLR            +46 705 989668
The PILLSBURY DOUGHBOY is CRYING for an END to BURT REYNOLDS movies!!

---

From: Mark Andrews <[email-masked]>
Date: Mon, 04 Sep 2017 22:22:22 +1000

> where there anyone who said: "don't use it", 15 years ago?

Yes.  There were lots that discourage the use of .local, lan,
.corp etc.  Just becaue you didn't hear from them doesn't mean
they weren't out there.

> they want/need something shorter like ".corp", ".lan", ".local", ...

Want maybe, need absolutely not.
 
> have been expanded with DNSSEC features ...

Everyone was told to register the domain you want to use, there was
no exception for active directory.

> 10.x.x.x to let's say 52.x.x.x - it is only a thought;

IPv6 would have been deployed a lot sooner. :-)
 
> using mDNS for .local as specified in RFC6762

Except such systems exist.  Go look at what a Mac does.  ping for
test.local and look and port 5353 traffic and compare it to port 53
traffic.

Mark

---

From: "Walter H." <[email-masked]>
Date: Mon, 4 Sep 2017 14:54:39 +0200

> .corp etc.  Just becaue you didn't hear from them doesn't mean

a discourage is not a "don't use" :-)

> Want maybe, need absolutely not.
question: why isn't this the answer of a car dealer?

> no exception for active directory.

not really, at those days only a few TLDs where possible, the many TLDs
came some years later ...

by the way: where is the problem with .home or .corp?
I ask this, because at my hoster I pre-reserved my "local domain" - a
.home, that I have used for many years several zears ago and nothing
happened ...

> IPv6 would have been deployed a lot sooner. :-)

not really, my ISP is still IPv4 only ..., my IPv6 connectivity is a
HE-tunnel ...
and the brand new OS from Microsoft still has the bugs inside: TEREDO, ...
which I had to deactivate first, before it is usable with IPv6 at all ...

> test.local and look and port 5353 traffic and compare it to port 53

I know, this RFC was written by Apple;

no Apple no problem, I would say :-)

---

From: Petr Špaček <[email-masked]>
Date: Mon, 4 Sep 2017 14:56:58 +0200

> they want/need something shorter like ".corp", ".lan", ".local", ...

I would like to comment on
'vendor told us and we followed his instructions'.
Maybe it is time to follow the new docs, e.g.:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Configure_Host_Names.html#sec-Recommended_Naming_Practices

Software and its docs have bugs which get fixed over time and there is
not way around it. Configuration has to follow the suit.

Please keep in mind that reserving a new name will not magically solve
the issue.

1. Existing systems will stay broken *unless* the reservation is for the
same string as used by particular network. Certainly this will not be
the case for all the broken installations.

In other words, some networks will stay non-complaint whatever dnsop
will do, which means that the broken networks will either get fixed over
time or stay broken. I do not see dnsop having real influence over this
aspect of network operation, sorry.

2. Also, reserving a random string does not solve problem of VPNs
between companies (customer using VPN to supplier's network, for
example), company mergers, etc.

If we reserved string 'example.', how it helped to solve the problem
when your company X needs to establish VPN tunnel to company Y internal
network to access its systems? How does it help if company X merges with
company Y?

Really, unique strings are the way to go.

Petr Špaček  @  CZ.NIC

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 4 Sep 2017 16:54:16 +0200

On Fri, Sep 01, 2017 at 10:01:38PM +0200,
 Walter H. <[email-masked]> wrote 
 a message of 125 lines which said:

> not one registry is willing to give me a domain - even when I pay
> for this - which I only use in a LAN, and the authoritativ DNS

That's clearly not true. .fr, for instance (but it is not the only
one) allows registration of a domain without name servers (or with
funny name servers such as ::1).

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 4 Sep 2017 16:59:16 +0200

On Mon, Sep 04, 2017 at 08:12:39AM +0200,
 Walter H. <[email-masked]> wrote 

> the 1st: uniqueness is not a requirement here

Serious mistake. Companies merge, and are bought. Any netadmin had, at
least once in his professional life, to manage RFC 1918 networks
merging and collisioning after some corporate change.

If it's not realistic to switch from .local to the proper
.private.mycompany.com to follow Best Practices, then it is certainly
not realistic to do so when two companies merge, and their .local
collide.

> the 2nd: global knowledge of locally used names might raise a
> security problem ...

You don't have to make the nameservers reachable from the outside. Most
of the time, name servers for .private.mycompany.com are
internal-only.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 4 Sep 2017 17:01:51 +0200

On Mon, Sep 04, 2017 at 10:54:44AM +0200,
 Walter H. <[email-masked]> wrote 

> I'd say: "either you trust the local net or not";

I don't claim to be a security expert, but I think it is a
mistake. Many local networks are vulnerable to packets with an
internal address coming from the outside, routing attacks diverting
traffic outside, etc. Not to mention the internal attacks, for
instance by a MS-Windows zombie.

It seems to me that having TLS, DNSSEC and SSH and so on even in the
local net is Best Practice.

---

From: "Walter H." <[email-masked]>
Date: Mon, 04 Sep 2017 17:21:54 +0200

On 04.09.2017 17:01, Stephane Bortzmeyer wrote:
>   Walter H.<[email-masked]>  wrote
> ..., but I think it is a
> mistake.
not really, when  there is a security problem, DNS is the less one ...
and I didn't say, that a locally running resolver would not be allowed 
to validate DNSSEC;
but there needn't be a DNSSEC signed local only zone, as the signature 
and zone content comes from the same host;
you can of course validate your own local only zone, nobody prevents you 
from doing so, but it is somewhat strange;
and the fact that a change of the zone doesn't need to be resigned 
raises problems to;

  Many local networks are vulnerable to packets with an
internal address coming from the outside, routing attacks diverting
traffic outside, etc. Not to mention the internal attacks, for
instance by a MS-Windows zombie.

even this is true, DNSSEC for the local zones doesn't make it any better;
as I said, when there is a security problem DNS is the less one ...

> local net is Best Practice.
yes and no; when operating a local  mail server that uses TLS for IMAP, 
SMTP, then
a Anti-virus has to break TLS in order to scan before it gets to the 
client ...

---

From: "Walter H." <[email-masked]>
Date: Mon, 04 Sep 2017 17:25:18 +0200

> funny name servers such as ::1).
this might be a mistake of mine, as I meant registrar, hoster which I 
considered ...

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 4 Sep 2017 17:28:29 +0200

On Mon, Sep 04, 2017 at 05:21:54PM +0200,
 Walter H. <[email-masked]> wrote 
 a message of 114 lines which said:

> when operating a local mail server that uses TLS for IMAP, SMTP,
> then a Anti-virus has to break TLS in order to scan before it gets
> to the client

Which is also a very bad idea, giving the current state of such tools:

http://users.encs.concordia.ca/~mmannan/publications/ssl-interception-ndss2016.pdf

https://jhalderm.com/pub/papers/interception-ndss17.pdf

---

From: Paul Vixie <[email-masked]>
Date: Mon, 04 Sep 2017 11:42:58 -0700

Mark Andrews wrote:
> In
> message<[email-masked]>,
> "Walter H." writes:
> Yes.  There were lots that discourage the use of .local, lan, .corp
> etc.  Just becaue you didn't hear from them doesn't mean they weren't
> out there.

alas, bad advice can circle the earth five times before the
countervailing good advice can get its shoes on.

-- 
P Vixie

---

From: Tony Finch <[email-masked]>
Date: Mon, 4 Sep 2017 20:16:37 +0100

> On 4 Sep 2017, at 13:54, Walter H. <[email-masked]> wrote:
> 
> not really, at those days only a few TLDs where possible, the many TLDs came some years later ...

It should have been clear after 1997-1998 from the discussions of the IAHC and the setup of ICANN that there would be a lot more TLDs. It took a long time to ramp up but the process started more than 20 years ago.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at

---

From: Tony Finch <[email-masked]>
Date: Mon, 4 Sep 2017 20:29:57 +0100

> On 3 Sep 2017, at 22:51, Paul Hoffman <[email-masked]> wrote:
> Because some vendors gave bad advice in their documentation, particularly in examples.
> 
> And that is what Microsoft has suggested in all their documentation for many years.

However, Microsoft did encourage their customers to use .local names for Active Directory domains for quite a long time - see for example this link to the documentation for Windows Small Business Server 2003. It isn't fair to only blame MS customers for choosing .local domains.

https://technet.microsoft.com/en-us/library/cc747455(v=ws.10).aspx

Tony.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 05 Sep 2017 06:45:49 +1000

In message <[email-masked]>, "Walter
> a discourage is not a "don't use" :-)

We gave them fair warning that and domain they choose could be
allocated in the future.  We told them to the advice you have been
getting today.  Use a zone registered to them.  They, like you are
today, are ignoring the advice.

> question: why isn't this the answer of a car dealer?

Because the car dealer is trying to take as much money off you as
they can.  We on the other hand are trying to save you money by
stopping you and everyone else getting into situations that will
cost you/them thousands of dollars to rectify in the future.

> came some years later ...

People were wanting to deploy more TLDs from the moment the Internet
was opened up to the public.

> which I had to deactivate first, before it is usable with IPv6 at all ...

If you didn't have the relief valve of RFC 1918 addresses then yes
IPv6 would have come a lot quicker and stuff like TEREDO wouldn't
exist.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 04 Sep 2017 14:39:58 -0700

Tony Finch wrote:
> It should have been clear after 1997-1998 from the discussions of the
> IAHC and the setup of ICANN that there would be a lot more TLDs. It
> took a long time to ramp up but the process started more than 20
> years ago.

money changes everything.

-- 
P Vixie

---

From: "Michael H. Warfield" <[email-masked]>
Date: Mon, 04 Sep 2017 18:12:05 -0400

> However, Microsoft did encourage their customers to use .local names
> for Active Directory domains for quite a long time - see for example
> this link to the documentation for Windows Small Business Server
> 2003. It isn't fair to only blame MS customers for choosing .local
> domains.

> https://technet.microsoft.com/en-us/library/cc747455(v=ws.10).aspx

I would point out an analogous situation with documentation and
addresses.  The documentation that accompanied Sun Microsystems SunOS
and Solaris used examples of IP address 1.1.1.1 and 1.2.3.4 and
similar, now making those blocks toxic since that /8 was assigned to
APNIC.  IIRC, they also used names like .local and .test in some of
their doco.  This isn't just a Microsoft think (and I'm far FAR from a
Microsoft apologist).  Sometimes our tech writers do things they
shouldn't when their crystal ball is cloud and we get stuck with the
results.  And I've dealt with far FAR worse.

> Tony.

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (o) +1 706 850-8773 |  [email-masked]
   /\/\|=mhw=|\/\/          | (c) +1 678 463-0932 |  http://www.wittsend.com/mhw/
ARIN whois: ARIN-MHW9       | An optimist believes we live in the best of all
PGP Key: 0xC0EB9675674627FF | possible worlds.  A pessimist is sure of it!

---

From: Lyndon Nerenberg <[email-masked]>
Date: Mon, 4 Sep 2017 15:22:35 -0700

> On Sep 4, 2017, at 3:12 PM, Michael H. Warfield <[email-masked]> wrote:
> 

Wasn't 192.9.200 (from the Sun docs) the "1918" network of the mid-1980s?  I also recall SunOS manuals from that era encouraging customers to contact SMI if they needed a class C network block.

--lyndon

---

From: Mark Andrews <[email-masked]>
Date: Tue, 05 Sep 2017 08:42:18 +1000

In message <[email-masked]>, "Michael H. Warfield" write
> results.  And I've dealt with far FAR worse.

The keyword above was examples which they clearly were.  Most of
1.0.0.0/8 is in use today despite those examples.  The use of local
test were also clearly examples.  The Microsoft page above advocated
the use literal use of .local which is very different.

APNIC could allocate those addresses if they wished without much
issues.  I'm sure there would be lots of takers even given the known
limitations.  There would be a little extra traffic.  They are
perfect for eyeball only usage.  The real issues arise if you try
to use those addresses for servers.

Mark

---

From: Tony Finch <[email-masked]>
Date: Tue, 5 Sep 2017 00:02:21 +0100

> On 4 Sep 2017, at 23:42, Mark Andrews <[email-masked]> wrote:
>> 
> The Microsoft page above advocated

Worse than that! It was the default suggested by the software!

I think this dated from the late 1990s when registering domain names was quite expensive and inconvenient, so I can see why they did it. A better alternative would have been to make the default parent domain something registered by MS, instead of a fake TLD.

Tony.

---

From: "Walter H." <[email-masked]>
Date: Tue, 5 Sep 2017 05:53:47 +0200

On Mon, September 4, 2017 21:16, Tony Finch wrote:
> It should have been clear after 1997-1998 from the discussions of the IAHC
> and the setup of ICANN that there would be a lot more TLDs.

"would" is fiction ...

---

From: "Walter H." <[email-masked]>
Date: Tue, 5 Sep 2017 05:56:12 +0200

On Mon, September 4, 2017 22:45, Mark Andrews wrote:
> they can.

and the registries are for free?

---

From: "Walter H." <[email-masked]>
Date: Tue, 5 Sep 2017 06:01:52 +0200

> the use literal use of .local which is very different.

and now in the IPv6 ages the same bug is done again ...

2001:db8: ...

---

From: "Walter H." <[email-masked]>
Date: Tue, 5 Sep 2017 06:04:04 +0200

On Tue, September 5, 2017 01:02, Tony Finch wrote:
>
> A better
> alternative would have been to make the default parent domain something
> registered by MS, instead of a fake TLD.

yes and no;  I still don't have "my" .home even I pre-registered it
several years ago ...

---

From: "Walter H." <[email-masked]>
Date: Tue, 5 Sep 2017 06:09:06 +0200

On Mon, September 4, 2017 21:29, Tony Finch wrote:
>
> However, Microsoft did encourage their customers to use .local names for
> Active Directory domains for quite a long time - see for example this link
> to the documentation for Windows Small Business Server 2003. It isn't fair
> to only blame MS customers for choosing .local domains.
>

I see it exact this, and it would be fair to prevent future bugs with
defining one or two FAKE TLDs (e.g. .corp, .lan) for exact this use case;

as I said there are 2 points:
- there isn't really a uniqness as requirement
- a public WHOIS grabbing for these domains needn't also be given;

---

From: Mark Andrews <[email-masked]>
Date: Tue, 05 Sep 2017 14:34:29 +1000

In message <[email-masked]>, "Walter
> > and the setup of ICANN that there would be a lot more TLDs.

Yes, it was clear that there would be more TLD's then even if most
of them would be run by speculators and would provide little benefit.
This was a little before Jon's death in 1998.  I remember having
lunch with him and thinking about this issue over lunch.

Mark

---

From: "Walter H." <[email-masked]>
Date: Tue, 5 Sep 2017 06:46:35 +0200

On Tue, September 5, 2017 06:34, Mark Andrews wrote:
>> IAHC

as I said "would" is fiction, and not real, so these didn't help anything ...

> This was a little before Jon's death in 1998.

I know Mr. "RFC-Editor"

> I remember having

and nothing happened ...

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 5 Sep 2017 09:04:29 +0200

On Tue, Sep 05, 2017 at 06:09:06AM +0200,
 Walter H. <[email-masked]> wrote 

> defining one or two FAKE TLDs (e.g. .corp, .lan) for exact this use

Why does it need to be a TLD (see all the discussions here about
Special Use Domain Names, .alt, .alt.arpa, etc)? Why not
lan.mycompany.com?

> - there isn't really a uniqness as requirement

As I said before, and explained, you're wrong here, since you don't
take merging and acquisition into account.

> - a public WHOIS grabbing for these domains needn't also be given;

With a subdomain of your Second Level Domain, no need for WHOIS (or
RDAP).

But I agree that ICANN rules for the .corp TLDs are stupid. If
McDonald's register .MCDONALDS, why do they need delegation and public
social info for the SLD?

---

From: "Walter H." <[email-masked]>
Date: Tue, 5 Sep 2017 10:14:57 +0200

On Tue, September 5, 2017 09:04, Stephane Bortzmeyer wrote:
> Special Use Domain Names, .alt, .alt.arpa, etc)?

.alt is a TLD ...

> Why not lan.mycompany.com?

because mycompany.com is in WHOIS ..., see below

> As I said before, and explained, you're wrong here,

no, because nobody said, that uniqness is forbidden ..., and uniqness
implicitly requires the other point which I'd say, that MUST NOT

> With a subdomain of your Second Level Domain, no need for WHOIS (or

you are wrong ...
the subdomain is part of the Second Level Domain and so there is a need
for WHOIS (or RDAP) for the Second Level Domain ...

---

From: Matthew Pounsett <[email-masked]>
Date: Tue, 5 Sep 2017 09:45:55 -0400

On 5 September 2017 at 00:01, Walter H. <[email-masked]> wrote:

> 2001:db8::/32 is reserved for documentation in RFC 3849.  As 192.0.2.0/24,
198.51.100.0/24, and 203.0.113.0/24 were in RFC 5737.

It's not a bug, it's a feature.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 6 Sep 2017 13:22:57 -0400

On Sat, Sep 02, 2017 at 07:23:30PM -0700, Paul Vixie wrote:

> it to BIND4. but we have yet to automate it. and this rat hole is a deep
> one, because sometimes the disconnection is "all the links connecting my
> city / state / island / country to the rest of the global internet" and
> sometimes it's just your laptop, or one vm, or your LAN, or your house or
> office or campus.

Nevertheless, I think you're right that this is a part of a much
bigger issue.  I was vaguely hopeful, once, that it was an issue
homenet was going to tackle, but I think it won't.  The issue, really,
is that people want an inter-net that works tolerably well when
arbitrary parts of the infrastructure break, and they want to do that
without any management overhead, and they want to do it on networks
that were designed more as "Internet clients" than "internetworking
networks".

Ironically, of course, the early Internet had a relatively high
failure tolerance, because the network wasn't that reliable yet.  One
of the nice parts of the design of the DNS (no, really, I come to
praise it!) is the way it is distributed in two ways.  The authority
is distributed, so there's not a giant central database administrator
and also so that authoritative servers for important stuff local to
you can be close to you.  But the data is also distributed (via caches
and long TTLs) so that many failure scenarios are hidden from view.
Of course, as a practical matter we have centralised authoritative
servers to an uncomfortable degree (and I'm aware my employer is part
of the reason for that).  Similarly, we have lowered TTLs in order to
get fast changes through the DNS in order to use it as a
systems-management tool.  But the knobs are there.

None of this, however, helps in a network enviroment that is treated
as (or even conceived as) one big client network, with all the "real"
resources in the ISP.  Such networks aren't really part of the
inter-networking environment.  Most home and many small corporate
networks are like this.  As the devices deployed in them get more
sophisticated, they represent a greater threat.  But they also
represent a rich mine of "why can't I just?" questions such as those
that are on display in this thread.

I don't know what to do about that.  There's no Internet driver
license, and yet the desire for an RFC1918 analogue name is to me
clearly something that only makes sense if you come at this from the
"client network" perspective.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Wed, 06 Sep 2017 10:39:47 -0700

On Wednesday, September 06, 2017 01:22:57 PM Andrew Sullivan wrote:
> ...  Such networks aren't really part of the
> inter-networking environment.  ...

right. but this is why we fail, and can't be used as a reason we won't change.

vixie

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 6 Sep 2017 13:48:58 -0400

> right. but this is why we fail, and can't be used as a reason we won't change.

Oh, yes, we are in complete agreement there.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Tony Finch <[email-masked]>
Date: Wed, 6 Sep 2017 19:48:10 +0100

Paul Vixie <[email-masked]> wrote:
> contributed it to BIND4. but we have yet to automate it.

This won't address the deeper problems that you outlined, but...

It occurs to me that this could be made a lot simpler with the right
flavour of metazone / catalogue zone.

On our site we encourage those running BIND to secondary our local zones,
but it's horrible to configure and there's a lot of manualarity to
co-ordinate delegation changes. But it has nice resilience and performance
properties.

However I'm doubtful that it's worth trying to make it possible to
automatically discover a catalogue zone for the local domains on the local
network...

Forwarding to our recursive servers is a lot simpler to configure and has
easier support for DNSSEC validation. Sadly DNSSEC reintroduces the
external dependency problem, but serve-stale should mitigate that when
our recursive servers support it.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Biscay: Westerly or northwesterly 3 or 4, occasionally 5 in north. Moderate,
occasionally rough in north. Mainly fair. Good.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 12 Sep 2017 20:03:31 -0400

> today, are ignoring the advice.

Yup, but people continue to ignore the advice, and, as far as I can
see, will continue to do so - .internal is intended to give people a
place where they can go do whatever they want without just squatting
on something.
I personally believe they should just use something which they have
registered -- but, I also believe that abstinence is the only way to
prevent teen pregnancy. Seeing as my believing this doesn't actually
*stop* teenagers having sex, I'd like them to do so in the least risky
way possible -- .internal, a condom for the namespace.

>> >> they want/need something shorter like ".corp", ".lan", ".local", ...

Perhaps corp.arpa, or internal.arpa, or home.arpa is the right answer
- unfortunately I think that they fail the "looks pretty" property.

>> > no exception for active directory.

Sorry, nope. You might have said that, I might have said that, but
many people remained unaware -- also Microsoft suggested (
https://support.microsoft.com/en-us/help/296250/the-domain-name-system-name-recommendations-for-small-business-server
)

"Three practical methods to name the DNS domain are:

* Make the name a private domain name that is used for name resolution
on the internal Small Business Server network. This name is usually
configured with the first-level domain of .local. At the present time,
the .local domain name is not registered on the Internet.
* Make the name a sub-domain of a publicly registered domain name. For
example, if the publicly registered domain name is Contoso.com, a
sub-domain of Corp.contoso.com can be used.
* Make the name the same as a publicly registered domain name.

Most Small Business Server customers should use the first method. The
following list describes some of the advantages when you use a
separate and private domain name for the local Small Business Server
network:

The management of the local namespace is controlled by the Small
Business Server Server. When you use a private FQDN for local DNS name
resolution, the DNS server becomes the start of authority for the
local domain. This result means that a query to external DNS root
servers is not required for local resource name resolution.

The security may be increased for your DNS server by not enabling zone
transfers by means of the zone transfer properties of the forward
lookup zone. Because dynamic registration of internal hosts can occur
with the DNS server, if you disable the zone transfers from external
clients, you can limit the exposure of internal host names to the
Internet.

The natural separation of internal and external networks occurs
because of the use of a separate internal namespace. A client query
generated from the Internet for www.contoso.local does not return any
valid domain information because .local, at the present time, is not a
registered domain name. However, by using the Web Publishing rules in
Internet Security and Acceleration (ISA) Server, internal Web sites
can be hosted externally and viewed by using resolvable domain names.
This hosting still requires a registered domain name as well as the
appropriate public DNS records that resolve to the external IP address
of Small Business Server. Refer to "Configuring Publishing" in ISA
Server Help for more information about Web Publishing rules."

Microsoft now recommends that people put stuff under a registered
name, but a significant number of people heard (and followed) the
earlier advice.
Microsoft also used .corp (or contoso.corp) in a large number of
examples (e.g: https://blogs.technet.microsoft.com/networking/2009/04/16/dns-client-name-resolution-behavior-in-windows-vista-vs-windows-xp/:
, including (IIRC) the step by step walkthrough of how to setup Active
Directory - and many people followed this --
http://www.enyo.de/fw/notes/the-great-corp-renaming.html

So, yes, people shouldn't have just used .local, or .corp -- but I
entirely understand why they did.

Reserving a TLD for internal shenanigans certainly won't fix existing
deployments. It also won't stop people from sometimes squatting on
whatever-they-feel-like. However, it will give people who are going to
do this sort of thing a safe place to do it. As Andrew says, there are
an almost unlimited number of strings that can be made with 63 octets.
I think the benefit of giving people a sandbox for this outweighs the
costs (basically none). Yes, there will be collisions if e.g.
companies merge, VPNs, and other cases (just like there were with
RFC1918); I think we need to note that as a disclaimer in the
document. People choosing to use this should be consenting adults.

---

From: william manning <[email-masked]>
Date: Tue, 12 Sep 2017 18:54:36 -0700

'cause warren isn't special enough to warrant getting the only copy of this.

/Wm
---------- Forwarded message ----------
From: william manning <[email-masked]>
Date: Tue, Sep 12, 2017 at 6:53 PM
Subject: Re: [DNSOP] DNSSEC in local networks
To: Warren Kumari <[email-masked]>

cry me a river.  in the face of conflicting strings, tie-break by using the
closest enclosing trust anchor. See the "Islands of Trust" RFCs.  Slavish
dependence on a single trust anchor is among the dumber things you can do,
operationally.

/Wm

On Tue, Sep 12, 2017 at 5:03 PM, Warren Kumari <[email-masked]> wrote:

> >> > In message <[email-masked]
> >,
> >> > "Walter H." writes:
> https://support.microsoft.com/en-us/help/296250/the-domain-n
> ame-system-name-recommendations-for-small-business-server
> )
>
> examples (e.g: https://blogs.technet.microsoft.com/networking/2009/04/16/
> dns-client-name-resolution-behavior-in-windows-vista-vs-windows-xp/:
> > PHONE: +61 2 9871 4742 <+61%202%209871%204742>
>  INTERNET: [email-masked]
> >