Solved FreeBSD IPv6 basics

Thanks,

… note the 'g' that you're not supposed to use...

Also, duly noted: "Nothing is needed …".

I wish :D

I took the current example given by Hurricane Electric, put it in the context of this 2021 article:

IPv6 via Hurricane Electric's Free IPv6 Tunnel Broker Service

– then wrote part of what's needed into my /etc/rc.conf. Results:

Code:
% service rtsold onestatus
rtsold is not running.
% ping6 2620:fe::fe
ping6: UDP connect: No route to host
% sudo service rtsold onestart
grahamperrin's password:
Starting rtsold.
% sudo service routing restart
delete host 127.0.0.1: gateway lo0
default              192.168.1.1          -fib 0   done
delete host ::1: gateway lo0
delete net fe80::: gateway ::1
delete net ff02::: gateway ::1
delete net ::ffff:0.0.0.0: gateway ::1
delete net ::0.0.0.0: gateway ::1
route: route has not been found
delete net default: gateway 2001:470:1f1c:a0::1 fib 0: not in table
add host 127.0.0.1: gateway lo0
add host ::1: gateway lo0
add net fe80::: gateway ::1
add net ff02::: gateway ::1
add net ::ffff:0.0.0.0: gateway ::1
add net ::0.0.0.0: gateway ::1
route: writing to routing socket: Network is unreachable
add net default: gateway 2001:470:1f1c:a0::1 fib 0: Network is unreachable
% sudo service netif restart
…

Still, no route to host when I attempt to ping6 an IPv6 address.



IPv6 aside, for a moment: over the years, I lost count of the number of times that I needed to restart the entire OS for things to work as required with IPv4. Sometimes it was enough to sleep then wake the computer but more often, when things became a struggle, it was quicker to restart.



Back to IPv6. Now whilst the computer restarts I'll click my heels three times, close my eyes and repeat to myself "There's no place like a tunnel … there's no place like a tunnel … there's no place like a tunnel …"
 
Just so that you know, Hurricane Electric is in California... clear on the other side of this blue planet from you, but supposedly has tunnel hosts all over the world... there should be something closer to your place.
 
… your place.

Yep, Hurricane Electric's tunnel creation routine is pleasantly clear. I chose one of the London servers:

1623733916533.png
 
I currently use a HE tunnel even though my ISP provides IPv6, because HE offers me static prefixes and even rdns delegations, while I only get a dynamic prefix from the ISP. I use custom scripts with ppp(8) like this:

/etc/ppp/ppp.linkup:
Code:
dsl:
 !bg /usr/local/sbin/ppp-up MYADDR
/etc/ppp/ppp.linkdown:
Code:
dsl:
 !bg /usr/local/sbin/ppp-down

The part of the script bringing up the tunnel looks like this:
Code:
#!/bin/sh
WAN_ADDR=$1
[...]
(
	fetch -o /dev/null "https://UUUUUUUU:PPPPPPPPPPPPPPPPP@ipv4.tunnelbroker.net/nic/update?hostname=NNNNNN&myip=$WAN_ADDR"
	ifconfig gif0 create
	ifconfig gif0 tunnel $WAN_ADDR <tunnel-ipv4-remote>
	ifconfig gif0 inet6 <tunnel-ipv6-local> <tunnel-ipv6-remote> prefixlen 128
	route -n add -inet6 default <tunnel-ipv6-remote>
	ifconfig gif0 group external
	ifconfig gif0 up
) & disown

Bringing it down in the ppp-down script is simply:
Code:
route del -inet6 default
ifconfig gif0 down
ifconfig gif0 destroy
 
SirDice 's answer from 2013, found by Google...
It's pretty old, this is what I have nowadays (running on 13.0-RELEASE):
Code:
cloned_interfaces="gif0"
create_args_gif0="tunnel A.A.A.A X.X.X.X"
ifconfig_gif0_ipv6="inet6 2001:YYYY:YYYY:YYY::2 2001:YYYY:YYYY:YYYY::1 prefixlen 64"
ipv6_defaultrouter="-iface gif0"

A.A.A.A is my own IPv4 address, X.X.X.X is HE's IPv4 tunnel broker's address. The IPv6 tunnel addresses are the ones I got from HE. The rest of the IPv6 configuration should still be the same as it was back then.
 
