Home / server / Questions / 318397
Accepted
Olaf
Asked: 2011-10-05 08:06:24 +0800 CST

Adding a hostname with 'www' to TXT entry in nameserver makes website unavailable - why?

  • 772

One way to verify sites when using Googles webmaster tools is to add a TXT entry to the nameserver, using the hostname and adding the provided text.

Accidentally (because I simply didn't know) I added two TXT entries, one with 'www' and one without, just to make sure Google would accept the code (because in the webmaster tools the site was entered with 'www').

What happened was: after the DNS entries had spread, the sites were not available anymore when using the hostname with 'www'. EDIT: No particular error message, just "Server not found".

Why? It was probably naive to think that the TXT entry format is somewhat arbitrary, but can someone explain to a shocked developer (=non-administrator) why a TXT record can influence something that should be handled by A records so destructively?

EDIT: Here is the example (but of course it is no longer online). The site is hosted at domainfactory, a shared hoster where one can edit the DNS settings (or have domainfactory manage them - in that case, the 'Ziel' column shows their name; usually it is no problem to mix entries):

enter image description here

It is exactly the last entry that made the site unavailable.

However, telling me that this should not happen is also a good answer - I can ask the hosting provider then.

Forgive me if I'm not familiar with nslookup, but I did one lookup with and one without www on one of the domains that still don't work, and this is the result:

C:\>nslookup www.foo.de
Server:  dns2.colt1.inetserver.de
Address:  195.234.228.93

Name:    www.foo.de

And the second one:

C:>nslookup foo.de
Server:  dns2.colt1.inetserver.de
Address:  195.234.228.93

Nicht autorisierende Antwort:
Name:    foo.de
Address:  81.20.84.178

The difference is that the request without 'www' showed a 'Nicht autorisierende Antwort:' (probably 'non-authorizing answer') but the correct IP.

domain-name-system google

3 Answers

  1. Best Answer

    OK, I can duplicate the behavior (BIND 9.6), and believe I've sussed out the cause:

    If you have a wildcard A record and a more specific TXT record as below the A record breaks.

    *.test.bsd-box.net.       IN        A        127.0.0.1
www.test.bsd-box.net.     IN        TXT      "This be a text record, mon!"

    but if you have a specific A record it works fine:

    *.test.bsd-box.net.       IN        A        127.0.0.1
www.test.bsd-box.net.     IN        A        127.0.0.1
www.test.bsd-box.net.     IN        TXT      "This be a text record, mon!"

    So apparently having a more specific record (even of a different type) masks the wildcard A record.

    I'm not sure what the underlying logic is that causes the wildcard A record to not be recognized if there's a more specific TXT record, or if it's an RFC-mandated thing or not, but you can peruse the DNS RFCs (and/or the BIND source) for more details.

    • 13

  2. Because it gets in the way of your wildcard ("*") record. If you have any records for an item, the wildcard no longer matches at all, for any record type.

    From RFC1034, §4.3.3:

    Wildcard RRs do not apply … [w]hen the query name or a name between the wildcard domain and the query name is [known] to exist. For example, if a wildcard RR has an owner name of "*.X", and the zone also contains RRs attached to B.X, the wildcards would apply to queries for name Z.X (presuming there is no explicit information for Z.X), but not to B.X, A.B.X, or X.

    Note that the example doesn't match the OP's situation, but the rule is the same.

    • 8

  3. Is it possible that while you were editing the zone you accidentally removed an A record of a CNAME recored?

    Perhaps it might be helpful to have a look at your complete Zone file, and see if everything you expect to be there is actually still there?

    • 1