Re: stretch and DNS name resolution service for other devices on a LAN

[David Wright]

On Fri 02 Mar 2018 at 23:56:02 (+0100), Pascal Hambourg wrote:
> Le 28/02/2018 à 21:13, David Wright a écrit :
> >>>#
> >>># /etc/interfaces.d/directcable for west 2018-02-25
> >>>
> >>>auto eth0
> >>>iface eth0 inet static
> >>>   address 192.168.2.15/24
> >>
> >>Fine. You could also add "allow-hotplug eth0" in case eth0 would be
> >>discovered late.
> >
> >OK. Tried that here. The   ip a   is before and after connecting the cable.
> (...)
> >allow-hotplug eth0
> >iface eth0 inet static
> >   address 192.168.2.15/24
> 
> Note : I wrote "also", not "instead".

Restored.

> >2: eth0:  mtu 1500 qdisc mq state UP group 
> >default qlen 1000
> > link/ether 00:1c:23:3b:9f:34 brd ff:ff:ff:ff:ff:ff
> > inet6 fe80::21c:23ff:fe3b:9f34/64 scope link
> >valid_lft forever preferred_lft forever
> 
> Something went wrong. eth0 is up but the IPv4 address defined in
> /etc/interfaces.d/directcable is not configured.
> 
> Could you post the output of
> 
> ifdown -v eth0
> ifup -v eth0

[…]
2: eth0:  mtu 1500 qdisc mq state UP group 
default qlen 1000
link/ether 00:1c:23:3b:9f:34 brd ff:ff:ff:ff:ff:ff
inet6 fe80::21c:23ff:fe3b:9f34/64 scope link 
   valid_lft forever preferred_lft forever
[…]
# ifdown -v eth0
Parsing file /etc/network/interfaces.d/directcable
ifdown: interface eth0 not configured
# ifup -v eth0
Parsing file /etc/network/interfaces.d/directcable
Configuring interface eth0=eth0 (inet)
run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/ethtool
run-parts: executing /etc/network/if-pre-up.d/linux-wlan-ng-pre-up
run-parts: executing /etc/network/if-pre-up.d/wireless-tools
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
ip addr add 192.168.2.15/255.255.255.0 broadcast 192.168.2.255dev eth0 
label eth0
ip link set dev eth0   up

run-parts --exit-on-error --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/000resolvconf
run-parts: executing /etc/network/if-up.d/avahi-autoipd
run-parts: executing /etc/network/if-up.d/avahi-daemon
run-parts: executing /etc/network/if-up.d/ethtool
run-parts: executing /etc/network/if-up.d/mountnfs
run-parts: executing /etc/network/if-up.d/openssh-server
run-parts: executing /etc/network/if-up.d/openvpn
run-parts: executing /etc/network/if-up.d/upstart
run-parts: executing /etc/network/if-up.d/wpasupplicant
Configuring interface eth0=eth0 (inet)
run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/ethtool
run-parts: executing /etc/network/if-pre-up.d/linux-wlan-ng-pre-up
run-parts: executing /etc/network/if-pre-up.d/wireless-tools
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
ip addr add 192.168.2.15/255.255.255.0 broadcast 192.168.2.255dev eth0 
label eth0
RTNETLINK answers: File exists
Failed to bring up eth0.
# 
[…]
2: eth0:  mtu 1500 qdisc mq state UP group 
default qlen 1000
link/ether 00:1c:23:3b:9f:34 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.15/24 brd 192.168.2.255 scope global eth0
   valid_lft forever preferred_lft forever
inet6 fe80::21c:23ff:fe3b:9f34/64 scope link 
   valid_lft forever preferred_lft forever
[…]
$ ip r
default via 192.168.1.1 dev wlan0 
169.254.0.0/16 dev eth0  scope link  metric 1000 
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.15 
192.168.2.0/24 dev eth0  proto kernel  scope link  src 192.168.2.15 
$ 

So, yes, that allows commands like this to work:

$ scp -p /etc/network/interfaces.d/directcable root@192.168.2.10:/tmp

leaving just the two problems:

a) if the cable is connected at boot, the machines' normal default
   routes don't come up properly, but they're only able to connect
   with each other,
b) I have to down and up the interface as root before making transfers.

which leads me to see no reason for withdrawing my original remark:

"I have one valuable use for IPv6 which is point-to-point connections.
I plug a CAT5 cable into the two ends and use predefined functions
to bulk-transfer files with scp."

but just to point out what I didn't make explicit six weeks ago:

1) you don't have to change anything as root in /etc,
2) you don't need root access for configuring the interfaces
   before doing transfers,
3) it's unimportant whether the CAT5 cable is connected at other
   times (particularly when booting).

So I'll be ignoring the Keep Off The Grass signs. Really.

Cheers,
David.

Re: stretch and DNS name resolution service for other devices on a LAN

[Pascal Hambourg]

Le 28/02/2018 à 21:13, David Wright a écrit :

#
# /etc/interfaces.d/directcable for west 2018-02-25

auto eth0
iface eth0 inet static
   address 192.168.2.15/24


Fine. You could also add "allow-hotplug eth0" in case eth0 would be
discovered late.


OK. Tried that here. The   ip a   is before and after connecting the cable.

(...)

allow-hotplug eth0
iface eth0 inet static
   address 192.168.2.15/24


Note : I wrote "also", not "instead".


2: eth0:  mtu 1500 qdisc mq state UP group 
default qlen 1000
 link/ether 00:1c:23:3b:9f:34 brd ff:ff:ff:ff:ff:ff
 inet6 fe80::21c:23ff:fe3b:9f34/64 scope link
valid_lft forever preferred_lft forever


Something went wrong. eth0 is up but the IPv4 address defined in 
/etc/interfaces.d/directcable is not configured.


Could you post the output of

ifdown -v eth0
ifup -v eth0

Re: stretch and DNS name resolution service for other devices on a LAN

[David Wright]