ipv6_defaultrouter="-iface gif0"

If I include the router address in rc.conf:

ipv6_defaultrouter="⋯:⋯⋯:⋯::1"

– then it's not usable following service netif restart.

Subsequent use of route(8) is effective.

So, what might cause the rc.conf entry to be non-effective?

Code:
root@mowa219-gjp4-8570p:~ # ifconfig gif0 destroy
root@mowa219-gjp4-8570p:~ # service netif restart
Stopping dhclient.
Waiting for PIDS: 10547.
Stopping Network: lo0 em0 ue0.
lo0: flags=8048<LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        ⋯
em0: flags=8c22<BROADCAST,OACTIVE,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ⋯
ue0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ⋯
Destroyed wlan(4) interfaces: wlan0.
Created wlan(4) interfaces: wlan0.
Created clone interfaces: gif0.
Starting Network: lo0 em0 ue0 gif0.
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        ⋯
em0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ⋯
ue0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ⋯
gif0: flags=8011<UP,POINTOPOINT,MULTICAST> metric 0 mtu 1480
        options=80000<LINKSTATE>
        tunnel inet 192.168.1.10 --> ⋯.⋯.⋯.⋯
        inet6 fe80::⋯:⋯:⋯:⋯%gif0 prefixlen 64 tentative scopeid 0x4
        inet6 ⋯:⋯:⋯:⋯::2 --> ⋯:⋯:⋯:⋯::1 prefixlen 128 tentative
        groups: gif
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
root@mowa219-gjp4-8570p:~ # ping forums.freebsd.org
ping: Unknown host
root@mowa219-gjp4-8570p:~ # ping forums.freebsd.org
PING forums.freebsd.org (204.109.59.195): 56 data bytes
64 bytes from 204.109.59.195: icmp_seq=0 ttl=55 time=132.500 ms
^C
--- forums.freebsd.org ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 132.500/132.500/132.500/0.000 ms
root@mowa219-gjp4-8570p:~ # ping6 2620:fe::fe
ping6: UDP connect: No route to host
root@mowa219-gjp4-8570p:~ # route -n add -inet6 default ⋯:⋯:⋯:⋯::1
add net default: gateway ⋯:⋯:⋯:⋯::1
root@mowa219-gjp4-8570p:~ # ping6 2620:fe::fe
PING6(56=40+8+8 bytes) ⋯:⋯:⋯:⋯::2 --> 2620:fe::fe
16 bytes from 2620:fe::fe, icmp_seq=0 hlim=60 time=6.753 ms
16 bytes from 2620:fe::fe, icmp_seq=1 hlim=60 time=7.033 ms
^C
--- 2620:fe::fe ping6 statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 6.753/6.893/7.033/0.140 ms
root@mowa219-gjp4-8570p:~ # man route
root@mowa219-gjp4-8570p:~ # uname -KrU
14.0-CURRENT 1400021 1400021
root@mowa219-gjp4-8570p:~ #
 
then it's not usable following service netif restart.
Restart the /etc/rc.d/routing 'service'; service routing restart. Restarting netif removes routes associated with those interfaces from the routing table, which will need to be added back. With interfaces that use DHCP this is not a problem as those routes will get added dynamically after the DHCP has succeeded. Static routes (defaultrouter, static_routes) however will need to be re-applied, that's not done automatically.
 
Thanks,

service routing restart

The annoyance with this – and I've had it for years – is that the restart of the routing service must be followed by a restart of em0, which uses DHCP.
As if: restarting the routing service causes routing to stop working for em0.
Is this normal behaviour?

