Re: DNS64 & nslookup

2018-04-12 Thread Mark Andrews

> On 13 Apr 2018, at 2:22 am, Mark Boolootian  wrote:
> 
> 
> Hi Mark,
> 
> I know this is the wrong list for this
> discussion, but I wanted to reply on
> general principles.  I lurk on the v6ops
> list so know you think about this stuff
> a lot.
> 
> > Secondly, I would look at other mechanisms than DNS64/NAT64 to provide
> > IPv4 as-a-service.  It really has a lot of issues which the other
> > mechanisms don’t.
> 
> As near as I can tell, the primary issues that one
> needs to contend with relate to embedded IPv4
> literals, a few problematic apps (e.g. FTP), and
> apps built with APIs that lack support for IPv6.
> In our environment, we also have to deal with the
> odd assorted devices that lack IPv6 support altogether
> as well.  The theory is that we can run 464XLAT
> in order to provide a bump-in-the-wire CLAT to
> help with these cases.  It does mean we still have
> to hand out IPv4 addresses, but we don't have to
> route any of the v4 traffic on our backbone by
> virtue of placing the CLAT box on the same
> subnet as the hosts.

DNS64 also causes issues with DNSSEC.  None of the other IPv4-as-service
mechanisms have this issue.

> We've been running a DNS64/NAT64 without CLAT
> net for a while without much trouble, but with a pretty
> limited clientele.  The CLAT piece comes soon, and
> access will expand.  If you really think this is asking
> for trouble, I'd be interested in anything you can tell
> me about said trouble.

DNS64 and DNSSEC - DO NOT CO-EXIST. DNS64 appropriated the
DNSSEC control bits and re-purposed them is a way that breaks
DNSSEC when there are spoofing attacks or misconfigurations
with some of the authoritative servers.

DNSSEC validators need to be able to send *both* CD=0 and CD=1
queries and have them work as required for DNSSEC when the zone
they are retrieving answers from is signed.  A DNSSEC validator
needs unmodified answers for *both* types of queries.  A DNS64 server
cannot do that and be a DNS64 server at the same time.  The cache
can hide some of this but TTL=0 answer don’t get this benefit.

The reason that you are not seeing problems is that there are
very few validators behind DNS64 servers, not because the two
protocols work together.

Even 464XLAT has prefix discovery issues at the moment because
ipv4only.arpa is signed if you are using a validating client or
intermediate validating resolver.

> > Thirdly, I wouldn’t rush to running IPv6-only.  It does have its advantages
> > but they come with serious drawbacks.  At this stage IPv6-only is still
> > niche only.
> 
> IPv6-only offers some operational benefit - you are
> moving in the direction of supporting one protocol, reducing 
> complexity, and security is simpler.  We could run dual-stack, 
> but it does nothing to relieve the pressure on our IPv4 space. 
> Considering the aforementioned strategy, if you think serious
> drawbacks are inevitable, I'm all ears.  I do have to be able
> to support this as a production service - and I'm still trying to
> convince myself that's possible.

I presented a whole suite of IPv4-as-service alternatives. All of
these relieve address pressure by sharing IPv4 addresses just as
DNS64/NAT64 shares IPv4 addresses.

All of them can be used in a IPv6-only environment or can be used
on the border router with a IPv6-only access network.

> best,
> mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


RE: DNS64 & nslookup

2018-04-12 Thread Lagerholm, Stephan


From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mark 
Boolootian
Sent: Thursday, April 12, 2018 9:22 AM
To: Mark Andrews <ma...@isc.org>
Cc: Bind Users <bind-users@lists.isc.org>
Subject: Re: DNS64 & nslookup



> We've been running a DNS64/NAT64 without CLAT
> net for a while without much trouble, but with a pretty
> limited clientele.  The CLAT piece comes soon, and
> access will expand.  If you really think this is asking
> for trouble, I'd be interested in anything you can tell
> me about said trouble.

Here at T-Mobile US we use DNS64/NAT64 setup extensively for all our Iphones 
(about 10 million give or take) without much trouble. And we have some 50 
million Androids that are running IPv6 only with 464XLAT. 
Every now and then we run into hostnames like:
dig @ns1.discover.com. zinc-txn-notify.discovernetwork.com  +norec
That are totally busted and cause DNS64 to derail but we are just burning them 
down 1 by 1. I encourage you to join us in the IPv6-only world.  


