EDNS compliance of servers for the Alexa Top 1M

2016-05-30 Thread Mark Andrews
If you are a Alexa Top 1M entry or host the DNS for a Alexa Top 1M entry you should be paying attention. I'm focusing here on unknown EDNS option handling as ISC is about to release a version of named which will exercise these errors in your nameservers. BIND 9.11.0 will ship with EDNS COOKIE en

Re: rfc 1812 third party address on traceroute

2016-05-30 Thread Larry Sheldon
I am completely innocent of rfc1812, and have been out of the game for a long time, but I am pretty sure I was taught (and in turn taught) that a router would reply using the address of the interface that originated the reply unless that interface was unnumbered, in which case it would reply

Re: Public DNS64

2016-05-30 Thread Mark Tinka
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:[regi

Re: rfc 1812 third party address on traceroute

2016-05-30 Thread Mikael Abrahamsson
On Mon, 30 May 2016, Randy Bush wrote: of course, simpletons such as i would desire the source of the time exceeded message to be A. after all, this is the interface to which i sent the icmp with the TTL to expire. I agree 100%, and I'd venture to guess that most of the people running networ

rfc 1812 third party address on traceroute

2016-05-30 Thread Randy Bush
rfc1812 says 4.3.2.4 ICMP Message Source Address Except where this document specifies otherwise, the IP source address in an ICMP message originated by the router MUST be one of the IP addresses associated with the physical interface over which the ICMP message is transmitted. If

Re: Public DNS64

2016-05-30 Thread Ca By
On Monday, May 30, 2016, Baldur Norddahl wrote: > > > > Like HE is doing? > > > > swmike@uplift:~$ dig +short ipv4.swm.pp.se @nat64.he.net > > 2001:470:64:::d4f7:c88f > > swmike@uplift:~$ ping6 2001:470:64:::d4f7:c88f > > PING 2001:470:64:::d4f7:c88f(2001:470:64:::d4f7:c88f)

Re: Public DNS64

2016-05-30 Thread Baldur Norddahl
> > Like HE is doing? > > swmike@uplift:~$ dig +short ipv4.swm.pp.se @nat64.he.net > 2001:470:64:::d4f7:c88f > swmike@uplift:~$ ping6 2001:470:64:::d4f7:c88f > PING 2001:470:64:::d4f7:c88f(2001:470:64:::d4f7:c88f) 56 data bytes > 64 bytes from 2001:470:64:::d4f7:c88f: icmp_

Re: Public DNS64

2016-05-30 Thread Mark Andrews
In message , 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 ipv4.swm.pp.

Re: Public DNS64

2016-05-30 Thread Mikael Abrahamsson
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 ipv4.swm.pp.se @nat64.he.net 2001:470:64:::d4f7:c88f swmike@uplift:~

Re: Public DNS64

2016-05-30 Thread Hugo Slabbert
On Mon 2016-May-30 11:45:11 +1000, Mark Andrews wrote: In message , 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