Does Maradns have support for RFC 7505 "Null MX" No Service records (i.e. can we use "." for non-existant MX and SRV records)?

[brownianmotion]

Hi gang,

I've been a happy Maradns user for a couple of decades now, and have recently had occasion to set up some new domains on my server. Given that these are specific purpose domains, it seemed reasonable to implement RFC 7505 Null MX to reduce spam traffic to the site.

RFC 7505 says that domains which do not receive email should return MX RDATA with

To indicate that a domain does not accept email, it advertises a
single MX RR (see Section 3.3.9 of [RFC1035]) with an RDATA section
consisting of preference number 0 and a zero-length label, written in
master files as ".", as the exchange domain, to denote that there
exists no mail exchanger for a domain.

However, it seems like Maradns does not like lines of the form

%		+300	mx	0 .

giving an error of

/usr/sbin/maradns: Processing zone example.com. right now.
/usr/sbin/maradns: Filename: db.example.com
/usr/sbin/maradns: Error: Unexpected character
/usr/sbin/maradns: Error is on line 22 in file db.example.com
/usr/sbin/maradns: context of error: %      +300   mx   0 . (closing this file)
/usr/sbin/maradns: Error: Problem getting rddata
/usr/sbin/maradns: Error is on line 22 in file db.example.com
/usr/sbin/maradns: context of error: %      +300   mx   0 . (closing this file)

Is there another format to write null mx records in? Or is this scenario simply not supported?

[brownianmotion]

Finally had a chance to look at the code to try and see what might be behind this.

It looks like the csv2_get_mx‎ function uses csv2_is_dchar‎ to locate the exchange domain when parsing, and csv2_is_dchar is looking for domain characters excluding dots.

My first instinct was the minimal fix was to change from csv2_is_dchar to csv2_is_fchar - this will include the dot as a valid option. However, thinking about it a little more, this would remove the possibility of using the origin as the exchange domain by using the % substitution - and it's probably worth maintaining that feature.

I suspect the correct fix is to introduce a new function (maybe called csv2_is_dchar_ordot in parallel with csv2_is_starwhitis_ordot‎)

+  /* Match on [0-9a-zA-Z\-\_\%\.] or anything utf-8 */
+  int csv2_is_dchar_ordot(int32 in) {
+          return (csv2_is_text(in) || in == '%' || in == '.');
+  }
+

and then modify csv2_get_mx to call it:

           /* And the MX host name */
           while(hlabels > 0) {
                   js_string *name;
-                  if(csv2_get_1st(stream,csv2_is_dchar,0) != JS_SUCCESS) {
+                  if(csv2_get_1st(stream,csv2_is_dchar_ordot,0) != JS_SUCCESS) {
                           js_destroy(out);
                           return 0;
                   }
                   if((name = csv2_get_hostname(stream,zone,3)) == 0) {
                           js_destroy(out);
                           return 0;
                   }

(The above are manually constructed pseudo-diffs for human consumption, because I'm not at my dev machine. I will test the fix out later today when I get chance.)

@samboy - if this tests out correct, would you like me to create a pull request for this, or would you just apply the changes as described above? If you want a pull request, do you have a preference for what to name the new function, or is csv2_is_dchar_ordot suitable?

---

After writing this all up, I decided to check where else csv2_is_dchar is used, in case the more correct fix was to just edit that function. It is used for csv2_get_mx, csv2_get_srv, and in csv2_read_rr for processing /origin and /opush commands as well as NS, CNAME, PTR, NSAP-PTR, and MB RR types.

As noted in my original post, RFC 7505 requires that . be acceptable for MX.

For SRV records, . should also be acceptable as RFC 2782 states:

A Target of "." means that the service is decidedly not available at this domain.

So we should probably also update csv2_get_srv to use csv2_is_dchar_ordot as well.

          /* Get the SRV host name */
-          if(csv2_get_1st(stream,csv2_is_dchar,0) != JS_SUCCESS) {
+          if(csv2_get_1st(stream,csv2_is_dchar_ordot,0) != JS_SUCCESS) {
                   js_destroy(out);
                   return 0;
           }
           if((name = csv2_get_hostname(stream,zone,3)) == 0) {
                   js_destroy(out);
                   return 0;
           }

I don't know enough about NSAP-PTR or MB in practice, but for /origin, /opush, NS, CNAME, and PTR there's probably no value in allowing a null hostname, so I suspect that we should leave csv2_is_dchar in csv_read_rr.

[brownianmotion]

Having been digging through the inner workings of it all, I just realised that there might be a way to get the right outcome without modifying the code, using RAW records. This is untested at the moment, but if I understand the format correctly, the expected outcome of a record like:

%		+300	mx	0 . 

is an answer section consisting of a record type of 15 for MX, with rdata consisting of a 16-bit integer of 0 (so 2 octets of 0) followed by a "zero-length" label, which would be represented by a single octet of 0. That should mean that the following raw record should be correct encoding of a null MX record.

%		+300	raw 15 \000\000\000 

Similarly, a non-existant service would have an SRV record (type 33) containing 3 16-bit integers of 0 for Priority, Weight, and Port, followed by a single-octet length of 0, and should be representable by either of:

_nonexistant._tcp.%		+300	srv	0 0 0 . 
_nonexistant._tcp.%		+300	raw 33 \000\000\000\000\000\000\000 

I will test these out later as well and confirm if they work - for folk who don't want to or can't update the code, this method could be a suitable alternative. Despite not being as easy to read, they're relatively straightforward as most of the "magic numbers" are zero...

[brownianmotion]

I have tested these raw values, and they produce the right outcome, so for now, I'll mark this as the answer. I'll get around to testing the code soon, and will update again when that happens.