[RFCI-Discuss] Interesting Question

[Derek J. Balling]

On Jan 6, 2006, at 12:28 PM, Abuse Desk wrote:
> ;; QUESTION SECTION:
> ;targetresume.com.              IN      NS
>
> ;; ANSWER SECTION:
> targetresume.com.       172800  IN      NS      ns1s.on-linejobs.com.
> targetresume.com.       172800  IN      NS      ns2.on-linejobs.com.

> Then we continue our quest for authoritative NS records, and run into
> the following twin brick walls (non-authoritative answers with the  
> name
> of a nameserver that doesn't exist):
>
> ; <<>> DiG 9.2.3 <<>> @ns1s.on-linejobs.com targetresume.com ns
>
> ;; QUESTION SECTION:
> ;targetresume.com.              IN      NS
>
> ;; ANSWER SECTION:
> targetresume.com.       3600    IN      NS      ns1s.

> ; <<>> DiG 9.2.3 <<>> @ns2.on-linejobs.com targetresume.com ns
>
> ;; QUESTION SECTION:
> ;targetresume.com.              IN      NS
>
> ;; ANSWER SECTION:
> targetresume.com.       3600    IN      NS      ns1s.

> Such behavior should cause a totally-compliant resolver not to even  
> get
> to the stage of looking for an MX record, shouldn't it?

I would agree to that logic. Because the only "authoritative" MX  
record can come from the host "ns1s.", which is NXDOMAIN. Thus, there  
is no MX (because any attempt to determine it will return SERVFAIL)

One could argue that this is "bogusns", but that's not a criteria we  
have, nor are we even inclined at the moment to try and tackle it,  
given how much trouble we have with the bogusmx logic.

> Extending the search, let's look for an MX record:
>
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0,  
> ADDITIONAL: 1
>
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0,  
> ADDITIONAL: 1

> So those nameservers aren't authoritative for the mailservers of
> targetresume.com either.

Yes, they are. The "aa" flag is set. Although they themselves claim  
that *other* servers are authoritative, they will also return an  
authoritative answer. (Bogus NS, but not necessarily Bogus MX).

> Is or should such behavior enough to qualify a domain for bogusmx
> listing?

No.

> Does it make sense to add a criterion for bogusmx that if any MX  
> record
> (including an implicit MX record of priority 0 as an A record in the
> absence of a real MX record) is found for a domain or subdomain by
> following the NS record chain from the root, and that MX record is not
> authoritative, then the domain or subdomain queried for that MX record
> shall be considered bogus because "non-authoritative answers aren't
> worth the bits that carried them"?

We don't pay attention to non-authoritative MX replies now. But if I  
have a path that goes:

root -> some_ns -> b0rked_ns

and "b0rked_ns" doesn't exist, it won't return MX records, so there  
won't be any MX records to be "bogus".

> Would a new bogusns zone fit the bill instead?

Yes, but don't hold your breath waiting for one. I've got enough on  
my plate trying to work out the occasional kinks in bogusmx (there's  
a couple edge cases that can send bogusmx into a long long work loop  
that takes about an hour to do a check on a single domain, clearly,  
there's an optimization I need to find somewhere).

> The SOA record is similarly hosed, referencing nameserver "ns1s." and
> contact "hostmaster@" as "hostmaster.".

We haven't got any position on SOA records at the moment, and aren't  
likely to have one for some time for the reasons above.

D


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2419 bytes
Desc: not available
Url : http://lists.megacity.org/pipermail/rfci-discuss/attachments/20060107/d2c4dbe3/smime.bin