>> Thirdly, I wouldn’t rush to running IPv6-only.  It does have its advantages
>> but they come with serious drawbacks.  At this stage IPv6-only is still
>> niche only.

I would encourage you to rush into running IPv6 only. It is not niche only, 
DNS64 scales and works fine even without 464XLAT.  Break stuff and expose the 
brokenness is the only path forward. 

/Stephan
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: DNS64 & nslookup

2018-04-12 Thread Mark Boolootian
Hi Mark,

I know this is the wrong list for this
discussion, but I wanted to reply on
general principles.  I lurk on the v6ops
list so know you think about this stuff
a lot.

> Secondly, I would look at other mechanisms than DNS64/NAT64 to provide
> IPv4 as-a-service.  It really has a lot of issues which the other
> mechanisms don’t.

As near as I can tell, the primary issues that one
needs to contend with relate to embedded IPv4
literals, a few problematic apps (e.g. FTP), and
apps built with APIs that lack support for IPv6.
In our environment, we also have to deal with the
odd assorted devices that lack IPv6 support altogether
as well.  The theory is that we can run 464XLAT
in order to provide a bump-in-the-wire CLAT to
help with these cases.  It does mean we still have
to hand out IPv4 addresses, but we don't have to
route any of the v4 traffic on our backbone by
virtue of placing the CLAT box on the same
subnet as the hosts.

We've been running a DNS64/NAT64 without CLAT
net for a while without much trouble, but with a pretty
limited clientele.  The CLAT piece comes soon, and
access will expand.  If you really think this is asking
for trouble, I'd be interested in anything you can tell
me about said trouble.

> Thirdly, I wouldn’t rush to running IPv6-only.  It does have its
advantages
> but they come with serious drawbacks.  At this stage IPv6-only is still
> niche only.

IPv6-only offers some operational benefit - you are
moving in the direction of supporting one protocol, reducing
complexity, and security is simpler.  We could run dual-stack,
but it does nothing to relieve the pressure on our IPv4 space.
Considering the aforementioned strategy, if you think serious
drawbacks are inevitable, I'm all ears.  I do have to be able
to support this as a production service - and I'm still trying to
convince myself that's possible.

best,
mark
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: DNS64 & nslookup

2018-04-11 Thread Mark Andrews
Firstly, you can tell nslookup to make  queries “nslookup -query=”.

nslookup is a really old tool which is why it make A queries by default.
It predates even the concept of IPv6 (which dates from ~1995).  The same
also applies to dig which is slightly younger than nslookup.

Secondly, I would look at other mechanisms than DNS64/NAT64 to provide
IPv4 as-a-service.  It really has a lot of issues which the other
mechanisms don’t.

Thirdly, I wouldn’t rush to running IPv6-only.  It does have its advantages
but they come with serious drawbacks.  At this stage IPv6-only is still
niche only.

DS-Lite, MAP-T, MAP-E, 464XLAT are all alternatives to running DNS64/NAT64.

Mark

> On 12 Apr 2018, at 9:26 am, Mark Boolootian  wrote:
> 
>>> As far as I know, a host with on an IPv6 address is only ever
>>> going to perform  lookups.  I'd be very interested to know
>>> if there are cases where that isn't true.
>> 
>> Well, if you run nslookup or dig -t a, you're asking for A records
>> explicitly.
> 
> Ah, true that.  Does nslookup do that by default?
> 
>> OK, fair enough.  If you ask a DNS64 server for an A record, it should still
>> give you back an A record.  If you ask for an  RR, then you will get 
>> back an
>>  record, even if it has to synthesize an A record into a 6-in-4 IPv6 
>> address.
> 
> Yes.  And this was what seemed weird about the original
> question.  In my experience, an IPv6 only host (and IPv6
> only means no routable v4 address - so you might have
> 169.254, but nothing else) only emits  lookups.  But
> maybe I need to look more carefully.  I'm working towards
> building an IPv6 only environment here, and my (often
> erroneous) thinking presupposes certain behavior.
> 
> cheers,
> mark
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: DNS64 & nslookup

