[Cerowrt-devel] coping with ipv6 source routing and dns

[Cerowrt-devel] coping with ipv6 source routing and dns

[Dave Taht]

I have been (mostly) happily fiddling with my new comcast ipv6 connection,
trying to route all dns queries over ipv6 in particular, by disabling
requesting the ipv4 dns addrs and relying on the dhcpv6 request to
succeed.

config interface eth0
        option 'ifname' 'eth0'
        option 'proto'  'dhcp'
        option 'peerdns' '0'

config interface wan6
        option ifname   @eth0
        option proto    dhcpv6
        option 'broadcast' '1'
        option 'metric' '2048'

works. yea! no more nat holes for ipv4 dns.

Problem is, I also have a hurricane electric tunnel. When I try to use
both, addresses from one get used on the other and dns forward
lookups fail.

I think the right answer is to abandon resolv.conf.auto
and instead explicitly assign ipv6 source addrs in dnsmasq...

server=2001:558:feed::1@AAAA:comcast:assigned:ipv6:address
server=2001:558:feed::2@AAAA:comcast.assigned:ipv6:address
server=2001:470:20::2@my:hurricane:assigned:ipv6:address

yes? (I'll be trying this in a bit)

One thing of possible useful note is that (yea!) we can just
select some arbitrary new ipv6 address within the assigned range,
add it to the local dnsmasq server box, and source dns lookups from
that, using up just that port space.

then my own /etc/resolv.conf just points to localhost
for hm.armory.com,

so I fix that with

server=/hm.armory.com/172.26.3.1/
server=/wifi.armory.com/172.26.2.1/

But this doesn't help in terms of reverse lookups (I think),
where I might or might not have my own delegated subdomain.

from

someoption=
comcast.assigned.ipv6.address.range/60 lookup via 2001:558:feed::1 or ::2
someoption=
he.assigned.ipv6.address.range/48 lookup via 2001:470:20::2

?

and then there's splitting dns... where I might want nuc.hm.armory.com
AAAAs available to the outside universe. somehow.

?


My brain hurts.




-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] coping with ipv6 source routing and dns

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 173 bytes --]

Dave Taht <dave.taht@gmail.com> writes:

> works. yea! no more nat holes for ipv4 dns.

Eh? Nat holes for DNS? What exactly are you doing, and what is your
setup? :)

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] coping with ipv6 source routing and dns

[Dave Taht]

On Wed, Jan 29, 2014 at 2:02 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> Dave Taht <dave.taht@gmail.com> writes:
>
>> works. yea! no more nat holes for ipv4 dns.
>
> Eh? Nat holes for DNS? What exactly are you doing, and what is your
> setup? :)
>
> -Toke

1 case:

Since most forwarders can't be trusted to return NXDOMAIN, an internal
email box at several of my sites runs dns directly. A few dnsrbl providers
offer ipv6 transport, so it's possible.

One advantage of dnssec is we get NXDOMAIN working again, so a
forwarder can be used...


-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] coping with ipv6 source routing and dns

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 570 bytes --]

Dave Taht <dave.taht@gmail.com> writes:

> Since most forwarders can't be trusted to return NXDOMAIN, an internal
> email box at several of my sites runs dns directly. A few dnsrbl
> providers offer ipv6 transport, so it's possible.

Ah, I see. I just run bind on cerowrt. Have to set an ntp server by IP
(or in /etc/hosts; I use an internal GPS-backed server) to bootstrap,
but otherwise it works well.

> One advantage of dnssec is we get NXDOMAIN working again, so a
> forwarder can be used...

Presumably only if the forwarder doesn't strip the dnssec stuff?

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] coping with ipv6 source routing and dns

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 893 bytes --]

Dave Taht <dave.taht@gmail.com> writes:

> But this doesn't help in terms of reverse lookups (I think),
> where I might or might not have my own delegated subdomain.
>
> from
>
> someoption=
> comcast.assigned.ipv6.address.range/60 lookup via 2001:558:feed::1 or ::2
> someoption=
> he.assigned.ipv6.address.range/48 lookup via 2001:470:20::2

As in, reverse lookup comcast.assign.ipv6.address.range from server
2001:558...etc? Isn't that just another server= option for some part of
ip6.arpa?

> and then there's splitting dns... where I might want nuc.hm.armory.com
> AAAAs available to the outside universe. somehow.

Assign a parent domain to a public server and subdelegate as appropriate
From there? (I think?)

> My brain hurts.

Well the 'distributed' part of DNS is not really meant to be distributed
in the true non-hierarchal sense, I suppose. :P

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]