| |||||||||||||||||||||||||||||||
|
[...] > traininghott.com definitely seems to have a standards-conformance issue > in the way it handles SOA queries [...] Hhm, I think I would disagree here. After all, their name servers do return SOA records when queried directly, even if they are too many. The interesting bit is, if I let my own name server do the querying, I get SERVFAIL: ; <<>> DiG 9.3.3rc2 <<>> @server traininghott.com. soa ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49324 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;traininghott.com. IN SOA ;; Query time: 331 msec but a tcpdump/wireshark analysis shows that there were two answers (the SOA RRs, two name servers, and nothing in the additional section; 2/2/0 in tcpdump output). This means that the querying server, which runs BIND 9.4.1_P1 btw., has decided to discard the response. I guess this kinda clarifies my original question "What kind of consequences can I expect trying to resolve records in a domain that has more than one SOA?". Kevin, can you explain > Note, however, that *transactionally* a zone transfer response includes > 2 SOA RRs. I cannot find anything on this?
| ||||||||||||||||||||||||||||||
© 2004-2008 readlist.com