2018-04-11 Thread Chuck Swiger
On Apr 11, 2018, at 4:26 PM, Mark Boolootian  wrote:
>>> As far as I know, a host with on an IPv6 address is only ever
>>> going to perform  lookups.  I'd be very interested to know
>>> if there are cases where that isn't true.
>> 
>> Well, if you run nslookup or dig -t a, you're asking for A records
>> explicitly.
> 
> Ah, true that.  Does nslookup do that by default?

Yes, nslookup has A as the default type.  Here is nslookup handling a  
query:

% nslookup -type= ipv4.l.google.com
Server: 192.168.1.1
Address:192.168.1.1#53

Non-authoritative answer:
*** Can't find ipv4.l.google.com: No answer

Authoritative answers can be found from:
l.google.com
origin = ns1.google.com
mail addr = dns-admin.google.com
serial = 192521433
refresh = 900
retry = 900
expire = 1800
minimum = 60

(If DNS64 was in place, I ought to see 74.125.24.x mapped to an IPv6 address 
instead-- something like 64:ff9b::74.125.24.x.)

Regards,
-- 
-Chuck

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: DNS64 & nslookup

2018-04-11 Thread Mark Boolootian
>> As far as I know, a host with on an IPv6 address is only ever
>> going to perform  lookups.  I'd be very interested to know
>> if there are cases where that isn't true.
>
> Well, if you run nslookup or dig -t a, you're asking for A records
> explicitly.

Ah, true that.  Does nslookup do that by default?

> OK, fair enough.  If you ask a DNS64 server for an A record, it should still
> give you back an A record.  If you ask for an  RR, then you will get back 
> an
>  record, even if it has to synthesize an A record into a 6-in-4 IPv6 
> address.

Yes.  And this was what seemed weird about the original
question.  In my experience, an IPv6 only host (and IPv6
only means no routable v4 address - so you might have
169.254, but nothing else) only emits  lookups.  But
maybe I need to look more carefully.  I'm working towards
building an IPv6 only environment here, and my (often
erroneous) thinking presupposes certain behavior.

cheers,
mark
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: DNS64 & nslookup

2018-04-11 Thread Chuck Swiger
On Apr 11, 2018, at 3:49 PM, Mark Boolootian  wrote:
> 
>>> I'll give those tools a try, but I don't understand how my client is 
>>> requesting
>> an A record. It only has IPv6 networking. DNS64 should be requesting an
>> A record, but that the client should see is the converted  record. Is 
>> that
>> not right?
>> 
>> Nope-- DNS requests aren't going to convert an A record to a  record.
>> 
>> Normally, IPv6 only machines should request IPv6  records by preference,
> 
> I think he was saying this.  If his machine is truly IPv6-only, then the
> resolver would only perform  lookups (I can't speak to what
> nslookup would do).  That  lookup gets forwarded to the DNS64
> box, which performs the A lookup (and finds no ), and then returns
> the synthesized  record.

Yes.  As Mark A noted, most apps use getaddrinfo()-- with PF_UNSPEC, the system
should ask for A or  records depending on whether IPv4 or IPv6 is preferred.

More sophisticated applications like web browsers tend to have an explicit
search ordering using several getaddrinfo() calls to try both PF_INET and 
PF_INET6,
and pay attention to which address family is getting results or results faster.

>> and fall back to IPv4 A records only when IPv6 isn't available.
> 
> As far as I know, a host with on an IPv6 address is only ever
> going to perform  lookups.  I'd be very interested to know
> if there are cases where that isn't true.

Well, if you run nslookup or dig -t a, you're asking for A records explicitly.

>> However, your   IPv6-only machine will route IPv4 traffic using
>> 6-in-4 or NAT64 addressing,   otherwise you'd get broken
>> connectivity to IPv4-only addresses.
> 
> Not that I'm saying anything you don't know, but that's the
> purpose of DNS64 - to make sure you can reach IPv4 only
> resources.  But if your IPv6-only host is trying to reach an
> IPv4 literal (e.g. embedded in a web page), then unless you
> have a 464 CLAT available, you're out of luck.

