Re: [dns-operations] Google DNS Admin

Here is a RIPE Atlas measurement towards that IP https://atlas.ripe.net/measurements/23785597/#!tracemon -- 10 out of 50 probes could not traceroute to that IP, but there didn't seem to be an obvious single point that they all stopped at (BT and Cogent and Liberty and ASK4 and Comcast) - this is a

Re: [dns-operations] [Ext] Re: help with a resolution

On Wed, Jan 08, 2020 at 07:12:09PM -0500, Warren Kumari wrote: > > Or more simply, when Let's Encrypt, or some cloud provider asks you to > > publish a TXT RR in your zone to prove zone control, how sure are you > > that's not a hash collision in disguise? > > It **could** be, but I'm still

Re: [dns-operations] Google DNS Admin

daniel> Thank you for this. Is there any chance at all I can get you to daniel> do a traceroute to daniel> 185.203.205.10 and 2a0c:d2c4::53:5:7335 daniel> And if you have access to a bgp speaking peer, show ip bgp daniel> 185.203.204.0/22 and show bgp ipv6 unicast 2a0c:d2c4::/32 (or daniel>

Re: [dns-operations] [Ext] Re: help with a resolution

On Jan 8, 2020, at 3:36 PM, Viktor Dukhovni wrote: > > Or more simply, when Let's Encrypt, or some cloud provider asks you to > publish a TXT RR in your zone to prove zone control, how sure are you > that's not a hash collision in disguise? > OK, that's an excellent example of a common

Re: [dns-operations] help with a resolution

On Wed, Jan 08, 2020 at 08:07:22PM +, Paul Vixie wrote: > On Wednesday, 8 January 2020 18:45:44 UTC Viktor Dukhovni wrote: > > > > Loop's toolchain has had the default algorithms so, which it inherited. > > > There is a branch that changes the defaults, but it won't be merged in > > > the

Re: [dns-operations] [Ext] Re: help with a resolution

On Wed, Jan 08, 2020 at 06:00:06PM -0500, Viktor Dukhovni wrote: > Well, there are various services where indeed the zone administrator signs > records from authenticated, but otherwise untrusted customers, provided > the RR owner is associated with the customer. > > For example, the .DE zone

Re: [dns-operations] [Ext] Re: help with a resolution

On Wed, Jan 8, 2020 at 6:47 PM Viktor Dukhovni wrote: > > On Wed, Jan 08, 2020 at 06:00:06PM -0500, Viktor Dukhovni wrote: > > > Well, there are various services where indeed the zone administrator signs > > records from authenticated, but otherwise untrusted customers, provided > > the RR owner

Re: [dns-operations] Google DNS Admin

Thank you for this. Is there any chance at all I can get you to do a traceroute to 185.203.205.10 and 2a0c:d2c4::53:5:7335 And if you have access to a bgp speaking peer, show ip bgp 185.203.204.0/22 and show bgp ipv6 unicast 2a0c:d2c4::/32 (or whatever the equivalent commands are for your NOS).

Re: [dns-operations] help with a resolution

On Wed, Jan 08, 2020 at 01:45:44PM -0500, Viktor Dukhovni wrote: > On Wed, Jan 08, 2020 at 11:34:00PM +0530, Mukund Sivaraman wrote: > > > > > [muks@jurassic ~/tmp-dnssec]$ dnssec-dsfromkey Kexample.org.+005+04222 > > > > example.org. IN DS 4222 5 1 7B83C10E0220CA65139DFFE14F3F24B8D8ACAEA2 > > >

Re: [dns-operations] [Ext] Re: Surprising behaviour by certain authoritative name servers

On 1/8/20, 7:40 AM, "dns-operations on behalf of Niall O'Reilly" wrote: On 7 Jan 2020, at 12:53, Greg Choules wrote: > I don't think it's a protocol violation, I think that's arguable. RFC1035, section 6.1.3: Both the TTL data for RRs and the timing data for

[dns-operations] Google DNS Admin

Is there anyone from google on this list? Every well-known recursor is returning valid results for as57335.net except for 8.8.8.8 and 8.8.4.4 and I'd like some assistance getting down to the root of the issue. ___ dns-operations mailing list

Re: [dns-operations] help with a resolution

On Wed, Jan 08, 2020 at 07:05:04PM +0800, William C wrote a message of 15 lines which said: > 1. how to check if a zone has a valid DNSSEC key? If you are not a DNSSEC expert, DNSviz is a handy tool > 2. how to validate if the zone has been signed with correct key?

Re: [dns-operations] Surprising behaviour by certain authoritative name servers

On Wed, Jan 08, 2020 at 08:15:50PM +0530, Mukund Sivaraman wrote: > On Tue, Jan 07, 2020 at 12:20:01PM +, Niall O'Reilly wrote: > > What's surprising is that an authoritative name server > > shows both a decremented TTL value (as if it were answering > > from cache) and the AA flag. > > These

Re: [dns-operations] Google DNS Admin

Daniel Corbe wrote: > > Every well-known recursor is returning valid results for as57335.net > except for 8.8.8.8 and 8.8.4.4 and I'd like some assistance getting > down to the root of the issue. Maybe connectivity problems? I can't get to any of the nameservers from 131.111.0.0/16 or

Re: [dns-operations] [Ext] Surprising behaviour by certain authoritative name servers

Thanks, Ed. On 8 Jan 2020, at 13:51, Edward Lewis wrote: > I'd agree that it **is not** a protocol violation based on this line of > reasoning: > > Imagine the zone being re-loaded often (more than once a second) with the > effect that every second or wall clock results in the(/a/each) set's

Re: [dns-operations] help with a resolution

Thanks all for explains. I am new to DNSSEC, so I have questions: 1. how to check if a zone has a valid DNSSEC key? 2. how to validate if the zone has been signed with correct key? Regards. on 2020/1/8 19:00, Stephane Bortzmeyer wrote: As explained by several experts, this domain is

Re: [dns-operations] Google DNS Admin

Am 08.01.2020 um 09:27 schrieb Daniel Corbe: Is there anyone from google on this list? You could also try here: https://groups.google.com/forum/#!forum/public-dns-discuss Winfried ___

Re: [dns-operations] Google DNS Admin

Hi, Any chance that you could provide the output of dig commands showing what the "bad" responses look like from Google recursive resolvers, and what the "good" responses look like from other resolvers, so we can examine the difference? Thanks, Hazel On Wed, 8 Jan 2020, 14:02 Daniel Corbe,

Re: [dns-operations] Google DNS Admin

8.8.8.8 is returning SERVFAIL from my location. ]$ host ns.as57335.net 8.8.8.8 Using domain server: Name: 8.8.8.8 Address: 8.8.8.8#53 Aliases: Host ns.as57335.net not found: 2(SERVFAIL) $ dig @8.8.8.8 ns.as57335.net ; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> @8.8.8.8 ns.as57335.net ; (1 server

