Re: DNS64 & nslookup
> 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
Phones are a niche market. They don’t do DNSSEC. Some of them have a CLAT to handle IPv4 literals. Also users are used to phones having restrictions on them which really shouldn’t be there and don’t get addressed even if you do complain so I wouldn’t take the lack of complaints as there are no problems. This is a industry wide issue. -- Mark Andrews > On 13 Apr 2018, at 02:47, Lagerholm, Stephan > wrote: > > > > 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 > Cc: Bind Users > 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
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 Cc: Bind Users 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
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
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
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
>> 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
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
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
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
>> 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
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
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
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
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