OK, fair enough.  If you ask a DNS64 server for an A record, it should still
give you back an A record.  If you ask for an  RR, then you will get back an
 record, even if it has to synthesize an A record into a 6-in-4 IPv6 
address.

Regards,
-- 
-Chuck

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: DNS64 & nslookup

2018-04-11 Thread Mark Andrews
DNS64 server takes a  lookup and if there are NOT  records at the name
it then performs a A lookup for the same name and maps the results into 
records and returns them.  There are additional caveats but that is the basic
process.

It does NOT take a A lookup and return  record.

A lookups get A answers.
 lookups get  answers.

Mark

> On 12 Apr 2018, at 8:51 am, Rick Tillery  wrote:
> 
> According to what I've read, that's exactly what DNS64 does. It converts A 
> records to  records. (For mixed networks, it just passes through  
> records, but that's not in my configuration):
> 
> "DNS64 is a mechanism for synthesizing  resource records (RRs) from A 
> RRs." - https://tools.ietf.org/html/rfc6147
> 
> "DNS64 describes a DNS server that when asked for a domain's  records, 
> but only finds A records, synthesizes the  records from the A records." - 
> https://en.m.wikipedia.org/wiki/IPv6_transition_mechanism
> 
> Rick
> 
> On Apr 11, 2018 5:40 PM, "Chuck Swiger"  wrote:
> On Apr 11, 2018, at 3:32 PM, Rick Tillery  wrote:
> > I'll give those tools a try, but I don't understand how my client is 
> > requesting an A record. It only has IPv6 networking. DNS64 should be 
> > requesting an A record, but that the client should see is the converted 
> >  record. Is that not right?
> 
> Nope-- DNS requests aren't going to convert an A record to a  record.
> 
> Normally, IPv6 only machines should request IPv6  records by preference, 
> and fall back to IPv4 A records only when IPv6 isn't available.  However, 
> your IPv6-only machine will route IPv4 traffic using 6-in-4 or NAT64 
> addressing, otherwise you'd get broken connectivity to IPv4-only addresses.
> 
> Regards,
> 
> -- 
> -Chuck
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: DNS64 & nslookup

2018-04-11 Thread Rick Tillery
According to what I've read, that's exactly what DNS64 does. It converts A
records to  records. (For mixed networks, it just passes through 
records, but that's not in my configuration):

"DNS64 is a mechanism for synthesizing  resource records (RRs) from A
RRs." - https://tools.ietf.org/html/rfc6147

"DNS64 describes a DNS server that when asked for a domain's  records,
but only finds A records, synthesizes the  records from the A records."
- https://en.m.wikipedia.org/wiki/IPv6_transition_mechanism

Rick

On Apr 11, 2018 5:40 PM, "Chuck Swiger"  wrote:

On Apr 11, 2018, at 3:32 PM, Rick Tillery  wrote:
> I'll give those tools a try, but I don't understand how my client is
requesting an A record. It only has IPv6 networking. DNS64 should be
requesting an A record, but that the client should see is the converted
 record. Is that not right?

Nope-- DNS requests aren't going to convert an A record to a  record.

Normally, IPv6 only machines should request IPv6  records by
preference, and fall back to IPv4 A records only when IPv6 isn't
available.  However, your IPv6-only machine will route IPv4 traffic using
6-in-4 or NAT64 addressing, otherwise you'd get broken connectivity to
IPv4-only addresses.

Regards,

-- 
-Chuck
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: DNS64 & nslookup

2018-04-11 Thread Mark Boolootian
>> I'll give those tools a try, but I don't understand how my client is 
>> requesting
> an A record. It only has IPv6 networking. DNS64 should be requesting an
> A record, but that the client should see is the converted  record. Is that
> not right?
>
> Nope-- DNS requests aren't going to convert an A record to a  record.
>
> Normally, IPv6 only machines should request IPv6  records by preference,

I think he was saying this.  If his machine is truly IPv6-only, then the
resolver would only perform  lookups (I can't speak to what
nslookup would do).  That  lookup gets forwarded to the DNS64
box, which performs the A lookup (and finds no ), and then returns
the synthesized  record.

> and fall back to IPv4 A records only when IPv6 isn't available.

As far as I know, a host with on an IPv6 address is only ever
going to perform  lookups.  I'd be very interested to know
if there are cases where that isn't true.

>  However, your   IPv6-only machine will route IPv4 traffic using
> 6-in-4 or NAT64 addressing,   otherwise you'd get broken
> connectivity to IPv4-only addresses.

Not that I'm saying anything you don't know, but that's the
purpose of DNS64 - to make sure you can reach IPv4 only
resources.  But if your IPv6-only host is trying to reach an
IPv4 literal (e.g. embedded in a web page), then unless you
have a 464 CLAT available, you're out of luck.

best,
mark
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: DNS64 & nslookup

2018-04-11 Thread Chuck Swiger
On Apr 11, 2018, at 3:32 PM, Rick Tillery  wrote:
> I'll give those tools a try, but I don't understand how my client is 
> requesting an A record. It only has IPv6 networking. DNS64 should be 
> requesting an A record, but that the client should see is the converted  
> record. Is that not right?

Nope-- DNS requests aren't going to convert an A record to a  record.

Normally, IPv6 only machines should request IPv6  records by preference, 
and fall back to IPv4 A records only when IPv6 isn't available.  However, your 
IPv6-only machine will route IPv4 traffic using 6-in-4 or NAT64 addressing, 
otherwise you'd get broken connectivity to IPv4-only addresses.

Regards,
-- 
-Chuck

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: DNS64 & nslookup

2018-04-11 Thread Mark Andrews
Because nslookup and dig are specialised DNS testing tools.  They
don’t use getaddrinfo to perform test lookups.  getaddrinfo is the
function that most applications use as part of the connection process.

> On 12 Apr 2018, at 8:33 am, Rick Tillery  wrote:
> 
> I'll give those tools a try, but I don't understand how my client is 
> requesting an A record. It only has IPv6 networking. DNS64 should be 
> requesting an A record, but that the client should see is the converted  
> record. Is that not right?
> 
> Rick
> 
> On Wed, Apr 11, 2018, 5:27 PM Chuck Swiger  wrote:
> On Apr 11, 2018, at 3:09 PM, Rick Tillery  wrote:
> > I appear to have my NAT64+DN64 IPv6 -> IPv4 network configured correctly, 
> > as I can access IPv4 only Internet sites, e.g. from my browser.  But some 
> > tools don't seem to work the way I think they should.
> > 
> > One example is nslookup.  If do nslookup ipv4.google.com, I get:
> > 
> > $ nslookup ipv4.google.com
> > Server: 2001:4:1f:98::2
> > Address:2001:4:1f:98::2#53
> > 
> > Non-authoritative answer:
> > ipv4.google.com canonical name = ipv4.l.google.com.
> > Name:   ipv4.l.google.com
> > Address: 216.58.218.110
> > 
> > Shouldn't the address (last line) be an IPv6 address (prefixed IPv4 
> > address, created by NAT64, such as 64:ff9b::216.58.218.110)?
> 
> Nope.  Whether your local system connects to IPv4 addresses via 
> NAT64-formatted IPv6 addresses is unrelated to DNS lookups of A or  
> records.  If you ask for an A record, you will get IPv4 address(es) back or 0 
> records, not an IPv6 address.
> 
> By the way, debugging DNS issues by using nslookup is difficult; try 
> switching to dig and consider the results of running "dig -t a 
> ipv4.l.google.com." and "dig -t  ipv4.l.google.com."
> 
> Regards,
> -- 
> -Chuck
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: DNS64 & nslookup

2018-04-11 Thread Rick Tillery
I'll give those tools a try, but I don't understand how my client is
requesting an A record. It only has IPv6 networking. DNS64 should be
requesting an A record, but that the client should see is the converted
 record. Is that not right?

Rick

On Wed, Apr 11, 2018, 5:27 PM Chuck Swiger  wrote:

> On Apr 11, 2018, at 3:09 PM, Rick Tillery  wrote:
> > I appear to have my NAT64+DN64 IPv6 -> IPv4 network configured
> correctly, as I can access IPv4 only Internet sites, e.g. from my browser.
> But some tools don't seem to work the way I think they should.
> >
> > One example is nslookup.  If do nslookup ipv4.google.com, I get:
> >
> > $ nslookup ipv4.google.com
> > Server: 2001:4:1f:98::2
> > Address:2001:4:1f:98::2#53
> >
> > Non-authoritative answer:
> > ipv4.google.com canonical name = ipv4.l.google.com.
> > Name:   ipv4.l.google.com
> > Address: 216.58.218.110
> >
> > Shouldn't the address (last line) be an IPv6 address (prefixed IPv4
> address, created by NAT64, such as 64:ff9b::216.58.218.110)?
>
> Nope.  Whether your local system connects to IPv4 addresses via
> NAT64-formatted IPv6 addresses is unrelated to DNS lookups of A or 
> records.  If you ask for an A record, you will get IPv4 address(es) back or
> 0 records, not an IPv6 address.
>
> By the way, debugging DNS issues by using nslookup is difficult; try
> switching to dig and consider the results of running "dig -t a
> ipv4.l.google.com." and "dig -t  ipv4.l.google.com."
>
> Regards,
> --
> -Chuck
>
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: DNS64 & nslookup

