No, expectation is that people getting AMPR address space should have the subnet they're in registered with the portal. That includes non-connected hosts and /32s.
Is it really a good idea to base the cleanup on data in the portal? I mean, the guy running the portal clearly does not have the resources (or the motivation?) to do even minor maintenance on it, let alone finish work on features like the DNS registration that have been in incompleted state for years. Is it a good idea to make our entire network dependent on that?
I cannot remove a subnet that was erroneously added in the past (and where user subnets where added inside) without deleting those, and a request to the maintainer to do that outside the portal UI that I sent months ago is still not processed.
I also cannot add any regional subnets for which parts are already registered to users. The whole implementation of subnet hierarchy and record ownership is much too strict, it only works when everything is done "the correct way" on the first try, which simply is not realistic. Compare it to HamnetDB where you can simply reshuffle the whole subnetting by inserting, deleting or editing existing records within the existing hierarchy.
I also don't like the idea to send a request to all users to "register themselves" and then being bombarded with allocation request mails from the portal that all need to be manually edited because the requesting user cannot specify an existing allocation to be registered.
Users that do not understand the whole mechanism cannot be ignored, because either you don't process the request and it remains on the todo list, or you reject the request and those users just click the links in the rejection mail which results in the same request being posted again :-(
In 44.137.0.0/16, really only the users that want to run an IPIP tunnel are registered in the portal, there are many other users that connect in a different way. Luckily we are not affected by this cleanup because we are BGP routed, but at the same time that also shows how this method is failing. After all, what does the routing method have to do with the DNS contents? Basically nothing. Why should all our inactive records remain there while those of other countries are deleted even when they may be active?
When we want to clean the DNS, we should look at the situation on a country by country base. I am all for deleting entries for callsigns that have expired, and in fact I regularly do that. Probably other countries also have lists of active callsigns and a quick scan can be made to delete all expired callsigns and probably also those records that are not related to callsigns. We could request all coordinators to send a list of active callsigns, and we could process those lists to generate a deletion list like I already do for my area.
We could also ask each coordinator what is the state of IP packet or other use of those addresses in their country, and maybe get whole networks deleted when they no longer exist.
I will try to dig in the old data I still have saved (for my area) to generate a list of callsigns and the date of last registration or reconfirmation, and try again to contact all callsigns with records before a certain date and delete them when there is no reply. This should clean out more records than the previous run, where I only deleted those registrations where the owner replied they no longer required them.
Rob
Rob,
Prior to flaming me, perhaps you should get your facts straight?
I have done several maintenance jobs and bug fixes on the Portal over the past couple of years, as and when they are reported to me. I’m working on a new feature right now that was requested.
If you have a problem you only need to contact me and ask for assistance, but I am not good at reading minds I’m afraid.
As for the DNS code in the Portal, it has been ready for over a year now, but Brian wanted me to hold off making it live until the current DNS can be cleaned up - hence this push to do just that.
As to your other comments regarding how the portal operates, that’s your opinion, which you are entitled to, but I originally wrote the code based on requirements and input from other folk, I didn’t just “make it up” myself.
Of course, if you want to offer your time re-write some of the code, or add new functionality then please lets talk, I’ve been asking for help on this for some time now, but apart from Tom who kindly provided (and still provides) the Polish translation, no-one else has done anything. And before anyone goes on about “open source” again, the code IS open source to the amateur radio community, just not the general public as it doesn’t need to be, if you want access to the code repository you only need to ask and it will be provided.
Kind Regards, Chris
On 7 Feb 2016, at 07:16, Rob Janssen pe1chl@amsat.org wrote:
(Please trim inclusions from previous messages) _______________________________________________
No, expectation is that people getting AMPR address space should have the subnet they're in registered with the portal. That includes non-connected hosts and /32s.
Is it really a good idea to base the cleanup on data in the portal? I mean, the guy running the portal clearly does not have the resources (or the motivation?) to do even minor maintenance on it, let alone finish work on features like the DNS registration that have been in incompleted state for years. Is it a good idea to make our entire network dependent on that?
I cannot remove a subnet that was erroneously added in the past (and where user subnets where added inside) without deleting those, and a request to the maintainer to do that outside the portal UI that I sent months ago is still not processed.
I also cannot add any regional subnets for which parts are already registered to users. The whole implementation of subnet hierarchy and record ownership is much too strict, it only works when everything is done "the correct way" on the first try, which simply is not realistic. Compare it to HamnetDB where you can simply reshuffle the whole subnetting by inserting, deleting or editing existing records within the existing hierarchy.
On 2/7/16 3:30 AM, G1FEF wrote:
Of course, if you want to offer your time re-write some of the code, or add new functionality then please lets talk, I’ve been asking for help on this for some time now, but apart from Tom who kindly provided (and still provides) the Polish translation, no-one else has done anything. And before anyone goes on about “open source” again, the code IS open source to the amateur radio community, just not the general public as it doesn’t need to be, if you want access to the code repository you only need to ask and it will be provided.
Chris, either open source it (GPL2/BSD) or quit complaining. No one here is willing to help you with a closed source proprietary project.
On 7 Feb 2016, at 15:03, Bryan Fields Bryan@bryanfields.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ On 2/7/16 3:30 AM, G1FEF wrote:
Of course, if you want to offer your time re-write some of the code, or add new functionality then please lets talk, I’ve been asking for help on this for some time now, but apart from Tom who kindly provided (and still provides) the Polish translation, no-one else has done anything. And before anyone goes on about “open source” again, the code IS open source to the amateur radio community, just not the general public as it doesn’t need to be, if you want access to the code repository you only need to ask and it will be provided.
Chris, either open source it (GPL2/BSD) or quit complaining. No one here is willing to help you with a closed source proprietary project.
Bryan, I’m not complaining, I was just replying to Rob’s complaint. I’m quite happy with the way it is. As I said, it is completely open to the amateur radio community, just not the general public as it doesn’t need to be. I’m perfectly happy to continue to bug fix and develop the code as a background project, but if you, or others, want things doing differently or quicker then you are very welcome to contribute to the project.
Regards, Chris
On 7 Feb 2016, at 15:03, Bryan Fields Bryan@bryanfields.net wrote:
Chris, either open source it (GPL2/BSD) or quit complaining. No one here is willing to help you with a closed source proprietary project.
That is untrue. I'm willing but I'd have to learn a new language to do so, and my current allotment of spare time doesn't seem to allow that right now.
If it were written in one of the languages I'm competent in, I'd already be making a few small changes. - Brian
Chris,
Thanks for all your efforts, especially your patience and tolerance!
I'd volunteer to help but my PHP skills are minimal.
I hoping my work with Brian will help get the DNS portion of the portal on line soon.
Regards,
-Neil
On Sun, Feb 7, 2016 at 10:13 AM, G1FEF chris@g1fef.co.uk wrote:
(Please trim inclusions from previous messages) _______________________________________________
On 7 Feb 2016, at 15:03, Bryan Fields Bryan@bryanfields.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ On 2/7/16 3:30 AM, G1FEF wrote:
Of course, if you want to offer your time re-write some of the code, or
add
new functionality then please lets talk, I’ve been asking for help on
this
for some time now, but apart from Tom who kindly provided (and still provides) the Polish translation, no-one else has done anything. And
before
anyone goes on about “open source” again, the code IS open source to the amateur radio community, just not the general public as it doesn’t need
to
be, if you want access to the code repository you only need to ask and
it
will be provided.
Chris, either open source it (GPL2/BSD) or quit complaining. No one
here is
willing to help you with a closed source proprietary project.
Bryan, I’m not complaining, I was just replying to Rob’s complaint. I’m quite happy with the way it is. As I said, it is completely open to the amateur radio community, just not the general public as it doesn’t need to be. I’m perfectly happy to continue to bug fix and develop the code as a background project, but if you, or others, want things doing differently or quicker then you are very welcome to contribute to the project.
Regards, Chris
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On 2/7/16 11:13 AM, G1FEF wrote:
Bryan, I’m not complaining, I was just replying to Rob’s complaint. I’m quite happy with the way it is. As I said, it is completely open to the amateur radio community, just not the general public as it doesn’t need to be. I’m perfectly happy to continue to bug fix and develop the code as a background project, but if you, or others, want things doing differently or quicker then you are very welcome to contribute to the project.
Chris,
The issue is most are unwilling to contribute to a proprietary project. I know others have brought this up before saying they would contribute if it was open source. An example: Tom Hayward, KD7LXL said on Jan 13, 2016 "If the portal is open sourced, expect a patch from me within the first week."
You don't get to say it's open source and freely available just to hams; that's doublespeak. It is de facto closed proprietary software no matter how you want to spin it. https://opensource.org/osd
The bigger issue is 44net relying on a piece of software without a defined license. You could stop development of it and that would be the end of it. There is no legal way we'd be able to use your code and continue to develop it going forward.
I've seen this happen with countless other amateur radio developed projects, and don't want to see it happen once again. I understand wanting to retain control of this, but the only way it's going to grow. You're the founder and the architect, that's not going to change.
If you wish to see unprecedented development of the portal happen, you must open source it.
On Sun, 7 Feb 2016 13:00:26 -0500, Bryan Fields Bryan@bryanfields.net wrote:
The bigger issue is 44net relying on a piece of software without a defined license. You could stop development of it and that would be the end of it. There is no legal way we'd be able to use your code and continue to develop it going forward.
I've seen this happen with countless other amateur radio developed projects, and don't want to see it happen once again. I understand wanting to retain control of this, but the only way it's going to grow. You're the founder and the architect, that's not going to change.
Well, in contrast, I've seen plenty of dead FOSS projects on the net. One only has to browse Sourceforge to find a dozen dead projects with zero contributions because the lead developer walked away. I'm not even sure there's a method for getting write access to them in those cases unless one copies the repo and starts a new one.
Personally, I've found projects that needed work, fixed some bugs or added features and tried to contact the owners of the project to submit a change and never heard back.
Look at GoogleCode for FOSS repositories that are simply frozen in time to no purpose. Sourceforge could go dark tomorrow and we'd lose a vast amount of code.
However, if the project has a proper open source licence you (or anyone else) has the opportunity to fork the project and continue on. If you're not willing to go to the effort - that's your choice.
Without such a licence, the originator can claim copyright if you attempt to fork their code, even if you have the source.
I once had a manager - when he started at the place that I worked (several years before I joined), someone came up to him and said:
"I'm indispensable, you can't run this organisation without me."
He was immediately fired. My manager's take - no one can be indispensable. If they are, get rid of them and clean up the mess, it's less trouble than being held hostage.
Is it time for us to start over?
- Richard, VE7CVS
On 2/7/16 6:45 PM, Geoff Joy -KE6QH- wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Sun, 7 Feb 2016 13:00:26 -0500, Bryan Fields Bryan@bryanfields.net wrote:
The bigger issue is 44net relying on a piece of software without a defined license. You could stop development of it and that would be the end of it. There is no legal way we'd be able to use your code and continue to develop it going forward.
I've seen this happen with countless other amateur radio developed projects, and don't want to see it happen once again. I understand wanting to retain control of this, but the only way it's going to grow. You're the founder and the architect, that's not going to change.
Well, in contrast, I've seen plenty of dead FOSS projects on the net. One only has to browse Sourceforge to find a dozen dead projects with zero contributions because the lead developer walked away. I'm not even sure there's a method for getting write access to them in those cases unless one copies the repo and starts a new one.
Personally, I've found projects that needed work, fixed some bugs or added features and tried to contact the owners of the project to submit a change and never heard back.
Look at GoogleCode for FOSS repositories that are simply frozen in time to no purpose. Sourceforge could go dark tomorrow and we'd lose a vast amount of code.
Greetings,
On Sun, 7 Feb 2016, Bryan Fields wrote:
(Please trim inclusions from previous messages) _______________________________________________ On 2/7/16 3:30 AM, G1FEF wrote:
Of course, if you want to offer your time re-write some of the code, or add new functionality then please lets talk, I’ve been asking for help on this for some time now, but apart from Tom who kindly provided (and still provides) the Polish translation, no-one else has done anything. And before anyone goes on about “open source” again, the code IS open source to the amateur radio community, just not the general public as it doesn’t need to be, if you want access to the code repository you only need to ask and it will be provided.
Chris, either open source it (GPL2/BSD) or quit complaining. No one here is willing to help you with a closed source proprietary project.
Agreed.
--- Jay WB8TKL
() ascii ribbon campaign in /\ support of plain text e-mail
o Averaging at least 3 days of MTBWTF!?!?!? o The solution for long term Internet growth is IPv6.
I’ve been asking for help on this for some time now, but apart from Tom who kindly provided (and still provides) the Polish translation, no-one else has done anything. -------------------------------------------- Im willing to translate to hebrew what ever you want just tell me What english text to translate
Ronen - 4Z4ZQ http://www.ronen.org
________________________________________
On Sun, Feb 07, 2016 at 08:16:51AM +0100, Rob Janssen wrote:
I cannot remove a subnet that was erroneously added in the past (and where user subnets where added inside) without deleting those [...]
Rob, if you'll tell me which subnet that has "children" should be removed and which of those "children" should be kept, I'll make a note of the "children", delete them, delete the erroneous subnet, and add the "children" back in. Annoying, but it should take only a few minutes, less time and more productive than arguing about it on the mailing list. - Brian
On Sun, Feb 07, 2016 at 08:16:51AM +0100, Rob Janssen wrote:
Is it really a good idea to base the cleanup on data in the portal?
What would you have me do? It's clear that the majority of the entries in the DNS are bogus. We have NOTHING to reference except the portal data. Doesn't it make sense to try to get that data in order? - Brian
On 2/7/16 8:11 AM, Brian Kantor wrote:
On Sun, Feb 07, 2016 at 08:16:51AM +0100, Rob Janssen wrote:
Is it really a good idea to base the cleanup on data in the portal?
What would you have me do? It's clear that the majority of the entries in the DNS are bogus. We have NOTHING to reference except the portal data. Doesn't it make sense to try to get that data in order?
- Brian
This is like throwing out the baby with the bath water. If the data can't be shown to be good, it also can't be shown to be bad. (I deal with data quality issues as part of my professional life.)
Requiring everyone to justify the existing data is not a practical solution, you are guaranteed to make a lot of people mad, and you will have a lot of cleanup work to do to get data reinstated - and most of it will happen soon after the deletions, so your workload will skyrocket.
Instead of deleting anything that you can't identify, how about marking it as 'unknown', and making it easy for users to claim later?
No, this doesn't get you instant cleanup. But with the help of the coordinators (who could be given virtual ownership of the ranges that they manage) it could get cleaned up over time, and any new entries would be assigned with owners (and even that data is going to become less trustworthy with age).
It's not like we've run out of 44.x space, is it?
- Richard, VE7CVS
Gentlemans (and maybe also Ladies) I dont see any big problem in adding latter the "missing" records in case they have gone I lost with this procedure 103 records that "might" be needed to be add again as soon as i will get back the network i used to have and start to operate back the gateway for them There is a backup of the old Zone files , i have a backup of my records (Brian with his kindness sent me a copy of my country records) the only problem i fear is that i will not be able to update the DNS via the portal (permission privileges etc) a thing i can do now with the DNS robot 73;s Ronen - 4Z4ZQ http://www.ronen.org
________________________________________ From: 44Net 44net-bounces+ronenp=hotmail.com@hamradio.ucsd.edu on behalf of Richard Chycoski ve7cvs@chycoski.com Sent: Sunday, February 7, 2016 8:50 AM To: 44net@hamradio.ucsd.edu Subject: Re: [44net] DNS cleanup
(Please trim inclusions from previous messages) _______________________________________________ On 2/7/16 8:11 AM, Brian Kantor wrote:
On Sun, Feb 07, 2016 at 08:16:51AM +0100, Rob Janssen wrote:
Is it really a good idea to base the cleanup on data in the portal?
What would you have me do? It's clear that the majority of the entries in the DNS are bogus. We have NOTHING to reference except the portal data. Doesn't it make sense to try to get that data in order? - Brian
This is like throwing out the baby with the bath water. If the data can't be shown to be good, it also can't be shown to be bad. (I deal with data quality issues as part of my professional life.)
Requiring everyone to justify the existing data is not a practical solution, you are guaranteed to make a lot of people mad, and you will have a lot of cleanup work to do to get data reinstated - and most of it will happen soon after the deletions, so your workload will skyrocket.
Instead of deleting anything that you can't identify, how about marking it as 'unknown', and making it easy for users to claim later?
No, this doesn't get you instant cleanup. But with the help of the coordinators (who could be given virtual ownership of the ranges that they manage) it could get cleaned up over time, and any new entries would be assigned with owners (and even that data is going to become less trustworthy with age).
It's not like we've run out of 44.x space, is it?
- Richard, VE7CVS _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On Sun, Feb 07, 2016 at 08:50:55AM -0800, Richard Chycoski wrote:
Instead of deleting anything that you can't identify, how about marking it as 'unknown', and making it easy for users to claim later?
That was going to be a subsequent phase of the project. At the moment, there is no way to "mark" the data at all - it either exists or it doesn't. What we were considering doing is importing the DNS entries into the portal, then requiring that each be claimed by someone within some period of time - perhaps a year or two. After that, unclaimed entries would be deleted.
The existing DNS entries have an ownership field, based on who entered them into the DNS database. That was added a few years ago, so there are a lot of entries with null ownership. Unfortunately, there are older entries which are still valid but have null ownership because they were added to the database before it had an ownership attribute.
This brings up the question of who is to be the owner of a DNS entry. Should it be the individual or group who asked for it to be added to the DNS or should it be the coordinator who entered it? The former would mean that hundreds of people would have to register with the portal and take ownership of each of their entries. The latter would mean that it would be up to the coordinators to keep track of who is still active (or still alive!) and delete entries for people who are no longer around. Neither is a satisfactory solution.
The goal is to have a tidy DNS database, with only entries that are valid as is possible. I am open to suggestions. - Brian
On 2/7/16 12:18 PM, Brian Kantor wrote:
This brings up the question of who is to be the owner of a DNS entry. Should it be the individual or group who asked for it to be added to the DNS or should it be the coordinator who entered it? The former would mean that hundreds of people would have to register with the portal and take ownership of each of their entries. The latter would mean that it would be up to the coordinators to keep track of who is still active (or still alive!) and delete entries for people who are no longer around. Neither is a satisfactory solution.
In my mind the only logical way to do it is to have the person that requests the DNS entry own it. Yes, they have to have an account and login once a year or whatever to say "yes I still need this".
It's not a bad solution, and once we have it setup it works well moving forward. It does mean the incumbent users need to do just a bit of effort to register, but really we're making this out to be much harder than it is.
Making the coordinator responsible for checking the validity of the data is not a scalable solution, as this is really easy to automate. I look at the coordinator as more a local help desk that can fix things when they break and issue IP allocations. They should not need to devote time to check out what's still good and not.
IP allocations are rather easy to validate (especially with the amount of users most regions have!), DNS not so much.
The goal is to have a tidy DNS database, with only entries that are valid as is possible. I am open to suggestions.
We need to have a three options, valid data, no data, and maybe it's good. The coordinator or who ever could then tag an entry as "maybe" and the system would send out an email to the admin for that item and they would have to validate it within 60 days or it's scheduled for deletion.
Thoughts?
I think that if a mechanism that lest say make ping daily to the hosts and keep track say after a year of non connect will be deleted if NO-IP.ORG do it to me every month then for us (the hams) a year is more then inough
As for who treat the DNS records in my country i did treat the routing and DNS for the last 20 years although i wasnt the official coordinator So i suggest that the most active persons in each country will deal with it (will have the permissions to edit records) in addition to the official coordinator although i think that a person that have a knowledge to set up a gateway can and can have the right to add his gateway sub net hosts direct without passing through a coordinator
Maybe a mechanism that check the IP that is going to be added to the DNS is matching the gateway subnet and if the answer is yes then let the gateway owner add the hosts to the DNS after all the subnet belong to him and the host that will be there belong to the subnet that is under his gateway responsibility
Regards Ronen - 4Z4ZQ http://www.ronen.org
________________________________________
On 07.02.2016 18:18, Brian Kantor wrote:
This brings up the question of who is to be the owner of a DNS entry. Should it be the individual or group who asked for it to be added to the DNS or should it be the coordinator who entered it? The former would mean that hundreds of people would have to register with the portal and take ownership of each of their entries. The latter would mean that it would be up to the coordinators to keep track of who is still active (or still alive!) and delete entries for people who are no longer around. Neither is a satisfactory solution.
At least for Germany the latter should be considered as a satisfactory solution. The German IP Coordination Team did a cleanup of the DNS entries associated with the IP Pool from Germany quite a while ago. During this process most individual allocations have been purged.
As of today most allocations are bound to repeater stations rather than to individuals. Repeater stations serve users with dynamic IP addresses. Permanent users can get static IPs and therefore can get a <callsign>.ampr.org DNS entry, however if the repeater will die our system will automatically flush this DNS entry again from the ampr.org domain. I'm pretty sure the DNS information from Germany in the ampr.org domain has a very good quality and is reflecting the real situation, however there is not a single allocation within the Portal for 44.224/15. Therefore we don't like to become this as a requirement. We use the Portal for direct-BGP and IPIP users on 44.130/16.
We submit almost daily a list of changes to the ampr.org domain through the E-Mail Robot and actually hold 20% of all A records. We vote to proceed with the suggested cleanup from Brian which will flush a lot of A-records even without any call sign information (which therefore can't even be tracked down to an individual). The cleanup would make us hold 34% of all records in the ampr.org domain.
73, Jann DG8NGN
[rant] I consider it part of the "job duties" as a coordinator.
I knew that when I took the job that as a coordinator I needed to keep track of "who's got what" assigned to them, and keep my area of responsibility organized.
If coordinators only want to add new stuff, and not clean up stale stuff, maybe they should reconsider the job.
[/rant]
At 09:18 AM 2/7/2016, you wrote:
This brings up the question of who is to be the owner of a DNS entry. Should it be the individual or group who asked for it to be added to the DNS or should it be the coordinator who entered it?
(Please trim inclusions from previous messages) _______________________________________________ Hi, Just let know that I manage 44.151.178.0/24 Currently setting up the router
73
F1SCA - Jean-Marc
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
There is actually nothing wrong with choosing the portal info as reference data.
Let me motivate: Amprgw DNS entries are only relevant for connected subnets. There is no public accessible tunnelled 44 network without having a portal entry. If there is no such entry, the tunnels would not work. BGP announced 44 subnets are well known, and can be easily excepted from the delete process. All other existing dns entries associated with a 44 address, if they exist, will be not be impacted in any way, since they are isolated, and the dns services at amprgw are not used by them.
Marius, YO2LOJ
-----Original Message----- From: Brian Kantor Sent: Sunday, February 07, 2016 18:11 To: AMPRNet working group Subject: Re: [44net] DNS cleanup
(Please trim inclusions from previous messages) _______________________________________________ On Sun, Feb 07, 2016 at 08:16:51AM +0100, Rob Janssen wrote:
Is it really a good idea to base the cleanup on data in the portal?
What would you have me do? It's clear that the majority of the entries in the DNS are bogus. We have NOTHING to reference except the portal data. Doesn't it make sense to try to get that data in order? - Brian _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Hello Marius,
Let me motivate: Amprgw DNS entries are only relevant for connected subnets. There is no public accessible tunnelled 44 network without having a portal entry. If there is no such entry, the tunnels would not work. BGP announced 44 subnets are well known, and can be easily excepted from the delete process. All other existing dns entries associated with a 44 address, if they exist, will be not be impacted in any way, since they are isolated, and the dns services at amprgw are not used by them.
My speicific issue here is that my local AMPR coordinator recently told me that unless all my IP addresses had a DNS entry, I risked loosing my allocations. I think this is a policy that *he* is setting himself (not a global AMPR policy) and though I don't agree with his view, I obliged to give him ~1024 hostnames to fill things out. If other AMPR coordinators have similar approaches, then DNS entries mean everything to the IP allocation be it a subnet or a /32.
--David KI6ZHD
On 7.2.2016. 19:56, David Ranch wrote:
My speicific issue here is that my local AMPR coordinator recently told me that unless all my IP addresses had a DNS entry, I risked loosing my allocations. I think this is a policy that *he* is setting himself (not a global AMPR policy) and though I don't agree with his view, I obliged to give him ~1024 hostnames to fill things out.
This requirement was strange to me from the first time I learned about 44net.
I leased public IP ranges few times for commercial purpose and was never asked to provide reverse DNS for them. It was done automatically by ISP. I had to deal with that only if I wanted reverse DNS customized.
Pedja YT9TP
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Sun, Feb 07, 2016 at 10:56:41AM -0800, David Ranch wrote:
My speicific issue here is that my local AMPR coordinator recently told me that unless all my IP addresses had a DNS entry, I risked loosing my allocations. I think this is a policy that *he* is setting himself (not a global AMPR policy) and though I don't agree with his view, I obliged to give him ~1024 hostnames to fill things out. If other AMPR coordinators have similar approaches, then DNS entries mean everything to the IP allocation be it a subnet or a /32.
This seems strange to me. It certainly isn't a policy that I made. - Brian
Hi Marius, Can I just check something:
All other existing dns entries associated with a 44 address, if they
exist, will be not be impacted in any way, since they are isolated, and the dns services at amprgw are not used by them.
I thought that it was the worldwide 'ampr.org' DNS that was being cleaned up. Have I got this wrong? Will the addresses of isolated users still resolve in worldwide DNS post-purge?
Thanks,
Gareth, G4HIP
Why does an hostname of an isolated system need to be resolved in a world wide DNS? It has no connection to the internet via the gw or to the tunnelling system, so that DNS resolution will allways lead to an unreachable host. I think it is better to get a 'hostname not found' than in unreachable IP.
But for those in need of such things, registering the subnet at the portal shouldn't be to hard to do. Just set its type to 'radio' and it will be there (and prevent the associated host names to be deleted).
Marius, YO2LOJ
-----Original Message----- From: Gareth Rowlands Sent: Sunday, February 07, 2016 21:42 To: 'AMPRNet working group' Subject: Re: [44net] DNS cleanup
(Please trim inclusions from previous messages) _______________________________________________ Hi Marius, Can I just check something:
All other existing dns entries associated with a 44 address, if they
exist, will be not be impacted in any way, since they are isolated, and the dns services at amprgw are not used by them.
I thought that it was the worldwide 'ampr.org' DNS that was being cleaned up. Have I got this wrong? Will the addresses of isolated users still resolve in worldwide DNS post-purge?
Thanks,
Gareth, G4HIP
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
-
Brian Kantor -
Bryan Fields -
David Ranch -
G1FEF -
Gareth Rowlands -
Geoff Joy -KE6QH- -
Jann Traschewski -
Jay Nugent -
Jean-Marc Magnier -
Marius Petrescu -
Neil Johnson -
Pedja YT9TP -
R P -
Richard Chycoski -
Rob Janssen -
William Lewis