Multiple SOA records?
Lars Hecking
RFC 1935 says:
2. Exactly one SOA RR should be present at the top of the zone.
Note: "should", not "must".
What kind of consequences can I expect trying to resolve records in a
domain that has more than one SOA? The domain that is making problems
is traininghott.com. Querying for its SOAs returns SERVFAIL, but querying
the domain's name servers directly returns two (different) SOAs. This
appears to create problems with mail (not sure here - another entity in
my organisation is experiencing the problem).
Kevin Darcy
> RFC 1935 says:
>
> 2. Exactly one SOA RR should be present at the top of the zone.
>
> Note: "should", not "must".
>
The language you quote from 1035 (1935 was obviously a typo) refers to
the validation of the data being loaded from a master file. Yes, there
*should* be only 1 SOA RR, but if the master file is *wrong*, there
*might* be more than 1 SOA RR. Stuff happens. Implicit here is the
conclusion that such a master file should be rejected by the nameserver.
But, when describing what is a valid zone and what isn't, I think a much
better source of authority is Section 4.2.1 of RFC 1034 (the companion
to 1035), which describes "
The data that describes a zone" and specifically says it includes "a single SOA RR that
describes zone management parameters.". Can't get much clearer that: "single".
Note, however, that *transactionally* a zone transfer response includes 2 SOA RRs. But those should be identical, unless perhaps the zone changed while the zone transfer was in progress.
> What kind of consequences can I expect trying to resolve records in a
> domain that has more than one SOA? The domain that is making problems
> is traininghott.com. Querying for its SOAs returns SERVFAIL, but querying
> the domain's name servers directly returns two (different) SOAs. This
> appears to create problems with mail (not sure here - another entity in
> my organisation is experiencing the problem)
>
traininghott.com definitely seems to have a standards-conformance issue
in the way it handles SOA queries (anyone feel like fingerprinting their
nameservers to see what DNS implementation they're running?), but I
wouldn't expect that to affect mail since mail shouldn't have any need
(that I can think of) to make SOA queries.
- Kevin
Lars Hecking
> The language you quote from 1035 (1935 was obviously a typo) refers to
Sorry, you're right.
> traininghott.com definitely seems to have a standards-conformance issue
> in the way it handles SOA queries (anyone feel like fingerprinting their
> nameservers to see what DNS implementation they're running?), but I
> wouldn't expect that to affect mail since mail shouldn't have any need
> (that I can think of) to make SOA queries.
version.bind. 0 CH TXT "9.4.0rc2"
and
version.bind. 0 CH TXT "9.4.0"
I need to get more details from my guys what exactly the issue is.
Kevin Darcy
>> The language you quote from 1035 (1935 was obviously a typo) refers to
>>
>
> Sorry, you're right.
>
>
>> traininghott.com definitely seems to have a standards-conformance issue
>> in the way it handles SOA queries (anyone feel like fingerprinting their
>> nameservers to see what DNS implementation they're running?), but I
>> wouldn't expect that to affect mail since mail shouldn't have any need
>> (that I can think of) to make SOA queries.
>>
>
> version.bind. 0 CH TXT "9.4.0rc2"
>
> and
>
> version.bind. 0 CH TXT "9.4.0"
>
>
ns2.safesecureweb.com? I just get timeouts when I try to do version
queries of those nameservers.
- Kevin
Lars Hecking
> > version.bind. 0 CH TXT "9.4.0rc2"
> >
> > and
> >
> > version.bind. 0 CH TXT "9.4.0"
> >
> >
> Hmmm... are you getting those responses from ns1.safesecureweb.com and
> ns2.safesecureweb.com? I just get timeouts when I try to do version
> queries of those nameservers.
Yep. Maybe they have routing problems on top of everyting else :)
$ dig @ns1.safesecureweb.com. version.bind chaos txt
; <<>> DiG 9.3.3rc2 <<>> @ns1.safesecureweb.com. version.bind chaos txt
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53584
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;version.bind. CH TXT
;; ANSWER SECTION:
version.bind. 0 CH TXT "9.4.0"
;; AUTHORITY SECTION:
version.bind. 0 CH NS version.bind.
;; Query time: 248 msec
;; SERVER: 66.241.192.6#53(66.241.192.6)
;; WHEN: Wed May 7 09:56:22 2008
;; MSG SIZE rcvd: 62
Lars Hecking
[...]
> 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?
Chris Buxton
transfer access to. The output will start and end with an SOA record.
For example:
$ dig @localhost localhost axfr
; <<>> DiG 9.4.1-P1 <<>> @localhost localhost axfr
; (3 servers found)
;; global options: printcmd
localhost. 86400 IN SOA localhost. root.localhost. 42 10800 900
604800 86400
localhost. 86400 IN NS localhost.
localhost. 86400 IN A 127.0.0.1
localhost. 86400 IN SOA localhost. root.localhost. 42 10800 900
604800 86400
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed May 7 07:15:35 2008
;; XFR size: 4 records (messages 1, bytes 134)
Chris Buxton
Professional Services
Men & Mice
Chris Thompson
> RFC 1935 [corrected later to 1035] says:
>
> 2. Exactly one SOA RR should be present at the top of the zone.
>
> Note: "should", not "must".
Note also that RFC 1035 precedes RFC 2119. These are not the MUST and
SHOULD that we use these days.
> What kind of consequences can I expect trying to resolve records in a
> domain that has more than one SOA? The domain that is making problems
> is traininghott.com. Querying for its SOAs returns SERVFAIL, but querying
> the domain's name servers directly returns two (different) SOAs. This
> appears to create problems with mail (not sure here - another entity in
> my organisation is experiencing the problem).
As others have commented, there seem to be all sorts of problems with
ns{1,2}.safesecureweb.com. For example
;; reply from unexpected source: 208.112.127.177#53, expected
66.241.192.6#53
Frankly, I don't believe that the responses are coming from a BIND 9.4.x
installation, whatever TXT/CH/version.bind says, without later tampering.
--
Chris Thompson
Email: ce...@cam.ac.uk
Kevin Darcy
> Kevin Darcy writes:
> [...]
>
>> 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.
>
have an owner name which is identical to the zone name. Put those two
things together, and you get that a given name can only own at most one
SOA RR. Expressed another way, SOA is a "singleton type".
Are you with me so far?
These servers are responding, to a regular query (as opposed to a
zone-transfer request) with two SOA RRs that have the same owner name
but different RDATA. How can this possibly conform to standards? One of
those RRs -- take your pick -- can't be legally owned by its owner name,
because of the existence of the other RR. One of them conforms to
standards; the other one violates them.
- Kevin