2018-04-11 Thread Chuck Swiger
On Apr 11, 2018, at 3:09 PM, Rick Tillery  wrote:
> I appear to have my NAT64+DN64 IPv6 -> IPv4 network configured correctly, as 
> I can access IPv4 only Internet sites, e.g. from my browser.  But some tools 
> don't seem to work the way I think they should.
> 
> One example is nslookup.  If do nslookup ipv4.google.com, I get:
> 
> $ nslookup ipv4.google.com
> Server: 2001:4:1f:98::2
> Address:2001:4:1f:98::2#53
> 
> Non-authoritative answer:
> ipv4.google.com canonical name = ipv4.l.google.com.
> Name:   ipv4.l.google.com
> Address: 216.58.218.110
> 
> Shouldn't the address (last line) be an IPv6 address (prefixed IPv4 address, 
> created by NAT64, such as 64:ff9b::216.58.218.110)?

Nope.  Whether your local system connects to IPv4 addresses via NAT64-formatted 
IPv6 addresses is unrelated to DNS lookups of A or  records.  If you ask 
for an A record, you will get IPv4 address(es) back or 0 records, not an IPv6 
address.

By the way, debugging DNS issues by using nslookup is difficult; try switching 
to dig and consider the results of running "dig -t a ipv4.l.google.com." and 
"dig -t  ipv4.l.google.com."

