[dns-operations] Problem: can't lookup a record

[Mark Andrews]

There is a broken/misconfigured load balancer at lp.herold.at.  It
is returning answers from the *wrong* zone.  It's different to see
a complaint like this for something other than AAAA records.  The
operators of the zone need to fix/replace/upgrade their nameservers.

herold.at should contact their load balancer vendor for correct
instructions on how to configure the load balancer when the address
being load balanced is at the top (apex) of the zone.  Often the
instructions assume that the name being load balanced is one level
deeper which isn't the case.

The load balancer should be configured with both the zone and the
host as mx.herold.at, not herold.at and mx.herold.at.

	good: zone mx.herold.at, host mx.herold.at
	bad:  zone herold.at, host mx.herold.at

Mark

mx.herold.at.		300	IN	NS	lp.herold.at.
;; Received 79 bytes from 80.240.225.50#53(dns3.telekom.at) in 552 ms

herold.at.		300	IN	SOA	lp.herold.at. operating.herold.at. 2011062101 3600 3600 3600 3600
;; Received 79 bytes from 194.146.184.132#53(lp.herold.at) in 395 ms


In message <201107250030.27153 at zmi.at>, Michael Monnerie writes:
> --===============1266670159703048203==
> Content-Type: multipart/signed; boundary="nextPart4860359.NRmvcb7r7W";
> 	protocol="application/pgp-signature"; micalg=pgp-sha1
> Content-Transfer-Encoding: 7bit
> 
> --nextPart4860359.NRmvcb7r7W
> Content-Type: multipart/mixed;
>   boundary="Boundary-01=_6zJLOx73hVYN2Nt"
> Content-Transfer-Encoding: 7bit
> 
> 
> --Boundary-01=_6zJLOx73hVYN2Nt
> Content-Type: text/plain;
>   charset="utf-8"
> Content-Transfer-Encoding: quoted-printable
> Content-Disposition: inline
> 
> Dear list,
> 
> I hope it's OK to ask on this list, maybe I should have written to the=20
> bind-users list, I don't know. I hope you forgive me if my question is=20
> misplaced here.
> 
> We have one strange system from which we always get SERVFAIL, while it=20
> seems the system returns NOERROR. Please see attached wireshark. I did=20
> the query from 127.0.0.1, which is 81.217.116.33 (gw.zmi.at) too, and=20
> that asks the responsible DNS servers. But in the end, the local DNS=20
> returns SERVFAIL, and I have no idea what the problem could be.
> 
> I tried that query from several other Linux versions, all fail:
> 
> gw.zmi.at: dig txt mx.herold.at
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 53625
> 
> kw.tuwien.ac.at: dig txt mx.herold.at
> ; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17602
> 
> www.viennapaint.com: dig txt mx.herold.at
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 48218
> 
> dns1.zmi.at: dig txt mx.herold.at
> ; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38301
> 
> dns2.zmi.at: dig txt mx.herold.at
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55570
> 
> gw.frimeco.com: dig txt mx.herold.at
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61182
> 
> But when on my local system I do this instead:
> 
> # dig TXT mx.herold.at @dns1.telekom.at
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4703
> ;; AUTHORITY SECTION:
> mx.herold.at.           300     IN      NS      lp.herold.at.
> 
> Then I do
> # dig TXT mx.herold.at @lp.herold.at
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46660
> ;; AUTHORITY SECTION:
> herold.at.              300     IN      SOA     lp.herold.at.=20
> operating.herold.at. 2011062101 3600 3600 3600 3600
> 
> So why does the simple "dig TXT mx.herold.at" fail? There must be=20
> something special about the answer.
> 
> =2D-=20
> mit freundlichen Gr=C3=BCssen,
> Michael Monnerie, Ing. BSc
> 
> it-management Internet Services: Prot=C3=A9ger
> http://proteger.at [gesprochen: Prot-e-schee]
> Tel: +43 660 / 415 6531
> 
> // Haus zu verkaufen: http://zmi.at/langegg/
> 
> --Boundary-01=_6zJLOx73hVYN2Nt
> Content-Type: application/octet-stream;
>   name="dns-problem.pcap"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment;
> 	filename="dns-problem.pcap"
> 
> 1MOyoQIABAAAAAAAAAAAAP//AABxAAAAnJgsTmdbAABKAAAASgAAAAAAAwQABgAAAAAAAAAACABF
> AAA62IsAAEARpCV/AAABfwAAAWqAADUAJv45niABAAABAAAAAAAAAm14Bmhlcm9sZAJhdAAAEAAB
> nJgsTs9qAABVAAAAVQAAAAAEAAEABgAIVFC+PwAACABFAABF9lYAAEARTUBR2WohwpK4hP35ADUA
> MTdUEX0AAAABAAAAAAABAm14Bmhlcm9sZAJhdAAAEAABAAApEAAAAIAAAACcmCxOXIcAAIYAAACG
> AAAAAAAAAQAGABLZVNYbAAAIAEUAAHaLFwAANxHBTsKSuIRR2WohADX9+QBinW0RfYSAAAEAAAAB
> AAECbXgGaGVyb2xkAmF0AAAQAAHADwAGAAEAAAEsACUCbHDADwlvcGVyYXRpbmfAD3feX1UAAA4Q
> AAAOEAAADhAAAA4QAAApEAAAAIAAAACcmCxOW4kAAFUAAABVAAAAAAQAAQAGAAhUUL4/AAAIAEUA
> AEWUEAAAQBGuhlHZaiHCkrmEx3EANQAxOFSIjwAAAAEAAAAAAAECbXgGaGVyb2xkAmF0AAAQAAEA
> ACkQAAAAgAAAAJyYLE7GqgAAhgAAAIYAAAAAAAABAAYAEtlU1hsAAAgARQAAdosYAAA6Eb1NwpK5
> hFHZaiEANcdxAGJb44iPhIAAAQAAAAEAAQJteAZoZXJvbGQCYXQAABAAAcAPAAYAAQAAASwAJQJs
> cMAPCW9wZXJhdGluZ8APd95fVQAADhAAAA4QAAAOEAAADhAAACkQAAAAgAAAAJyYLE47rAAASgAA
> AEoAAAAAAAMEAAYAAAAAAAAAAAgARQAAOtiMAABAEaQkfwAAAX8AAAEANWqAACb+OZ4ggYIAAQAA
> AAAAAAJteAZoZXJvbGQCYXQAABAAAQ==
> 
> --Boundary-01=_6zJLOx73hVYN2Nt--
> 
> --nextPart4860359.NRmvcb7r7W
> Content-Type: application/pgp-signature; name=signature.asc 
> Content-Description: This is a digitally signed message part.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.16 (GNU/Linux)
> 
> iEYEABECAAYFAk4snQIACgkQzhSR9xwSCbS42QCg77QkrDiq8FQ/KBq8Qca2YLgP
> 5qcAoLotD4L/sLiRb4OrrZei326iUnLJ
> =BQdW
> -----END PGP SIGNATURE-----
> 
> --nextPart4860359.NRmvcb7r7W--
> 
> --===============1266670159703048203==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
> --===============1266670159703048203==--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org