I did: =>dig -x 44.24.240.173 @a.ns.hamwan.net. ; <<>> DiG 9.2.4 <<>> -x 44.24.240.173 @a.ns.hamwan.net. ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55622 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;173.240.24.44.in-addr.arpa. IN PTR ;; ANSWER SECTION: *173.240.24.44.in-addr.arpa. 3600 IN PTR ae7q.hamwan.net.* ;; Query time: 147 msec ;; SERVER: 44.24.244.2#53(44.24.244.2) ;; WHEN: Thu May 15 20:44:05 2014 ;; MSG SIZE rcvd: 73 =>dig ae7q.hamwan.net. @a.ns.hamwan.net. ; <<>> DiG 9.2.4 <<>> ae7q.hamwan.net. @a.ns.hamwan.net. ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46180 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;ae7q.hamwan.net. IN A ;; AUTHORITY SECTION: *ae7q.hamwan.net. 3600 IN NS ns1.ae7q.ampr.org.* ;; Query time: 101 msec ;; SERVER: 44.24.244.2#53(44.24.244.2) ;; WHEN: Thu May 15 20:45:39 2014 ;; MSG SIZE rcvd: 64 =>dig ns1.ae7q.ampr.org. @ampr.org. ; <<>> DiG 9.2.4 <<>> ns1.ae7q.ampr.org. @ampr.org. ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27978 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 1 ;; QUESTION SECTION: ;ns1.ae7q.ampr.org. IN A ;; ANSWER SECTION: *ns1.ae7q.ampr.org. 3600 IN A 44.24.240.173* ;; AUTHORITY SECTION: ampr.org. 3600 IN NS ampr-dns.in-berlin.de. ampr.org. 3600 IN NS ampr.org. ampr.org. 3600 IN NS munnari.OZ.AU. ampr.org. 3600 IN NS ns1.defaultroute.net. ampr.org. 3600 IN NS ns2.threshinc.com. ampr.org. 3600 IN NS ns0.comgw.net. ampr.org. 3600 IN NS hamradio.ucsd.edu. ;; ADDITIONAL SECTION: ampr.org. 3600 IN A 44.0.0.1 ;; Query time: 157 msec ;; SERVER: 44.0.0.1#53(44.0.0.1) ;; WHEN: Thu May 15 20:47:46 2014 ;; MSG SIZE rcvd: 263 Now, this is not correct. While I appreciate the PTR record for 44.24.240.173, it needs to point to a *hostname* record ("A" or CNAME"), not a *domainname* record. This is not the fault of the PTR record, but the record that it points to: The NS record for ae7q.hamwan.net effectively declares ae7q.hamwan.net as a *subdomain*, with ns1.ae7q.ampr.org as its*nameserver*. Now, ns1.ae7q.ampr.org has the IP address of 44.24.240.173, but that doesn't mean that the domain ae7q.hamwan.net is anywhere near 44.24.240.x. The correct solution to this problem is to replace the NS record for ae7q.hamwan.net with a reference to a host; eg: 1. ae7q.hamwan.net. 3600 IN A 44.24.240.173 2. ae7q.hamwan.net. 3600 IN CNAME ns1.ae7q.ampr.org. The administrative advantage of the CNAME is that if my IP address changes, you don''t have to change the forward record (you'll still have to update PTR records). The administrative disadvantage is that the CNAME is dependent upon a different administrative organization. However, neither solution above allows for ae7q.hamwan.net to be a subdomain. If you want to allow ae7q.hamwan.net to be a subdomain, you need to lay the following foundation: 173.240.24.44.in-addr.arpa. 3600 IN PTR ns1.ae7q.hamwan.net. ; (or ns1.ae7q.ampr.org.) ae7q.hamwan.net. 3600 IN NS ns1.ae7q.hamwan.net. ; (or ns1.ae7q.ampr.org.) ns1.ae7q.hamwan.net. 3600 IN A 44.24.240.173 ; (if ns1.ae7q.ampr.org. is not used) That by itself will not allow *me* to add subdomain records, but it lays the foundation. I prefer creating ns1.ae7q.hamwan.net (all three records above), as it keeps the records independent of a different administrative organization. If you want to get carried away, you could also add the following record: www.ae7q.hamwan.net. 3600 IN CNAME ns1.ae7q.hamwan.net. ; (or ns1.ae7q.ampr.org.) -- Dean
Hey Dean, How about we just delegate the forward + reverse to your NS and you take care of the rest? IN PTR queries for 173.240.24.44.in-addr.arpa. would just get referrals to your NS. BTW, this looks wrong to me: 1. ae7q.hamwan.net. 3600 IN A 44.24.240.173 2. ae7q.hamwan.net. 3600 IN CNAME ns1.ae7q.ampr.org. It simultaneously declares to a resolver that ae7q.hamwan.net is not the canonical name for the desired record (A, etc), and also offers up an authoritative answer for IN A. Domains with CNAME declared shouldn't have other records (such as the IN A here). Resolvers should chase down the query using the CNAME instead. Note to DNS admins: To delegate forward & reverse to Dean's NS: ae7q.hamwan.net. IN NS ns1.ae7q.hamwan.net. 173.240.24.44.in-addr.arpa. IN NS ns1.ae7q.hamwan.net. ns1.ae7q.hamwan.net. IN A 44.24.240.173 Dassit. --Bart On 5/15/2014 9:49 PM, Dean Gibson AE7Q wrote:
I did:
=>dig -x 44.24.240.173 @a.ns.hamwan.net.
; <<>> DiG 9.2.4 <<>> -x 44.24.240.173 @a.ns.hamwan.net. ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55622 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION: ;173.240.24.44.in-addr.arpa. IN PTR
;; ANSWER SECTION: *173.240.24.44.in-addr.arpa. 3600 IN PTR ae7q.hamwan.net.*
;; Query time: 147 msec ;; SERVER: 44.24.244.2#53(44.24.244.2) ;; WHEN: Thu May 15 20:44:05 2014 ;; MSG SIZE rcvd: 73
=>dig ae7q.hamwan.net. @a.ns.hamwan.net.
; <<>> DiG 9.2.4 <<>> ae7q.hamwan.net. @a.ns.hamwan.net. ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46180 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION: ;ae7q.hamwan.net. IN A
;; AUTHORITY SECTION: *ae7q.hamwan.net. 3600 IN NS ns1.ae7q.ampr.org.*
;; Query time: 101 msec ;; SERVER: 44.24.244.2#53(44.24.244.2) ;; WHEN: Thu May 15 20:45:39 2014 ;; MSG SIZE rcvd: 64
=>dig ns1.ae7q.ampr.org. @ampr.org.
; <<>> DiG 9.2.4 <<>> ns1.ae7q.ampr.org. @ampr.org. ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27978 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 1
;; QUESTION SECTION: ;ns1.ae7q.ampr.org. IN A
;; ANSWER SECTION: *ns1.ae7q.ampr.org. 3600 IN A 44.24.240.173*
;; AUTHORITY SECTION: ampr.org. 3600 IN NS ampr-dns.in-berlin.de. ampr.org. 3600 IN NS ampr.org. ampr.org. 3600 IN NS munnari.OZ.AU. ampr.org. 3600 IN NS ns1.defaultroute.net. ampr.org. 3600 IN NS ns2.threshinc.com. ampr.org. 3600 IN NS ns0.comgw.net. ampr.org. 3600 IN NS hamradio.ucsd.edu.
;; ADDITIONAL SECTION: ampr.org. 3600 IN A 44.0.0.1
;; Query time: 157 msec ;; SERVER: 44.0.0.1#53(44.0.0.1) ;; WHEN: Thu May 15 20:47:46 2014 ;; MSG SIZE rcvd: 263
Now, this is not correct. While I appreciate the PTR record for 44.24.240.173, it needs to point to a *hostname* record ("A" or CNAME"), not a *domainname* record. This is not the fault of the PTR record, but the record that it points to: The NS record for ae7q.hamwan.net effectively declares ae7q.hamwan.net as a *subdomain*, with ns1.ae7q.ampr.org as its*nameserver*. Now, ns1.ae7q.ampr.org has the IP address of 44.24.240.173, but that doesn't mean that the domain ae7q.hamwan.net is anywhere near 44.24.240.x.
The correct solution to this problem is to replace the NS record for ae7q.hamwan.net with a reference to a host; eg:
1. ae7q.hamwan.net. 3600 IN A 44.24.240.173 2. ae7q.hamwan.net. 3600 IN CNAME ns1.ae7q.ampr.org.
The administrative advantage of the CNAME is that if my IP address changes, you don''t have to change the forward record (you'll still have to update PTR records). The administrative disadvantage is that the CNAME is dependent upon a different administrative organization. However, neither solution above allows for ae7q.hamwan.net to be a subdomain.
If you want to allow ae7q.hamwan.net to be a subdomain, you need to lay the following foundation:
173.240.24.44.in-addr.arpa. 3600 IN PTR ns1.ae7q.hamwan.net. ; (or ns1.ae7q.ampr.org.) ae7q.hamwan.net. 3600 IN NS ns1.ae7q.hamwan.net. ; (or ns1.ae7q.ampr.org.) ns1.ae7q.hamwan.net. 3600 IN A 44.24.240.173 ; (if ns1.ae7q.ampr.org. is not used)
That by itself will not allow *me* to add subdomain records, but it lays the foundation. I prefer creating ns1.ae7q.hamwan.net (all three records above), as it keeps the records independent of a different administrative organization.
If you want to get carried away, you could also add the following record:
www.ae7q.hamwan.net. 3600 IN CNAME ns1.ae7q.hamwan.net. ; (or ns1.ae7q.ampr.org.)
-- Dean
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
You are correct; #1 and #2 *together* are wrong. I did not make it clear in my previous message, that the two were mutually exclusive choices (for the case being discussed). Your "note to DNS admins" is indeed what I want. Thanks, Dean On 2014-05-15 22:02, Bart Kus wrote:
Hey Dean,
How about we just delegate the forward + reverse to your NS and you take care of the rest? IN PTR queries for 173.240.24.44.in-addr.arpa. would just get referrals to your NS.
BTW, this looks wrong to me:
1. ae7q.hamwan.net. 3600 IN A 44.24.240.173 2. ae7q.hamwan.net. 3600 IN CNAME ns1.ae7q.ampr.org.
It simultaneously declares to a resolver that ae7q.hamwan.net is not the canonical name for the desired record (A, etc), and also offers up an authoritative answer for IN A. Domains with CNAME declared shouldn't have other records (such as the IN A here). Resolvers should chase down the query using the CNAME instead.
Note to DNS admins:
To delegate forward & reverse to Dean's NS:
ae7q.hamwan.net. IN NS ns1.ae7q.hamwan.net. 173.240.24.44.in-addr.arpa. IN NS ns1.ae7q.hamwan.net. ns1.ae7q.hamwan.net. IN A 44.24.240.173
Dassit.
--Bart
On 5/15/2014 9:49 PM, Dean Gibson AE7Q wrote:
I did:
=>dig -x 44.24.240.173 @a.ns.hamwan.net.
; <<>> DiG 9.2.4 <<>> -x 44.24.240.173 @a.ns.hamwan.net. ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55622 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION: ;173.240.24.44.in-addr.arpa. IN PTR
;; ANSWER SECTION: *173.240.24.44.in-addr.arpa. 3600 IN PTR ae7q.hamwan.net.*
;; Query time: 147 msec ;; SERVER: 44.24.244.2#53(44.24.244.2) ;; WHEN: Thu May 15 20:44:05 2014 ;; MSG SIZE rcvd: 73
=>dig ae7q.hamwan.net. @a.ns.hamwan.net.
; <<>> DiG 9.2.4 <<>> ae7q.hamwan.net. @a.ns.hamwan.net. ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46180 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION: ;ae7q.hamwan.net. IN A
;; AUTHORITY SECTION: *ae7q.hamwan.net. 3600 IN NS ns1.ae7q.ampr.org.*
;; Query time: 101 msec ;; SERVER: 44.24.244.2#53(44.24.244.2) ;; WHEN: Thu May 15 20:45:39 2014 ;; MSG SIZE rcvd: 64
=>dig ns1.ae7q.ampr.org. @ampr.org.
; <<>> DiG 9.2.4 <<>> ns1.ae7q.ampr.org. @ampr.org. ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27978 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 1
;; QUESTION SECTION: ;ns1.ae7q.ampr.org. IN A
;; ANSWER SECTION: *ns1.ae7q.ampr.org. 3600 IN A 44.24.240.173*
;; AUTHORITY SECTION: ampr.org. 3600 IN NS ampr-dns.in-berlin.de. ampr.org. 3600 IN NS ampr.org. ampr.org. 3600 IN NS munnari.OZ.AU. ampr.org. 3600 IN NS ns1.defaultroute.net. ampr.org. 3600 IN NS ns2.threshinc.com. ampr.org. 3600 IN NS ns0.comgw.net. ampr.org. 3600 IN NS hamradio.ucsd.edu.
;; ADDITIONAL SECTION: ampr.org. 3600 IN A 44.0.0.1
;; Query time: 157 msec ;; SERVER: 44.0.0.1#53(44.0.0.1) ;; WHEN: Thu May 15 20:47:46 2014 ;; MSG SIZE rcvd: 263
Now, this is not correct. While I appreciate the PTR record for 44.24.240.173, it needs to point to a *hostname* record ("A" or CNAME"), not a *domainname* record. This is not the fault of the PTR record, but the record that it points to: The NS record for ae7q.hamwan.net effectively declares ae7q.hamwan.net as a *subdomain*, with ns1.ae7q.ampr.org as its*nameserver*. Now, ns1.ae7q.ampr.org has the IP address of 44.24.240.173, but that doesn't mean that the domain ae7q.hamwan.net is anywhere near 44.24.240.x.
The correct solution to this problem is to replace the NS record for ae7q.hamwan.net with a reference to a host; eg:
1. ae7q.hamwan.net. 3600 IN A 44.24.240.173 2. ae7q.hamwan.net. 3600 IN CNAME ns1.ae7q.ampr.org.
The administrative advantage of the CNAME is that if my IP address changes, you don''t have to change the forward record (you'll still have to update PTR records). The administrative disadvantage is that the CNAME is dependent upon a different administrative organization. However, neither solution above allows for ae7q.hamwan.net to be a subdomain.
If you want to allow ae7q.hamwan.net to be a subdomain, you need to lay the following foundation:
173.240.24.44.in-addr.arpa. 3600 IN PTR ns1.ae7q.hamwan.net. ; (or ns1.ae7q.ampr.org.) ae7q.hamwan.net. 3600 IN NS ns1.ae7q.hamwan.net. ; (or ns1.ae7q.ampr.org.) ns1.ae7q.hamwan.net. 3600 IN A 44.24.240.173 ; (if ns1.ae7q.ampr.org. is not used)
That by itself will not allow *me* to add subdomain records, but it lays the foundation. I prefer creating ns1.ae7q.hamwan.net (all three records above), as it keeps the records independent of a different administrative organization.
If you want to get carried away, you could also add the following record:
www.ae7q.hamwan.net. 3600 IN CNAME ns1.ae7q.hamwan.net. ; (or ns1.ae7q.ampr.org.)
-- Dean
On Thu, May 15, 2014 at 9:49 PM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:
Now, this is not correct. While I appreciate the PTR record for 44.24.240.173, it needs to point to a hostname record ("A" or CNAME"), not a domainname record. This is not the fault of the PTR record, but the record that it points to: The NS record for ae7q.hamwan.net effectively declares ae7q.hamwan.net as a subdomain, with ns1.ae7q.ampr.org as its nameserver. Now, ns1.ae7q.ampr.org has the IP address of 44.24.240.173, but that doesn't mean that the domain ae7q.hamwan.net is anywhere near 44.24.240.x.
Dean, The reason there is an NS record at ae7q.hamwan.net is because I needed to test user NS records while working on the portal UI. On April 10 you talked about running your own DNS server, and complained that ampr.org did not allow NS records. Not wanting HamWAN to be accused of the same thing, I made sure you could create NS records yourself from the portal. Use your Logbook of the World certificate to log in here: http://portal.hamwan.org/dns/ It will allow you to create, edit, and delete any DNS record within the {LoTW callsign}.hamwan.net domain (e.g., AE7Q.hamwan.net). You can manipulate the records as you see fit. Tom KD7LXL
Thanks! OK, now I need to "reinstate" my LoTW cert (actually, apply for a new one) ... On 2014-05-15 23:32, Tom Hayward wrote:
On Thu, May 15, 2014 at 9:49 PM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:
Now, this is not correct. While I appreciate the PTR record for 44.24.240.173, it needs to point to a hostname record ("A" or CNAME"), not a domainname record. This is not the fault of the PTR record, but the record that it points to: The NS record for ae7q.hamwan.net effectively declares ae7q.hamwan.net as a subdomain, with ns1.ae7q.ampr.org as its nameserver. Now, ns1.ae7q.ampr.org has the IP address of 44.24.240.173, but that doesn't mean that the domain ae7q.hamwan.net is anywhere near 44.24.240.x. Dean,
The reason there is an NS record at ae7q.hamwan.net is because I needed to test user NS records while working on the portal UI. On April 10 you talked about running your own DNS server, and complained that ampr.org did not allow NS records. Not wanting HamWAN to be accused of the same thing, I made sure you could create NS records yourself from the portal.
Use your Logbook of the World certificate to log in here: http://portal.hamwan.org/dns/
It will allow you to create, edit, and delete any DNS record within the {LoTW callsign}.hamwan.net domain (e.g., AE7Q.hamwan.net). You can manipulate the records as you see fit.
Tom KD7LXL
On Fri, May 16, 2014 at 12:21 AM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:
Thanks!
OK, now I need to "reinstate" my LoTW cert (actually, apply for a new one)
If you still have the username/password or email address (to receive a password reset), getting a new one signed is really fast. The slow part of the process is receiving the postcard in the mail, which you shouldn't have to do again. We'll eventually support our own HamWAN certificate authority. ARRL was the first popular certificate authority to embed callsigns in the certificates. They put the callsign under "1.3.6.1.4.1.12348.1.1". We plan to release some instructions for generating a certificate and certificate signing request with your callsign embedded at that location. Then we'll sign certificates after verifying your license. It's very convenient that the ARRL already does this for us, for free. Tom KD7LXL
On 2014-05-16 08:22, Tom Hayward wrote:
On Fri, May 16, 2014 at 12:21 AM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:
Thanks!
OK, now I need to "reinstate" my LoTW cert (actually, apply for a new one) If you still have the username/password or email address (to receive a password reset), getting a new one signed is really fast. The slow part of the process is receiving the postcard in the mail, which you shouldn't have to do again.
We'll eventually support our own HamWAN certificate authority. ARRL was the first popular certificate authority to embed callsigns in the certificates. They put the callsign under "1.3.6.1.4.1.12348.1.1". We plan to release some instructions for generating a certificate and certificate signing request with your callsign embedded at that location. Then we'll sign certificates after verifying your license. It's very convenient that the ARRL already does this for us, for free.
Tom KD7LXL
1. My last certificate was from 2009, and when I tried to login to the LoTW site with my name/password, it didn't know me. 2. The ARRL/LoTW sites gave no hint (that I could find) as to how to renew an expired certificate, so I downloaded the current version of the LoTW software, installed it, and attempted to load my most recent (expired) certificate. 3. The LoTW program said /"Na-ne, na-ne, na-ne, you can only load this certificate on the computer it was created on."/ 4. The ARRL site described how to "backup" a certificate on the original computer, so that you could move it to a new computer. 5. Fortunately, I keep old Windows computers around for (ha-ha) sentimental reasons, so I fired up what I thought was the originating computer. Success! The old LoTW software was there, and when I fired it up, it found the certificate, only to say, /"Na-ne, na-ne, na-ne, this certificate is expired, and we certainly won't load it for you."/ 6. So, I installed the *new* LoTW software on the *old* computer, and presto, there was the "backup" option. Furthermore, the new LoTW software even deigned to load the expired certificate, so I backed it up pronto. Further, the "renew" option was no longer grayed out. This looked suspiciously promising. 7. So, I "restored" the backup file on my regular Windows computer, and clicked on "renew" in the LoTW software. I only had to erase the QSL end date and change my eMail address, and I successfully submitted the renewal request. The LoTW software gave no indication as to whether I will need to await a postcard, so we shall see ...
On Sat, May 17, 2014 at 1:26 AM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:
My last certificate was from 2009, and when I tried to login to the LoTW site with my name/password, it didn't know me.
2009, that's not long at all! Last year I got a new certificate. My original, expired certificate was issued in 2003. I thought all I did was generate the new certificate, then login and download the TQ6 file from their website. Reading the instructions again has me doubting that. I may have needed my original postcard, which I still have filed away, to login to the website. Tom KD7LXL
On 2014-05-17 08:25, Tom Hayward wrote:
On Sat, May 17, 2014 at 1:26 AM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:
My last certificate was from 2009, and when I tried to login to the LoTW site with my name/password, it didn't know me. 2009, that's not long at all! Last year I got a new certificate. My original, expired certificate was issued in 2003.
I thought all I did was generate the new certificate, then login and download the TQ6 file from their website. Reading the instructions again has me doubting that. I may have needed my original postcard, which I still have filed away, to login to the website.
Tom KD7LXL
That may have been (and still be) true. This morning I received the certificate file via eMail (one business-day turn-around), and the password they had of record was not what I had recorded, so what you suggest above might have worked.
This requires a specific (and non-current) version of a specific browser (eg, Opera) ?!?!?!? On 2014-05-15 23:32, Tom Hayward wrote:
On Thu, May 15, 2014 at 9:49 PM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:
Now, this is not correct. While I appreciate the PTR record for 44.24.240.173, it needs to point to a hostname record ("A" or CNAME"), not a domainname record. This is not the fault of the PTR record, but the record that it points to: The NS record for ae7q.hamwan.net effectively declares ae7q.hamwan.net as a subdomain, with ns1.ae7q.ampr.org as its nameserver. Now, ns1.ae7q.ampr.org has the IP address of 44.24.240.173, but that doesn't mean that the domain ae7q.hamwan.net is anywhere near 44.24.240.x. Dean,
The reason there is an NS record at ae7q.hamwan.net is because I needed to test user NS records while working on the portal UI. On April 10 you talked about running your own DNS server, and complained that ampr.org did not allow NS records. Not wanting HamWAN to be accused of the same thing, I made sure you could create NS records yourself from the portal.
Use your Logbook of the World certificate to log in here: http://portal.hamwan.org/dns/
It will allow you to create, edit, and delete any DNS record within the {LoTW callsign}.hamwan.net domain (e.g., AE7Q.hamwan.net). You can manipulate the records as you see fit.
Tom KD7LXL
Dean, Using that specific version of Opera is only if you want to visit the authenticated portal site over the RF network. It's the only browser that we could get to work with unencrypted SSL mutual certificate authentication. Nobody else on the internet seems to do that, so there's not a lot of support for it. If you're using your commercial internet connection instead, you don't have to worry about that and you can use just about any browser if you have your LotW certificate setup in it. -Cory NQ1E On Jun 8, 2014 5:24 PM, "Dean Gibson AE7Q" <hamwan@ae7q.com> wrote:
This requires a specific (and non-current) version of a specific browser (eg, Opera) ?!?!?!?
On 2014-05-15 23:32, Tom Hayward wrote:
On Thu, May 15, 2014 at 9:49 PM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:
Now, this is not correct. While I appreciate the PTR record for 44.24.240.173, it needs to point to a hostname record ("A" or CNAME"), not a domainname record. This is not the fault of the PTR record, but the record that it points to: The NS record for ae7q.hamwan.net effectively declares ae7q.hamwan.net as a subdomain, with ns1.ae7q.ampr.org as its nameserver. Now, ns1.ae7q.ampr.org has the IP address of 44.24.240.173, but that doesn't mean that the domain ae7q.hamwan.net is anywhere near 44.24.240.x.
Dean,
The reason there is an NS record at ae7q.hamwan.net is because I needed to test user NS records while working on the portal UI. On April 10 you talked about running your own DNS server, and complained that ampr.org did not allow NS records. Not wanting HamWAN to be accused of the same thing, I made sure you could create NS records yourself from the portal.
Use your Logbook of the World certificate to log in here: http://portal.hamwan.org/dns/
It will allow you to create, edit, and delete any DNS record within the {LoTW callsign}.hamwan.net domain (e.g., AE7Q.hamwan.net). You can manipulate the records as you see fit.
Tom KD7LXL
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
OK, imported the .p12 certificate into both Firefox and Internet Explorer, and both now show it in the list of personal certificates. Then, I temporarily disabled routing 44.x.x.x addresses out the MikroTik. A "traceroute" confirms I'm not going out the MikroTik radio. I get the same message: "We need to authenticate you, but we can't use encryption over ham radio." Do I have to reboot Windows? On 2014-06-08 17:43, Cory (NQ1E) wrote:
Dean,
Using that specific version of Opera is only if you want to visit the authenticated portal site over the RF network. It's the only browser that we could get to work with unencrypted SSL mutual certificate authentication. Nobody else on the internet seems to do that, so there's not a lot of support for it.
If you're using your commercial internet connection instead, you don't have to worry about that and you can use just about any browser if you have your LotW certificate setup in it.
-Cory NQ1E
On Jun 8, 2014 5:24 PM, "Dean Gibson AE7Q" <hamwan@ae7q.com <mailto:hamwan@ae7q.com>> wrote:
This requires a specific (and non-current) version of a specific browser (eg, Opera) ?!?!?!?
On 2014-05-15 23:32, Tom Hayward wrote:
On Thu, May 15, 2014 at 9:49 PM, Dean Gibson AE7Q <hamwan@ae7q.com <mailto:hamwan@ae7q.com>> wrote:
Now, this is not correct. While I appreciate the PTR record for 44.24.240.173 <tel:44.24.240.173>, it needs to point to a hostname record ("A" or CNAME"), not a domainname record. This is not the fault of the PTR record, but the record that it points to: The NS record for ae7q.hamwan.net <http://ae7q.hamwan.net> effectively declares ae7q.hamwan.net <http://ae7q.hamwan.net> as a subdomain, with ns1.ae7q.ampr.org <http://ns1.ae7q.ampr.org> as its nameserver. Now, ns1.ae7q.ampr.org <http://ns1.ae7q.ampr.org> has the IP address of 44.24.240.173 <tel:44.24.240.173>, but that doesn't mean that the domain ae7q.hamwan.net <http://ae7q.hamwan.net> is anywhere near 44.24.240.x.
Dean,
The reason there is an NS record at ae7q.hamwan.net <http://ae7q.hamwan.net> is because I needed to test user NS records while working on the portal UI. On April 10 you talked about running your own DNS server, and complained that ampr.org <http://ampr.org> did not allow NS records. Not wanting HamWAN to be accused of the same thing, I made sure you could create NS records yourself from the portal.
Use your Logbook of the World certificate to log in here: http://portal.hamwan.org/dns/
It will allow you to create, edit, and delete any DNS record within the {LoTW callsign}.hamwan.net <http://hamwan.net> domain (e.g., AE7Q.hamwan.net <http://AE7Q.hamwan.net>). You can manipulate the records as you see fit.
Tom KD7LXL
_______________________________________________ PSDR mailing list PSDR@hamwan.org <mailto:PSDR@hamwan.org> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
On Sun, Jun 8, 2014 at 5:24 PM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:
This requires a specific (and non-current) version of a specific browser (eg, Opera) ?!?!?!?
Dean, The portal can be accessed from a few different protocols/configurations: http://portal.hamwan.org/ - plain old HTTP. This can be used to access parts of the portal that do not require authentication, like record listings and the map (e.g., http://portal.hamwan.org/dns/all/ ). We don't suggest logging in here because your username and password would be sent in the clear. https://portal.hamwan.org/ - HTTP over non-cipher (not encrypted), authenticated SSL. This is a Part-97-friendly way to authenticate with the portal. We have SSL configured to request a Logbook of the World certificate and only negotiate SSL with null ciphers. Most browsers don't allow null ciphers, so they will report an SSL cipher mismatch. I found that Opera 12.16, the most recent version of Opera released for Linux, has an option to allow null ciphers. I wrote up some instructions for this and left the sections for other browsers blank. You or anyone else who wants to experiment is welcome to experiment and come up with some instructions for other browsers. http://encrypted.hamwan.org/ - redirects to https://encrypted.hamwan.org/ https://encrypted.hamwan.org/ - HTTP over encrypted, authenticated SSL. This is configured for standard, encrypted SSL, so it is NOT allowed over Part 97, but should work with normal browser settings. The content is the same at all of these addresses; it's just the protocols that differ. By the way, the SSL configuration may not be compatible with Internet Explorer; I never tested it. I seem to recall something about Internet Explorer not liking optional SSL authentication (as opposed to forced or disabled). Firefox, Chrome, Safari, and Opera are tested and working. If you've done all this and it's still asking you to authenticate, there may be a bug in my code that pulls your callsign out of the LoTW certificate. Tom KD7LXL
OK, after disabling the 44.x.x.x route, Firefox accepts the LoTW certificate for http://encrypted.hamwan.org, and your web pages work. FYI: In Internet Explorer (which I tested for you, but don't normally use), there's a long, LONG pause before it asks me to confirm using the LoTW certificate, and then an even longer pause before your web page comes up, that denies access. After re-enabling the 44.x.x.x route, https://encrypted.hamwan.org still works in Firefox (even after restarting it) -- I hope that's not a bug, because traceroute is showing a direct 44.x.x.x path to it. However, when I get to my page for adding DNS records, the terminology used fails me, even after 15 years of running BIND with a number of domains and subdomains, and teaching it at the U. Washington: 1. I know the distinction between a "hostname" and an "interface" on a host, but not in a DNS record. 2. I know what an "interface" is in a route, but not in a DNS record. Is that terminology in the RFC? Somehow I changed the PTR record to be what I want. However, I'm at a loss as to the difference between creating a "host" (which apparently wants a MAC address, a lat/long, but not an IP address!), and just creating an "A" record. So, I deleted everything and manually added the "A" record. As a result, when I click on the "Your hosts" tab, there's nothing, not even a listing header. I'd gladly use the "Create Host" page, except that I no idea what to do with the "interface" fields. I have no idea what the "Primary" checkbox is for (more terminology issues). I know what "primary" and "slave" mean in terms of NS records, but not for a host. Also, when I do a DNS search for my callsign on your web page, I see all three of my desired DNS records. However, when I use "DIG", I see: / dig @a.ns.hamwan.net ns1.ae7q.hamwan.net. ae7q.hamwan.net. ns -x 44.24.240.173 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52006 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;ns1.ae7q.hamwan.net. IN A ;; AUTHORITY SECTION: ae7q.hamwan.net. 3600 IN NS ns1.ae7q.hamwan.net. ;; Query time: 65 msec ;; SERVER: 44.24.244.2#53(44.24.244.2) ;; WHEN: Sun Jun 8 20:03:05 2014 ;; MSG SIZE rcvd: 51 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40908 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;ae7q.hamwan.net. IN NS ;; AUTHORITY SECTION: ae7q.hamwan.net. 3600 IN NS ns1.ae7q.hamwan.net. ;; Query time: 86 msec ;; SERVER: 44.24.244.2#53(44.24.244.2) ;; WHEN: Sun Jun 8 20:03:05 2014 ;; MSG SIZE rcvd: 51 ; <<>> DiG 9.2.4 <<>> @a.ns.hamwan.net ns1.ae7q.hamwan.net. ae7q.hamwan.net. -x 44.24.240.173 ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22989 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;173.240.24.44.in-addr.arpa. IN PTR ;; ANSWER SECTION: 173.240.24.44.in-addr.arpa. 3600 IN PTR ns1.ae7q.hamwan.net. ;; Query time: 24 msec ;; SERVER: 44.24.244.2#53(44.24.244.2) ;; WHEN: Sun Jun 8 20:03:05 2014 ;; MSG SIZE rcvd: 77/ Note that there is no A record pointing to 44.24.240.173 (the PTR record is correct). I've spent a couple hours trying to get it to show up in DIG, to no avail. It didn't show up in DIG even before I deleted the "host" entry. Also, the query for the NS record doesn't return an ANSWER section; it just returns an AUTHORITY section (which happens to contain the "answer"). That's not what I see when I query for NS records for subdomains for (as an example) "u.washington.edu". I'm glad I'm retired and have the time to spend on this ... This is your guys' network, and in a sense, I'm just playing around. You should run DNS as you want. However, If someone like me has these issues (I'm a perfectionist), I'll bet others are going to be lost ... On 2014-06-08 18:18, Tom Hayward wrote:
On Sun, Jun 8, 2014 at 5:24 PM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:
This requires a specific (and non-current) version of a specific browser (eg, Opera) ?!?!?!? Dean,
The portal can be accessed from a few different protocols/configurations:
http://portal.hamwan.org/ - plain old HTTP. This can be used to access parts of the portal that do not require authentication, like record listings and the map (e.g., http://portal.hamwan.org/dns/all/ ). We don't suggest logging in here because your username and password would be sent in the clear.
https://portal.hamwan.org/ - HTTP over non-cipher (not encrypted), authenticated SSL. This is a Part-97-friendly way to authenticate with the portal. We have SSL configured to request a Logbook of the World certificate and only negotiate SSL with null ciphers. Most browsers don't allow null ciphers, so they will report an SSL cipher mismatch. I found that Opera 12.16, the most recent version of Opera released for Linux, has an option to allow null ciphers. I wrote up some instructions for this and left the sections for other browsers blank. You or anyone else who wants to experiment is welcome to experiment and come up with some instructions for other browsers.
http://encrypted.hamwan.org/ - redirects to https://encrypted.hamwan.org/
https://encrypted.hamwan.org/ - HTTP over encrypted, authenticated SSL. This is configured for standard, encrypted SSL, so it is NOT allowed over Part 97, but should work with normal browser settings.
The content is the same at all of these addresses; it's just the protocols that differ.
By the way, the SSL configuration may not be compatible with Internet Explorer; I never tested it. I seem to recall something about Internet Explorer not liking optional SSL authentication (as opposed to forced or disabled). Firefox, Chrome, Safari, and Opera are tested and working.
If you've done all this and it's still asking you to authenticate, there may be a bug in my code that pulls your callsign out of the LoTW certificate.
Tom KD7LXL
On Sun, Jun 8, 2014 at 8:42 PM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:
OK, after disabling the 44.x.x.x route, Firefox accepts the LoTW certificate for http://encrypted.hamwan.org, and your web pages work. FYI: In Internet Explorer (which I tested for you, but don't normally use), there's a long, LONG pause before it asks me to confirm using the LoTW certificate, and then an even longer pause before your web page comes up, that denies access.
Interesting. I'm pretty sure it's stuck trying to deal with the "VerifyClient Optional" piece in SSL--something I've heard is not supported. I'm torn as to how to deal with this. If I simply require client verification (SSL authentication), the error message for those without LoTW certificates will be the browser's protocol error page, not something with the HamWAN logo and an explanation.
After re-enabling the 44.x.x.x route, https://encrypted.hamwan.org still works in Firefox (even after restarting it) -- I hope that's not a bug, because traceroute is showing a direct 44.x.x.x path to it.
No, not a bug. In case of emergency, there may be a case for using that encrypted interface over Part 97 (i.e., someone will die if they don't get their DNS configured, and they only have access to Chrome at the time...). I put "encrypted" in the domain so that it would be very obvious encryption was part of the protocol and the control operator could decide if that was something they wanted to access over RF.
However, when I get to my page for adding DNS records, the terminology used fails me, even after 15 years of running BIND with a number of domains and subdomains, and teaching it at the U. Washington:
I know the distinction between a "hostname" and an "interface" on a host, but not in a DNS record. I know what an "interface" is in a route, but not in a DNS record.
It sounds like you're in the Host section, not the DNS record section. https://encrypted.hamwan.org/host/new Knowing your background, I think reading the code might help you understand the relationships: https://github.com/HamWAN/hamwan-portal/blob/master/portal/models.py#L50 (Maybe I should make a UML diagram or something.) A Host is something we use for tracking assets on the network. For example, each of our sector routers has a Host record with type set to "sector". With a little script I wrote (inspired by Ansible), I can send a command to all sector routers at once. The target list is compiled by querying all hosts with type == sector. Another script can icmp ping all hosts to report their status. Each host can have zero-to-many IP addresses. Some validation ensures we haven't assigned the same IP address to more than one host. The Host/IPAddress form has a field for "interface" so we can keep track of which interface the IP address was configured on (e.g., ether1 or wlan1). What does this have to do with DNS? When saving an IP address record, you can select "auto DNS" and "primary". This is *not* a direct interface to bind, but rather a tool to automatically generate some DNS records. If "auto DNS" is checked, an A record will be generated in the following format: [interface].[hostname].hamwan.net [hostname] is restricted to something that ends in the callsign you are logged in with, for example "home.ae7q". The "primary" field can be used in conjunction with "auto DNS" to indicate which interface is the primary for that host. For modems like yours, this will be the public side, wlan1. This will generate a CNAME record in the following format: [hostname].hamwan.net CNAME [interface].[hostname].hamwan.net Okay, say you don't select "auto DNS", but you want some A records, CNAMES, and maybe some other DNS record types. This is what the DNS section is for. Any time you're not happy with auto generated records, you can manually enter them in the DNS record section. https://encrypted.hamwan.org/dns/new/ Seeing as you're the first network user to poke around in this management portal, I expect you'll find some bugs and usability issues. Please document this stuff so bugs can be fixed and documentation can be improved. Tom KD7LXL
Gotcha (in the sense I understand). Check out my current setup, for reasonableness. Possible bugs: 1. The DNS records that "Create Host" (and its "edit/update" variant) creates (A and PTR), do not have a TTL (which I assume means they pick it up the zone default). Easily edited in "Your DNS records". Of course, let me know if you would prefer the field blank, in order to use the zone default. 2. For "ether1.paine.ae7q.hamwan.net", "Create Host" would not allow me to specify an IP address outside of my allocation. It's useful to have such an A record (obviously without the PTR record), if only for record-keeping on an interface (eg, mine) that accesses another network. I created it separately. 3. The list of "Your DNS records" does not include the PTR record, which then must be searched for, in order to edit (eg, to add the TTL value). 4. The "All Yo' Stuff", apparently being intended to be inclusive, could include "Your DNS records". Going to dinner now ... -- Dean On 2014-06-08 21:18, Tom Hayward wrote:
On Sun, Jun 8, 2014 at 8:42 PM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:
OK, after disabling the 44.x.x.x route, Firefox accepts the LoTW certificate for http://encrypted.hamwan.org, and your web pages work. FYI: In Internet Explorer (which I tested for you, but don't normally use), there's a long, LONG pause before it asks me to confirm using the LoTW certificate, and then an even longer pause before your web page comes up, that denies access. Interesting. I'm pretty sure it's stuck trying to deal with the "VerifyClient Optional" piece in SSL--something I've heard is not supported. I'm torn as to how to deal with this. If I simply require client verification (SSL authentication), the error message for those without LoTW certificates will be the browser's protocol error page, not something with the HamWAN logo and an explanation.
After re-enabling the 44.x.x.x route, https://encrypted.hamwan.org still works in Firefox (even after restarting it) -- I hope that's not a bug, because traceroute is showing a direct 44.x.x.x path to it. No, not a bug. In case of emergency, there may be a case for using that encrypted interface over Part 97 (i.e., someone will die if they don't get their DNS configured, and they only have access to Chrome at the time...). I put "encrypted" in the domain so that it would be very obvious encryption was part of the protocol and the control operator could decide if that was something they wanted to access over RF.
However, when I get to my page for adding DNS records, the terminology used fails me, even after 15 years of running BIND with a number of domains and subdomains, and teaching it at the U. Washington:
I know the distinction between a "hostname" and an "interface" on a host, but not in a DNS record. I know what an "interface" is in a route, but not in a DNS record. It sounds like you're in the Host section, not the DNS record section.
https://encrypted.hamwan.org/host/new
Knowing your background, I think reading the code might help you understand the relationships: https://github.com/HamWAN/hamwan-portal/blob/master/portal/models.py#L50
(Maybe I should make a UML diagram or something.)
A Host is something we use for tracking assets on the network. For example, each of our sector routers has a Host record with type set to "sector". With a little script I wrote (inspired by Ansible), I can send a command to all sector routers at once. The target list is compiled by querying all hosts with type == sector. Another script can icmp ping all hosts to report their status.
Each host can have zero-to-many IP addresses. Some validation ensures we haven't assigned the same IP address to more than one host. The Host/IPAddress form has a field for "interface" so we can keep track of which interface the IP address was configured on (e.g., ether1 or wlan1).
What does this have to do with DNS? When saving an IP address record, you can select "auto DNS" and "primary". This is *not* a direct interface to bind, but rather a tool to automatically generate some DNS records. If "auto DNS" is checked, an A record will be generated in the following format: [interface].[hostname].hamwan.net
[hostname] is restricted to something that ends in the callsign you are logged in with, for example "home.ae7q".
The "primary" field can be used in conjunction with "auto DNS" to indicate which interface is the primary for that host. For modems like yours, this will be the public side, wlan1. This will generate a CNAME record in the following format: [hostname].hamwan.net CNAME [interface].[hostname].hamwan.net
Okay, say you don't select "auto DNS", but you want some A records, CNAMES, and maybe some other DNS record types. This is what the DNS section is for. Any time you're not happy with auto generated records, you can manually enter them in the DNS record section.
https://encrypted.hamwan.org/dns/new/
Seeing as you're the first network user to poke around in this management portal, I expect you'll find some bugs and usability issues. Please document this stuff so bugs can be fixed and documentation can be improved.
Tom KD7LXL
On Sun, Jun 8, 2014 at 10:34 PM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:
Gotcha (in the sense I understand). Check out my current setup, for reasonableness. Possible bugs:
The DNS records that "Create Host" (and its "edit/update" variant) creates (A and PTR), do not have a TTL (which I assume means they pick it up the zone default). Easily edited in "Your DNS records". Of course, let me know if you would prefer the field blank, in order to use the zone default.
This is as designed. They'll pick up the default TTL of 3600. Overriding this in the DNS section as you describe is also not a problem and should work just fine. However, if you go back to the Host form, check "auto DNS", and save, your customization might be overwritten by the automatically-generated record. Just uncheck "auto DNS" to preserve your manual customizations.
For "ether1.paine.ae7q.hamwan.net", "Create Host" would not allow me to specify an IP address outside of my allocation. It's useful to have such an A record (obviously without the PTR record), if only for record-keeping on an interface (eg, mine) that accesses another network. I created it separately.
This is also as designed. I don't want to maintain records for stuff outside of our network. I suppose I should add an exception for RFC 1918 addresses for cases like this. I'll have to make sure the unique constraint is disabled for these.
The list of "Your DNS records" does not include the PTR record, which then must be searched for, in order to edit (eg, to add the TTL value).
I'm not sure why this isn't working for you. I see the PTRs for IPs assigned to me. Here's the code for that query: https://github.com/HamWAN/hamwan-portal/blob/master/dns/views.py#L105 Notice how unwieldy this query could get if a user owns a lot of IP addresses--I don't have a better idea for querying PTRs.
The "All Yo' Stuff", apparently being intended to be inclusive, could include "Your DNS records".
Good catch. I don't think that code has been touched since before the DNS section existed. Tom
On 2014-06-08 23:15, Tom Hayward wrote:
On Sun, Jun 8, 2014 at 10:34 PM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote: ...
For "ether1.paine.ae7q.hamwan.net", "Create Host" would not allow me to specify an IP address outside of my allocation. It's useful to have such an A record (obviously without the PTR record), if only for record-keeping on an interface (eg, mine) that accesses another network. I created it separately. This is also as designed. I don't want to maintain records for stuff outside of our network.
I suppose I should add an exception for RFC 1918 addresses for cases like this. I'll have to make sure the unique constraint is disabled for these.
I had thought you might not want to be a general DNS service; it could be taken advantage of. In which case you should prevent me from adding the record separately (as I did). I see no reason to make an exception for RFC 1918 address; if you don't want the records. I only put it in there for symmetry with wan1.paine.ae7q.hamwan.net as documentation. I have no intention of actually using that DNS hostname (the hostname I use is part of my own internal domain). Of course, you could allow the entry in the "Host" info, and just not propagate it over to DNS ...
The list of "Your DNS records" does not include the PTR record, which then must be searched for, in order to edit (eg, to add the TTL value). I'm not sure why this isn't working for you. I see the PTRs for IPs assigned to me.
Here's the code for that query: https://github.com/HamWAN/hamwan-portal/blob/master/dns/views.py#L105
Notice how unwieldy this query could get if a user owns a lot of IP addresses--I don't have a better idea for querying PTRs.
I just did a search for "ae7q" to find mine ...
On Mon, Jun 9, 2014 at 12:26 AM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:
addresses--I don't have a better idea for querying PTRs.
I just did a search for "ae7q" to find mine ...
The reason I don't do that is because "ae7q" is found in the content field of the PTR. Authorization to edit a PTR needs to come from the name field (reversed IP address), where that IP address is allocated to the logged in user. For example, your PTR could point to "paine.44rf.net" and a search for "ae7q" wouldn't find it. A search for the reverse of the IP address would find it, and that's working for me, so I'm not sure why it doesn't work for you. This is an edge case, for sure. Tom
On 2014-06-08 23:15, Tom Hayward wrote:
On Sun, Jun 8, 2014 at 10:34 PM, Dean Gibson AE7Q <hamwan@ae7q.com> wrote:
...
The DNS records that "Create Host" (and its "edit/update" variant) creates (A and PTR), do not have a TTL (which I assume means they pick it up the zone default). .... This is as designed. They'll pick up the default TTL of 3600.
In which case perhaps a label other than "None" might be used (like "Zone default") in the listing ...
participants (4)
-
Bart Kus -
Cory (NQ1E) -
Dean Gibson AE7Q -
Tom Hayward