Regards,
-- 
-Chuck

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


DNS64 & nslookup

2018-04-11 Thread Rick Tillery
I appear to have my NAT64+DN64 IPv6 -> IPv4 network configured correctly,
as I can access IPv4 only Internet sites, e.g. from my browser.  But some
tools don't seem to work the way I think they should.

One example is nslookup.  If do nslookup ipv4.google.com, I get:

$ nslookup ipv4.google.com
Server: 2001:4:1f:98::2
Address:2001:4:1f:98::2#53

Non-authoritative answer:
ipv4.google.com canonical name = ipv4.l.google.com.
Name:   ipv4.l.google.com
Address: 216.58.218.110


Shouldn't the address (last line) be an IPv6 address (prefixed IPv4
address, created by NAT64, such as 64:ff9b::216.58.218.110)?

Here is my network configuration, set up with only IPv6 (DHCP address):

$ ip a
1: lo:  mtu 6556 qdisc noqueue state UNKNOWN qlen 1
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: enp0s3:  mtu 1500 qdisc pfifo_fast
state UP qlen 1000
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
inet6 2001:4:1f:98::1b1/128 scope global dynamic
   valid_lft 4663sec preferred_lft 1963sec
inet6 fe80:::::/64 scope link
   valid_lft forever preferred_lft forever


Here is the named.conf.options file:

options {
directory "/var/cache/bind";
auth-nxdomain no;
listen-on-v6 { any; };
allow-query { any; };
dns64 64::ff9b::/96 {
clients { any; };
exclude { ::/0; };
};
};


Is the nslookup output correct?  And if not, is this why tools like ping,
used with a URL, can't resolve the host without being explicitly told (i.e.
with ping -6 or ping6) that the target is IPv6?

Rick
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users