Re: [dns-operations] Surprising behaviour by certain authoritative name servers

On Tue, Jan 07, 2020 at 12:20:01PM +, Niall O'Reilly wrote: > What's surprising is that an authoritative name server > shows both a decremented TTL value (as if it were answering > from cache) and the AA flag. These days, another kind of authoritative nameservice seems to have arrived - the

Re: [dns-operations] Google DNS Admin

--- Begin Message --- On Wed, 2020-01-08 at 03:27 -0500, Daniel Corbe wrote: > Is there anyone from google on this list? > > Every well-known recursor is returning valid results for as57335.net > except for 8.8.8.8 and 8.8.4.4 and I'd like some assistance getting > down to the root of the issue.

Re: [dns-operations] help with a resolution

On Wed, Jan 08, 2020 at 07:05:04PM +0800, William C wrote: > Thanks all for explains. > I am new to DNSSEC, so I have questions: > > 1. how to check if a zone has a valid DNSSEC key? The hash in the DS record in the parent zone should correspond to the DNSKEY at the apex of your (child) zone.

Re: [dns-operations] help with a resolution

On Wed, Jan 08, 2020 at 08:11:56PM +0530, Mukund Sivaraman wrote: > [muks@jurassic ~/tmp-dnssec]$ dnssec-keygen -f KSK example.org > Generating key pair..+ .+ > Kexample.org.+005+04222 > > [muks@jurassic ~/tmp-dnssec]$ dnssec-dsfromkey Kexample.org.+005+04222

Re: [dns-operations] Google DNS Admin

On Wed, Jan 08, 2020 at 02:57:17PM +, Tony Finch wrote: > Daniel Corbe wrote: > > > > Every well-known recursor is returning valid results for as57335.net > > except for 8.8.8.8 and 8.8.4.4 and I'd like some assistance getting > > down to the root of the issue. > > Maybe connectivity

Re: [dns-operations] Google DNS Admin

--- Begin Message --- [Google Public DNS engineer here] As others have mentioned this appears to be a connectivity or load problem. We are getting successful resolution in about 50% of metros globally and timeouts in the rest of the metros. The locations are consistent across 3 attempts. FWIW we

Re: [dns-operations] help with a resolution