On Wed 28 Feb 2018 at 19:42:27 (+0100), Pascal Hambourg wrote:
> Le 28/02/2018 à 18:14, David Wright a écrit :
> >
> >$ cat /etc/network/interfaces /etc/network/interfaces.d/directcable
> ># This file describes the network interfaces available on your system
> ># and how to activate them. For more information, see interfaces(5).
> >
> >source /etc/network/interfaces.d/*
> >
> ># The loopback network interface
> >auto lo
> >iface lo inet loopback
> >
> >#
> ># /etc/interfaces.d/directcable for west 2018-02-25
> >
> >auto eth0
> >iface eth0 inet static
> >   address 192.168.2.15/24
> 
> Fine. You could also add "allow-hotplug eth0" in case eth0 would be
> discovered late.

OK. Tried that here. The   ip a   is before and after connecting the cable.

$ cat /etc/network/interfaces /etc/network/interfaces.d/directcable-hot-plug 
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

#
# /etc/interfaces.d/directcable for west 2018-02-25

allow-hotplug eth0
iface eth0 inet static
  address 192.168.2.15/24

#
$ ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc mq state DOWN group 
default qlen 1000
link/ether 00:1c:23:3b:9f:34 brd ff:ff:ff:ff:ff:ff
3: wlan0:  mtu 1500 qdisc mq state UP group 
default qlen 1000
link/ether 00:1c:bf:d5:28:76 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.15/24 brd 192.168.1.255 scope global wlan0
   valid_lft forever preferred_lft forever
inet6 fe80::21c:bfff:fed5:2876/64 scope link 
   valid_lft forever preferred_lft forever
$ ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc mq state UP group 
default qlen 1000
link/ether 00:1c:23:3b:9f:34 brd ff:ff:ff:ff:ff:ff
inet6 fe80::21c:23ff:fe3b:9f34/64 scope link 
   valid_lft forever preferred_lft forever
3: wlan0:  mtu 1500 qdisc mq state UP group 
default qlen 1000
link/ether 00:1c:bf:d5:28:76 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.15/24 brd 192.168.1.255 scope global wlan0
   valid_lft forever preferred_lft forever
inet6 fe80::21c:bfff:fed5:2876/64 scope link 
   valid_lft forever preferred_lft forever
$ 

> >$ ip a
> >2: eth0:  mtu 1500 qdisc mq state UP group 
> >default qlen 1000
> > link/ether 00:1c:23:3b:9f:34 brd ff:ff:ff:ff:ff:ff
> > inet6 fe80::21c:23ff:fe3b:9f34/64 scope link
> >valid_lft forever preferred_lft forever
> 
> The IPv4 address is not configured on eth0. No need to check the
> connectivity with ping, it won't work until the IPv4 addresses are
> configured on both ethernet interfaces.
> 
> After adding the iface stanza, did you restart the system, or start
> the interface with "ifup -a" ?

Yes. AFAIK there's no clean way to restart networking, so I've always
rebooted at both ends after making any change.

# ifup -a
# ifup eth0
ifup: interface eth0 already configured
# 

If I reboot but forget to disconnect the cable, then the machines
come up in a deadly embrace, ie each is the default IPv4 gateway
for the other, by way of the cable. OTOH in the absence of
/etc/interfaces.d/directcable or /etc/interfaces.d/directcable-hot-plug,
the machines come up normally, with their gateway through the wlan0
interface, but also able to transfer files or login to one another
through the already connected cable. I just tested that from this
laptop two floors below them both.

Cheers,
David.

Re: stretch and DNS name resolution service for other devices on a LAN

[Pascal Hambourg]

Le 28/02/2018 à 18:14, David Wright a écrit :


$ cat /etc/network/interfaces /etc/network/interfaces.d/directcable
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

#
# /etc/interfaces.d/directcable for west 2018-02-25

auto eth0
iface eth0 inet static
   address 192.168.2.15/24


Fine. You could also add "allow-hotplug eth0" in case eth0 would be 
discovered late.



$ ip a
2: eth0:  mtu 1500 qdisc mq state UP group 
default qlen 1000
 link/ether 00:1c:23:3b:9f:34 brd ff:ff:ff:ff:ff:ff
 inet6 fe80::21c:23ff:fe3b:9f34/64 scope link
valid_lft forever preferred_lft forever


The IPv4 address is not configured on eth0. No need to check the 
connectivity with ping, it won't work until the IPv4 addresses are 
configured on both ethernet interfaces.


After adding the iface stanza, did you restart the system, or start the 
interface with "ifup -a" ?

Re: stretch and DNS name resolution service for other devices on a LAN

[David Wright]

On Tue 27 Feb 2018 at 20:59:17 (+0100), Pascal Hambourg wrote:
> Le 25/02/2018 à 18:35, David Wright a écrit :
> >On Sat 24 Feb 2018 at 09:49:27 (+0100), Pascal Hambourg wrote:
> >
> On disadvantage is that these addresses are not globally unique (the
> link local prefix exists on all interfaces) and must be appended
> with an interface name.
> >>>
> >>>Not an issue here. The only change I have made since you commented
> >>>on this in August 2016 is that I now sed the output of
> >>> ip -o link show
> >>>to pick up the name of the ethernet interface. (The file that defines
> >>>my IPv6 functions is shared with wheezy/jessie/stretch hosts, and
> >>>"eth0" doesn't cut it any more.)
> >>
> >>Hackish.
> >
> >Why is this any more hackish than just setting net.ifnames=0
> >and sticking with eth0?
> 
> net.ifnames=0 is system configuration. Having to extract an
> interface name by its MAC address at the application level is a
> kludge. No regular user application should need to deal with
> interface names or MAC addresses. That's what IP addresses and
> hostnames are for.
> 
> The second disadvantage is that if the
> interface is replaced for whatever reason, the interface name may
> change and the MAC address will change. The link local addresses is
> based on the MAC addresses, so it will change too.
> >>>
> >>>Well, as the MAC addresses are all configured in my router,
> >>
> >>No, A MAC address is configured in the ethernet adapter NVRAM.
> >>Besides, The two interfaces we are discussing about are not
> >>connected to any router.
> >
> >AIUI the MAC addresses are "burnt" into the card.
> 
> Just what I said. Programmed into an NVRAM on the card.

Yes, I'm agreeing with you, and indicating that I don't use any
methods for changing the MAC (which I have heard of people doing).

> >I then have to copy
> >the MAC addresses into the router by hand so that it can dispense the
> >correct IP numbers when devices connect to it.
> 
> IIUC the ethernet interface is not connected to the router. How
> could the router dispense anything to it ?

It's not connected now. There are times when it has been.
That's not the point. You brought up the subject of replacing
interface cards. I was just saying that maintaining MAC
addresses is relatively easy on the computers and difficult
on the router. I can't just scp a file of configuration stuff
into the router.

But this is irrelevant to what I'm trying to do. Replacing
interface cards has nothing to do with why I am, or am not, using
IPv6 to transfer information through a CAT5 cable.

> >The point I am making is that were I to be replacing interfaces
> >all the time, it would still be easier to keep the MAC references
> >up to date in my bash functions than in the router configuration pages.
> 
> Even easier and much cleaner would be to update the system
> configuration instead of user scripts.

So this is what I'm trying to do with your help.

> So Andy is right : you could use IPv4 for this. But rather with
> static configuration than unpredictable APIPA assignments.
> >>>
> >>>Of course I could, but then I've got to interfere with the routing
> >>>table to prevent the file transfers going through the default
> >>>wireless interface.
> >>
> >>You can't be more wrong. With the static configuration of a pair of
> >>IPv4 addresses in a distinct prefix at both ends of the ethernet
> >>link the traffic between these addresses would flow through the
> >>ethernet link.
> >
> >OK, so I would do something like this, would I?
> >
> ># cat /etc/network/interfaces.d/directcable
> >
> >auto eth0
> >iface eth0 inet static
> >   address 192.168.2.123/24
> 
> Of course. Just make sure the prefix is distinct from the router's
> one to avoid any routing conflict.
> No need to bother with things such as "I only need a pair of host
> addresses so I am going to define a /30 prefix". There are plenty of
> private addresses available, so keep it simple.
> 
> >with the appropriate values for eth0 and 123 at each end,
> >connect a cable and then type
> >
> >$ scp /etc/network/interfaces.d/directcable username@192.168.2.222:/tmp/
> >
> >to effect a file transfer (after the ssh dialog)?
> 
> Yes.
> Additionally, you can define hostnames for both addresses in
> /etc/hosts on both hosts and use these instead of the IP addresses.

That'll come later when I've succeeded with IP addresses.

> The same applies to ULA IPv6 addresses, except you have to get a
> (free) ULA prefix before.

Well, if you wean me off IPv6, I can forget about doing that.

> >>Anyway, we have a saying here which roughly translates to : "you
> >>cannot force an unthirsty donkey to drink".
> >
> >Some sort of passing insult?
> 
> No, it is just an expression, like "I didn't pay good money". It
> means that I can't convince you if you don't want to be convinced.

To convince me, it's got to work. The British expression is
You can lead a horse to water but you can't make him drink.
So you're 

Re: stretch and DNS name resolution service for other devices on a LAN

[Pascal Hambourg]

Le 25/02/2018 à 18:35, David Wright a écrit :

On Sat 24 Feb 2018 at 09:49:27 (+0100), Pascal Hambourg wrote:


On disadvantage is that these addresses are not globally unique (the
link local prefix exists on all interfaces) and must be appended
with an interface name.


Not an issue here. The only change I have made since you commented
on this in August 2016 is that I now sed the output of
 ip -o link show
to pick up the name of the ethernet interface. (The file that defines
my IPv6 functions is shared with wheezy/jessie/stretch hosts, and
"eth0" doesn't cut it any more.)


Hackish.


Why is this any more hackish than just setting net.ifnames=0
and sticking with eth0?


net.ifnames=0 is system configuration. Having to extract an interface 
name by its MAC address at the application level is a kludge. No regular 
user application should need to deal with interface names or MAC 
addresses. That's what IP addresses and hostnames are for.



The second disadvantage is that if the
interface is replaced for whatever reason, the interface name may
change and the MAC address will change. The link local addresses is
based on the MAC addresses, so it will change too.


Well, as the MAC addresses are all configured in my router,


No, A MAC address is configured in the ethernet adapter NVRAM.
Besides, The two interfaces we are discussing about are not
connected to any router.


AIUI the MAC addresses are "burnt" into the card.


Just what I said. Programmed into an NVRAM on the card.


I then have to copy
the MAC addresses into the router by hand so that it can dispense the
correct IP numbers when devices connect to it.


IIUC the ethernet interface is not connected to the router. How could 
the router dispense anything to it ?



The point I am making is that were I to be replacing interfaces
all the time, it would still be easier to keep the MAC references
up to date in my bash functions than in the router configuration pages.


Even easier and much cleaner would be to update the system configuration 
instead of user scripts.



So Andy is right : you could use IPv4 for this. But rather with
static configuration than unpredictable APIPA assignments.


Of course I could, but then I've got to interfere with the routing
table to prevent the file transfers going through the default
wireless interface.


You can't be more wrong. With the static configuration of a pair of
IPv4 addresses in a distinct prefix at both ends of the ethernet
link the traffic between these addresses would flow through the
ethernet link.


OK, so I would do something like this, would I?

# cat /etc/network/interfaces.d/directcable

auto eth0
iface eth0 inet static
   address 192.168.2.123/24


Of course. Just make sure the prefix is distinct from the router's one 
to avoid any routing conflict.
No need to bother with things such as "I only need a pair of host 
addresses so I am going to define a /30 prefix". There are plenty of 
private addresses available, so keep it simple.



with the appropriate values for eth0 and 123 at each end,
connect a cable and then type

$ scp /etc/network/interfaces.d/directcable username@192.168.2.222:/tmp/

to effect a file transfer (after the ssh dialog)?


Yes.
Additionally, you can define hostnames for both addresses in /etc/hosts 
on both hosts and use these instead of the IP addresses.


The same applies to ULA IPv6 addresses, except you have to get a (free) 
ULA prefix before.



Anyway, we have a saying here which roughly translates to : "you
cannot force an unthirsty donkey to drink".


Some sort of passing insult?


No, it is just an expression, like "I didn't pay good money". It means 
that I can't convince you if you don't want to be convinced.

Re: stretch and DNS name resolution service for other devices on a LAN

[David Wright]

On Sat 24 Feb 2018 at 09:49:27 (+0100), Pascal Hambourg wrote:
> Le 22/02/2018 à 22:57, David Wright a écrit :
> >On Tue 23 Jan 2018 at 20:56:31 (+0100), Pascal Hambourg wrote:
> >>Le 23/01/2018 à 18:08, David Wright a écrit :
> >>>
> >>>[My Laptop] --- wireless connection IPv4 --- [Router] --- Internet Modem
> >>>  | / |
> >>>  | CAT5 cable IPv6/  |
> >>>  |   /   | wireless/wired
> >>>[My Desktop] --- wireless connection IPv4 __/| connections
> >>>  | IPv4
> >>>  |
> >>> [TVs]
> >>>
> Both devices will allocate themselves an address in the 'link local' 
> range,
> and these addresses can then be used for communicating between the 
> devices.
> >>
> >>They can, but they should not be used with application-layer
> >>protocols. Really. IPv6 link local addresses are not meant for this.
> >
> >Well, I won't argue with this as I don't know what they were
> >originally meant for.
> 
> They are meant to be used with low level IPv6 services (automatic
> configuration, neighbour discovery...)
> 
> >However, I don't see why I have them if I'm
> >not allowed to use them when I find a good reason to. I didn't pay
> >good money just to stare at the numbers in  ip address show.
> 
> You did not pay any money for IPv6 link local addresses.

It's an expression. They hand one a newspaper when one gets on the
transAtlantic flight. When one's wife says "You could leave that on
the seat for the next person boarding", one might reply "I didn't pay
good money just to leave the crossword behind".

> >>On disadvantage is that these addresses are not globally unique (the
> >>link local prefix exists on all interfaces) and must be appended
> >>with an interface name.
> >
> >Not an issue here. The only change I have made since you commented
> >on this in August 2016 is that I now sed the output of
> > ip -o link show
> >to pick up the name of the ethernet interface. (The file that defines
> >my IPv6 functions is shared with wheezy/jessie/stretch hosts, and
> >"eth0" doesn't cut it any more.)
> 
> Hackish.

Why is this any more hackish than just setting net.ifnames=0
and sticking with eth0?

> >>The second disadvantage is that if the
> >>interface is replaced for whatever reason, the interface name may
> >>change and the MAC address will change. The link local addresses is
> >>based on the MAC addresses, so it will change too.
> >
> >Well, as the MAC addresses are all configured in my router,
> 
> No, A MAC address is configured in the ethernet adapter NVRAM.
> Besides, The two interfaces we are discussing about are not
> connected to any router.

AIUI the MAC addresses are "burnt" into the card. I then have to copy
the MAC addresses into the router by hand so that it can dispense the
correct IP numbers when devices connect to it.

The point I am making is that were I to be replacing interfaces
all the time, it would still be easier to keep the MAC references
up to date in my bash functions than in the router configuration pages.

> >>IMO, simple
> >>static configuration with a ULA prefix, or with a global prefix if
> >>you own one, would be much reliable.
> >
> >So what would be involved in setting that up? I have no idea where
> >to start. I can't believe it's as simple as 1,2,3 below.
> 
> Get a ULA prefix. Online generators are available on the web.
> Pick up two host addresses in the prefix.
> Statically assign an address to the two interface in
> /etc/network/interfaces or any other network manager.

I'll try that when I've got IPv4 working, as that would make
all of Andy, Greg and yourself happy.

> >>So Andy is right : you could use IPv4 for this. But rather with
> >>static configuration than unpredictable APIPA assignments.
> >
> >Of course I could, but then I've got to interfere with the routing
> >table to prevent the file transfers going through the default
> >wireless interface.
> 
> You can't be more wrong. With the static configuration of a pair of
> IPv4 addresses in a distinct prefix at both ends of the ethernet
> link the traffic between these addresses would flow through the
> ethernet link.

OK, so I would do something like this, would I?

# cat /etc/network/interfaces.d/directcable

auto eth0
iface eth0 inet static
  address 192.168.2.123/24

#

with the appropriate values for eth0 and 123 at each end,
connect a cable and then type

$ scp /etc/network/interfaces.d/directcable username@192.168.2.222:/tmp/

to effect a file transfer (after the ssh dialog)?

> >If I use IPv6, this is all I have to do to transfer large files at
> >CAT5 speeds:
> >
> >1) plug a CAT5 cable into ethernet ports at each machine,
> >2) on the source, type:   6 
> >3) when finished, remove the cable.
> >
> >The wireless interface is unaware of any change, so I can 

Re: stretch and DNS name resolution service for other devices on a LAN

[Curt]

On 2018-02-24, Pascal Hambourg  wrote:
>
> Anyway, we have a saying here which roughly translates to : "you cannot 
> force an unthirsty donkey to drink".

I looked it up (because neither me nor hubby--de vieille souche--recognized
it right off).

 On ne saurait faire boire un âne qui n’a pas soif.

Donkeys being noted for their obstinacy.

We say: You can lead a horse to water but you can't make it drink.

Not *quite* the same; but after all, we cowboys can't ride no donkey
into the sunset.

(A sexist variation: You can lead a girl to Vassar but you can't make
her think.)


-- 
“Be yourself; everyone else is already taken.”
-Oscar Wilde

Re: stretch and DNS name resolution service for other devices on a LAN

[Pascal Hambourg]

Le 22/02/2018 à 22:57, David Wright a écrit :

On Tue 23 Jan 2018 at 20:56:31 (+0100), Pascal Hambourg wrote:

Le 23/01/2018 à 18:08, David Wright a écrit :


[My Laptop] --- wireless connection IPv4 --- [Router] --- Internet Modem
  | / |
  | CAT5 cable IPv6/  |
  |   /   | wireless/wired
[My Desktop] --- wireless connection IPv4 __/| connections
  | IPv4
  |
 [TVs]


Both devices will allocate themselves an address in the 'link local' range,
and these addresses can then be used for communicating between the devices.


They can, but they should not be used with application-layer
protocols. Really. IPv6 link local addresses are not meant for this.


Well, I won't argue with this as I don't know what they were
originally meant for.


They are meant to be used with low level IPv6 services (automatic 
configuration, neighbour discovery...)



However, I don't see why I have them if I'm
not allowed to use them when I find a good reason to. I didn't pay
good money just to stare at the numbers in  ip address show.


You did not pay any money for IPv6 link local addresses.


On disadvantage is that these addresses are not globally unique (the
link local prefix exists on all interfaces) and must be appended
with an interface name.


Not an issue here. The only change I have made since you commented
on this in August 2016 is that I now sed the output of
 ip -o link show
to pick up the name of the ethernet interface. (The file that defines
my IPv6 functions is shared with wheezy/jessie/stretch hosts, and
"eth0" doesn't cut it any more.)


Hackish.


The second disadvantage is that if the
interface is replaced for whatever reason, the interface name may
change and the MAC address will change. The link local addresses is
based on the MAC addresses, so it will change too.


Well, as the MAC addresses are all configured in my router,


No, A MAC address is configured in the ethernet adapter NVRAM. Besides, 
The two interfaces we are discussing about are not connected to any router.



IMO, simple
static configuration with a ULA prefix, or with a global prefix if
you own one, would be much reliable.


So what would be involved in setting that up? I have no idea where
to start. I can't believe it's as simple as 1,2,3 below.


Get a ULA prefix. Online generators are available on the web.
Pick up two host addresses in the prefix.
Statically assign an address to the two interface in 
/etc/network/interfaces or any other network manager.



So Andy is right : you could use IPv4 for this. But rather with
static configuration than unpredictable APIPA assignments.


Of course I could, but then I've got to interfere with the routing
table to prevent the file transfers going through the default
wireless interface.


You can't be more wrong. With the static configuration of a pair of IPv4 
addresses in a distinct prefix at both ends of the ethernet link the 
traffic between these addresses would flow through the ethernet link.



If I use IPv6, this is all I have to do to transfer large files at
CAT5 speeds:

1) plug a CAT5 cable into ethernet ports at each machine,
2) on the source, type:   6 
3) when finished, remove the cable.

The wireless interface is unaware of any change, so I can still use
the WAN, or even connect to the other host through its normal wireless
route and, say, initiate transfers in the opposite direction (which
has the advantage that such a connection stays up after the cable has
been removed).


Same with IPv4.

Anyway, we have a saying here which roughly translates to : "you cannot 
force an unthirsty donkey to drink".

Re: stretch and DNS name resolution service for other devices on a LAN

[David Wright]

On Tue 23 Jan 2018 at 20:56:31 (+0100), Pascal Hambourg wrote:
> Le 23/01/2018 à 18:08, David Wright a écrit :
> >
> >[My Laptop] --- wireless connection IPv4 --- [Router] --- Internet Modem
> >  | / |
> >  | CAT5 cable IPv6/  |
> >  |   /   | wireless/wired
> >[My Desktop] --- wireless connection IPv4 __/| connections
> >  | IPv4
> >  |
> > [TVs]
> >
> >>Both devices will allocate themselves an address in the 'link local' range,
> >>and these addresses can then be used for communicating between the devices.
> 
> They can, but they should not be used with application-layer
> protocols. Really. IPv6 link local addresses are not meant for this.

Well, I won't argue with this as I don't know what they were
originally meant for. However, I don't see why I have them if I'm
not allowed to use them when I find a good reason to. I didn't pay
good money just to stare at the numbers in  ip address show.
You see, Greg only considered IPv6 in terms of the number of addresses
in the IPv4 private ranges, whereas I have this other valuable use.

> On disadvantage is that these addresses are not globally unique (the
> link local prefix exists on all interfaces) and must be appended
> with an interface name.

Not an issue here. The only change I have made since you commented
on this in August 2016 is that I now sed the output of
ip -o link show
to pick up the name of the ethernet interface. (The file that defines
my IPv6 functions is shared with wheezy/jessie/stretch hosts, and
"eth0" doesn't cut it any more.)

> The second disadvantage is that if the
> interface is replaced for whatever reason, the interface name may
> change and the MAC address will change. The link local addresses is
> based on the MAC addresses, so it will change too.

Well, as the MAC addresses are all configured in my router, having
to edit a MAC in one bash file and push it out to my hosts is hardly
a burden after logging in to the router and typing or pasting things
there. (I hate systems that barely allow you time to sneeze before
they require logging in again.)

> IMO, simple
> static configuration with a ULA prefix, or with a global prefix if
> you own one, would be much reliable.

So what would be involved in setting that up? I have no idea where
to start. I can't believe it's as simple as 1,2,3 below.

> So Andy is right : you could use IPv4 for this. But rather with
> static configuration than unpredictable APIPA assignments.

Of course I could, but then I've got to interfere with the routing
table to prevent the file transfers going through the default
wireless interface. The whole point of plugging in a CAT5 cable is
to avoid hogging wireless bandwidth.

If I use IPv6, this is all I have to do to transfer large files at
CAT5 speeds:

1) plug a CAT5 cable into ethernet ports at each machine,
2) on the source, type:   6 
3) when finished, remove the cable.

The wireless interface is unaware of any change, so I can still use
the WAN, or even connect to the other host through its normal wireless
route and, say, initiate transfers in the opposite direction (which
has the advantage that such a connection stays up after the cable has
been removed).

Cheers,
David.

Re: stretch and DNS name resolution service for other devices on a LAN

[rodaryj]

I didn't read all the answers (only half of those). But I have the same 
problem and I now think it has nothing to do with named, bind (4 8 or 9). 
During Stretch installation with netinst, Network-manager configured once for 
all /etc/hostname and /etc/resolv.conf. As I have only one routable address, 
it is the only one remembered, and the DHCP server used during install is the 
only one kept in /etc/resolv.conf ' (a soft link rewrited each time you 
destroy and edit it). Now I got rid of Network-manager and with my own named 
config and /etc/resolv.conf I have full access to resolving.  I still have 
problems with NAT on my home network with iptables config. I tam aboutto go 
back to Jessie, to when everything was OK :-). Sorry for my English

Re: stretch and DNS name resolution service for other devices on a LAN

[Pascal Hambourg]

Le 23/01/2018 à 18:08, David Wright a écrit :


[My Laptop] --- wireless connection IPv4 --- [Router] --- Internet Modem
  | / |
  | CAT5 cable IPv6/  |
  |   /   | wireless/wired
[My Desktop] --- wireless connection IPv4 __/| connections
  | IPv4
  |
 [TVs]


Both devices will allocate themselves an address in the 'link local' range,
and these addresses can then be used for communicating between the devices.


They can, but they should not be used with application-layer protocols. 
Really. IPv6 link local addresses are not meant for this.


On disadvantage is that these addresses are not globally unique (the 
link local prefix exists on all interfaces) and must be appended with an 
interface name. The second disadvantage is that if the interface is 
replaced for whatever reason, the interface name may change and the MAC 
address will change. The link local addresses is based on the MAC 
addresses, so it will change too. IMO, simple static configuration with 
a ULA prefix, or with a global prefix if you own one, would be much 
reliable.


So Andy is right : you could use IPv4 for this. But rather with static 
configuration than unpredictable APIPA assignments.

Re: stretch and DNS name resolution service for other devices on a LAN

[David Wright]

On Tue 23 Jan 2018 at 16:06:01 (-), Andy Hawkins wrote:
> Hi,
> 
> In article <20180123144327.GA6815@alum>,
>David Wright wrote:
> > This would all be a step in the wrong direction here. Point (2) was
> > that using IPv6 over CAT5 avoids swamping the router. (Of course,
> > that's already been snipped out of the thread.) If the DHCP server
> > is down, then the router is down, and there are no links to anywhere
> > except the CAT5 cable I've just connected.
> >
> > So why would I worry about whether the IPv4 had reconfigured itself
> > when I've got a perfectly good dedicated IPv6 link between the two
> > computers? And why should I be worrying about DHCP failures?—the
> > only time my router is dead is during power cuts.
> 
> You were giving your reasoning for using IPv6 as being able to handle direct
> cable connections between devices.
> 
> I was simply explaining that you don't need IPv6 to do this, as IPv4 will
> probably fall back to 'link local' addresses if they receive no response
> from a DHCP server (which they won't, as all they're connected to is some
> other PC). 

You still don't quite understand what I'm doing, so here's a diagram
(needs monospace font):

[My Laptop] --- wireless connection IPv4 --- [Router] --- Internet Modem
 | / |
 | CAT5 cable IPv6/  |
 |   /   | wireless/wired
[My Desktop] --- wireless connection IPv4 __/| connections
 | IPv4
 |
[TVs]

> Both devices will allocate themselves an address in the 'link local' range,
> and these addresses can then be used for communicating between the devices.

… but meanwhile *I* can carry on using them both on the Internet
while transfers are taking place, and the TVs are unaffected by
any excessive traffic through the router.

In the case where a desktop is wired to the router, then just that
PC would lose its connectivity to all other machines (except
[My Laptop] of course) during a CAT5 connection (assuming it had
just the usual single ethernet port).

Cheers,
David.

Re: stretch and DNS name resolution service for other devices on a LAN

[Andy Hawkins]

Hi,

In article <20180123144327.GA6815@alum>,
   David Wright wrote:
> This would all be a step in the wrong direction here. Point (2) was
> that using IPv6 over CAT5 avoids swamping the router. (Of course,
> that's already been snipped out of the thread.) If the DHCP server
> is down, then the router is down, and there are no links to anywhere
> except the CAT5 cable I've just connected.
>
> So why would I worry about whether the IPv4 had reconfigured itself
> when I've got a perfectly good dedicated IPv6 link between the two
> computers? And why should I be worrying about DHCP failures?—the
> only time my router is dead is during power cuts.

You were giving your reasoning for using IPv6 as being able to handle direct
cable connections between devices.

I was simply explaining that you don't need IPv6 to do this, as IPv4 will
probably fall back to 'link local' addresses if they receive no response
from a DHCP server (which they won't, as all they're connected to is some
other PC). 

Both devices will allocate themselves an address in the 'link local' range,
and these addresses can then be used for communicating between the devices.

Andy

Re: stretch and DNS name resolution service for other devices on a LAN

[David Wright]

On Tue 23 Jan 2018 at 13:41:31 (+), Joe wrote:
> On Tue, 23 Jan 2018 11:12:41 + (UTC)
> Curt  wrote:
> 
> > On 2018-01-23, Andy Hawkins  wrote:
> > > Hi,
> > > In article <20180122185135.GA12212@alum>,
> > >David Wright wrote:  
> > >>> You should be able to do that with IPv4 too. If DHCP address
> > >>> allocation fails,  
> > >>
> > >> Elaborate on this please. What do you mean by "fails".
> > >> What am I meant to want to fail?  
> > >
> > > If a host that's expecting to receive its address via DHCP receives
> > > no response from the DHCP server, it should fall back automatically
> > > to a 'link local' address.  
> > 
> > Is this what you're referring to ("an IPv4 address within the
> > 169.254/16 prefix that is valid for communication with other devices
> > connected to the same physical (or logical) link," failing--or in the
> > absence of--automatic or manual assignment)?
> > 
> > https://tools.ietf.org/html/rfc3927
> 
> Indeed so. It ensures that if the DHCP server temporarily suffers a
> problem, any Windows machine on the network (I have no data for Linux)
> that gets rebooted stands absolutely zero chance of communicating with
> any network machine which hasn't been rebooted. The idea that the
> previous working address (even within the lease period), or the
> [Windows] manually entered 'alternate' address should be tried does not
> arise.
> 
> I would hope that the Linux network management utilities take a more
> intelligent view of the situation, I haven't yet had cause to find out.

This would all be a step in the wrong direction here. Point (2) was
that using IPv6 over CAT5 avoids swamping the router. (Of course,
that's already been snipped out of the thread.) If the DHCP server
is down, then the router is down, and there are no links to anywhere
except the CAT5 cable I've just connected.

So why would I worry about whether the IPv4 had reconfigured itself
when I've got a perfectly good dedicated IPv6 link between the two
computers? And why should I be worrying about DHCP failures?—the
only time my router is dead is during power cuts.

Cheers,
David.

Re: stretch and DNS name resolution service for other devices on a LAN

[Joe]

On Tue, 23 Jan 2018 11:12:41 + (UTC)
Curt  wrote:

> On 2018-01-23, Andy Hawkins  wrote:
> > Hi,
> > In article <20180122185135.GA12212@alum>,
> >David Wright wrote:  
> >>> You should be able to do that with IPv4 too. If DHCP address
> >>> allocation fails,  
> >>
> >> Elaborate on this please. What do you mean by "fails".
> >> What am I meant to want to fail?  
> >
> > If a host that's expecting to receive its address via DHCP receives
> > no response from the DHCP server, it should fall back automatically
> > to a 'link local' address.  
> 
> Is this what you're referring to ("an IPv4 address within the
> 169.254/16 prefix that is valid for communication with other devices
> connected to the same physical (or logical) link," failing--or in the
> absence of--automatic or manual assignment)?
> 
> https://tools.ietf.org/html/rfc3927

Indeed so. It ensures that if the DHCP server temporarily suffers a
problem, any Windows machine on the network (I have no data for Linux)
that gets rebooted stands absolutely zero chance of communicating with
any network machine which hasn't been rebooted. The idea that the
previous working address (even within the lease period), or the
[Windows] manually entered 'alternate' address should be tried does not
arise.

I would hope that the Linux network management utilities take a more
intelligent view of the situation, I haven't yet had cause to find out.

-- 
Joe

Re: stretch and DNS name resolution service for other devices on a LAN

[Curt]

On 2018-01-23, Andy Hawkins  wrote:
> Hi,
> In article <20180122185135.GA12212@alum>,
>David Wright wrote:
>>> You should be able to do that with IPv4 too. If DHCP address allocation
>>> fails,
>>
>> Elaborate on this please. What do you mean by "fails".
>> What am I meant to want to fail?
>
> If a host that's expecting to receive its address via DHCP receives no 
> response from the
> DHCP server, it should fall back automatically to a 'link local' address.

Is this what you're referring to ("an IPv4 address within the 169.254/16
prefix that is valid for communication with other devices connected to
the same physical (or logical) link," failing--or in the absence
of--automatic or manual assignment)?

https://tools.ietf.org/html/rfc3927

> Andy
>
>


-- 
“True terror is to wake up one morning and discover that your high school class
is running the country.” – Kurt Vonnegut

Re: stretch and DNS name resolution service for other devices on a LAN

[Andy Hawkins]

Hi,
In article <20180122185135.GA12212@alum>,
   David Wright wrote:
>> You should be able to do that with IPv4 too. If DHCP address allocation
>> fails,
>
> Elaborate on this please. What do you mean by "fails".
> What am I meant to want to fail?

If a host that's expecting to receive its address via DHCP receives no response 
from the
DHCP server, it should fall back automatically to a 'link local' address.

Andy

Re: stretch and DNS name resolution service for other devices on a LAN

[David Wright]

On Mon 22 Jan 2018 at 17:21:23 (-), Andy Hawkins wrote:
> Hi,
> 
> In article <20180119151835.GA8374@alum>,
>David Wright wrote:
> > I have one valuable use for IPv6 which is point-to-point connections.
> > I plug a CAT5 cable into the two ends and use predefined functions
> > to bulk-transfer files with scp. Why?
> > 1) I don't have to touch the IPv4 configuration,
> > 2) We can still watch TV; ie the router doesn't get swamped.
> 
> You should be able to do that with IPv4 too. If DHCP address allocation
> fails,

Elaborate on this please. What do you mean by "fails".
What am I meant to want to fail?

> then both devices should pick up a link-local IPv4 address (in the
> 169.254.x.x block). You can use this address to do whatever you need to do.

Cheers,
David.

Re: stretch and DNS name resolution service for other devices on a LAN

[Andy Hawkins]

Hi,

In article <20180119151835.GA8374@alum>,
   David Wright wrote:
> I have one valuable use for IPv6 which is point-to-point connections.
> I plug a CAT5 cable into the two ends and use predefined functions
> to bulk-transfer files with scp. Why?
> 1) I don't have to touch the IPv4 configuration,
> 2) We can still watch TV; ie the router doesn't get swamped.

You should be able to do that with IPv4 too. If DHCP address allocation
fails, then both devices should pick up a link-local IPv4 address (in the
169.254.x.x block). You can use this address to do whatever you need to do.

Andy

Re: stretch and DNS name resolution service for other devices on a LAN

[Pascal Hambourg]

Le 19/01/2018 à 06:10, D. R. Evans a écrit :

Pascal Hambourg wrote on 01/18/2018 02:41 PM:


Note : ping is not a proper DNS tool becaus it calls the libc resolver
for name resolution, which may use other name sources than DNS. Use dig,
host or nslookup instead.


I admit that I'm quite surprised that everything doesn't use the libc resolver
(by which I assume you mean the operations performed by gethostbyname() or
something equivalent). I should look at the code for dig or nslookup sometime
to see how they resolve names.


DNS tools directly send DNS queries to the specified nameserver. They 
may use the libc resolver only to resolve the nameserver hostname (if 
the nameserver is specified by hostname) or get the nameserver address 
list from /etc/resolv.conf (if a nameserver is not specified).

Re: stretch and DNS name resolution service for other devices on a LAN

[Pascal Hambourg]

Le 19/01/2018 à 16:14, Rob van der Putten a écrit :


If you have got your own IPv6 /48 combined with RFC1918 IPv4 then split 
horizon DNS is probably a good idea;

https://en.wikipedia.org/wiki/Split-horizon_DNS


Why ?

My home network also has private IPv4 + global IPv6 addresse and I use 
split DNS, but not for that reason. I set up split DNS on my DNS server 
in order to serve both internal (authoritative + recursive) and external 
(authoritative) queries.

Re: stretch and DNS name resolution service for other devices on a LAN

[Michael Stone]

On Fri, Jan 19, 2018 at 04:14:38PM +0100, Rob van der Putten wrote:

AFAIK Bind is the only named with a good split horizon implementation.


most implementations will let you bind to a particular IP so you can run 
different configurations on internal & external IPs. bind has a lot of 
configuration flexibility to run them in a single process, which is a 
double edged sword--it's also really easy to screw up if you make a typo.


Mike Stone

Re: stretch and DNS name resolution service for other devices on a LAN

[David Wright]

On Fri 19 Jan 2018 at 08:47:25 (-0500), Greg Wooledge wrote:
> On Fri, Jan 19, 2018 at 11:45:23AM -, Andy Hawkins wrote:
> > Apologies for the slight thread hijack.
> > 
> > What would people recommend for a home LAN DNS server that is authoritative
> > for a single domain, providing A, , PTR (both IPv4 and IPv6), NS and
> > CNAME records to that domain?
> 
> My only experience is with bind8, bind9, and tinydns (from djbdns).

… and mine's less than that. I stick to /etc/hosts.

> I've never used IPv6 for anything.  None of the networks that I deal
> with use IPv6, period.  They don't even have the option.

I have one valuable use for IPv6 which is point-to-point connections.
I plug a CAT5 cable into the two ends and use predefined functions
to bulk-transfer files with scp. Why?
1) I don't have to touch the IPv4 configuration,
2) We can still watch TV; ie the router doesn't get swamped.

> I have to wonder what kind of home you live in, that requires local
> IPv6.  Most homes are small enough that you can get by with the roughly
> 2^24 addresses available in the private IPv4 ranges (10/8, 192.168/16,
> and 172.16/12).
> 
> So, my first pick would be tinydns, and forget about IPv6.  But I may
> not be the best person to try to address whatever your needs are.

Cheers,
David.

Re: stretch and DNS name resolution service for other devices on a LAN

[Rob van der Putten]

Hi


On 19/01/18 15:08, Andy Hawkins wrote:


I guess I don't *need* IPv6, but as a technology geek it's just something I
wanted to play around with. I've set up a tunnel with Hurricane Electric
that gets me a fully routable IPv6 prefix that I can assign an address from
to each of the devices on my LAN.


If you have got your own IPv6 /48 combined with RFC1918 IPv4 then split 
horizon DNS is probably a good idea;

https://en.wikipedia.org/wiki/Split-horizon_DNS


I do use a 192.168/16 for my local IPv4 addressing, but given that moving
forward IPv6 is likely to become more and more available, I thought it worth
having a play with. I can now (if I want) allow IPv6 access to every device
on my internal network without having to worry about NAT and port forwarding
to get connections through my firewall.

Thanks for the pointer to tinydns, I'll take a look.


AFAIK Bind is the only named with a good split horizon implementation.


Regards,
Rob

Re: stretch and DNS name resolution service for other devices on a LAN

[Andy Hawkins]

Hi,

In article <102059aa-fd21-11e7-9b6a-00163eeb5...@msgid.mathom.us>,
   Michael Stone wrote:
> If you said why you were looking to abandon a (presumably working?) 
> solution that might help explain your requirements. If your goal is 
> simple integration between DNS and DHCP (which is not what you 
> originally asked for) then dnsmasq is probably the easiest solution. 

Part of it is simplicity. As Greg Wooledge said, bind and dhcpd just seem
like massive overkill for a small network such as mine.

Also, the integration of DNS and DHCP would be a useful one as well, as
currently the majority of my machines are assigned a fixed address by the
dhcp server, and this address has an appropriate 'A' record in bind.

That means whenever I want to add a machine that can be accessible by name,
I have to reconfigure both dhcpd *and* bind.

I realise that with a bit of effort I could probably configure bind and
dhcpd to talk to each other and update DNS records, but again that all just
seems overkill for my 'needs'.

That said, my setup at home is massive overkill anyway (a XCP based VM host,
running several VMs to isolate the various services provided to my network).
I'm an inveterate fiddler when it comes to computing, so am always on the look
out for the next 'best' thing to try!

Thanks again to all for the input.

Andy

Re: stretch and DNS name resolution service for other devices on a LAN

[Andy Hawkins]

Hi,

In article <20180119134725.lk5gywprdit4s...@eeg.ccf.org>,
   Greg Wooledge wrote:
> My only experience is with bind8, bind9, and tinydns (from djbdns).
> I've never used IPv6 for anything.  None of the networks that I deal
> with use IPv6, period.  They don't even have the option.
>
> I have to wonder what kind of home you live in, that requires local
> IPv6.  Most homes are small enough that you can get by with the roughly
> 2^24 addresses available in the private IPv4 ranges (10/8, 192.168/16,
> and 172.16/12).
>
> So, my first pick would be tinydns, and forget about IPv6.  But I may
> not be the best person to try to address whatever your needs are.

I guess I don't *need* IPv6, but as a technology geek it's just something I
wanted to play around with. I've set up a tunnel with Hurricane Electric
that gets me a fully routable IPv6 prefix that I can assign an address from
to each of the devices on my LAN.

I do use a 192.168/16 for my local IPv4 addressing, but given that moving
forward IPv6 is likely to become more and more available, I thought it worth
having a play with. I can now (if I want) allow IPv6 access to every device
on my internal network without having to worry about NAT and port forwarding
to get connections through my firewall.

Thanks for the pointer to tinydns, I'll take a look.

Andy

Re: stretch and DNS name resolution service for other devices on a LAN

[Michael Stone]

On Fri, Jan 19, 2018 at 12:27:57PM -, Andy Hawkins wrote:

Hi,

In article ,
  john doe wrote:

What would people recommend for a home LAN DNS server that is authoritative
for a single domain, providing A, , PTR (both IPv4 and IPv6), NS and
CNAME records to that domain?



Have a look at:

http://www.thekelleys.org.uk/dnsmasq/doc.html


I probably should have said that I'm currently using bind for DNS, and the
ISC DHCP server to issue IP addresses on the local network.

I have looked into dnsmasq in the past, as I quite like the idea of having
something lightweight do both jobs.

Are there any other options, or should I just dive in and try to convert to
dnsmasq?


If you said why you were looking to abandon a (presumably working?) 
solution that might help explain your requirements. If your goal is 
simple integration between DNS and DHCP (which is not what you 
originally asked for) then dnsmasq is probably the easiest solution. 


Mike Stone

Re: stretch and DNS name resolution service for other devices on a LAN

[Michael Stone]

On Fri, Jan 19, 2018 at 08:47:25AM -0500, Greg Wooledge wrote:

I have to wonder what kind of home you live in, that requires local
IPv6.  Most homes are small enough that you can get by with the roughly
2^24 addresses available in the private IPv4 ranges (10/8, 192.168/16,
and 172.16/12).

So, my first pick would be tinydns, and forget about IPv6.  But I may
not be the best person to try to address whatever your needs are.


Some people actually like having end to end addressibility, the way the 
internet was designed to work, and don't want to have NAT layers.


Mike Stone

Re: stretch and DNS name resolution service for other devices on a LAN

[Greg Wooledge]

On Fri, Jan 19, 2018 at 11:45:23AM -, Andy Hawkins wrote:
> Apologies for the slight thread hijack.
> 
> What would people recommend for a home LAN DNS server that is authoritative
> for a single domain, providing A, , PTR (both IPv4 and IPv6), NS and
> CNAME records to that domain?

My only experience is with bind8, bind9, and tinydns (from djbdns).
I've never used IPv6 for anything.  None of the networks that I deal
with use IPv6, period.  They don't even have the option.

I have to wonder what kind of home you live in, that requires local
IPv6.  Most homes are small enough that you can get by with the roughly
2^24 addresses available in the private IPv4 ranges (10/8, 192.168/16,
and 172.16/12).

So, my first pick would be tinydns, and forget about IPv6.  But I may
not be the best person to try to address whatever your needs are.

Re: stretch and DNS name resolution service for other devices on a LAN

[Andy Hawkins]

Hi,

In article ,
   john doe wrote:
>> What would people recommend for a home LAN DNS server that is authoritative
>> for a single domain, providing A, , PTR (both IPv4 and IPv6), NS and
>> CNAME records to that domain?
>> 
>
> Have a look at:
>
> http://www.thekelleys.org.uk/dnsmasq/doc.html

I probably should have said that I'm currently using bind for DNS, and the
ISC DHCP server to issue IP addresses on the local network.

I have looked into dnsmasq in the past, as I quite like the idea of having
something lightweight do both jobs.

Are there any other options, or should I just dive in and try to convert to
dnsmasq?

Thanks

Andy

Re: stretch and DNS name resolution service for other devices on a LAN

[john doe]

On 1/19/2018 12:45 PM, Andy Hawkins wrote:

Hi,

Apologies for the slight thread hijack.

In article <20180118214314.442arvnrw4xbx...@eeg.ccf.org>,
Greg Wooledge wrote:

The pacakge for ISC's BIND is called bind9.

This would certainly do the job, but it's massively overkill for a simple
home LAN DNS server.  Nevertheless, if it's what you already know, there
is benefit in using the known but overengineered tool rather than learning
a new tool.


What would people recommend for a home LAN DNS server that is authoritative
for a single domain, providing A, , PTR (both IPv4 and IPv6), NS and
CNAME records to that domain?



Have a look at:

http://www.thekelleys.org.uk/dnsmasq/doc.html

--
John Doe

Re: stretch and DNS name resolution service for other devices on a LAN

[Andy Hawkins]

Hi,

Apologies for the slight thread hijack.

In article <20180118214314.442arvnrw4xbx...@eeg.ccf.org>,
   Greg Wooledge wrote:
> The pacakge for ISC's BIND is called bind9.
>
> This would certainly do the job, but it's massively overkill for a simple
> home LAN DNS server.  Nevertheless, if it's what you already know, there
> is benefit in using the known but overengineered tool rather than learning
> a new tool.

What would people recommend for a home LAN DNS server that is authoritative
for a single domain, providing A, , PTR (both IPv4 and IPv6), NS and
CNAME records to that domain?

Thanks

Andy

Re: stretch and DNS name resolution service for other devices on a LAN

[D. R. Evans]

Greg Wooledge wrote on 01/18/2018 02:43 PM:

> 
> The pacakge for ISC's BIND is called bind9.
> 
> This would certainly do the job, but it's massively overkill for a simple
> home LAN DNS server.  Nevertheless, if it's what you already know, there
> is benefit in using the known but overengineered tool rather than learning
> a new tool.

As noted elsewhere, I'd forgotten the name of the resolver -- and also hadn't
realised that everything needed for such resolution wasn't automatically
installed with the base system.

All installed and working now.

Thanks very much for the pointer.

  Doc

-- 
Web:  http://enginehousebooks.com/drevans



signature.asc
Description: OpenPGP digital signature

Re: stretch and DNS name resolution service for other devices on a LAN

[D. R. Evans]

Pascal Hambourg wrote on 01/18/2018 02:41 PM:

> 
> named is not a package name. The package name is and has always been 
> bind9. Note that there are other recursive DNS server packages such as 
> unbound.

Ah! It's been so long since I've built a system that didn't install bind
automatically that I'd completely forgotten that. Thank you for reminding me.

> 
> Note : ping is not a proper DNS tool becaus it calls the libc resolver 
> for name resolution, which may use other name sources than DNS. Use dig, 
> host or nslookup instead.

I admit that I'm quite surprised that everything doesn't use the libc resolver
(by which I assume you mean the operations performed by gethostbyname() or
something equivalent). I should look at the code for dig or nslookup sometime
to see how they resolve names.

Anyway, thanks very much for the comment about bind. I installed it, and
indeed it seems to be performing as expected.

  Doc

-- 
Web:  http://enginehousebooks.com/drevans



signature.asc
Description: OpenPGP digital signature

Re: stretch and DNS name resolution service for other devices on a LAN

[Greg Wooledge]

On Thu, Jan 18, 2018 at 02:34:50PM -0700, D. R. Evans wrote:
> Can someone please point me to intelligible instructions as to how to have the
> stretch box respond correctly to remote DNS requests coming in over the local
> network?

Install a name server.  Make sure it's listening on your LAN address,
not (just) on 127.0.0.1.  Configure it to respond however you need.

> This seems to be one of those things that systemd has taken over ("named" is
> no longer available in the repository, for example, presumably because it's no
> longer needed),

The pacakge for ISC's BIND is called bind9.

This would certainly do the job, but it's massively overkill for a simple
home LAN DNS server.  Nevertheless, if it's what you already know, there
is benefit in using the known but overengineered tool rather than learning
a new tool.

Re: stretch and DNS name resolution service for other devices on a LAN

[Pascal Hambourg]

Le 18/01/2018 à 22:34, D. R. Evans a écrit :

I am trying to configure a debian stretch box to provide certain services to
my home network. (In the past this was a wheezy box, and I had everything
working fine. I have not changed the configuration of any other machine; so,
for example, DNS requests from machines on the LAN are still sent to the
stretch machine for resolution.)

Somehow I can't get name resolution to work except locally on the stretch box
itself.

Can someone please point me to intelligible instructions as to how to have the
stretch box respond correctly to remote DNS requests coming in over the local
network?

This seems to be one of those things that systemd has taken over ("named" is
no longer available in the repository, for example, presumably because it's no
longer needed), and my attempts to find documentation on how to configure a
machine as a DNS server under systemd have failed, probably because I'm not
being sufficiently smart about search terms.


named is not a package name. The package name is and has always been 
bind9. Note that there are other recursive DNS server packages such as 
unbound.



Just to be clear:
   1. If I ping a destination by name from the stretch box, it resolves the
name and pings the destination.
   2. If I ping the IP address of a destination on the internet from a machine
on the LAN, the ping works.
   3. If I ping a destination on the internet *by name* from a machine on the
LAN, the ping does not work.
   4. Any attempt to resolve a name from a machine on the LAN fails; attempting
to resolve the same name from the stretch machine works.


Note : ping is not a proper DNS tool becaus it calls the libc resolver 
for name resolution, which may use other name sources than DNS. Use dig, 
host or nslookup instead.