Extra fields for MX, SVR, etc?

[amyers1616]

Are there plans for adding the ability to store more information with certain records like, MX and SVR? These types need additional information in their records to be useful. Things like TXT records on the other hand, don't necessarily need a name value for the record and should be optional.

[peteeckel]

Currently no, but it's certainly something worth thinking about. There are quite a lot of possible record types with different syntax requirements, which will make it a major effort to implement sensible forms for all of them.

However, there is good old issue https://github.com/auroraresearchlab/netbox-dns/issues/72, which may address some of the things you have in mind at least on the verification level. One of the ideas would be to define regular expressions for all or at least the most common record types that provide a simple way to safeguard against incorrect entries. They could also be made configurable so specific requirements can be adjusted to.

By the way, every record does have a name, which is implicitly referring to the zone name in many cases (often for TXT, SOA, NS, MX etc.). The name is one of the things that are never optional. Have a look at RFC 1035 Section 3.2. However, thinking about it we could make entering it optional and substitute the domain name or "@" (short for the current origin, by default the zone name) for an empty name.

[amyers1616]

Thanks for the reply. Yes, I was thinking "optional" as @ for short since that is a common shorthand.

I may toy around with some basic forms and do a PR if I get something workable. Possibly changing the form up depending on the record type that's selected. I think I saw that as something that was working in Netbox 3.2 on some of the default forms.

[peteeckel]

Possibly changing the form up depending on the record type that's selected.

I think that would be exactly the right way to do it - select a record type at the top of the form and then dynamically enable and disable the required form fields depending on what type was selected. The main thing about that will be to get the fields for all of the possible record types right, but once the functionality is in place in principle that should be something that can be gradually extended.

[jcollie]

I don't know if I'd recommend using regular expressions to validate the data. I'd use dnspython. It has a really handy function dns.rdata.from_text() for parsing the data:

>>> import dns.rdata
>>> r=dns.rdata.from_text("IN", "MX", "1 smtp.example.org.")
>>> r.preference
1
>>> r.exchange
<DNS name smtp.example.org.>
>>> r.exchange.to_text()
'smtp.example.org.'
>>> r=dns.rdata.from_text("IN", "MX", "11111111 smtp.example.org.")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.10/site-packages/dns/rdata.py", line 613, in from_text
    rdata = cls.from_text(rdclass, rdtype, tok, origin, relativize,
  File "/usr/lib/python3.10/site-packages/dns/rdtypes/mxbase.py", line 48, in from_text
    preference = tok.get_uint16()
  File "/usr/lib/python3.10/site-packages/dns/tokenizer.py", line 520, in get_uint16
    raise dns.exception.SyntaxError(
dns.exception.SyntaxError: 11111111 is not an unsigned 16-bit integer
>>> 

dnspython is pure Python, widely packaged, and has comprehensive coverage of DNS record types.

[peteeckel]

Looks like a much more elegant solution to me, thanks!

[peteeckel]

@amyers1616: Did you find the time to play around with the idea of dynamic forms that change the data to be entered depending on the record type that was selected?

I'm not much of a JavaScript guy, so I shy away from digging into this issue, but if you have some viable approach for at least the most common record types I'd be willing to take it from there, or we could work out the feature together. I still think it's a great idea and would make life for the casual user much easier.

[amyers1616]

@peteeckel - no, I didn't mess with it at all. I'm even worse at javascript than I am at python and it's just not been a priority yet.

[peteeckel]

Too bad ... OK, I'll see if I can hack something sensible together. It seems Bootstrap has some mechanisms (nav-tab etc.) that could be suitable for what we have in mind.

Don't hold your breath, though ...