Code:
root@mowa219-gjp4-8570p:~ # grep ifconfig_em0 /etc/rc.conf | grep -v \#
ifconfig_em0="DHCP"
root@mowa219-gjp4-8570p:~ # ping6 2620:fe::fe
PING6(56=40+8+8 bytes) ⋯:⋯:⋯:⋯::2 --> 2620:fe::fe
16 bytes from 2620:fe::fe, icmp_seq=0 hlim=60 time=6.559 ms
^C
--- 2620:fe::fe ping6 statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 6.559/6.559/6.559/0.000 ms
root@mowa219-gjp4-8570p:~ # service routing restart
delete host 127.0.0.1: gateway lo0
default              192.168.1.1          -fib 0   done
delete host ::1: gateway lo0
delete net fe80::: gateway ::1
delete net ff02::: gateway ::1
delete net ::ffff:0.0.0.0: gateway ::1
delete net ::0.0.0.0: gateway ::1
delete net default: gateway ⋯:⋯:⋯:⋯::1
add host 127.0.0.1: gateway lo0
add host ::1: gateway lo0
add net fe80::: gateway ::1
add net ff02::: gateway ::1
add net ::ffff:0.0.0.0: gateway ::1
add net ::0.0.0.0: gateway ::1
add net default: gateway ⋯:⋯:⋯:⋯::1
root@mowa219-gjp4-8570p:~ # ping forums.freebsd.org
PING6(56=40+8+8 bytes) ⋯:⋯:⋯:⋯::2 --> 2607:fc50:1:c600:216:3eff:fe15:195
ping: sendmsg: No route to host
ping6: wrote forums.freebsd.org 16 chars, ret=-1
ping: sendmsg: No route to host
ping6: wrote forums.freebsd.org 16 chars, ret=-1
ping: sendmsg: No route to host
ping6: wrote forums.freebsd.org 16 chars, ret=-1
ping: sendmsg: No route to host
ping6: wrote forums.freebsd.org 16 chars, ret=-1
ping: sendmsg: No route to host
ping6: wrote forums.freebsd.org 16 chars, ret=-1
^C
--- forums.freebsd.org ping6 statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss
root@mowa219-gjp4-8570p:~ # ping6 2620:fe::fe
PING6(56=40+8+8 bytes) ⋯:⋯:⋯:⋯::2 --> 2620:fe::fe
ping6: sendmsg: No route to host
ping6: wrote 2620:fe::fe 16 chars, ret=-1
ping6: sendmsg: No route to host
ping6: wrote 2620:fe::fe 16 chars, ret=-1
ping6: sendmsg: No route to host
ping6: wrote 2620:fe::fe 16 chars, ret=-1
ping6: sendmsg: No route to host
ping6: wrote 2620:fe::fe 16 chars, ret=-1
^C
--- 2620:fe::fe ping6 statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss
root@mowa219-gjp4-8570p:~ # service netif restart em0
Stopping dhclient.
Waiting for PIDS: 11090.
Stopping Network: em0.
em0: flags=8c22<BROADCAST,OACTIVE,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ⋯
Starting Network: em0.
em0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ⋯
root@mowa219-gjp4-8570p:~ # ping forums.freebsd.org
PING forums.freebsd.org (204.109.59.195): 56 data bytes
64 bytes from 204.109.59.195: icmp_seq=0 ttl=55 time=132.435 ms
^C
--- forums.freebsd.org ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 132.435/132.435/132.435/0.000 ms
root@mowa219-gjp4-8570p:~ # ping6 2620:fe::fe
PING6(56=40+8+8 bytes) ⋯:⋯:⋯:⋯::2 --> 2620:fe::fe
16 bytes from 2620:fe::fe, icmp_seq=0 hlim=60 time=7.133 ms
16 bytes from 2620:fe::fe, icmp_seq=1 hlim=60 time=6.661 ms
16 bytes from 2620:fe::fe, icmp_seq=2 hlim=60 time=6.667 ms
^C
--- 2620:fe::fe ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 6.661/6.820/7.133/0.221 ms
root@mowa219-gjp4-8570p:~ #
 
The annoyance with this – and I've had it for years – is that the restart of the routing service must be followed by a restart of em0, which uses DHCP.
Try only starting it; service routing start. A restart is essentially a stop followed by a start. The stop will remove all routes, including the default gateway that was set with DHCP. But only starting it might produce some "route already exists" type messages.

Code:
service netif restart
service routing start
 
So, a stop followed by a start (restart) is not an effective start?

Should routines such as <https://cgit.freebsd.org/src/tree/libexec/rc/rc.d/routing> and <https://cgit.freebsd.org/src/tree/libexec/rc/rc.d/netif> be made to behave more predictably?

Postscript

I always found it odd that output from service netif restart was somewhat rushed for some types of interface. For example:

Code:
root@mowa219-gjp4-8570p:~ # service netif restart em0
Stopping dhclient.
Waiting for PIDS: 4016.
Stopping Network: em0.
em0: flags=8c22<BROADCAST,OACTIVE,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=481249b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LRO,WOL_MAGIC,VLAN_HWFILTER,NOMAP>
        ether ⋯
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
Starting Network: em0.
em0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=481249b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LRO,WOL_MAGIC,VLAN_HWFILTER,NOMAP>
        ether ⋯
        media: Ethernet autoselect
        status: no carrier
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
root@mowa219-gjp4-8570p:~ #
  • no inet address
  • no carrier.
Shortly afterwards:

Code:
root@mowa219-gjp4-8570p:~ # ifconfig em0
em0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=481249b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LRO,WOL_MAGIC,VLAN_HWFILTER,NOMAP>
        ether ⋯
        inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
root@mowa219-gjp4-8570p:~ #
 
They already behave very predictably. But I might be biased after using them for 20+ years.

I always found it odd that output from service netif restart was somewhat rushed for some types of interface.
Only if it's DHCP. That might take a while for it to get the address, the 'service' script is already finished. To force trigger a DHCP request it's better to use service dhclient restart em0.
 
fe80

Those are link-local addresses. …

… How can you tell? …

… The FreeBSD machine only shows an fe80 ipv6 address …

Found: <https://en.wikipedia.org/wiki/Link-local_address>,

… In IPv6, they are assigned from the block fe80::/10. …

fd58

Found: <https://community.talktalk.co.uk/t5/Technology/When-will-TalkTalk-support-IPv6/m-p/1689294#M16878> (2015-06-11):

… fd58 IPv6 is a Unique Local Addresses as opposed to a Link-Local Address. They are somewhat equivalent to the usual 192.168.1.0/24 addresses used in IPv4 NAT. …

– and The IPv6 ULA registry by ungleich.ch.

So re: <https://forums.FreeBSD.org/threads/80878/post-517155> it seems to me that:
  1. accepting ICMPv6 router advertisement messages – with em0 – allows me, theoretically, to have a ULA however
  2. accepting these messages with em0 will be pointless for as long as my ISP does not provide IPv6 service – true?
 
They already behave very predictably. But I might be biased after using them for 20+ years.

Thanks, would it be fair to say that prediction includes the possibility of the routing service not starting when restarted?

I mean: if it's not a bug, the plainest possible statement might help to avoid future confusion.
 
Where would a person look to discover the limitations in this case?
Reading the actual scripts in /etc/rc.d/ can be quite enlightening. Over the years I've probably read all of them at least once. Some more often than others, they do change over time. It's a little daunting at first but going through the entire rc(8) script process (starting with /etc/rc) can be quite an eye-opener.
 
If no (valid) nameservers are defined in the resolver for the purposes of drill(1): how are names resolved for other purposes?

Code:
root@mowa219-gjp4-8570p:~ # slowcat --bps 200 /etc/resolv.conf
# Generated by resolvconf
search lan
nameserver 192.168.1.1

root@mowa219-gjp4-8570p:~ # route -6 show beefy1.nyi.freebsd.org
   route to: beefy1.nyi.freebsd.org
destination: default
       mask: default
    gateway: tunnel642390.tunnel.tserv1.lon2.ipv6.he.net
        fib: 0
  interface: gif0
      flags: <UP,GATEWAY,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1480         1         0
root@mowa219-gjp4-8570p:~ # route show forums.freebsd.org
   route to: 204.109.59.195
destination: default
       mask: default
    gateway: 192.168.1.1
        fib: 0
  interface: em0
      flags: <UP,GATEWAY,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500         1         0
root@mowa219-gjp4-8570p:~ # drill -6 beefy1.nyi.freebsd.org
Error: error sending query: No (valid) nameservers defined in the resolver
root@mowa219-gjp4-8570p:~ # drill -4 forums.freebsd.org
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 48227
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; forums.freebsd.org.  IN      A

;; ANSWER SECTION:
forums.freebsd.org.     1408    IN      A       204.109.59.195

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 1 msec
;; SERVER: 192.168.1.1
;; WHEN: Tue Jun 15 15:16:57 2021
;; MSG SIZE  rcvd: 52
root@mowa219-gjp4-8570p:~ #

