Anyone know of a reliable public DNS64 service? Would be cool if Google added a Public DNS64 service, then I could point the NAT64 prefix at appropriately placed boxes in my network. Why? Other people are better than me at running DNS resolvers :-) -- Tim:>
On Fri, Aug 15, 2014 at 3:29 PM, Tim Durack <tdurack@gmail.com> wrote:
Anyone know of a reliable public DNS64 service?
Would be cool if Google added a Public DNS64 service, then I could point the NAT64 prefix at appropriately placed boxes in my network.
Why? Other people are better than me at running DNS resolvers :-)
No one is better than you at running DNS resolvers with low latency from your network. Even if they can run DNS resolvers with magical capabilities, they will still suffer from transit time. Rubens
Yeah, sort of agree, except I'm allergic to running services that aren't straight bit shoveling. NAT64 is pushing it, but at least that is just announcing a prefix. On Fri, Aug 15, 2014 at 2:33 PM, Rubens Kuhl <rubensk@gmail.com> wrote:
On Fri, Aug 15, 2014 at 3:29 PM, Tim Durack <tdurack@gmail.com> wrote:
Anyone know of a reliable public DNS64 service?
Would be cool if Google added a Public DNS64 service, then I could point the NAT64 prefix at appropriately placed boxes in my network.
Why? Other people are better than me at running DNS resolvers :-)
No one is better than you at running DNS resolvers with low latency from your network. Even if they can run DNS resolvers with magical capabilities, they will still suffer from transit time.
Rubens
-- Tim:>
For a public DNS64 service you also need a public NAT64. I suppose anyone willing to run a Tor exit node might be also willing to run such a service but it would be a traffic source anonymiser and likely would be abused. That said I could see it as a commercial service where only certain sets of IPv6 clients get to use the service with a strict mapping to IPv4 source addresses, logging etc. A ISP which had already set this up for themselves and had enough IPv4 addresses could offer this to IPv6 only ISP's as a service they could buy. Similarly a consortium of ISPs could set this up for their members possibly pooling IPv4 addresses from the members. Someone like HE might like to run such a service to further promote IPv6. This is something transit providers might get into. IPv6 to IPv4 Translation services for IPv6 only clients. The same arguements also work for DS-Lite. Mark In message <CAE_ug15pz69UOwQZ1z0kOKc+zE2s7j2H8-qoeo-QkE=M-jCKQg@mail.gmail.com>, Tim Durack writes:
Yeah, sort of agree, except I'm allergic to running services that aren't straight bit shoveling. NAT64 is pushing it, but at least that is just announcing a prefix.
On Fri, Aug 15, 2014 at 2:33 PM, Rubens Kuhl <rubensk@gmail.com> wrote:
On Fri, Aug 15, 2014 at 3:29 PM, Tim Durack <tdurack@gmail.com> wrote:
Anyone know of a reliable public DNS64 service?
Would be cool if Google added a Public DNS64 service, then I could point the NAT64 prefix at appropriately placed boxes in my network.
Why? Other people are better than me at running DNS resolvers :-)
No one is better than you at running DNS resolvers with low latency from your network. Even if they can run DNS resolvers with magical capabilities, they will still suffer from transit time.
Rubens
-- Tim:> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 2014-08-15 16:11, Mark Andrews wrote:
For a public DNS64 service you also need a public NAT64.
Not necessarily. If the public DNS64 server is using the well-known prefix 64:ff9b::/96 (from RFC6052), then all an eyeball network needs to do is route that /96 toward their own NAT64 environment. Jima
In message <53EE8A4B.9000101@jima.us>, Jima writes:
On 2014-08-15 16:11, Mark Andrews wrote:
For a public DNS64 service you also need a public NAT64.
Not necessarily. If the public DNS64 server is using the well-known prefix 64:ff9b::/96 (from RFC6052), then all an eyeball network needs to do is route that /96 toward their own NAT64 environment.
Jima
I can see a transfer request being made to TEXAS-WESLEYAN-UNIVERSITY for 64.64.64.0/24. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
For the record: Tim, I'm not on the NANOG lists and I don't see how I can respond to this thread: https://mailman.nanog.org/pipermail/nanog/2014-August/069267.html but I figured I'd let you know that: https://developers.google.com/speed/public-dns/docs/dns64 is now available for testing. Perhaps it will be some use. Regards, -Erik On Fri, Aug 15, 2014 at 2:29 PM, Tim Durack <tdurack@gmail.com> wrote:
Anyone know of a reliable public DNS64 service?
Would be cool if Google added a Public DNS64 service, then I could point the NAT64 prefix at appropriately placed boxes in my network.
Why? Other people are better than me at running DNS resolvers :-)
-- Tim:>
-- Tim:>
Interesting. Now we just need someone like he.net to announce the 64:ff9b::/96 prefix and run a public nat64 service. Den 30. maj 2016 03.08 skrev "Tim Durack" <tdurack@gmail.com>:
For the record:
Tim,
I'm not on the NANOG lists and I don't see how I can respond to this thread:
https://mailman.nanog.org/pipermail/nanog/2014-August/069267.html
but I figured I'd let you know that:
https://developers.google.com/speed/public-dns/docs/dns64
is now available for testing. Perhaps it will be some use.
Regards, -Erik
On Fri, Aug 15, 2014 at 2:29 PM, Tim Durack <tdurack@gmail.com> wrote:
Anyone know of a reliable public DNS64 service?
Would be cool if Google added a Public DNS64 service, then I could point the NAT64 prefix at appropriately placed boxes in my network.
Why? Other people are better than me at running DNS resolvers :-)
-- Tim:>
-- Tim:>
Ok that would be a bad idea. Nat64 is not stateless so to anycast it would be unstable. Sorry time to get to sleep. Regards Baldur Den 30. maj 2016 03.25 skrev "Baldur Norddahl" <baldur.norddahl@gmail.com>:
Interesting. Now we just need someone like he.net to announce the 64:ff9b::/96 prefix and run a public nat64 service. Den 30. maj 2016 03.08 skrev "Tim Durack" <tdurack@gmail.com>:
For the record:
Tim,
I'm not on the NANOG lists and I don't see how I can respond to this thread:
https://mailman.nanog.org/pipermail/nanog/2014-August/069267.html
but I figured I'd let you know that:
https://developers.google.com/speed/public-dns/docs/dns64
is now available for testing. Perhaps it will be some use.
Regards, -Erik
On Fri, Aug 15, 2014 at 2:29 PM, Tim Durack <tdurack@gmail.com> wrote:
Anyone know of a reliable public DNS64 service?
Would be cool if Google added a Public DNS64 service, then I could point the NAT64 prefix at appropriately placed boxes in my network.
Why? Other people are better than me at running DNS resolvers :-)
-- Tim:>
-- Tim:>
In message <CAPkb-7Dcfwzy2amNXJS0jQKm1S36N8c5p=SpjMbeWFRt4OOphw@mail.gmail.com> , Baldur Norddahl writes:
Ok that would be a bad idea. Nat64 is not stateless so to anycast it would be unstable.
This is not anycast NAT64. It is anycast DNS64 with the well known 64:ff9b::/96 prefix and a local NAT64 box. While I don't like DNS64 as a solution, this service doesn't need to be critised for faults that don't exist with it. Mark
Sorry time to get to sleep.
Regards
Baldur Den 30. maj 2016 03.25 skrev "Baldur Norddahl" <baldur.norddahl@gmail.com>:
Interesting. Now we just need someone like he.net to announce the 64:ff9b::/96 prefix and run a public nat64 service. Den 30. maj 2016 03.08 skrev "Tim Durack" <tdurack@gmail.com>:
For the record:
Tim,
I'm not on the NANOG lists and I don't see how I can respond to this thread:
https://mailman.nanog.org/pipermail/nanog/2014-August/069267.html
but I figured I'd let you know that:
https://developers.google.com/speed/public-dns/docs/dns64
is now available for testing. Perhaps it will be some use.
Regards, -Erik
On Fri, Aug 15, 2014 at 2:29 PM, Tim Durack <tdurack@gmail.com> wrote:
Anyone know of a reliable public DNS64 service?
Would be cool if Google added a Public DNS64 service, then I could point the NAT64 prefix at appropriately placed boxes in my network.
Why? Other people are better than me at running DNS resolvers :-)
-- Tim:>
-- Tim:>
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Mon 2016-May-30 11:45:11 +1000, Mark Andrews <marka@isc.org> wrote:
In message <CAPkb-7Dcfwzy2amNXJS0jQKm1S36N8c5p=SpjMbeWFRt4OOphw@mail.gmail.com> , Baldur Norddahl writes:
Ok that would be a bad idea. Nat64 is not stateless so to anycast it would be unstable.
This is not anycast NAT64. It is anycast DNS64 with the well known 64:ff9b::/96 prefix and a local NAT64 box.
While I don't like DNS64 as a solution, this service doesn't need to be critised for faults that don't exist with it.
Pretty sure this was in response to:
Interesting. Now we just need someone like he.net to announce the 64:ff9b::/96 prefix and run a public nat64 service.
...so specifically regarding the idea of a public, anycast NAT64 service, rather than the public DNS64 service Google is doing.
Mark
-- Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com pgp key: B178313E | also on Signal
Sorry time to get to sleep.
Regards
Baldur Den 30. maj 2016 03.25 skrev "Baldur Norddahl" <baldur.norddahl@gmail.com>:
Interesting. Now we just need someone like he.net to announce the 64:ff9b::/96 prefix and run a public nat64 service. Den 30. maj 2016 03.08 skrev "Tim Durack" <tdurack@gmail.com>:
For the record:
Tim,
I'm not on the NANOG lists and I don't see how I can respond to this thread:
https://mailman.nanog.org/pipermail/nanog/2014-August/069267.html
but I figured I'd let you know that:
https://developers.google.com/speed/public-dns/docs/dns64
is now available for testing. Perhaps it will be some use.
Regards, -Erik
On Fri, Aug 15, 2014 at 2:29 PM, Tim Durack <tdurack@gmail.com> wrote:
Anyone know of a reliable public DNS64 service?
Would be cool if Google added a Public DNS64 service, then I could point the NAT64 prefix at appropriately placed boxes in my network.
Why? Other people are better than me at running DNS resolvers :-)
-- Tim:>
-- Tim:>
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Mon, 30 May 2016, Hugo Slabbert wrote:
...so specifically regarding the idea of a public, anycast NAT64 service, rather than the public DNS64 service Google is doing.
Like HE is doing? swmike@uplift:~$ dig +short AAAA ipv4.swm.pp.se @nat64.he.net 2001:470:64:ffff::d4f7:c88f swmike@uplift:~$ ping6 2001:470:64:ffff::d4f7:c88f PING 2001:470:64:ffff::d4f7:c88f(2001:470:64:ffff::d4f7:c88f) 56 data bytes 64 bytes from 2001:470:64:ffff::d4f7:c88f: icmp_seq=1 ttl=42 time=316 ms 64 bytes from 2001:470:64:ffff::d4f7:c88f: icmp_seq=2 ttl=42 time=315 ms Now, pinging myself via DNS64/NAT64 service and getting 315ms RTT means the NAT64 isn't very local to me... :P -- Mikael Abrahamsson email: swmike@swm.pp.se
In message <alpine.DEB.2.02.1605301725200.28372@uplift.swm.pp.se>, Mikael Abrah amsson writes:
On Mon, 30 May 2016, Hugo Slabbert wrote:
...so specifically regarding the idea of a public, anycast NAT64 service, rather than the public DNS64 service Google is doing.
Like HE is doing?
swmike@uplift:~$ dig +short AAAA ipv4.swm.pp.se @nat64.he.net 2001:470:64:ffff::d4f7:c88f swmike@uplift:~$ ping6 2001:470:64:ffff::d4f7:c88f PING 2001:470:64:ffff::d4f7:c88f(2001:470:64:ffff::d4f7:c88f) 56 data bytes 64 bytes from 2001:470:64:ffff::d4f7:c88f: icmp_seq=1 ttl=42 time=316 ms 64 bytes from 2001:470:64:ffff::d4f7:c88f: icmp_seq=2 ttl=42 time=315 ms
Now, pinging myself via DNS64/NAT64 service and getting 315ms RTT means the NAT64 isn't very local to me... :P
I don't know if that is a anycast NAT64. Just because pings get through doesn't mean that other traffic will get through. It really depends upon whether all the IPv6 traffic in the stream all gets routed to the same NAT64 instance. For short lived session this is highly likely. For long lived sessions not so much. For ping there is a single packet each direction. For other protocols there isn't. Mark
-- Mikael Abrahamsson email: swmike@swm.pp.se -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Like HE is doing?
swmike@uplift:~$ dig +short AAAA ipv4.swm.pp.se @nat64.he.net 2001:470:64:ffff::d4f7:c88f swmike@uplift:~$ ping6 2001:470:64:ffff::d4f7:c88f PING 2001:470:64:ffff::d4f7:c88f(2001:470:64:ffff::d4f7:c88f) 56 data bytes 64 bytes from 2001:470:64:ffff::d4f7:c88f: icmp_seq=1 ttl=42 time=316 ms 64 bytes from 2001:470:64:ffff::d4f7:c88f: icmp_seq=2 ttl=42 time=315 ms
Now, pinging myself via DNS64/NAT64 service and getting 315ms RTT means the NAT64 isn't very local to me... :P
It goes to the USA and back again. They would need NAT64 servers in every region and then let the DNS64 service decide which one is close to you by encoding the region information in the returned IPv6 address. Such as 2001:470:64:[region number]::/96. An anycast solution would need a distributed NAT64 implementation, such that the NAT64 servers could somehow synchronize state. A more simple solution is just to have the DNS64 be anycast and have a DNS64 at each NAT64 location with the DNS64 returning pointers to the local NAT64. Now, can we have a public MAP server? That might scale. The geo blockers will hate it. What is not to like? Regards, Baldur
On Monday, May 30, 2016, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
Like HE is doing?
swmike@uplift:~$ dig +short AAAA ipv4.swm.pp.se @nat64.he.net 2001:470:64:ffff::d4f7:c88f swmike@uplift:~$ ping6 2001:470:64:ffff::d4f7:c88f PING 2001:470:64:ffff::d4f7:c88f(2001:470:64:ffff::d4f7:c88f) 56 data
bytes
64 bytes from 2001:470:64:ffff::d4f7:c88f: icmp_seq=1 ttl=42 time=316 ms 64 bytes from 2001:470:64:ffff::d4f7:c88f: icmp_seq=2 ttl=42 time=315 ms
Now, pinging myself via DNS64/NAT64 service and getting 315ms RTT means the NAT64 isn't very local to me... :P
It goes to the USA and back again. They would need NAT64 servers in every region and then let the DNS64 service decide which one is close to you by encoding the region information in the returned IPv6 address. Such as 2001:470:64:[region number]::/96.
An anycast solution would need a distributed NAT64 implementation, such that the NAT64 servers could somehow synchronize state. A more simple solution is just to have the DNS64 be anycast and have a DNS64 at each NAT64 location with the DNS64 returning pointers to the local NAT64.
Now, can we have a public MAP server? That might scale. The geo blockers will hate it. What is not to like?
MAP scale. I know folks think it is theoretically nice but.... Just curious, has anyone yet deployed MAP at scale? I know of several production and large scale nat64s (usually mobile 464xlat related), and a few large ds-lite, but never MAP in production at scale. Maybe i am missing something. CB Regards,
Baldur
On Monday, May 30, 2016, Ca By <cb.list6@gmail.com> wrote:
On Monday, May 30, 2016, Baldur Norddahl <baldur.norddahl@gmail.com <javascript:_e(%7B%7D,'cvml','baldur.norddahl@gmail.com');>> wrote:
Like HE is doing?
swmike@uplift:~$ dig +short AAAA ipv4.swm.pp.se @nat64.he.net 2001:470:64:ffff::d4f7:c88f swmike@uplift:~$ ping6 2001:470:64:ffff::d4f7:c88f PING 2001:470:64:ffff::d4f7:c88f(2001:470:64:ffff::d4f7:c88f) 56 data
bytes
64 bytes from 2001:470:64:ffff::d4f7:c88f: icmp_seq=1 ttl=42 time=316 ms 64 bytes from 2001:470:64:ffff::d4f7:c88f: icmp_seq=2 ttl=42 time=315 ms
Now, pinging myself via DNS64/NAT64 service and getting 315ms RTT means the NAT64 isn't very local to me... :P
It goes to the USA and back again. They would need NAT64 servers in every region and then let the DNS64 service decide which one is close to you by encoding the region information in the returned IPv6 address. Such as 2001:470:64:[region number]::/96.
An anycast solution would need a distributed NAT64 implementation, such that the NAT64 servers could somehow synchronize state. A more simple solution is just to have the DNS64 be anycast and have a DNS64 at each NAT64 location with the DNS64 returning pointers to the local NAT64.
Now, can we have a public MAP server? That might scale. The geo blockers will hate it. What is not to like?
MAP scale. I know folks think it is theoretically nice but....
Just curious, has anyone yet deployed MAP at scale? I know of several production and large scale nat64s (usually mobile 464xlat related), and a few large ds-lite, but never MAP in production at scale. Maybe i am missing something.
CB
Tore's email reminded me that we got no answers about a production large scale MAP deployment. I guess it is yet to be deployed. Since it came up 2x in this thread, not only is MAP apparently not deployed anywhere at scale and therefore unproven in the real world, it would not fit this public usecase. MAP requires dhcpv6 and that dhcpv6 server must statefully / tight-coordination assign the addresses and ports to the end user. This complexity and requirement, along with the unsavoriness of yet another tunnel made MAP a deal breaker for my network. It also statically assigns s fixed number of scarce ipv4 ports to users, this is inefficient and not flexible. I suppose some party could launch a public dhpv6 server. But the 2nd hop routing would not work without several hacks CB
Regards,
Baldur
On 31/May/16 01:28, Baldur Norddahl wrote:
It goes to the USA and back again. They would need NAT64 servers in every region and then let the DNS64 service decide which one is close to you by encoding the region information in the returned IPv6 address. Such as 2001:470:64:[region number]::/96.
An anycast solution would need a distributed NAT64 implementation, such that the NAT64 servers could somehow synchronize state. A more simple solution is just to have the DNS64 be anycast and have a DNS64 at each NAT64 location with the DNS64 returning pointers to the local NAT64.
That is what we do. We've got NAT64 routers deployed at every PoP/region, to keep NAT64 state local and more predictable. Needless to say, the distribution reduces the impact of the "CG" from the "CG-NAT64". Mark.
* Baldur Norddahl
It goes to the USA and back again. They would need NAT64 servers in every region and then let the DNS64 service decide which one is close to you by encoding the region information in the returned IPv6 address. Such as 2001:470:64:[region number]::/96.
An anycast solution would need a distributed NAT64 implementation, such that the NAT64 servers could somehow synchronize state.
Or you could simply accept that active sessions are torn down whenever the routing topology changes enough to flip traffic to the anycast prefix to another NAT64 instance in a different region. It would be no different from any other anycasted service. Tore
In message <20160601103707.7de9d97f@envy.e5.y.home>, Tore Anderson writes:
* Baldur Norddahl
It goes to the USA and back again. They would need NAT64 servers in every region and then let the DNS64 service decide which one is close to you by encoding the region information in the returned IPv6 address. Such as 2001:470:64:[region number]::/96.
An anycast solution would need a distributed NAT64 implementation, such that the NAT64 servers could somehow synchronize state.
Or you could simply accept that active sessions are torn down whenever the routing topology changes enough to flip traffic to the anycast prefix to another NAT64 instance in a different region.
It would be no different from any other anycasted service.
But some services are inherently short lived. NAT64 has no such property.
Tore -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
* Mark Andrews
In message <20160601103707.7de9d97f@envy.e5.y.home>, Tore Anderson writes:
Or you could simply accept that active sessions are torn down whenever the routing topology changes enough to flip traffic to the anycast prefix to another NAT64 instance in a different region.
It would be no different from any other anycasted service.
But some services are inherently short lived. NAT64 has no such property.
Well, yes - it depends on the service/application, right? That is, anycasted_${service} will work pretty much the same as ${service}_via_anycasted_nat64 for most values of ${service}. Assuming that: 1) most of your customer's sessions are short-lived and/or their applications can handle failures reasonably gracefully, and/or 2) you have a stable and well-designed network where you can be reasonably certain that the traffic from clients in city/region/country X is going to consistently be routed to the NAT64 instance in city/region/country X: ...you will have very little to gain by setting up some complicated NAT64 session replication scheme to city/region/country Y, Z, and so on. KISS: Just use different IPv4 source address pools in each location and accept that any long-lived sessions are interrupted when your routing turns really wonky once in a blue moon. If on the other hand you cannot under any circumstance accept disruption to existing sessions, you probably don't want to be using any form of NAT in the first place. It's not like anycast routes flipping is the only reason why sessions through a NAT can be disrupted. In that case, native IPv6 is probably better, or possibly MAP if you have no control over the (presumably IPv4-only) remote ends of those sessions. Tore
DNS64 is a bad solution. It breaks DNSSEC. The proported benefits of DNS64 over other ways of providing IPv4 over IPv6 don't actually exist. DS-Lite or one of the MAP encapsulation will actually be better in the long run. I say this as someone who has written a DNS64 implementation. Mark In message <CAE_ug16_y+Ww8B3vkh-V4RNgGJyGcT9GH65z7uYpf_-XuR_ReA@mail.gmail.com> , Tim Durack writes:
For the record:
Tim,
I'm not on the NANOG lists and I don't see how I can respond to this thread:
https://mailman.nanog.org/pipermail/nanog/2014-August/069267.html
but I figured I'd let you know that:
https://developers.google.com/speed/public-dns/docs/dns64
is now available for testing. Perhaps it will be some use.
Regards, -Erik
On Fri, Aug 15, 2014 at 2:29 PM, Tim Durack <tdurack@gmail.com> wrote:
Anyone know of a reliable public DNS64 service?
Would be cool if Google added a Public DNS64 service, then I could point the NAT64 prefix at appropriately placed boxes in my network.
Why? Other people are better than me at running DNS resolvers :-)
-- Tim:>
-- Tim:> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
IP6.ARPA lookups aren't working. Adobe.com doesn't have AAAA record so it correctly returns a DNS64 mapped AAAA record. However when you attempt to do a IP6.ARPA lookup on that address it does not follow the synthesised CNAME record as you would expect from a recursive DNS64 server. Mark ; <<>> DiG 9.11.0a2 <<>> aaaa adobe.com @2001:4860:4860::6464 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16081 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;adobe.com. IN AAAA ;; ANSWER SECTION: adobe.com. 10799 IN AAAA 64:ff9b::c096:1075 ;; Query time: 435 msec ;; SERVER: 2001:4860:4860::6464#53(2001:4860:4860::6464) ;; WHEN: Mon May 30 11:55:56 EST 2016 ;; MSG SIZE rcvd: 66 ; <<>> DiG 9.11.0a2 <<>> -x 64:ff9b::c096:1075 @2001:4860:4860::6464 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16070 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;5.7.0.1.6.9.0.c.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.9.f.f.4.6.0.0.ip6.arpa. IN PTR ;; ANSWER SECTION: 5.7.0.1.6.9.0.c.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.9.f.f.4.6.0.0.ip6.arpa. 10799 IN CNAME 117.16.150.192.in-addr.arpa. ;; Query time: 355 msec ;; SERVER: 2001:4860:4860::6464#53(2001:4860:4860::6464) ;; WHEN: Mon May 30 11:56:12 EST 2016 ;; MSG SIZE rcvd: 138 ; <<>> DiG 9.11.0a2 <<>> ptr 117.16.150.192.in-addr.arpa @2001:4860:4860::6464 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 93 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;117.16.150.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 117.16.150.192.in-addr.arpa. 10532 IN PTR www.wip4.adobe.com. ;; Query time: 338 msec ;; SERVER: 2001:4860:4860::6464#53(2001:4860:4860::6464) ;; WHEN: Mon May 30 11:56:36 EST 2016 ;; MSG SIZE rcvd: 88 In message <CAE_ug16_y+Ww8B3vkh-V4RNgGJyGcT9GH65z7uYpf_-XuR_ReA@mail.gmail.com> , Tim Durack writes:
For the record:
Tim,
I'm not on the NANOG lists and I don't see how I can respond to this thread:
https://mailman.nanog.org/pipermail/nanog/2014-August/069267.html
but I figured I'd let you know that:
https://developers.google.com/speed/public-dns/docs/dns64
is now available for testing. Perhaps it will be some use.
Regards, -Erik
On Fri, Aug 15, 2014 at 2:29 PM, Tim Durack <tdurack@gmail.com> wrote:
Anyone know of a reliable public DNS64 service?
Would be cool if Google added a Public DNS64 service, then I could point the NAT64 prefix at appropriately placed boxes in my network.
Why? Other people are better than me at running DNS resolvers :-)
-- Tim:>
-- Tim:> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
participants (10)
-
Baldur Norddahl -
Ca By -
Hugo Slabbert -
Jima -
Mark Andrews -
Mark Tinka -
Mikael Abrahamsson -
Rubens Kuhl -
Tim Durack -
Tore Anderson