Hi Viktor On Wed, Jan 08, 2020 at 10:05:53AM -0500, Viktor Dukhovni wrote: > On Wed, Jan 08, 2020 at 08:11:56PM +0530, Mukund Sivaraman wrote: > > > [muks@jurassic ~/tmp-dnssec]$ dnssec-keygen -f KSK example.org > > Generating key pair..+ .+ > >

Re: [dns-operations] help with a resolution

On Wed, Jan 08, 2020 at 11:34:00PM +0530, Mukund Sivaraman wrote: > > > [muks@jurassic ~/tmp-dnssec]$ dnssec-dsfromkey Kexample.org.+005+04222 > > > example.org. IN DS 4222 5 1 7B83C10E0220CA65139DFFE14F3F24B8D8ACAEA2 > > > example.org. IN DS 4222 5 2 > > >

Re: [dns-operations] help with a resolution

On Wednesday, 8 January 2020 18:45:44 UTC Viktor Dukhovni wrote: > > Loop's toolchain has had the default algorithms so, which it inherited. > > There is a branch that changes the defaults, but it won't be merged in > > the first quarter of this year. > > If there is a default, it should

Re: [dns-operations] help with a resolution

On Wed, Jan 8, 2020 at 1:54 PM Viktor Dukhovni wrote: > > On Wed, Jan 08, 2020 at 11:34:00PM +0530, Mukund Sivaraman wrote: > > > > > [muks@jurassic ~/tmp-dnssec]$ dnssec-dsfromkey Kexample.org.+005+04222 > > > > example.org. IN DS 4222 5 1 7B83C10E0220CA65139DFFE14F3F24B8D8ACAEA2 > > > >

Re: [dns-operations] Google DNS Admin

In article you write: >-=-=-=-=-=- > >On Wed, 2020-01-08 at 03:27 -0500, Daniel Corbe wrote: >> Is there anyone from google on this list? >> >> Every well-known recursor is returning valid results for as57335.net >> except for 8.8.8.8 and 8.8.4.4 and I'd like some assistance getting >> down to

Re: [dns-operations] help with a resolution

On Wed, Jan 08, 2020 at 02:53:42PM -0500, Warren Kumari wrote: > Can someone please explain to me in baby words how the SHA-1 issue affects > DNSSEC? [...] but SHA-1 is still 2nd-preimage resistant - given the hash > a94a8fe5ccb19ba61c4c0873d391e987982fbbd3, it is infeasible to find another >

Re: [dns-operations] [Ext] Re: help with a resolution

I'm with Warren: I don't see how the chosen-prefix collision affects DNSSEC. On Jan 8, 2020, at 12:18 PM, Viktor Dukhovni wrote: > > On Wed, Jan 08, 2020 at 02:53:42PM -0500, Warren Kumari wrote: > >> Can someone please explain to me in baby words how the SHA-1 issue affects >> DNSSEC? [...]

Re: [dns-operations] [Ext] Re: help with a resolution

On Wed, Jan 08, 2020 at 09:00:26PM +, Paul Hoffman wrote: > I'm with Warren: I don't see how the chosen-prefix collision affects DNSSEC. And yet it does, because signatures over a benign RRset A, may also be valid signatures for a malicious RRset B, where A and B don't share the same (owner,

Re: [dns-operations] [Ext] Re: help with a resolution

On Jan 8, 2020, at 2:10 PM, Viktor Dukhovni wrote: > If I can get you to sign A, you may > be inadvertently also signing B. This is the crux of your argument, and the crux of every attack that leverages hash collisions. If "I" can get "you" to sign something without adding any randomness to

Re: [dns-operations] [Ext] Re: help with a resolution

On Wed, Jan 08, 2020 at 10:45:54PM +, Paul Hoffman wrote: > However, in DNSSEC, what is the scenario where "I" can get "you" to sign an > RRset? Aren't RRsets all signed by their owner, the creator of the RRset? If > I'm a signer and I'm willing to sign something that I didn't create, I >

Re: [dns-operations] Surprising behaviour by certain authoritative name servers

On 7 Jan 2020, at 12:53, Greg Choules wrote: > I don't think it's a protocol violation, I think that's arguable. RFC1035, section 6.1.3: Both the TTL data for RRs and the timing data for refreshing activities depends on 32 bit timers in units of seconds. Inside the database, refresh

Re: [dns-operations] help with a resolution

On Wed, Jan 08, 2020 at 08:56:41AM +0800, William C wrote a message of 59 lines which said: > Can you help check why public nameservers (all 8.8.8.8, 1.1.1.1, 9.9.9.9 > etc) can't resolve this domain? As explained by several experts, this domain is DNSSEC-broken. This has nothing to to with