I see resolver(3):

… If no server is configured, the host running the resolver is tried. …

– but I can't see how that explains things.
 
You can resolve IPv6 addresses on a IPv4 DNS server. drill beefy1.nyi.freebsd.org AAAA. For resolving IPv6 addresses you don't need to contact the DNS server on IPv6 too (which is what drill -6 ... does). You don't have IPv6 DNS servers defined in your /etc/resolv.conf, which is fine.

With DNS A records are IPv4 addresses, AAAA records are the IPv6 addresses. You can query ANY to see all types of records. drill beefy1.nyi.freebsd.org ANY.
 
Sorry, I omitted the background.

I used option -6 because (previously) without it, the result seemed to bear no resemblance to the IP address:

Code:
root@mowa219-gjp4-8570p:~ # drill beefy1.nyi.freebsd.org
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 56417
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; beefy1.nyi.freebsd.org.      IN      A

;; ANSWER SECTION:

;; AUTHORITY SECTION:
freebsd.org.    1799    IN      SOA     ns0.freebsd.org. hostmaster.freebsd.org. 2021061501 3600 900 1209600 3600

;; ADDITIONAL SECTION:

;; Query time: 29 msec
;; SERVER: 192.168.1.1
;; WHEN: Tue Jun 15 16:17:57 2021
;; MSG SIZE  rcvd: 91
root@mowa219-gjp4-8570p:~ # ping beefy1.nyi.freebsd.org
PING6(56=40+8+8 bytes) ⋯:⋯:⋯:⋯::2 --> 2610:1c1:1:6080::16:10
16 bytes from 2610:1c1:1:6080::16:10, icmp_seq=0 hlim=52 time=73.690 ms
^C
--- beefy1.nyi.freebsd.org ping6 statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 73.690/73.690/73.690/0.000 ms
root@mowa219-gjp4-8570p:~ #

2610:1c1:1:6080::16:10 is the address, yes?
 
I used option -6 because (previously) without it, the result seemed to bear no resemblance to the IP address:
By default it will query for the A record, which doesn't exist. So it only shows you the SOA record of the authoritative domain. Query the AAAA record instead.
 
… You can query ANY to see all types of records. drill beefy1.nyi.freebsd.org ANY.

This puzzled me:

Code:
% drill beefy1.nyi.freebsd.org ANY
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 6490
;; flags: qr tc rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; beefy1.nyi.freebsd.org.      IN      ANY

;; ANSWER SECTION:

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 70 msec
;; SERVER: 192.168.1.1
;; WHEN: Tue Jun 15 16:32:14 2021
;; MSG SIZE  rcvd: 40

;; WARNING: The answer packet was truncated; you might want to
;; query again with TCP (-t argument), or EDNS0 (-b for buffer size)
%

… Query the AAAA record instead.

Better:

Code:
% drill beefy1.nyi.freebsd.org AAAA
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 32103
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; beefy1.nyi.freebsd.org.      IN      AAAA

;; ANSWER SECTION:
beefy1.nyi.freebsd.org. 2753    IN      AAAA    2610:1c1:1:6080::16:10

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 1 msec
;; SERVER: 192.168.1.1
;; WHEN: Tue Jun 15 16:32:22 2021
;; MSG SIZE  rcvd: 68
%

Too much (for me):

Code:
% drill -t beefy1.nyi.freebsd.org ANY
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 52621
;; flags: qr rd ra ; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; beefy1.nyi.freebsd.org.      IN      ANY

