• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

Hey maybe there is a problem in updating your dns chache?

Started by remohurri, September 23, 2009, 03:04:58 AM

Previous topic - Next topic

remohurri

hello,
I've resetted many time the mail test .... and retried...
any time I have obtained "NO MX found using your domain to try.Failed to get AAAA from MX".... but
from my dns I can obtain:
dig remo6test.t-bizcom.com AAAA

; <<>> DiG 9.3.2 <<>> remo6test.t-bizcom.com AAAA
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14761
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;remo6test.t-bizcom.com.                IN      AAAA

;; ANSWER SECTION:
remo6test.t-bizcom.com. 172800  IN      AAAA    2001:5c0:1400:b::3c57

;; AUTHORITY SECTION:
t-bizcom.com.           172800  IN      NS      dns2.t-bizcom.com.
t-bizcom.com.           172800  IN      NS      dns.t-bizcom.com.
t-bizcom.com.           172800  IN      NS      ns2.t-bizcom.com.

;; ADDITIONAL SECTION:
dns.t-bizcom.com.       172800  IN      A       80.105.154.99
ns2.t-bizcom.com.       172800  IN      A       151.38.159.14
dns2.t-bizcom.com.      172800  IN      A       88.149.190.155

;; Query time: 1 msec
;; SERVER: 151.38.159.14#53(151.38.159.14)
;; WHEN: Wed Sep 23 11:56:28 2009
;; MSG SIZE  rcvd: 171

You may say that i'ts a fault by my DNS but....
Eve if I try an external dns (like the opends one) I can see:
dig @208.67.222.222 remo6test.t-bizcom.com AAAA

; <<>> DiG 9.3.2 <<>> @208.67.222.222 remo6test.t-bizcom.com AAAA
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61695
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;remo6test.t-bizcom.com.                IN      AAAA

;; ANSWER SECTION:
remo6test.t-bizcom.com. 172800  IN      AAAA    2001:5c0:1400:b::3c57

;; Query time: 398 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Wed Sep 23 11:59:34 2009
;; MSG SIZE  rcvd: 68
and.....
the SOA is ns2.t-bizcom.com....
So when I look from my dns from (ns2.t-bizcom.com) I'm looking exactly from the authoritative DNS.


So please can you explain me what you mean with "NO MX found using your domain to try.Failed to get AAAA from MX"

And yes... I've waited an entire day after I Ive updated the dns with the new AAAA records used for testing... (to avoid the problem of dns cache updating) lieaving so much time.....

Any suggestion?

Thanks

kcochran

A day would have helped expire the cache if your TTL was 86400.  Looks like you've got it set to 2 days based on your pasted dig outputs.  The cache is showing it had 68778 seconds left to expire before I flushed it.  Also

$ dig remo6test.t-bizcom.com mx @dns.t-bizcom.com

; <<>> DiG 9.6.0-APPLE-P2 <<>> remo6test.t-bizcom.com mx @dns.t-bizcom.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40445
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;remo6test.t-bizcom.com. IN MX

;; AUTHORITY SECTION:
t-bizcom.com. 86400 IN SOA ns2.t-bizcom.com. root.ns2.t-bizcom.com. 2008112016 10800 3600 604800 86400

;; Query time: 266 msec
;; SERVER: 80.105.154.99#53(80.105.154.99)
;; WHEN: Wed Sep 23 08:30:22 2009
;; MSG SIZE  rcvd: 85


Looks like the nameservers for t-bizcom.com are out of sync since ns2 has a 2009 serial.

Remember folks, TTLs cover how long your record sticks in the cache.  Don't set them long when you're testing things!

remohurri

you queried dns.t-bizcom.com but.... SOA record say.....
;; ANSWER SECTION:
t-bizcom.com.           172800  IN      SOA     ns2.t-bizcom.com. root.ns2.t-bizcom.com. 2009092310 10800 3600 604800 86400
so eventually it's dns.t-bizcom.com that's out of sync not ns2!
.....
and yes this have a long  time 86400 because it's not a "test" server.

The only thing that is in some sense wrong is that dns.t-bizcom.com it's out of sync....
Unfortunately you have queried dns instead of ns2
And (sincerly) for some reason I have not noted before your message that dns was out of sync.

So you are only in part right... and... I am only in part wrong...

anyway i wiil ask to the admin of the other site a verify of the update (dns is on a different network and different office/location but as far as I know it's a slave... so in teory it must fetch automatically from ns2... but for some reason this was not true this time) .

Bye... for now...  and thanks for your advice.



kcochran

The textual information in the SOA is primarily useful for a human.  When a query is made, it goes to the rots, they throw back the list of NS records which are designated as authoritative for the zone, and then one of those is queried.  Only then does it get an SOA record, and it will not query the defined "source ns" in that record trying to find a record it couldn't find in the initial query.  All the designated primaries need to return the same data for consistent results.

remohurri

Human you said?
It's the first time in my life that I hear that an MTA is a human  :)
In general you may see that mainly *applications* not humans are driving the queries... but this is another story.
I've just said (in the previus post, please read it) that **before** your advice I was unaware of the misalignent af the second DNS (normally acting as slave and automatically updating).
For some reason the second DNS have lost it's original configuration as slave... and produced the results that we have said in the previus post.
That's all.
I've already said thank you for your advice... in the previuos post.... so.. thank you again... but the issue seem clear and resolved.

kcochran

An MTA will normally query for MX, and failing that, then the A or AAAA for the original hostname directly.  No application will normally directly query for an SOA.  The SOA is effectively a meta-record ("Most of these fields are pertinent only for name server maintenance operations." in the RFC), containing data applicable to the authoritative nameservers, and to a more limited degree, external ones.

Glad to hear that everything's synced up now and working!