Value field validity check

[xsu734]

Hello,
since the Name field already has a check for domain name validity, I wanted to ask, why this check is not implemented in the Value field as well. For example, the value of a CNAME record should always be a domain name. Same goes for the second part of MX record value. Maybe I am missing some obvious reason, I'm still pretty new to DNS.

Thank you for your time and all the work on this plugin

[peteeckel]

Hi @xsu734, thanks for asking ... however, the answer might not be entirely to your liking :-)

Validating RR names is (not extremely, but resonably) easy. There are some special cases, and there is some stuff that is ... let me say, not very well defined (speak about underscores in host names, which are kind of allowed in special places, but not on all server implementations are they allowed everywhere - don't get me started). But eventually we have a sufficiently usable solution, considerung some feature flags that may be set or not.

With values it's another story. There are almost a hundred different RR types, some of which have variants with entirely different syntaxes. Doing this by hand is almost impossible, at least it's not something anyone would want to maintain as a side-project.

For this reason, there is some validation in place, but only to the extent that dnspython provides. For example you can't add a completely botched MX record (just try :-)), but there are certainly ways to create malformed records that dnspython validation is not catching. Considering the above facts, that's not surprising and you actually can't blame the dnspython team for it. They do their best, and NetBox DNS is participating from their work.

As for your CNAME example - what is a domain name?

name is definitely a valid value for CNAME.
xn--aa is one as well.
xn--bb isn't.

Can you figure out why? Multiply that by a hundred.

And yes, I tried ...

[xsu734]

Hello again and thank you for your reply.

Yes, trying to figure out value validation for all RR types would be unreasonable, but I do think having it present for frequently used types (CNAME, MX) and not having it for others is better, than not having it at all.

With CNAME values my though process was something like:

1. a CNAME record value is supposed to point to the name of a different record
2. names of records are checked for domain name validity
3. therefore, checking for domain name validity in CNAME record values would make sense

[peteeckel]

I fully agree that it would make sense to check for the validity of record values pointing at names.

But believe me, it is not that easy. For instance, a CNAME could point to a record in an entirely unrelated zone, and that zone could be served by a Microsoft AD DNS server. For this type of server it is legal to have underscores in names, which is not the standard. Would such a value be valid or not?

I'm not happy with the way dnspython validates names either. By default it doesn't catch the xn-bb example above, you need to have it translate it to IDN notation to make it spot the error (which I'm doing). Some other names have to be caught by using more or less involved regexes. dnspython makes a good effort to validate values, but it is limited by the same problems I outlined in the above CNAME example: There are some incompatble and non-RFC compliant servers around.

We could validate the values for CNAMEs pointing at names that are within NetBox DNS, and I think that could be relatively easy as well (there's some code that links CNAMEs to the names they are pointing at anyway). But we must be aware that the names used in CNAME, DNAME, MX, SRV etc. may not be ones whose validity we can determine at all (I always hated the underscore anomaly in MS AD, and since I started working on NetBox DNS I learned that there is a lot more stuff like that to worry about).

Bottom line: A generic solution is difficult to achieve. Maybe I'll look into contributing to dnspython to improve the situation, but adding another layer of home-grown validation to NetBox DNS is nothing I have in mind. It's bad enough as it is.

Did you consider using CUSTOM_VALIDATORS?

[xsu734]

Thank you for the clarification. I will try to look into custom validators.

[peteeckel]

... and I will have another look at ways to provide a bit more validation of values. No promises, though - it's not the first attempt.

[peteeckel]

Another question: Can you give me an example of a CNAME or MX that is accepted but shouldn't be?

[xsu734]

I think that right now, CNAMES allow any string that does not include spaces, parentheses or quotes. This is a valid CNAME value: [#^$[¨}!;--_?:.@/\ˇ´%].

With MX, you must have an integer, a space, and a string. This works well, but the string can include anything (same as CNAME). So this is a valid MX value:
10 [#^$[¨}!;--_?:.@/\ˇ´%].

[peteeckel]

As much as I hate it - I'm afraid that's a valid IDN :-(

>>> rr = dns.rdata.from_text('IN', 'CNAME', '[#^$[¨}!;--_?:.@/\ˇ´%]')
>>> rr
<DNS IN CNAME rdata: xn--[#^\$[\032}!-20e>
>>> rr.target.to_unicode()
'[#^\\$[\\032̈}!'

Something's definitely fishy here. My regular expressions (correctly) decline its validity, but dnspython is not that picky.

I'll think of something. That is not like it should be.

[peteeckel]

#257 is merged now. I hope I won't regret it too much, but your example record was definitely too bad to let it live :-)

[peteeckel]

I implemented a mild form of validation for domain names in values in #256.

This tries to avoid the problems outlined above (though it won't catch everything as a consequence) and will definitely disallow values like the 'RR values of death' from your examples.

Fortunately I could only find 15 RR types that can contain domain names in their values - not all of them in the same form, though. I hope I didn't introduce too many restrictions (all tests are working, but there are never enough to be sure).

[Serverhamster]

Is it possible that the new validation also blocks values like selector1-example-com._domainkey._SOMEDOMAIN.onmicrosoft.com. ? I can't get these values accepted.

This is what Microsoft uses by default for DKIM CNAME records (https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure)

[peteeckel]

Yes, I can confirm that the new value validation for CNAMES disallows this name.

selector1-example-com._domainkey._SOMEDOMAIN.onmicrosoft.com.

And no, it shouldn't. I intended to implement the value validation so that it uses the most relaxed variant of name validation (because we just can't know what the nameserver resolving the value of the CNAME or other record will accept), and obviously it's not relaxed enough.

I'll take care of it.

[peteeckel]

Opened (and closed :-)) #285.