Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extra fields for MX, SVR, etc? #160

Open
amyers1616 opened this issue Apr 4, 2022 · 8 comments
Open

Extra fields for MX, SVR, etc? #160

amyers1616 opened this issue Apr 4, 2022 · 8 comments

Comments

@amyers1616
Copy link

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
Copy link
Contributor

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 #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
Copy link
Author

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
Copy link
Contributor

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
Copy link

jcollie commented Apr 30, 2022

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
Copy link
Contributor

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

@peteeckel
Copy link
Contributor

@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
Copy link
Author

@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
Copy link
Contributor

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 ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants