Manually adding PTR records?
anton
30-04-2009 15:51:37
Hi - I have the following situation:
The firewall, having multiple IP aliases on its external interface, has multiple interfaces defined (though this may technically not be correct, but the closest thing I could see to an alias is another interface with the same MAC).
When adding these additional (alias) interfaces, no PTR records are created for them. And when I went to add them by hand, I'm finding there is no way to add PTR records? Am I missing something?
Thanks,
Anton
The firewall, having multiple IP aliases on its external interface, has multiple interfaces defined (though this may technically not be correct, but the closest thing I could see to an alias is another interface with the same MAC).
When adding these additional (alias) interfaces, no PTR records are created for them. And when I went to add them by hand, I'm finding there is no way to add PTR records? Am I missing something?
Thanks,
Anton
tmyoungjr
01-05-2009 07:47:56
Yeah, you can add multiple "interfaces" per host - but you'll only get one PTR record generated. I do not see a way to generate additional PTR records.
General best practices state one PTR record. However the official rules state there can be many.
I'm guessing Matt just took the best practices and went that route.
"While most rDNS entries only have one PTR record, the rules allow many different PTR records.[1] However, having multiple PTR records for the same IP address is generally not recommended unless there is a specific need. For example, if a webserver supports many virtual hosts, there can be one PTR record for each host and some versions of name server software will automatically add a PTR record for each host. Multiple PTR records can cause a couple of problems, including triggering bugs in programs that only expect there to ever be a single PTR record and, in the case of a large webserver, having hundreds of PTR records can cause the DNS packets to be much larger than normal."
General best practices state one PTR record. However the official rules state there can be many.
I'm guessing Matt just took the best practices and went that route.
"While most rDNS entries only have one PTR record, the rules allow many different PTR records.[1] However, having multiple PTR records for the same IP address is generally not recommended unless there is a specific need. For example, if a webserver supports many virtual hosts, there can be one PTR record for each host and some versions of name server software will automatically add a PTR record for each host. Multiple PTR records can cause a couple of problems, including triggering bugs in programs that only expect there to ever be a single PTR record and, in the case of a large webserver, having hundreds of PTR records can cause the DNS packets to be much larger than normal."
anton
01-05-2009 08:16:53
Yes, I understand not having more than 1 PTR record per IP normally, but each alias (defined as interface in ONA) is a separate, unique IP.
When manually adding DNS records, the following record types are available in the drop down box: A, CNAME, MX, NS, SRV, TXT. This is the same for both forward and reverse zones, which doesn't quite make sense - PTR records are needed for the reverse zones obviously. Without that, it isn't possible to manually add any reverse DNS records.
Perhaps I should file this as a bug..?
Anton
When manually adding DNS records, the following record types are available in the drop down box: A, CNAME, MX, NS, SRV, TXT. This is the same for both forward and reverse zones, which doesn't quite make sense - PTR records are needed for the reverse zones obviously. Without that, it isn't possible to manually add any reverse DNS records.
Perhaps I should file this as a bug..?
Anton
Matt
01-05-2009 08:51:34
Yes the ability to add manual PTR records is something that I need to fix. Opening a ticket on it would be good just to get it on the list to help me remember.
Basically 99% of the hosts in the database are simple cases where you will have an A record and a single PTR record that points back to it. By default, A records will automatically have a PTR record set up for them. This of course can be disabled so only the A record is created.
The most common case however for multiple PTR records is for things such as routers. I may have the standard A/PTR pair like this:
router.example.com -> 10.1.1.1
1.1.1.10.in-addr.arpa -> router.example.com
But the other 10 IP interfaces on that router really should have PTR records so that if you want to use DNS to quickly tell you that IP address 10.7.7.1 is also associated with rotuer.example.com, you can. This scenario is not yet possible in the interface as Anton found out.
It is something however that I plan to do.
also, just a quick note on some of the terms used here. The database references the IPs as "interfaces". This is not really the best term to use but its been around a long time and will take some serious effort to change
.. each host in the database can have multiple IP addresses added to it (interfaces).. their is an interface name field that is used for things like "eth0, eth0:1, FastEthernet0/1.3" etc. so you can define multiple IP addresses per physical interface/sub interface this way. its just a bit confusing as the word interface is misleading. Hope that clarifies it a bit.
Basically 99% of the hosts in the database are simple cases where you will have an A record and a single PTR record that points back to it. By default, A records will automatically have a PTR record set up for them. This of course can be disabled so only the A record is created.
The most common case however for multiple PTR records is for things such as routers. I may have the standard A/PTR pair like this:
router.example.com -> 10.1.1.1
1.1.1.10.in-addr.arpa -> router.example.com
But the other 10 IP interfaces on that router really should have PTR records so that if you want to use DNS to quickly tell you that IP address 10.7.7.1 is also associated with rotuer.example.com, you can. This scenario is not yet possible in the interface as Anton found out.
It is something however that I plan to do.
also, just a quick note on some of the terms used here. The database references the IPs as "interfaces". This is not really the best term to use but its been around a long time and will take some serious effort to change
.. each host in the database can have multiple IP addresses added to it (interfaces).. their is an interface name field that is used for things like "eth0, eth0:1, FastEthernet0/1.3" etc. so you can define multiple IP addresses per physical interface/sub interface this way. its just a bit confusing as the word interface is misleading. Hope that clarifies it a bit.
anton
01-05-2009 09:34:39
Thanks for the response, I have added this to the bug tracker. Sounds like I'm not telling you anything you don't already know, the router example is pretty much what I ran into.
As for the term "interfaces", it is probably not 100% accurate, but it wasn't hard to figure out that that was the way to deal with additional IPs so it's not that big a deal.
Anton
As for the term "interfaces", it is probably not 100% accurate, but it wasn't hard to figure out that that was the way to deal with additional IPs so it's not that big a deal.
Anton
tmyoungjr
01-05-2009 11:58:25
Thanks for the response, I have added this to the bug tracker. Sounds like I'm not telling you anything you don't already know, the router example is pretty much what I ran into.
As for the term "interfaces", it is probably not 100% accurate, but it wasn't hard to figure out that that was the way to deal with additional IPs so it's not that big a deal.
Anton
you'll find that matt knows about most issues you'll come across
he's just entirely too busy - someone needs to pay him to do this (not me tho!)