[Unbound-users] Problems with dipmap.com

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Attila,

On 09/19/2011 01:03 PM, Attila Nagy wrote:
> Hi,
> 
> There is a problem with resolving names from dipmap.com with unbound.
> Currently, the root NSs give back three nameservers, from which only one
> works (at least from our network).
> And that one has a bad NS RR:
> $ dig ns dipmap.com @ns.dipmap.com.
> 
> ; <<>> DiG 9.6.-ESV-R4-P1 <<>> ns dipmap.com @ns.dipmap.com.
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25982
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;dipmap.com.                    IN      NS
> 
> ;; ANSWER SECTION:
> dipmap.com.             60      IN      NS      sql2005.
> 
> It seems that unbound stores that nameserver and wants to query it, so
> either a time out or a SERVFAIL happens to the client.

Yes it wants to query it, but in my test it quickly finds out that the
bad-name does not exist.  Then it tries the last resort: it falls back
to the parent nameserver NSset.  And this works.  So it works fine for me?

> I thought that a recursive DNS server shouldn't cache NS records from
> the zone's authoritative name server, it should only trust in the upper
> servers.

No, the child's server is the most authoritative for its NS record.  The
upper servers only give hints to reach the child.  But this zone is
misconfigured, yeah.

> ISC BIND doesn't have this behaviour -it seems-, so it can resolve names
> from this domain.

Well, so should we really.  Since it works for me, but not for you, can
you tell me what happens when it does not want to work: set verbosity to
4 and do a probe and look at the logs.  It should try the last resort.

This was added in 1.4.5 so if you are running older unbound, that would
explain.

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOdzDQAAoJEJ9vHC1+BF+NtfkP/2tveMnG3fxejSxvCbXOvjSc
PfI/5JYQlkTCvXn0QAXZbLpgnVWq+dx3lEhkK41oRPTvO1N5H3lx2Sj8XWwIrTnl
rsP29Gh+LtoteyVoBemd+Uf8Na7Rx+zzNjrhgKtE3KTE/WhWTKt6+0XGo0jOP4vl
yYeCayRlMzLb5E2jLXjBJ1Vcbi5m0uVyDrTdRQ34qw21y+HH+o+pxhcL0roGkmh3
AFdtMaQClpBhBfOuQrA/CtzBPYGR4xy5EDWJQ4fannW7g8Qeav2ei97HW9V5ZVFa
160uSlqZ9RrZJombZog+X0ROJdOA6tB8zrnM9qHXDl4a95nfT9f3IP60yNNQYJEn
8eC4E0psWnGvPqvDPPO/EikdoQAKaDhPIHhjg/xNmdwNhL+/DWYnTDTHXuYfBtfy
qU4JzcBEdHd8gILwU7VNqoD/52fDiEfagtt2eyd4++o8A0jSHWQwL77gerPj3mA4
KXR0I//BRdXrZlgErp+Ne0Nlzqk9J5A92S1DkJe5DU3+1c+UKIhNx0S0QPuPE5ST
ryF3E6f5JgOMoEk/SXcGfzM7LmBMhsTrDa5sRvhY+j3mJS1T7MfJMr7iedetH29J
ifZY5XMzdJz3whQpg51wb9Rk4WAGUItKc7LseUMBlW+2FLxfZkzY307TM5ZKuKRa
xMt8GtJK+qrCkKQLY7rh
=nDDW
-----END PGP SIGNATURE-----