=A0=A0=A0The "86397" in the ANSWER SECTION is the TTL, and shows that I've
got a few seconds short of 24 hours left for this entry in the cache.
This value will count down to zero, at which point the cache expires
and a new authoritative entry (hopefully the right one) will be
retrieved.
=A0=A0=A0The other thing is to use "@servername" in your dig query, which
will explicitly bypass the locally configured resolvers, and query the
named DNS server.
hrm@ruthven:~ $ dig @ns1.bb-online.net. oxfordflutes.co.uk
[...]
=A0=A0=A0In this case, I'm querying one of the definitive servers for
oxfordflutes.net, and so should get the results that I've asked them
to publish. You can check whether the DNS servers under your control
(usually the primary and one or more secondaries) are sending the
right answers. If they are, then you should simply have to wait until
the TTL in the previous query reaches zero. If not, then you have some
kind of misconfiguration of your servers.
=A0=A0=A0Oh, and you should be able to get the definitive list of
nameservers by issuing an NS query:
hrm@ruthven:~ $ dig NS oxfordflutes.co.uk
; <<>> DiG 9.7.3 <<>> NS oxfordflutes.co.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43912
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;oxfordflutes.co.uk.=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 IN=A0=A0=A0 =A0=A0=A0 NS
;; ANSWER SECTION:
oxfordflutes.co.uk.=A0=A0=A0 =A0=A0=A0 86400=A0=A0=A0 IN=A0=A0=A0 =A0=A0=A0=
NS=A0=A0=A0 =A0=A0=A0 brain.bb-online.co.uk.
oxfordflutes.co.uk.=A0=A0=A0 =A0=A0=A0 86400=A0=A0=A0 IN=A0=A0=A0 =A0=A0=A0=
NS=A0=A0=A0 =A0=A0=A0 ns1.bb-online.net.
oxfordflutes.co.uk.=A0=A0=A0 =A0=A0=A0 86400=A0=A0=A0 IN=A0=A0=A0 =A0=A0=A0=
NS=A0=A0=A0 =A0=A0=A0 ns2.bb-online.net.
;; Query time: 48 msec
;; SERVER: 10.0.0.10#53(10.0.0.10)
;; WHEN: Tue Feb=A0 7 21:54:55 2012
;; MSG SIZE=A0 rcvd: 115
=A0=A0=A0So here my definitive nameservers are brain, ns1 and
ns2.bb-online.net.=A0 Check the data returned by all of the servers
(with the @server syntax above) for the NS query, just to see if one
is out of sync with the others.
=A0=A0=A0Hugo.
--=20
=3D=3D=3D Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk=
=3D=3D=3D
=A0 PGP key: 515C238D from wwwkeys.eu.pgp.net or
http://www.carfax.org.uk
=A0 =A0 =A0 =A0 =A0 =A0 --- UNIX:=A0 Japanese brand of food containers. ---=
=A0 =A0 =A0 =A0 =A0 =A0=20
---453615747-1753851572-1328812433=:87945
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;"><br><br>Thanks to all who replied. I de=
cided to wait out the 48hrs left on the local nameserver (Hugo's tip) and t=
hen the problem sorted itself. :)<br><br>Valuable tips might like these oug=
ht to be compiled into a sysadmin pocketbook: 'wisdom from bitfolk'.<br><br=
>Cheers!<br><br><br><br>--- On <b>Tue, 2/7/12, Hugo Mills <i><hugo-bf@ca=
rfax.org.uk></i></b> wrote:<br><blockquote style=3D"border-left: 2px sol=
id rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Hugo M=
ills <hugo-bf@???><br>Subject: Re: [bitfolk] Renumbering: r=
esolver not working? still points to 212.x, instead of 85.y on >=3D1 mac=
hine<br>To: "Max B" <txtmax@???><br>Cc: users@???<=
br>Received: Tuesday, February 7, 2012, 9:59 PM<br><br><div class=3D"plainM=
ail">On Tue, Feb 07, 2012 at 12:56:19PM -0800, Max B wrote:<br><br>> tha=
nks for
everyone's response to my wiki proposal. I hadn't<br>> intended a=
flame war, and may respond selectively at a future date,<br>> when for =
instance, I am not faced with a puzzle, as follows.<br><br>> dig returns=
the correct value 85.y on my VPS.<br>> <br>> dig returns the old add=
ress 212.x elsewhere (at work).<br><br> Two things you can=
look at: dig tells you the TTL remaining on any<br>entry when you query it=
. For example: <br><br>hrm@ruthven:~ $ dig oxfordflutes.co.uk<br><br>; <=
<>> DiG 9.7.3 <<>> oxfordflutes.co.uk<br>;; global opt=
ions: +cmd<br>;; Got answer:<br>;; ->>HEADER<<- opcode: QUERY, =
status: NOERROR, id: 52296<br>;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTH=
ORITY: 0, ADDITIONAL: 0<br><br>;; QUESTION SECTION:<br>;oxfordflutes.co.uk.=
IN &nbs=
p; A<br><br>;; ANSWER
SECTION:<br>oxfordflutes.co.uk. 86397=
IN A &nb=
sp; 85.119.82.48<br><br>;; Query time: 0 msec<br>;; SERV=
ER: 10.0.0.10#53(10.0.0.10)<br>;; WHEN: Tue Feb 7 21:50:55 2012<br>;;=
MSG SIZE rcvd: 52<br><br> The "86397" in the ANSWER=
SECTION is the TTL, and shows that I've<br>got a few seconds short of 24 h=
ours left for this entry in the cache.<br>This value will count down to zer=
o, at which point the cache expires<br>and a new authoritative entry (hopef=
ully the right one) will be<br>retrieved.<br><br> The othe=
r thing is to use "@servername" in your dig query, which<br>will explicitly=
bypass the locally configured resolvers, and query the<br>named DNS server=
.<br><br>hrm@ruthven:~ $ dig @ns1.bb-online.net. oxfordflutes.co.uk<br>[...=
]<br><br> In this case, I'm querying one of the
definitive servers for<br>oxfordflutes.net, and so should get the results =
that I've asked them<br>to publish. You can check whether the DNS servers u=
nder your control<br>(usually the primary and one or more secondaries) are =
sending the<br>right answers. If they are, then you should simply have to w=
ait until<br>the TTL in the previous query reaches zero. If not, then you h=
ave some<br>
