DNS64 & nslookup

[Mark Andrews]

> On 13 Apr 2018, at 2:22 am, Mark Boolootian <booloo at ucsc.edu> 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: marka at isc.org