1

I am creating a DNS A Record via the Google Cloud API, ending up with:

  • DNS Name: some-subdomain.mysite.io
  • Type: A
  • TTL: 1
  • IP: 35.XXX.XXX.XX

After the entry is confirmed as created and viewable in the API, I am trying to resolve it using nslookup, but I get:

$ nslookup some-subdomain.mysite.io
 Server:        192.168.178.1
 Address:   192.168.178.1#53

** server can't find some-subdomain.mysite.io: NXDOMAIN

It stays like this for a few minutes, until it eventually resolves.

Because the first lookup is after it's been created, I'd expect it not to miss (And therefore have no miss to cache). Is there anything I can do to make the lookup succeed sooner?

mogronalol
  • 121
  • 1
  • 5
  • i don't know about google but the DNS server you are querying need to refresh its cache and there might be multiple dns servers on the road to the final one – olivierg Aug 01 '17 at 20:08
  • In this case, should there be anything cached? It's the first time the domain is queried. – mogronalol Aug 01 '17 at 20:25
  • DNS updates are never instant. Things have to replicate. There is nothing you can do to fix this. – Appleoddity Aug 02 '17 at 01:48
  • 1
    I thought the first time the domain is looked up, it will recursively go through the name servers until it finds the authoritative name server, at which point it should contain the record? And that the only time it wouldn't do that is if it's a cached miss. – mogronalol Aug 02 '17 at 07:46

3 Answers3

3

If you do the query just before creating the record you pollute the cache with a NXDOMAIN return code for the record for a delay called the negative TTL which is specified in the SOA record (last item).

Also, you should not use nslookup for DNS diagnostics, but dig and you should always specify the nameserver your query, to make sure to separate results coming from the authoritative nameservers with those being cached somewhere in a recursive nameserver.

Patrick Mevzek
  • 9,273
  • 7
  • 29
  • 42
1

You create A Record via the Google Cloud API and start to resolve it. But you don't know how often Google update it's DNS configuration, may be it take few minutes to update zone configuration, that's why it not resolving for few minutes.

If you want know more about DNS work, you could read this article or check this comics, for example.

Alexander Tolkachev
  • 4,513
  • 3
  • 14
  • 23
1

The solution we came up with was to use a wildcard DNS entry. So now I have an entry:

*.mysite.io -> 10.XX.XX.XX

This means any sub domain we create is resolvable immediately as the DNS already exists. We then route internally based on the host header.

mogronalol
  • 121
  • 1
  • 5
  • Hey, my head is exploding with all this. You wrote that wildcard dns entry solved your usecase. And you said "This means any sub domain we create is resolvable immediately and then we route internally based on host header". Can you elaborate on that internal routing part? How are you doing it? – Srikanth Sep 04 '18 at 18:47
  • 1
    @Srikanth Don't bother the whole sentence is wrong. Using a wildcard does not change anything regarding how TTL works. If you query for `foobar.example.com` and the record does not exist you "pollute" your DNS cache with an entry for it that will be kept up to the "negative TTL" amount. If you create a record for `foobar.example.com` or for `*.example.com` that won't change anything in the fact that you already have the answer for `foobar.example.com` in your cache, and it will be used. Also, separately, wildcards should be used with precaution. – Patrick Mevzek May 22 '20 at 18:47