[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [public-dns-discuss] Digest for public-dns-discuss AT googlegroups.com - 9 updates in 8 topics



is this for me to use?

On Wed, 10 Oct 2018 at 21:26, <public-dns-discuss AT googlegroups.com> wrote:
public-dns-discuss AT googlegroups.com Google Groups
Topic digest
View all topics
site won't open using google public DNS
Alex Dupuy <alexdupuy AT google.com>: Oct 10 08:46AM -0700

You had a stale DS record, presumably from before your move to Cloudflare
hosted DNS (http://dnsviz.net/d/www.dulani.gov.sa/W5qHaw/dnssec/).
 
This has since been fixed
(http://dnsviz.net/d/www.dulani.gov.sa/W74eag/dnssec/).
Back to top
Website not resolving by google, but is by others
Alex Dupuy <alexdupuy AT google.com>: Oct 10 08:40AM -0700

Our resolvers (especially in Chile, Singapore, and Taiwan) are not getting
timely responses from your name servers, which appear to be hosted on
Linode VMs:
 
$ nsips mali-interest-hub.com
ns1.thehostelry.net 14399 A 178.79.134.103 ;
li190-103.members.linode.com [AS63949]
ns2.thehostelry.net 14399 A 139.162.185.132 ;
li1502-132.members.linode.com [AS63949]
ns3.thehostelry.net 14399 A 178.79.142.26 ; li198-26.members.linode.com
[AS63949]
ns4.thehostelry.net 14399 A 173.255.228.168 ;
li238-168.members.linode.com [AS63949]
 
Especially since these are all located on a single AS, routing issues could
be a single point of failure for your DNS. I strongly recommend that you
arrange for secondary DNS coverage from another DNS hosting service, there
are several free secondary DNS services, both Hurricane Electric and NS1
are quite good
see https://www.keycdn.com/blog/best-free-dns-hosting-providers.
Back to top
DNS Lookups fail on Google resolver, works on others.
Alex Dupuy <alexdupuy AT google.com>: Oct 10 08:33AM -0700

Your DNSSEC zone had bad NSEC3 records that proved the nonexistence of the
pay.epicwebstudios.com subdomain, as shown in the *Errors* section
of http://dnsviz.net/d/pay.epicwebstudios.com/W7WS8g/dnssec/
 
You have since fixed that
(http://dnsviz.net/d/pay.epicwebstudios.com/W7YYfw/dnssec/), so presumably
all is working now.
 
In the future, try using the dns.google.com query tool as it can provide
some limited diagnostic comments on reasons for resolution failure.
 
Also, be sure to check against other DNSSEC-validating public resolvers
like 9.9.9.9 and 1.1.1.1.
Back to top
edns esc blacklisted by google ?
Alex Dupuy <alexdupuy AT google.com>: Oct 10 08:15AM -0700

Your name servers (including the alternate addresses 92.223.100.101 and
92.223.100.201 that you omitted) appear to be returning /16 scope
prefix-length on all queries, which might not be optimal for IPv6 clients,
since the first 16 bits of an IPv6 address usually do not provide any
consistent geographical location (typically 32 or even 48 bits are needed
for accurate geo-location).
 
It can take a while for the auto-detection feature of Google Public DNS to
recognize ECS support from name servers that did not previously support it,
since we will only send ECS once every thousand queries when we detect no
support.
 
We are currently showing that a few more than 450 of our resolvers (in
virtually all of our data center locations, except in Finland) are still
sending only that minimal level of ECS to your anycast name server IPv4
addresses. While this is only a bit more than 5% of our resolvers, as the
first guideline points out, even just a few name servers that do not
support ECS will be responsible for the vast majority of cached data.
Recognizing support for ECS would be much faster if you had followed the
eighth guideline, and used new IP addresses for the name servers that
supported ECS.
 
For what it is worth, when I run the query you suggested in New York, I am
getting ECS scoped responses from Google Public DNS for your domain.
 
If your ECS support is not new, and this is not just a slow process of
recognizing support, I would say the most likely guideline that you are not
following is that you are not sending ECS for some domains that are
delegated to the name server addresses you have indicated.
 
Otherwise, some time will probably fix all the problems.
Back to top
Possibility to add extra NS, because of wrong registrar setup?
Alex Dupuy <alexdupuy AT google.com>: Oct 10 07:41AM -0700

ville wrote:
 
> But the real NS is: ns-cloud-c1.googledomains.com
> <http://ns-cloud-e1.googledomains.com/>
 
> Can we add ns-cloud-e1.googledomains.com to NS records?
 
Adding a name server that does not serve the zone to the NS records will
not help, for a number of reasons:
 
1. NS records in the DNS simply point to name servers that are supposed
to be able to answer queries for the zone. Changes to NS records only
affect which name servers may be asked, they do not have any affect on
whether the name servers will be able to answer.
2. Google Public DNS (unlike most other recursive resolvers) is
“parent-centric”—meaning that it only uses the name servers that are
returned in the referral responses from the parent (TLD) zone name servers,
and does not make NS queries to this child zone. So adding “lame” name
servers that can't answer queries to the NS record set in your zone won't
even affect which name servers Google Public DNS will query—only changes in
the TLD name server set affect Google Public DNS.
 
There are some things you *can* do:
 
1. Update the name servers for your domain listed at your registrar and
watch the responses from the TLD registry name servers to see when they
start serving the new referral response. When that happens, you can use the
flush/refresh features of Google Public DNS
<https://developers.google.com/speed/public-dns/cache>, OpenDNS/Umbrella
<https://support.opendns.com/hc/en-us/articles/227988627-How-to-clear-the-DNS-Cache->,
Verisign Public DNS
<https://www.verisign.com/en_US/security-services/public-dns/dns-cache/index.xhtml>,
and the Cloudflare DNS resolver <https://1.1.1.1/purge-cache/> to update
some (but not all) of the large public DNS resolvers.
2. Temporarily create a duplicate zone in Google Cloud DNS that is
served from the “incorrect” name server set. This may not be worth the
effort, since most recursive resolvers will keep trying other name servers
if they get a REFUSED answer from a name server that is not able to respond
to a query.
Back to top
Rate limit for DNS over HTTPS
Alex Dupuy <alexdupuy AT google.com>: Oct 10 07:22AM -0700

You can request an increased rate limit
at https://issuetracker.google.com/issues/new?component=191885&template=1024641.
 
Note that there are multiple internal limits besides the raw QPS, so that
even with an increased limit, some queries may be dropped, depending on
usage patterns.
Back to top
DNS type 'mx' lookup of iberdom.com responded with code SERVFAIL
marcpbodner AT gmail.com: Oct 10 05:16AM -0700

Alex,
 
I am getting the same error:
 
Delivery incomplete
There was a temporary problem delivering your message to
*omer AT bodnerflom.com*. Gmail will retry for 48 more hours. You'll be
notified if the delivery fails permanently.
The response was:
 
DNS Error: 4727646 DNS type 'mx' lookup of bodnerflom.com responded with
code SERVFAIL
 
 
I am able to send messages out but someone who uses Gmail is not able to
send me anything....What do I do??
 
Thanks for all your help!
 
Omer
 
 
 
 
 
On Tuesday, January 31, 2017 at 10:47:47 AM UTC-5, Ruben Garcia wrote:
Puneet Sood <puneets AT google.com>: Oct 10 05:52AM -0700

The zone has a lame delegation.
See http://dnsviz.net/d/bodnerflom.com/dnssec/.
 
On Wednesday, October 10, 2018 at 8:43:23 AM UTC-4, marcpbodner AT gmail.com
wrote:
Back to top
Option to flush cache for CAA RR Type
wasielewski AT iza.org: Oct 09 02:05AM -0700

The German Telekom uses the website https://digwebinterface.com/ to
verified CAA records, they only use the default resolver which is 8.8.4.4. Our
certificate requests are always NOT DNSSEC domains.
 
The tip with the TTL is really good, sometimes it's the simplest solutions
you do not come up with on your own. Thanks
 
 
On Friday, October 5, 2018 at 4:27:21 PM UTC+2, Alex Dupuy wrote:
Back to top
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to public-dns-discuss+unsubscribe AT googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "public-dns-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public-dns-discuss+unsubscribe AT googlegroups.com.
To post to this group, send email to public-dns-discuss AT googlegroups.com.
Visit this group at https://groups.google.com/group/public-dns-discuss.
To view this discussion on the web visit https://groups.google.com/d/msgid/public-dns-discuss/CAFo%3D6kBhYm%2BRYnQSozG8A41Aykt_Tdu1_c%2Bx6qPnpFj0nAZDew%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.