;; ANSWER SECTION:
beefy1.nyi.freebsd.org. 3386    IN      MX      0 .
beefy1.nyi.freebsd.org. 3386    IN      RRSIG   MX 8 4 3600 20210625143127 20210611134305 49369 freebsd.org. ux24FhKhzzngJS2PDMl8I63PjJcGM9WuLhwgSS7Alj6P7KkDtcz7I02qcUdWaSVWhOK2L2S9uataGVi3n/xO4fuwC/w85+CUWJGhgU5cbgJjjbsM7qsUYtu7Fg85TDCGP42ZVzUO7BDTRFCBX1kFjovBysbu+Ncm9d88+iL6p3IOJ5HU1u0LnpJvKceQM7V8UJaMcJHuZ9o722+j5gBdtnqFRLK+zYxrZWZzbOYNj+wSFmFiEvPW5+4o5yoKVDZtNd6u8oy5m51tC5vFZyu81gTGABnRXuQm/n6Kzyisak7GH/jS23xj11Ix7GOqFn9D1MCCoHXsE0AMJ5lcPko9lQ==
beefy1.nyi.freebsd.org. 3386    IN      AAAA    2610:1c1:1:6080::16:10
beefy1.nyi.freebsd.org. 3386    IN      RRSIG   AAAA 8 4 3600 20210620130135 20210606052101 49369 freebsd.org. GOUSOGotp/PGXcx6SsVgv728K+nM/wmXvdUelOkR7a84MsDzRBkJ5MshtbPl/HZHp/sdGfSs9B3KD7Ec4sNRRQN35ij3enrVObzSpMbrifWNfry8600UXafZx4GoHgfp4OUMEW5GGmiI+Kkv6NfzUUu6mJ/h0mBEDjuGCJxj2kdh5obnchc1pK7cMsc+uT5lsGtpESvju+AyDQzrVVPQsoIbva+rIzk3wmJgptFkNCz6S32QD+CCxQZwvW/io3Qxl6yZPSem2+68uj/uTIacfHUkunqHQWyAolMbN5Wg2TcHPb+W1FYEISm8g+8iTbgmgZjFa5hEn/GN02hdCr1aVg==
beefy1.nyi.freebsd.org. 3386    IN      SSHFP   1 1 f52d930a176a932e0c8b2b4260532998f0a8ac31
beefy1.nyi.freebsd.org. 3386    IN      SSHFP   1 2 fde59a689c98a3ebd70c75fa93153b6c901ee3940b43d78a050fe817dc916a09
beefy1.nyi.freebsd.org. 3386    IN      SSHFP   2 1 6f547f99c627d4393b932d25d573a6fc2b3c02e3
beefy1.nyi.freebsd.org. 3386    IN      SSHFP   2 2 ce4ea449b733a722b2e46bb45903a9645014db73d00830b112dfbcead4bb721b
beefy1.nyi.freebsd.org. 3386    IN      SSHFP   3 1 0997c79d4a81da1984d6d5029c88af947bf7a4d4
beefy1.nyi.freebsd.org. 3386    IN      SSHFP   3 2 554276abc900f2b804fe56c5641b902f572a150fbf0a8982cfab7d371184d37a
beefy1.nyi.freebsd.org. 3386    IN      SSHFP   4 1 11858500544c7da6650b0edc868aac3b62259998
beefy1.nyi.freebsd.org. 3386    IN      SSHFP   4 2 89f6db00b871a8d97bc261de9dd7cbc658f29cc40b53b4d09c9c1a93d4a7337e
beefy1.nyi.freebsd.org. 3386    IN      RRSIG   SSHFP 8 4 3600 20210624225406 20210611015616 49369 freebsd.org. puBgb5PCWBiEQAhpIFlBGSJjoZuJ28oHX3ME6wufjnCWCLiAZuEcpNzaBA4SWMRS4AjLsGaAX0xnx8fRT3s/Mj6Pmdb74JBu30OaAFlJV/qiAHhJNURAmCzE/ftQtD8uRwuvu7HEjRjA9aHutEwcfiqTw0SqFddRuVmF9vHwqU+DLXnhr4+L8KQD4zN55G6Bos+eTfalPCHlNQ4iSCcQb8ioaf62ldW4M5tl3k21cd6KcL7Ay4sHAH5xarWDEWe3RrKMj405OhcC9CXf/cIprN4LwEvLpXPC556gX/hUOJyTC5bl0HkdEqYrA7EuYxP2RMx/SyhBATNcHimCPrVQWg==

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 21 msec
;; SERVER: 192.168.1.1
;; WHEN: Tue Jun 15 16:35:23 2021
;; MSG SIZE  rcvd: 1300
%
 
This is where the piping comes in handy: % drill -t beefy1.nyi.freebsd.org ANY, pipe that into grep, like so: % drill -t beefy1.nyi.freebsd.org ANY | grep AAAA, and you'll get your IPv6 address to use. :p
 
Back
Top