Re: SRV Request to DNS
In message <561e91ed.3060...@clegg.com>, Alan Clegg writes: > > > Are there *any* current, well-known protocols that make use of SRV > > records to find the port? The examples I've seen just use it to find a > > server (analogous to the way MX records are used for mail). > > I guess it depends on what you define as a well-known protocol... > > Teamspeak 3: > https://support.teamspeakusa.com/index.php?/Knowledgebase/Article/View/293 > /12/does-teamspeak-3-support-dns-srv-records > > AlanC > -- > When I do still catch the odd glimpse, it's peripheral; mere fragments > of mad-doctor chrome, confining themselves to the corner of the eye. All protocols that use SRV do. It's the operators that decide the port to put in the SRV record, not the protocol. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SRV Request to DNS
On 10/14/15 11:29 AM, Barry Margolin wrote: > Are there *any* current, well-known protocols that make use of SRV > records to find the port? The examples I've seen just use it to find a > server (analogous to the way MX records are used for mail). I guess it depends on what you define as a well-known protocol... Teamspeak 3: https://support.teamspeakusa.com/index.php?/Knowledgebase/Article/View/293/12/does-teamspeak-3-support-dns-srv-records AlanC -- When I do still catch the odd glimpse, it's peripheral; mere fragments of mad-doctor chrome, confining themselves to the corner of the eye. signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SRV Request to DNS
On Wed, Oct 14, 2015 at 11:40 AM, Anders Löwinger wrote: > Den 2015-10-14 kl. 17:29, skrev Barry Margolin: > > Are there **any** current, well-known protocols that make use of SRV > records to find the port? The examples I've seen just use it to find a > server (analogous to the way MX records are used for mail). > > > Examples: > > SIP > http://www.voip-info.org/wiki/view/DNS+SRV > > XMPP > http://wiki.xmpp.org/web/SRV_Records > > > /Anders > > Kerberos http://web.mit.edu/kerberos/krb5-1.6/krb5-1.6.3/doc/krb5-admin.html#Hostnames-for-KDCs --- But not sure if the 'port' is actually used, since it can also be defined in the conf file. -- Bob Harold ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SRV Request to DNS
Den 2015-10-14 kl. 17:29, skrev Barry Margolin: Are there*any* current, well-known protocols that make use of SRV records to find the port? The examples I've seen just use it to find a server (analogous to the way MX records are used for mail). Examples: SIP http://www.voip-info.org/wiki/view/DNS+SRV XMPP http://wiki.xmpp.org/web/SRV_Records /Anders ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SRV Request to DNS
In article , Mark Andrews wrote: > To answer the question. What you do when given a name and a port > is protocol specific. Read the protocol specification. Note if > the port is the well known port for the protocol then it may be > ignored. > > If the protocol does not specify most developers will just implement > the protocol over that port to the specified host taking into account > well known ports if needed. > > To used SRV with a protocol you need a specification that says to > do so. Using SRV without such a specification results in undefined > behaviour. Are there *any* current, well-known protocols that make use of SRV records to find the port? The examples I've seen just use it to find a server (analogous to the way MX records are used for mail). Theoretically, this could be useful for HTTP, so you wouldn't have to put :port# in URLs if the domain uses an alternate port. It would make things easier when you have servers for multiple domains behind a NAT router with a single public address. But AFAIK there's been no movement to require browsers to use SRV for this. -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: dname reverse delegation
Yeah, it looks like I might have to give up on this. paul -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Matus UHLAR - fantomas Sent: Wednesday, October 14, 2015 10:29 AM To: bind-users@lists.isc.org Subject: Re: dname reverse delegation On 14.10.15 10:11, Paul A wrote: >Niall my problem is the name server that delegated the reserve does look up the record correctly. > >I have this in the zone, > >DNAME 0/24 >;; >;;; delegate to server >;; >0/24NS ns.someserver.com >;; > > >At the ns.someserver.com the looks ups work with no problems. However at the main name server the PTR look up does not work. >Not sure what im missing. You have been already advised to avoid the ".0/24." NONSENSE. You can easily delegate x.x.x.IN-ADDR.ARPA without putting useless (and as you report, problematic) subdomain ".0/24." there... >;; ANSWER SECTION: >x.x.x.in-addr.arpa. 172800 IN DNAME 0/24.x.x.x.IN-ADDR.ARPA. >2.x.x.x.in-addr.arpa. 172800 IN CNAME 2.0/24.x.x.x.IN-ADDR.ARPA. >2.0/24.x.x.x.IN-ADDR.ARPA. 172800 IN CNAME 2.0/24.0/24.x.x.x.IN-ADDR.ARPA. >2.0/24.0/24.x.x.x.IN-ADDR.ARPA. 172800 IN CNAME 2.0/24.0/24.0/24.x.x.x.IN-ADDR.ARPA. >2.0/24.0/24.0/24.x.x.x.IN-ADDR.ARPA. 172800 IN CNAME 2.0/24.0/24.0/24.0/24.x.x.x.IN-ADDR... > >But the looking up the record on ns1.someserver.com works fine. > >;; ANSWER SECTION: >13.7.69.in-addr.arpa. 172229 IN DNAME 0/24.x.x.69.IN-ADDR.ARPA. >2.13.7.69.in-addr.arpa. 172229 IN CNAME 2.0/24.x.x.69.IN-ADDR.ARPA. >2.0/24.13.7.69.IN-ADDR.ARPA. 172800 IN PTR x-x-x-x.rev.XXX.com. >On Tue, 13 Oct 2015 21:40:30 +0100, >Paul A wrote: >> >> I have a few /24 that I want to delegate using DNAME. > > Are you expecting to save yourself trouble by doing so? > If not, you should probably reconsider. [...] > Don't be distracted by RFC2317. It describes the trickery you need > when you're dealing with a longer prefix (fewer addresses) than a > /24. If you have "a few /24", you can deal with them without needing > any of that. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "They say when you play that M$ CD backward you can hear satanic messages." "That's nothing. If you play it forward it will install Windows." ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dname reverse delegation
On 14.10.15 10:11, Paul A wrote: Niall my problem is the name server that delegated the reserve does look up the record correctly. I have this in the zone, DNAME 0/24 ;; ;;; delegate to server ;; 0/24NS ns.someserver.com ;; At the ns.someserver.com the looks ups work with no problems. However at the main name server the PTR look up does not work. Not sure what im missing. You have been already advised to avoid the ".0/24." NONSENSE. You can easily delegate x.x.x.IN-ADDR.ARPA without putting useless (and as you report, problematic) subdomain ".0/24." there... ;; ANSWER SECTION: x.x.x.in-addr.arpa. 172800 IN DNAME 0/24.x.x.x.IN-ADDR.ARPA. 2.x.x.x.in-addr.arpa. 172800 IN CNAME 2.0/24.x.x.x.IN-ADDR.ARPA. 2.0/24.x.x.x.IN-ADDR.ARPA. 172800 IN CNAME 2.0/24.0/24.x.x.x.IN-ADDR.ARPA. 2.0/24.0/24.x.x.x.IN-ADDR.ARPA. 172800 IN CNAME 2.0/24.0/24.0/24.x.x.x.IN-ADDR.ARPA. 2.0/24.0/24.0/24.x.x.x.IN-ADDR.ARPA. 172800 IN CNAME 2.0/24.0/24.0/24.0/24.x.x.x.IN-ADDR... But the looking up the record on ns1.someserver.com works fine. ;; ANSWER SECTION: 13.7.69.in-addr.arpa. 172229 IN DNAME 0/24.x.x.69.IN-ADDR.ARPA. 2.13.7.69.in-addr.arpa. 172229 IN CNAME 2.0/24.x.x.69.IN-ADDR.ARPA. 2.0/24.13.7.69.IN-ADDR.ARPA. 172800 IN PTR x-x-x-x.rev.XXX.com. On Tue, 13 Oct 2015 21:40:30 +0100, Paul A wrote: I have a few /24 that I want to delegate using DNAME. Are you expecting to save yourself trouble by doing so? If not, you should probably reconsider. [...] Don't be distracted by RFC2317. It describes the trickery you need when you're dealing with a longer prefix (fewer addresses) than a /24. If you have "a few /24", you can deal with them without needing any of that. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "They say when you play that M$ CD backward you can hear satanic messages." "That's nothing. If you play it forward it will install Windows." ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: dname reverse delegation
Niall my problem is the name server that delegated the reserve does look up the
record correctly.
I have this in the zone,
DNAME 0/24
;;
;;; delegate to server
;;
0/24NS ns.someserver.com
;;
At the ns.someserver.com the looks ups work with no problems. However at the
main name server the PTR look up does not work.
Not sure what im missing.
;; ANSWER SECTION:
x.x.x.in-addr.arpa. 172800 IN DNAME 0/24.x.x.x.IN-ADDR.ARPA.
2.x.x.x.in-addr.arpa. 172800 IN CNAME 2.0/24.x.x.x.IN-ADDR.ARPA.
2.0/24.x.x.x.IN-ADDR.ARPA. 172800 IN CNAME 2.0/24.0/24.x.x.x.IN-ADDR.ARPA.
2.0/24.0/24.x.x.x.IN-ADDR.ARPA. 172800 IN CNAME
2.0/24.0/24.0/24.x.x.x.IN-ADDR.ARPA.
2.0/24.0/24.0/24.x.x.x.IN-ADDR.ARPA. 172800 IN CNAME
2.0/24.0/24.0/24.0/24.x.x.x.IN-ADDR...
But the looking up the record on ns1.someserver.com works fine.
;; ANSWER SECTION:
13.7.69.in-addr.arpa. 172229 IN DNAME 0/24.x.x.69.IN-ADDR.ARPA.
2.13.7.69.in-addr.arpa. 172229 IN CNAME 2.0/24.x.x.69.IN-ADDR.ARPA.
2.0/24.13.7.69.IN-ADDR.ARPA. 172800 IN PTR x-x-x-x.rev.XXX.com.
Thanks, p
-Original Message-
From: Niall O'Reilly [mailto:niall.orei...@ucd.ie]
Sent: Tuesday, October 13, 2015 6:29 PM
To: Paul A
Cc: bind-users@lists.isc.org
Subject: Re: dname reverse delegation
On Tue, 13 Oct 2015 21:40:30 +0100,
Paul A wrote:
>
> I have a few /24 that I want to delegate using DNAME.
Are you expecting to save yourself trouble by doing so?
If not, you should probably reconsider.
If you decide DNAME is a useful trick, bear in mind that what DNAME
does is not really delegation, but just a trick for the lazy. I'm
actually one of those lazy people, so please understand that I don't
mean the word offensively. Besides, cleverer people than I have
recognized laziness as a virtue.
I have persuaded the administrator of the
1.0.0.7.7.0.1.0.0.2.ip6.arpa. zone to use a DNAME rather than a
delegation for f.3.1.0.0.7.7.0.1.0.0.2.ip6.arpa. Yes, this is for
IPv6, but it's conveniently to hand, and the principles are the
same. I have actually had second thoughts about this, and more than
once, but never felt worried enough that making the change needed
priority before the other things on my do-list.
The trouble I save by doing this is that of maintaining two zone
files for my and corresponding PTR records. Instead, I can
keep both together in one file, like this:
$ORIGIN no8.be.
bode3600IN 2001:770:13f:0:5054:ff:fe00:d978
8.7.9.d.0.0.e.f.f.f.0.0.4.5.0.5.0.0.0.0.f.3.1.0.0.7.7.0.1.0.0.2.ip6 3600 IN PTR
bode
Using 'dig', you can explore how it works, and what zones are
involved, by using commands such as these:
dig bode.no8.be
dig -x 2001:770:13f:0:5054:ff:fe00:d978
dig +trace -x 2001:770:13f:0:5054:ff:fe00:d978 dig
f.3.1.0.0.7.7.0.1.0.0.2.ip6.arpa ns dig no8.be ns
You can do the same for your /24's, if the administrator of the
parent reverse zone is minded to co-operate. Alternatively,
you can use a normal delegation and set up your zone as follows,
filling in the gaps appropriately.
$TTL 3600 ;; or whatever
$ORIGIN 13.168.192.in-addr.arpa.
@ IN SOA ...
IN NS ...
IN DNAME whatever.example.net.
Then, you populate the whatever.example.net. zone with the PTR records:
$TTL 3600 ;; or whatever
$ORIGIN whatever.example.net.
@ IN SOA ...
IN NS ...
0 IN PTR base-addr.whatever-else.example.net.
1 IN PTR some-host.whatever-else.example.net.
2 IN PTR anor-host.whatever-else.example.net.
;; and so on ...
255 IN PTR bcast-addr.whatever-else.example.net.
> Lets says I have 192.168.13.0/24 how would I go about doing reserve on
> the forwarding server using DNAME.
>
> Currently on the forwarding server I have
>
> NS ns.isp.com
>
> ;;
>
> DNAME 0/24
Don't be distracted by RFC2317. It describes the trickery you need
when you're dealing with a longer prefix (fewer addresses) than a
/24. If you have "a few /24", you can deal with them without
needing any of that.
> ;;
>
> ;;; delegate to server
>
> 0/24 NS ns.someserver.com.
>
> On the server handling the PTRs (ns.someserver.com) I have:
>
> zone "0/24.13.168.192.IN-ADDR.ARPA" {
>
> type master;
>
> file "/slvdb/db.13.168.192";
>
> };
>
> In the PTR server the zone file looks like a normal PTR file and when
> I query on this server its working, I get the DNAME/CNAME and PTR.
>
> However when I query on the forwarding server it’s not working, I just
> keep getting the CNAME over and over again but not actual PTR.
I'm not sure what in what sense you're using the term "forwarding
server".
If you mean the authoritative server where the DNAME record is sitting,
then I believe that this is normal. An authoritative server should
return just the DNAME and synthesized CNAME, as it's not responsible
for chasing down the CNAME reference. That's the job of a recursive
resolver.
> Shouldn’t the forwarding server query the
