Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
3  
Adding a TXT record for www should not affect A record resolution. How about providing us some salient details (like the contents of your zone file, and possibly the results of dig, or at least nslookup from an affected machine). –  voretaq7 Oct 4 '11 at 16:16
    
@voretaq7: Thanks, and sorry, I'm developer, and while I'm hardly familiar with nslookup, I don't even know dig. One of the sites still isn't back after removing the entry - I will post the nslookup results in my question. –  Olaf Oct 4 '11 at 16:38
    
How was it unavailable? What type of error? –  jdw Oct 4 '11 at 16:42
    
@jdw: Simply "Server not found", same as if there is a typo. No particular error message. –  Olaf Oct 4 '11 at 16:47
    
Gotcha. I'm betting BIND did not restart on that machine after you made your change for whatever reason. It makes no sense that your entire domain would go down if you made a typo, but if BIND did not restart, that would explain it. –  jdw Oct 4 '11 at 16:57

3 Answers 3

up vote 13 down vote accepted

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.

share|improve this answer
4  
Wildcards only apply if NO other data is present for the name. –  MikeyB Oct 4 '11 at 17:00
2  
As per tools.ietf.org/html/rfc4592#section-3.3 –  MikeyB Oct 4 '11 at 17:05
    
That sounds like it! Thanks very much for the explanation. But shouldn't it be "...having a more specific record of a different type masks..." instead of "...having a more specific record (even of a different type) masks..." because as you write a specific A record doesn't mask an A wildcard but a different type does...? –  Olaf Oct 4 '11 at 17:10
    
@Olaf That is quite possibly how it should be, but the RFC says otherwise. I would point out though that checking RR types during the label match phase would be computationally expensive in huge zones... –  voretaq7 Oct 4 '11 at 17:25

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.

share|improve this answer

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?

share|improve this answer
    
No, the hosting provider uses an interface that makes it difficult to accidentally delete entries. I have edited all I have into my question. –  Olaf Oct 4 '11 at 16:43

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.