I own a domain, and clearly its DNS resolution is fine, everywhere seems to point to the right server : https://dnschecker.org/#A/e-bis.fr
I created a wildcard for subdomains, and it seems like it only points to the right server in some random places in the world, changes randomly every once in a while (as in sometimes a server will say it resolves, and one hour later it won't anymore) : https://dnschecker.org/#A/whatever.e-bis.fr
At first I thought it was a propagation issue, but it's been a week now so clearly it's me messing up the config at some point.
Here's the zone file used by bind9 for this domain :
# IN SOA ns3032550.ip-91-121-79.eu. postmaster.e-bis.fr. (
2014070501 ; Serial
8H ; Refresh
30M ; Retry
4W ; Expire
8H ; Minimum TTL
)
IN NS ns3032550.ip-91-121-79.eu.
IN NS ns.kimsufi.com.
e-bis.fr. IN A 91.121.79.161
*.e-bis.fr. IN A 91.121.79.161
ownercheck IN TXT "28834a04"
I do a service bind9 reload every time I update it, so the only thing I can see is the issue being in the zone file. I'm terrible with them, so it wouldn't surprise me if it was a beginner mistake.
Thanks in advance to anyone who can help,
Éric B.
Turns out I had just forgotten to update the serial (I think?).
For anyone running into the same problem, it was this line 2014070501 ; Serial which I had not updated. Incrementing it then restarting the service is enough.
Related
Lately i have seen high time to first byte for my sites.
Most of the time it is by javascript. A test at webpagetest.org usually shows like....
URL: http://example.com/
Loaded by: http://example.com/some-kind-of-javascript.js
When i remove that javascript then anothe javascript appears in that place.
What does loaded by exactly mean??
Check example test result....
https://www.webpagetest.org/result/190729_JY_cb028989b0f44671fba830c9eaca29d7/1/details/#waterfall_view_step1
I'm not sure why you think it's Javascript that is the problem? It looks to me like it's the initial HTML that is causing the problem.
Time to First byte for a resource is the time take from after sending the request (e.g. GET /) until it receives the first byte back. It excludes the DNS lookup, TCP connection and SSL handshake time, so really is a measure of the time take to start receiving that resource. Note that the "first byte" time at the top of the waterfall is the full end to end time, including DNS/TCP/SSL and any redirects, but the TTFB for each resource this is split out more.
I don't know how your home page is created - I would guess it's not a static page so whatever is generating this (PHP?) is taking too long. Whether this is due to bad backend code, an under-resourced server, a slow database, or something else is impossible to say from the outside. I would suggest getting in touch with your hosting provider and/or reviewing your code and server.
Say we have an A REC that points to IP x of our LB for one of our services. It has a TTL of 3600s. But... what it should have been was a C NAME that points to a A REC for a VIP. It's already in production and has about 10 services that calls the new A REC comprising of ~100 machines. If the A REC is deleted and a new C NAME is created with the same name and points to a new A REC, will the consumers notice this change? Is there a chance that the callers would time out?
I'd assume with the amount of machines some are bound to be impacted. If I set the TTL to 5 hours would there be a better chance of no one noticing?
So my question is, how do I swap an A REC for a C NAME without consumers of our service noticing?
Would it matter if the record is for use inside the network only vs available to the public?
I ask because we will need to load balance across data centers soon, and we have some records that are stuck pointing to an IP.
It would be nice to have an explanation of how the DNS system would behave in this scenario. Thanks.
Let's assume that you have a name foo.example.org that has nothing except an A record with the IPv4 address 192.0.2.1 and a 3600 second TTL. Anyone who looks up foo.example.org will get that A record, and remember it for an hour before they go and ask your name server for fresher information.
Then assume you change things so that foo.example.org has a CNAME record pointing at bar.example.net, which in turn has an A record holding the address 192.0.2.1. Anyone who looks up the name foo.example.org for the first time will get the CNAME, proceed to look up bar.example.net, and get the A record from there.
The only complication is that anyone who looked up foo.example.org during the 3600 seconds immediately before you change to the CNAME chain took effect will remember the direct lookup, and thus not see the new information until the TTL expires. So for up to an hour after you do the change, some people may still see the old information. So to keep the change transparent to users, make sure that the old information (the old IP address) still works for at least one full TTL period after you make a change.
This is not in any way special for changing from A to CNAME. No matter what you change, there will be a full TTL period during which clients can legitimately get the old info. That's just how DNS works.
On top of that, of course, there are clients and caching servers that don't pay as much attention to the TTL value as they should, but that's a whole different thing.
I am downloading the .COM zone file every day. It's a list of all .COM domains in the world with their primary nameserver.
Sample of the zone file:
DAYTONOHIOJOBS NS NS1.HOSTINGNET
DAYTONOHIOJOBS NS NS2.HOSTINGNET
DAYTONOHIOMAP NS NS1.HOSTINGNET
DAYTONOHIOMAP NS NS2.HOSTINGNET
DAYTONOHIONEWS NS NS1.HOSTINGNET
DAYTONOHIONEWS NS NS2.HOSTINGNET
To save in disk space, you can see .COM has been removed from the domain name (it's all .COM anyway).
The same goes for the nameserver (if it ends in .COM it has been removed).
This zone file is around 270,000,000 lines and about 9 GB.
My goal is to monitor a specific nameserver. Every day I want a list of all domains with that specific nameserver, but also a list of all new domains with that nameserver (new as in: yesterday this domain didn't have that nameserver yet).
I wrote a perl script to open and load "yesterdays" database and then open "todays" database and loop and compare. But this takes hours and lots of memory.
What would be the best way to do this?
Here is how I would do it, judging by what I know:
Have the script read the first file. For each line that corresponds to the nameserver of interest, add the entry to a hashmap.
Have the script read the second file. For each line that corresponds to the nameserver of interest, check if the entry is in the hashmap. If it isn't, it is new. If it is, it is unchanged - remove it from the hashmap.
At the end, all entries still left in the hashmap have been removed.
This does assume that the hashmap with this particular nameservers domains fits into memory, but on a reasonable machine and for a reasonable nameserver, this seems a reasonable assumption...
You may grep today and yestarday files for lines with the nameserver and compare the two results. (grep - command line unix tool)
You may keep compressed files (gzip) and use zgrep for initial grep.
I'm trying to code my own DNS server, I'm reading through RFC1035 on DNS but I have a few queries:
1) I want my server to respond with a CNAME for a particular request, but no A records - can I do this? for example, receive request for 'server1.com', response 'CNAME server2.com', and then the client queries another DNS server to get the A record for 'server2.com'.
I've currently set the header to: '\x84\x00' such to say this is the authoritive server, but recurse is not possible. Is this right?
2) I want my server to respond with no records for any other request, such that the client then queries a different DNS server for the records. I've currently set header to '\x83\x03' such to signal a NAME ERROR reply code. Is this right? Then what do I follow this with, zeros in all the other fields, or just end the packet there? I don't want to respond with 'this name doesn't exist', rather 'I don't know this name, try someone else' - how do I do this?
Many Thanks :)
Sounds about right - in fact, CNAME with A records is incorrect (RFC1034 section 3.6.2: "If a CNAME RR is present at a node, no other data should be present").
This would be very unusual behaviour from an authoritative nameserver - I'd suggest rethinking it or at least testing with some real-life resolvers to ensure they do what you want. RCODE #3 ("name error" or NXDOMAIN) is positive confirmation that the name doesn't exist. This would cause resolvers to terminate resolution and possibly cache the nonexistence of the name, which doesn't sound like what you're after. If you want the resolver to query one of the other nameservers that was delegated to for that zone, I guess SERVFAIL (RCODE #2) is the most appropriate/likely to have the desired effect.
By the way, for debugging the exact format of your DNS packets I can highly recommend Wireshark for its decoding accuracy compared with pasting hex codes into Stack Overflow ;)
In the CNAME case, your (authoritative) server should just return the CNAME in the answer section unless it is also authoritative for the domain that the CNAME points to, in which case it should also include the result of following the CNAME.
For your second case you should return RCODE 5 ("REFUSED") - this is the preferred error that an authoritative server should give when asked a question for a domain for which it is not configured.
Following that, you still need to send the four 16-bit count fields and a copy of the question from the original request. In this case the four counts would be (1, 0, 0, 0) - one question, no answer, no ns records, no additional records.
In my rails app i do a nslookup using a ruby library resolv. If the site like dgdfgdfgdfg.com is entered its talking too long to resolve. in some instance like 20 sec.(mostly for non-existent sites) Because it cause the application to slowdown.
So i though of introducing a timeout period for the dns lookup.
What will be the ideal timeout period for the dns lookup so that resolution of actual site doesnt fail. will something like 10 sec will be fine?
There's no IETF mandated value, although §6.1.3.3 of RFC 1123 suggests a value not less than 5 seconds.
Perl's Net::DNS and the command line dig utility do default to 5 seconds between retries. Some versions of the Microsoft resolver appear to default to 3 seconds.
You can run some tests among the users to find out the right number compromising responsiveness / performance.
Also you can adjust that timeout dinamically depending on the network traffic.
For example, for every sucessful resolv, you save how much time it took you to resolv it. And every hour (for example) you can calculate an average and set double of its value as timeout (Remember that "average" is, roughly speaking, "the middle"). This way if your latency is high at some point, it autoadjust itself to increase the timeout period.