Reverse DNS RFCs and Recommendations
I've been (probably needlessly) pouring over the Reverse DNS RFCs for long enough to actually have questions about a subject that should be relatively unimportant. I do want to make sure that we set up our reverse DNS correctly and most efficiently the first time so that we don't irritate other network operators with difficult regex based filtering ( http://www.gossamer-threads.com/lists/nanog/users/113633 ) and we don't have to change things as per a recommendation down the road. RFC draft-msullivan-dnsop-generic-naming-schemes-00.txt states: When using IP addresses in host names, their numbers SHOULD be separated by '.'s (dots) rather than any meta character such as a '-' (dash) and expressed in decimal. Host names SHOULD NOT use the '_' (underscore) character, host names for hosts with any form of SMTP mail service MUST NOT use the '_' (underscore) character. It is preferable to use the IP address in reverse format in the same way the the IN-ADDR.ARPA. domain is defined. Now since it is only a first revision draft I'm taking what it has to say with a grain of salt and it seems has taken quite a bit of criticism on forums. I'm also not singling out on Time Warner, WOW, Comcast or Charter for their naming conventions nor do I think they are bad, I'm just using them as examples because they are local, well-known ISPs. Actual Examples: cpe-67-XX-XX-XX.stny.res.rr.com - 67.XX.XX.XX d28-XX-XX-XX.dim.wideopenwest.com - 28.XX.XX.XX c-68-XX-XX-XX.hsd1.mi.comcast.net - 68.XX.XX.XX 24-XX-XX-XX.static.bycy.mi.charter.com - 24.XX.XX.XX *Most ISP Reverse DNS Hostnames (from what I've observed) seem to use the dash "-" character with the forward format, as opposed to the reverse IN-ADDR.ARPA. dotted scheme as recommended in the draft *Comcast and Charter all have geographic based furthest-right-hand tokens. *Charter, WideOpenWest, Time Warner, and Comcast all have some acronym that is not immediately clear, at least to me (HSD - High Speed Data?, BYCY - Bay City, MI?, DIM - Dynamic IP Mapping?, STNY - Southern Tier New York?) Which finally brings me to my questions: It seems like the unspoken de facto that mail admins appreciate given the IP 203.0.113.15 is "203-0-113-15.[type].[static/dynamic].yourdomain.tld". This seems perfectly acceptable, it's short, detailed and to the point. Is there really anything bad about this? What, if any would you name a network, gateway, broadcast address? Should the PTR be empty? <tinfoilhat> I've seen a lot about naming what type of technology it is (wireless, adsl, cable, etc.) in order to filter out the "high speed spammers". It seems to me that this would open up the likelihood of a targeted attack. We've all heard of security though obscurity and of course no one relies on it but we have to face the fact there are CVEs every day for various networking hardware/firmware. If an attacker can query DNS and find out that the IP is for wireless they could filter all wireless gear exploits. Is this still a good practice given the abundance of high speed data connections or is this just opening yourself up to reconnaissance?</tinfoilhat> There is a Merit Network mailing list discussion that outlines most of what I've read that can be found here ( http://www.merit.edu/mail.archives/nanog/msg06843.html ) Nolan Rollo VoIP Engineer Main: 517.223.3610x114 Fax: 517.223.4120 www.kw-corp.com<http://www.kw-corp.com/>
relatively unimportant. I do want to make sure that we set up our reverse DNS correctly
the only thing that's important is that forward and reverse DNS matches. After that, there is no correct or incorrect, so you need to do something that makes sense for your deployment. Nick
On Wed, Oct 30, 2013 at 04:24:42PM +0000, Nick Hilliard wrote:
the only thing that's important is that forward and reverse DNS matches.
As I think I've said before on this list, when we tried to get consensus on that claim in the DNSOP WG at the IETF, we couldn't. Indeed, we couldn't even get consensus on the much more bland statement, "Some people rely on the reverse, and you might want to take that into consideration when running your services." Now, IETF non-consensus on the way the Internet works is hardly a surprise, but I thought I'd point this out just in case people want to be prepared for flames from people who feel strongly about the matter. Note, also, that there's an important distinction to be made between matching reverse and mere existence of some reverse. An lot of sites don't require matching any more, because of the way it can bloat PTR RRsets if there are a lot of forward names at the same IP address. Best, A -- Andrew Sullivan Dyn, Inc. asullivan@dyn.com v: +1 603 663 0448
On Wed, 30 Oct 2013, Andrew Sullivan wrote:
On Wed, Oct 30, 2013 at 04:24:42PM +0000, Nick Hilliard wrote:
the only thing that's important is that forward and reverse DNS matches.
As I think I've said before on this list, when we tried to get consensus on that claim in the DNSOP WG at the IETF, we couldn't. Indeed, we couldn't even get consensus on the much more bland statement, "Some people rely on the reverse, and you might want to take that into consideration when running your services."
The classic TCP wrapper had this as one of the security features, if reverse said something and this couldn't be verified by doing a forward lookup, the reverse was treated as invalid and not used for name based policies. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Wed, Oct 30, 2013 at 06:13:35PM +0100, Mikael Abrahamsson wrote:
The classic TCP wrapper had this as one of the security features
I would agree with that if you'd put scare-quotes around the word "security". In general anyone depending on the reverse tree to provide them any kind of security is engaged in wishful thinking, particularly if the lookup isn't validated with DNSSEC. (But yes, that's waht the TCP wrappers package was supposed to be doing.) A -- Andrew Sullivan Dyn, Inc. asullivan@dyn.com v: +1 603 663 0448
Andrew Sullivan wrote:
The classic TCP wrapper had this as one of the security features
I would agree with that if you'd put scare-quotes around the word "security". In general anyone depending on the reverse tree to provide them any kind of security is engaged in wishful thinking,
No, it's you who have wishful thinking.
particularly if the lookup isn't validated with DNSSEC.
As is discussed recently in IETF main and dns MLs, Lack of secure time in most environment makes DNSSEC insecure. Legal enforcement on zone administrators makes related zones insecure. For most users, security by plain DNS with reverse look up is fine. Masataka Ohta
On Oct 30, 2013, at 11:55 AM, Andrew Sullivan <asullivan@dyn.com> wrote:
As I think I've said before on this list, when we tried to get consensus on that claim in the DNSOP WG at the IETF, we couldn't. Indeed, we couldn't even get consensus on the much more bland statement, "Some people rely on the reverse, and you might want to take that into consideration when running your services."
It's taking all of my willpower to avoid an IETF rant. :) The "SHOULD" here is one way. A PTR record should point to a valid forward name that resolves to the same IP address. To quote RFC 1034, a PTR is "a pointer to another part of the domain name space". If the RHS of a PTR is not a valid domain name, that's just not true. But rather than some pedantic rant about standards there's a practical purpose here. Tools that receive IP addresses will generate names using reverse lookups, those names should then work. For instance if trace route gives a name, "ping <name>" should then work. But the opposite is not true. Many forward records may point to the same IP address, and there is no need for reverses to match. (in shorthand) 10.0.0.1 PTR webhosting.foo.com webhosting.foo.com A 10.0.0.1 www.sitea.com A 10.0.0.1 www.siteb.com A 10.0.0.1 www.sitec.com A 10.0.0.1 -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On Wed, Oct 30, 2013 at 12:36:03PM -0500, Leo Bicknell wrote:
The "SHOULD" here is one way.
Of course, there is no SHOULD anywhere. RFC 1034 is from the era before RFC 2119, and there really isn't any guidance on the use of the reverse tree anywhere. It was the discovery of that very gap way back in 2006 that caused me to try to resurrect Daniel Senie's original draft and drive it through DNSOP. I think I was less cynical in those days.
purpose here. Tools that receive IP addresses will generate names using reverse lookups, those names should then work. For instance if trace route gives a name, "ping <name>" should then work.
Rather than "should" here, I'd prefer to say that it'd be nice if they work (just so that people don't mistake that should for a 2119 word). But the distinction you're making is roughly parallel with the distinction draft-ietf-dnsop-reverse-mapping-considerations-06 made between existing and matching reverse entries. I agree this distinction is worth keeping in mind.
But the opposite is not true. Many forward records may point to the same IP address, and there is no need for reverses to match.
I can assure you that there are people who insist that they _do_ need to match. It's also possible to have those multiple matches, as long as the list is not too long. I think the view that every forward must have a matching reverse is somewhat unrealistic; but the last time I expressed such a strong opinion about the reverse tree I landed in a long interaction with the proprietor of av8.net, so I'm disinclined to defend my opinion very hard. I do think that the people who think that the reverse tree is entirely optional are neglecting the interoperability consequences of that decision. That interoperation is the only real reason I can see to maintain the reverse; but it's a pretty important reason! Best, A -- Andrew Sullivan Dyn, Inc. asullivan@dyn.com v: +1 603 663 0448
On 10/30/2013 9:55 AM, Andrew Sullivan wrote:
As I think I've said before on this list, when we tried to get consensus on that claim in the DNSOP WG at the IETF, we couldn't. Indeed, we couldn't even get consensus on the much more bland statement, "Some people rely on the reverse, and you might want to take that into consideration when running your services."
Now, IETF non-consensus on the way the Internet works is hardly a surprise, but I thought I'd point this out just in case people want to be prepared for flames from people who feel strongly about the matter.
I'm beginning to think that documenting failures to get consensus could be almost as important as documenting successes, in order to provide a basis for countering folks who claim something is required, when there's explicit public experience that it isn't. Looks to me that Andrew's note is an example of that potential benefit. Rather than having to have someone remember this stuff, anyone could point to the 'failure' document. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
In message <5272E4A6.9080601@dcrocker.net>, Dave Crocker writes:
On 10/30/2013 9:55 AM, Andrew Sullivan wrote:
As I think I've said before on this list, when we tried to get consensus on that claim in the DNSOP WG at the IETF, we couldn't. Indeed, we couldn't even get consensus on the much more bland statement, "Some people rely on the reverse, and you might want to take that into consideration when running your services."
Now, IETF non-consensus on the way the Internet works is hardly a surprise, but I thought I'd point this out just in case people want to be prepared for flames from people who feel strongly about the matter.
I'm beginning to think that documenting failures to get consensus could be almost as important as documenting successes, in order to provide a basis for countering folks who claim something is required, when there's explicit public experience that it isn't.
Looks to me that Andrew's note is an example of that potential benefit. Rather than having to have someone remember this stuff, anyone could point to the 'failure' document.
There is consensus. There SHOULD be PTR records. This is even documented in various RFC. Now the methods IPS's use to do this for home customer addresses with IPv4 don't scale to IPv6. They also don't let the home customer specify the name in the PTR record. Additionally ISP's use PTR records as a revenue source by only offering to set them to commercial customers. Part of this is that it is often a manual proceedure. That said it is possible to completely automate the secure assignment of PTR records. It is also possible to completely automate the secure delegation of the reverse name space. See http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00 (yes I am aware of the typos which I will fix once the submission window re-opens). Similar techiques can be applied to individual IPv4 delegations. You add PTR records rather than NS and DS records. In named the SIG(0) signed UPDATE requests are granted using update-policy { grant * self *; }; when setting up the reverse zone. The code to do it is over a decade old at this point. It just requires willingness to do it. For ISP's to come out of the 90's and use the technology that was designed to allow this to happen. Mark
d/
-- Dave Crocker Brandenburg InternetWorking bbiw.net
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Mark Andrews wrote:
That said it is possible to completely automate the secure assignment of PTR records. It is also possible to completely automate the secure delegation of the reverse name space. See http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00
It is a lot simpler and a lot more practical just to use shared secret between a CPE and a ISP's name server for TSIG generation. As the secret can be directly shared end to end, it is more secure than DNSSEC involving untrustworthy third parties. Masataka Ohta
On Fri, 01 Nov 2013 16:03:56 +0900, Masataka Ohta said:
It is a lot simpler and a lot more practical just to use shared secret between a CPE and a ISP's name server for TSIG generation.
Hmm.. Shared secret between a CPE you don't necessarily control and your own DNS server? This *will* get you a dartboard with your picture on it at the ISP's help desk.
Valdis.Kletnieks@vt.edu wrote:
It is a lot simpler and a lot more practical just to use shared secret between a CPE and a ISP's name server for TSIG generation.
Hmm.. Shared secret between a CPE you don't necessarily control and your own DNS server?
Of course. That is the very basic requirement for any security between two parties. Masataka Ohta
On Fri, Nov 1, 2013 at 3:03 AM, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
Mark Andrews wrote:
That said it is possible to completely automate the secure assignment of PTR records. It is also possible to completely automate the secure delegation of the reverse name space. See http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00
It is a lot simpler and a lot more practical just to use shared secret between a CPE and a ISP's name server for TSIG generation.
Howdy, I hope you don't mean to suggest that a user should be able to use his normal ISP username and password to set those DNS records which the ISP has determined that he's allowed to set. That's just crazy talk! Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
In message <5273525C.5060908@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
Mark Andrews wrote:
That said it is possible to completely automate the secure assignment of PTR records. It is also possible to completely automate the secure delegation of the reverse name space. See http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00
It is a lot simpler and a lot more practical just to use shared secret between a CPE and a ISP's name server for TSIG generation.
No it isn't. It requires a human to transfer the secret to the CPE device or to register the secret with the ISP. I'm talking about just building this into CPE devices and having it just work with no human involvement.
As the secret can be directly shared end to end, it is more secure than DNSSEC involving untrustworthy third parties.
Masataka Ohta -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Mark Andrews wrote:
It is a lot simpler and a lot more practical just to use shared secret between a CPE and a ISP's name server for TSIG generation.
No it isn't. It requires a human to transfer the secret to the CPE device or to register the secret with the ISP.
Not necessarily. When the CPE is configured through DHCP (or PPP?), the ISP can send the secret.
I'm talking about just building this into CPE devices and having it just work with no human involvement.
See above. Involving DNSSEC here is overkill and unnecessarily introduce vulnerabilities. Masataka Ohta
In message <52743027.7050203@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
Mark Andrews wrote:
It is a lot simpler and a lot more practical just to use shared secret between a CPE and a ISP's name server for TSIG generation.
No it isn't. It requires a human to transfer the secret to the CPE device or to register the secret with the ISP.
Not necessarily. When the CPE is configured through DHCP (or PPP?), the ISP can send the secret.
Which can be seen, in many cases, by other parties which is why I discounted plain TSIG key exchanges over DHCP years ago regardless of which side send the key material.
I'm talking about just building this into CPE devices and having it just work with no human involvement.
See above.
Involving DNSSEC here is overkill and unnecessarily introduce vulnerabilities.
You do realise that you can use KEY records without DNSSEC. The KEY record is in the zone to be updated so it is implictly trusted.
Masataka Ohta
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
In message <20131102002035.963BA96D853@rock.dv.isc.org>, Mark Andrews writes:
In message <52743027.7050203@necom830.hpcl.titech.ac.jp>, Masataka Ohta write s:
Mark Andrews wrote:
It is a lot simpler and a lot more practical just to use shared secret between a CPE and a ISP's name server for TSIG generation.
No it isn't. It requires a human to transfer the secret to the CPE device or to register the secret with the ISP.
Not necessarily. When the CPE is configured through DHCP (or PPP?), the ISP can send the secret.
Which can be seen, in many cases, by other parties which is why I discounted plain TSIG key exchanges over DHCP years ago regardless of which side send the key material.
Now you could do a DH key exchange over DHCP then do a encrypted TSIG key exchange. This however also requires a encrypted key exchange of the TSIG with the nameserver. The DHCP server could do this with TKEY. Note a full DH key exhange is not strictly required. The CPE could just send a public key and the DHCP server could encrypt the TSIG secret using it when replying.
I'm talking about just building this into CPE devices and having it just work with no human involvement.
See above.
Involving DNSSEC here is overkill and unnecessarily introduce vulnerabilities.
You do realise that you can use KEY records without DNSSEC. The KEY record is in the zone to be updated so it is implictly trusted.
Masataka Ohta
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Mark Andrews wrote:
It is a lot simpler and a lot more practical just to use shared secret between a CPE and a ISP's name server for TSIG generation.
No it isn't. It requires a human to transfer the secret to the CPE device or to register the secret with the ISP.
Not necessarily. When the CPE is configured through DHCP (or PPP?), the ISP can send the secret.
Which can be seen, in many cases, by other parties
Who can see the packets sent from the local ISP to the CPE directly connected to the ISP? If you mind wire tapping, you have other things to worry about, which needs your access line encrypted (by a manually configured password), which makes DHCP packets invisible. Masataka Ohta
Not necessarily. When the CPE is configured through DHCP (or PPP?), the ISP can send the secret.
Which can be seen, in many cases, by other parties
Who can see the packets sent from the local ISP to the CPE directly connected to the ISP?
The NSA, FBI, CIA, DHS. Or, the ISP, the ISP's employees, contractors, sub-contractors. Or the phone company handling the PPPOE, L2TP, or whatever else. Or the WiFi sniffer on the street outside.
(2013/11/02 10:48), Alex Rubenstein wrote:
Not necessarily. When the CPE is configured through DHCP (or PPP?), the ISP can send the secret.
Which can be seen, in many cases, by other parties
Who can see the packets sent from the local ISP to the CPE directly connected to the ISP?
The NSA, FBI, CIA, DHS.
If you mind wire tapping, you have other things to worry about, which needs your access line encrypted (by a manually configured password), which makes DHCP packets invisible.
Or, the ISP, the ISP's employees, contractors, sub-contractors.
If you can't trust the ISP, you can't make rDNS operated by the ISP secure.
Or the phone company handling the PPPOE, L2TP, or whatever else.
If you mind wire tapping, you have other things to worry about, which needs your access line encrypted (by a manually configured password), which makes DHCP packets invisible.
Or the WiFi sniffer on the street outside.
Does your CPE retransmit a received DHCP reply to Wifi? Masataka Ohta
In message <527459C4.5000308@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
Mark Andrews wrote:
It is a lot simpler and a lot more practical just to use shared secret between a CPE and a ISP's name server for TSIG generation.
No it isn't. It requires a human to transfer the secret to the CPE device or to register the secret with the ISP.
Not necessarily. When the CPE is configured through DHCP (or PPP?), the ISP can send the secret.
Which can be seen, in many cases, by other parties
Who can see the packets sent from the local ISP to the CPE directly connected to the ISP?
The dhcpd traffic coming in over the cable modem and you want to send secrets in the clear over a channel like this. bsdi# tcpdump -n -i sis0 port bootpc tcpdump: listening on sis0 15:05:15.637252 10.72.0.1.67 > 255.255.255.255.68: hops:1 xid:0xc58c07ae flags:0x8000 Y:122.106.168.231 G:10.72.0.1 ether 0:1d:9:81:64:ba [|bootp] 15:05:15.650590 10.72.0.1.67 > 255.255.255.255.68: hops:1 xid:0xc58c07ae flags:0x8000 Y:122.106.168.231 G:10.72.0.1 ether 0:1d:9:81:64:ba [|bootp] 15:05:34.942619 10.72.0.1.67 > 255.255.255.255.68: hops:1 xid:0x122cf3bb flags:0x8000 Y:10.72.194.250 S:10.72.0.1 G:10.72.0.1 ether 0:17:ee:4c:f3:74 [|bootp] 15:05:36.975213 10.72.0.1.67 > 255.255.255.255.68: hops:1 xid:0x122cf3bb secs:2 flags:0x8000 Y:10.72.194.250 S:10.72.0.1 G:10.72.0.1 ether 0:17:ee:4c:f3:74 [|bootp] 15:05:36.992714 10.72.0.1.67 > 255.255.255.255.68: hops:1 xid:0x122cf3bb secs:2 flags:0x8000 Y:10.72.194.250 S:10.72.0.1 G:10.72.0.1 ether 0:17:ee:4c:f3:74 [|bootp] 15:05:55.931705 10.72.0.1.67 > 255.255.255.255.68: hops:1 xid:0x732 flags:0x8000 Y:10.72.3.3 S:10.72.0.1 G:10.72.0.1 ether 0:11:1a:19:25:a2 [|bootp] 15:05:57.951400 10.72.0.1.67 > 255.255.255.255.68: hops:1 xid:0x732 secs:2 flags:0x8000 Y:10.72.3.3 S:10.72.0.1 G:10.72.0.1 ether 0:11:1a:19:25:a2 [|bootp] 15:05:57.964049 10.72.0.1.67 > 255.255.255.255.68: hops:1 xid:0x732 secs:2 flags:0x8000 Y:10.72.3.3 S:10.72.0.1 G:10.72.0.1 ether 0:11:1a:19:25:a2 [|bootp] 15:05:58.930921 10.72.0.1.67 > 255.255.255.255.68: hops:1 xid:0xc7dba2af flags:0x8000 Y:122.106.152.0 G:10.72.0.1 ether 0:14:bf:a0:db:c8 [|bootp] 15:06:00.054322 10.72.0.1.67 > 255.255.255.255.68: hops:1 xid:0xc7dba2b0 flags:0x8000 Y:122.106.152.0 G:10.72.0.1 ether 0:14:bf:a0:db:c8 [|bootp] 15:06:00.068061 10.72.0.1.67 > 255.255.255.255.68: hops:1 xid:0xc7dba2b0 flags:0x8000 Y:122.106.152.0 G:10.72.0.1 ether 0:14:bf:a0:db:c8 [|bootp] 15:06:08.933232 10.72.0.1.67 > 255.255.255.255.68: hops:1 xid:0x111fb9c2 flags:0x8000 Y:10.72.23.110 S:10.72.0.1 G:10.72.0.1 ether 0:1a:de:6f:99:e6 [|bootp] 15:06:10.941233 10.72.0.1.67 > 255.255.255.255.68: hops:1 xid:0x111fb9c2 secs:2 flags:0x8000 Y:10.72.23.110 S:10.72.0.1 G:10.72.0.1 ether 0:1a:de:6f:99:e6 [|bootp] 15:06:10.959519 10.72.0.1.67 > 255.255.255.255.68: hops:1 xid:0x111fb9c2 secs:2 flags:0x8000 Y:10.72.23.110 S:10.72.0.1 G:10.72.0.1 ether 0:1a:de:6f:99:e6 [|bootp] ^C 10638 packets received by filter 0 packets dropped by kernel bsdi#
If you mind wire tapping, you have other things to worry about, which needs your access line encrypted (by a manually configured password), which makes DHCP packets invisible.
Masataka Ohta -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Mark Andrews wrote:
Who can see the packets sent from the local ISP to the CPE directly connected to the ISP?
The dhcpd traffic coming in over the cable modem and you want to send secrets in the clear over a channel like this.
Over the cable modem? The cable modem is the CPE, which accept the DHCP packet to it. Masataka Ohta
In message <5274A77A.8090403@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
Mark Andrews wrote:
Who can see the packets sent from the local ISP to the CPE directly connected to the ISP?
The dhcpd traffic coming in over the cable modem and you want to send secrets in the clear over a channel like this.
Over the cable modem?
Yes.
The cable modem is the CPE, which accept the DHCP packet to it.
A cable modem both accepts DHCP packets (for management of the modem) and passes DHCP packets through to the customer device.
Masataka Ohta
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Mark Andrews wrote:
Over the cable modem?
Yes.
OK.
The cable modem is the CPE, which accept the DHCP packet to it.
A cable modem both accepts DHCP packets (for management of the modem) and passes DHCP packets through to the customer device.
Even if the CPE does so, which means there is no NAT, the key to update rDNS must, naturally, be contained only in DHCP reply to the CPE. And, I'm afraid your draft assumes that the CPE behaves as a DHCP server for local hosts, which means the CPE is responsible for rDNS registration. Masataka Ohta
Hi, Op 2 nov. 2013, om 12:16 heeft Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> het volgende geschreven:
Mark Andrews wrote:
A cable modem both accepts DHCP packets (for management of the modem) and passes DHCP packets through to the customer device.
Even if the CPE does so, which means there is no NAT, the key to update rDNS must, naturally, be contained only in DHCP reply to the CPE.
You are misunderstanding the technology. Many cable operators offer a cable modem in bridged mode so that the customer can attach his own home-router behind it. Sending keys over a medium shared between multiple customers is not safe. Cheers, Sander
Sander Steffann wrote:
Hi,
Hi,
Even if the CPE does so, which means there is no NAT, the key to update rDNS must, naturally, be contained only in DHCP reply to the CPE.
You are misunderstanding the technology. Many cable operators offer a cable modem in bridged mode so that the customer can attach his own home-router behind it.
The situation is no different from:
If you mind wire tapping, you have other things to worry about, which needs your access line encrypted (by a manually configured password), which makes DHCP packets invisible.
Though some ISPs do not operate their network very securely, you can't have better security than that offered by your local ISP. Also remember that this thread is on secure rDNS by the ISP, which means you can't expect the ISP operate rDNS very securely even though the ISP operate rest of networking not very securely. Masataka Ohta
Sander Steffann wrote:
Also remember that this thread is on secure rDNS by the ISP, which means you can't expect the ISP operate rDNS very securely even though the ISP operate rest of networking not very securely.
You're linking things together that are completely orthogonal...
You misunderstand very basic points on why forward and reverse DNS checking is useful. If an attacker can snoop DHCP reply packet to a victim's CPE, the attacker can snoop any packet to a victim's server, which is already bad. Worse, the attacker can override a connection to the server by forging reply packets as if they are returned by the legitimate server with correct TCP sequence numbers etc, which is especially effective if combined with DOS attack to the legitimate server. Thus, there is no point to make forward and reverse DNS secure. That is, Mark's security model is broken only to introduce obscurity with worse security. Masataka Ohta PS If the server and its clients share some secret for mutual authentication as protection against snooping, there is no point to make forward and reverse DNS secure.
On Tue, Nov 5, 2013 at 6:00 PM, Masataka Ohta < mohta@necom830.hpcl.titech.ac.jp> wrote:
Sander Steffann wrote:
...
You're linking things together that are completely orthogonal...
You misunderstand very basic points on why forward and reverse DNS checking is useful.
Just to note... the main reason checking reverse DNS stays useful: is because that it is so hard to change in many cases. Specifically: if a server at some IP address X is under the control of a spammer; and rDNS is not setup, or rDNS points to some dynamic-looking hostname, It will be difficult or not possible for the spammer to modify the RDNS of the IP address, in many cases; the RDNS is most often managed by the ISP. Or it may be in a DNS infrastructure running on separate networks, with separate access credentials. If RDNS were easy to change; e.g. if you just needed to guess a password to the server, and get signing key information from a DHCP transaction; the spammer would just change it. Delegating "Secure RDNS update" with prefix delegation may in fact, make RDNS information so easy to publish, that the spammers of the world can do it, after compromising a router or host on the victim network, and just "Registering the better hostname in the DNS". The update process may be "secure", but there are new attack vectors. The value of even looking at RDNS, let alone worrying about Forward+Reverse DNS agreement/confirmation may not translate well to IPv6. -- -JH
In message <527986A2.6010806@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
Sander Steffann wrote:
Also remember that this thread is on secure rDNS by the ISP, which means you can't expect the ISP operate rDNS very securely even though the ISP operate rest of networking not very securely.
You're linking things together that are completely orthogonal...
You misunderstand very basic points on why forward and reverse DNS checking is useful.
If an attacker can snoop DHCP reply packet to a victim's CPE, the attacker can snoop any packet to a victim's server, which is already bad.
The DHCP reply packet is special as is is broadcasted. The unicast traffic isn't seen.
Worse, the attacker can override a connection to the server by forging reply packets as if they are returned by the legitimate server with correct TCP sequence numbers etc, which is especially effective if combined with DOS attack to the legitimate server.
Thus, there is no point to make forward and reverse DNS secure.
That is, Mark's security model is broken only to introduce obscurity with worse security.
This is a about adding a delegation into the DNS securely so only the machine that the prefix is delegated to and the ISP can update it. There are a number of reasons to want to do this securely from both the ISP side and the customer side regardless of whether you secure the DNS responses themselves.
Masataka Ohta
PS
If the server and its clients share some secret for mutual authentication as protection against snooping, there is no point to make forward and reverse DNS secure.
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Mark Andrews wrote:
You misunderstand very basic points on why forward and reverse DNS checking is useful.
If an attacker can snoop DHCP reply packet to a victim's CPE, the attacker can snoop any packet to a victim's server, which is already bad.
The DHCP reply packet is special as is is broadcasted.
What? Rfc3315 is explicit on it: 18.2.8. Transmission of Reply Messages The Reply message MUST be unicast through the interface on which the original message was received.
That is, Mark's security model is broken only to introduce obscurity with worse security.
This is a about adding a delegation into the DNS securely so only the machine that the prefix is delegated to and the ISP can update it. There are a number of reasons to want to do this securely from both the ISP side and the customer side regardless of whether you secure the DNS responses themselves.
And carrying TSIG key in DHCP reply is just secure from the both sides. Masataka Ohta
In message <5279F5E1.9030104@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
Mark Andrews wrote:
You misunderstand very basic points on why forward and reverse DNS checking is useful.
If an attacker can snoop DHCP reply packet to a victim's CPE, the attacker can snoop any packet to a victim's server, which is already bad.
The DHCP reply packet is special as is is broadcasted.
What?
Rfc3315 is explicit on it:
18.2.8. Transmission of Reply Messages
The Reply message MUST be unicast through the interface on which the original message was received.
While IPv6 is unicast, IPv4 isn't and having a scheme that will work for IPv4 as well as IPv6 is useful. Also there is NO GUARANTEE that the response can't be seen so you design the protocol to work when it can be seen.
That is, Mark's security model is broken only to introduce obscurity with worse security.
This is a about adding a delegation into the DNS securely so only the machine that the prefix is delegated to and the ISP can update it. There are a number of reasons to want to do this securely from both the ISP side and the customer side regardless of whether you secure the DNS responses themselves.
And carrying TSIG key in DHCP reply is just secure from the both sides.
Not in the clear it isn't.
Masataka Ohta
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Mark Andrews wrote:
The DHCP reply packet is special as is is broadcasted.
What?
Rfc3315 is explicit on it:
18.2.8. Transmission of Reply Messages
The Reply message MUST be unicast through the interface on which the original message was received.
While IPv6 is unicast, IPv4 isn't and having a scheme that will work for IPv4 as well as IPv6 is useful.
In your draft, you wrote: CPE generates DHCPv6 Prefix Delegation [RFC3633] request which Moreover, even for IPv4, the scheme can (and should) mandate unicast DHCP reply.
Also there is NO GUARANTEE that the response can't be seen so you design the protocol to work when it can be seen.
Your misunderstanding on DHCPv6 is OK, because you also misunderstand that it were more secure? Then, as there is NO GUARANTEE that CAs of DNSSEC can't be compromised, you MUST design the protocol to work when they can be compromised.
And carrying TSIG key in DHCP reply is just secure from the both sides.
Not in the clear it isn't.
Clear text in DHCP reply is just secure when required security level allows to use DHCP. Masataka Ohta
In message <5274DEF9.3040405@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
Mark Andrews wrote:
Over the cable modem?
Yes.
OK.
The cable modem is the CPE, which accept the DHCP packet to it.
A cable modem both accepts DHCP packets (for management of the modem) and passes DHCP packets through to the customer device.
Even if the CPE does so, which means there is no NAT, the key to update rDNS must, naturally, be contained only in DHCP reply to the CPE.
A cable modem is a media converter. That can be managed and that management interface also uses DHCP is irrelevent.
And, I'm afraid your draft assumes that the CPE behaves as a DHCP server for local hosts, which means the CPE is responsible for rDNS registration.
My draft assumes the CPE device is a PD client. It may or may not be a DHCP server for the internal network. Again that is irrelevent.
Masataka Ohta
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Mark Andrews <marka@isc.org> writes:
That said it is possible to completely automate the secure assignment of PTR records. It is also possible to completely automate the secure delegation of the reverse name space. See http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00
I like that. I'd really like to see CPE vendors implementing it. AFAICT, it is perfectly possible to apply that on top of the idea you had about letting TCP clients update their own key. CPEs supporting the DHCPv6 option will use that, while the others still have the ability to add a KEY record from a TCP client in the deletated prefix. As long as you let TSIG signed updates trump anything and do not allow unsigned updates if there is a KEY, then these should work just fine together. But I believe the draft could use a couple of clarifications to avoid interpretation bugs: CPE generates DHCPv6 Prefix Delegation [RFC3633] request which includes a KEY-RDATA option (code point TBA) which contains a the rdata of a DNS KEY record containing a RSASHA256 key using the public components of the previously generated RSA key pair. Is this new DHCPv6 option to be placed under OPTION_IA_PD, or is it a "top level" option? I.e. will it be possible to set different keys for (the theoretical) multi-prefix requests? We've already seen confusion wrt placement of the OPTION_DNS_SERVERS, so it is important to explicitly state where such options, which may be considered local to part of the DHCPv6 message, belong. I do know that RFC3315 is clear on the default: Unless otherwise noted, each option may appear only in the options area of a DHCP message and may appear only once. But experience with OPTION_DNS_SERVERS has shown that this is not enough. Pleace be explicit about where in the packet any new DHCPv6 options belong. CPE device generates DNS UPDATE [RFC2136] which delegates the reverse name space to itself and others if they have been configured. The CPE uses SIG(0) [RFC2931] to sign the request with owner name matching the reverse of the delegated prefix. This could use a few examples and clarifications wrt the owner name. I interpret it as: IA_PD = 2001:db8:1::/48 => owner name = 1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa But what about for example IA_PD = 2001:db8:2:4::/62 ? Are you going to add multiple owner names, or should there be some rule here allowing multiple delegations with a single owner name for PD on non-nibble boundaries? For example IA_PD = 2001:db8:2:4::/62 => owner name = 4.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa allowed to update: 4.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa 5.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa 6.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa 7.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa (not that I would ever consider delegating prefixes on anything but nibble boundaries, but someone else might - and the draft should consider this possibility) Bjørn
In message <87iow8tjw9.fsf@nemi.mork.no>, =?utf-8?Q?Bj=C3=B8rn_Mork?= writes:
Mark Andrews <marka@isc.org> writes:
That said it is possible to completely automate the secure assignment of PTR records. It is also possible to completely automate the secure delegation of the reverse name space. See http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00
I like that. I'd really like to see CPE vendors implementing it.
AFAICT, it is perfectly possible to apply that on top of the idea you had about letting TCP clients update their own key. CPEs supporting the DHCPv6 option will use that, while the others still have the ability to add a KEY record from a TCP client in the deletated prefix. As long as you let TSIG signed updates trump anything and do not allow unsigned updates if there is a KEY, then these should work just fine together.
But I believe the draft could use a couple of clarifications to avoid interpretation bugs:
CPE generates DHCPv6 Prefix Delegation [RFC3633] request which includes a KEY-RDATA option (code point TBA) which contains a the rdata of a DNS KEY record containing a RSASHA256 key using the public components of the previously generated RSA key pair.
Is this new DHCPv6 option to be placed under OPTION_IA_PD, or is it a "top level" option? I.e. will it be possible to set different keys for (the theoretical) multi-prefix requests?
As far as I cans see there is no point in using different key RDATA. All it does is introduce key management problems. I expect a CPE to only use a single public key for all prefixes that are delegated to it. That said we should look at rolling the key. CPE replacement etc.
We've already seen confusion wrt placement of the OPTION_DNS_SERVERS, so it is important to explicitly state where such options, which may be considered local to part of the DHCPv6 message, belong. I do know that RFC3315 is clear on the default:
Unless otherwise noted, each option may appear only in the options area of a DHCP message and may appear only once.
But experience with OPTION_DNS_SERVERS has shown that this is not enough. Pleace be explicit about where in the packet any new DHCPv6 options belong.
CPE device generates DNS UPDATE [RFC2136] which delegates the reverse name space to itself and others if they have been configured. The CPE uses SIG(0) [RFC2931] to sign the request with owner name matching the reverse of the delegated prefix.
This could use a few examples and clarifications wrt the owner name. I interpret it as:
IA_PD = 2001:db8:1::/48 => owner name = 1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
But what about for example IA_PD = 2001:db8:2:4::/62 ? Are you going to add multiple owner names, or should there be some rule here allowing multiple delegations with a single owner name for PD on non-nibble boundaries? For example
IA_PD = 2001:db8:2:4::/62 => owner name = 4.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa allowed to update: 4.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa 5.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa 6.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa 7.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
The DHCP server would add multiple KEY records each with the same RDATA. This would still be a single DNS UPDATE transaction. A non nibble aligned PD results in multiple delegations in the DNS. The CPE would perform multiple DNS UPDATE requests, one for each delegation. Doing it the other way would require telling the nameserver the nameserver that key A is allowed to update B, C and D as well. With multiple keys each one is self describing about what it can update. In terms of named's update policy you would just add this grant clause to the zone configuration on the master to allow the CPE to add/update the delegation. update-policy { grant * self *; };
(not that I would ever consider delegating prefixes on anything but nibble boundaries, but someone else might - and the draft should consider this possibility)
Bj=C3=B8rn -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00 It would be great to have this conversation in the IETF Homenet WG, as well as DNSops. This would solve the gaps I identified. Not sure why I, as an ISP, would spend money on this. Lee
In message <CE9E4E3C.367C3%Lee@asgard.org>, Lee Howard writes:
http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00
It would be great to have this conversation in the IETF Homenet WG, as well as DNSops.
I did send the announcement to homenet as well with reply-to sent to dnsop. While I am in homenet I would prefer the conversation in one place in the IETF. I do realise that it also needs to be here and potentially other places.
This would solve the gaps I identified. Not sure why I, as an ISP, would spend money on this.
What money do they need to spend once the DHCP server supports it? It's a little bit of disk, a little bit of memory, a little bit less DNS traffic to their servers (as the referral will push queries to the customer's DNS servers) which is will come in at cents per customer per annum. Enterprises effectively do the equivalent amount of work today registering PTR records in the DNS using TSIG requests from the DHCP server. Mark
Lee
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Reverse DNS for (typical) residential customer IPv6 addresses is dead, people just haven¹t come to grips with it just yetŠ ;-) When publicly-reachable services in home networks are created that may be a different matter of course. But it is hard to imagine an ISP automatically or dynamically generating reverse records for all the IPv6 addresses handed out to your average residential users. Jason On 11/5/13, 12:31 AM, "Lee Howard" <Lee@asgard.org> wrote:
http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00
It would be great to have this conversation in the IETF Homenet WG, as well as DNSops. This would solve the gaps I identified. Not sure why I, as an ISP, would spend money on this.
Lee
On Nov 6, 2013, at 9:02 AM, Livingood, Jason <Jason_Livingood@cable.comcast.com> wrote:
Reverse DNS for (typical) residential customer IPv6 addresses is dead, people just haven¹t come to grips with it just yetŠ ;-)
When publicly-reachable services in home networks are created that may be a different matter of course. But it is hard to imagine an ISP automatically or dynamically generating reverse records for all the IPv6 addresses handed out to your average residential users.
Jason
On 11/5/13, 12:31 AM, "Lee Howard" <Lee@asgard.org> wrote:
http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00
It would be great to have this conversation in the IETF Homenet WG, as well as DNSops. This would solve the gaps I identified. Not sure why I, as an ISP, would spend money on this.
Lee
Dynamic DNS providers will undoubtably endeavor to make money from AAAA and SRV entries for publicly-reachable services in SOHO and home networks. Dynamic DNS providers are normally not delegated authority to provide PTR records for ISP managed addresses, making provision of complementary AAAA and PTR records highly unlikely. Because of the cost of scaling and delegation issues I agree with Jason and see no compelling business case for rDNS services for SOHO or residential users. It’s dead, Jim James R. Cutler james.cutler@consultant.com
In message <5964ADA4-8FCF-4FCE-9E64-7474CCAE57F2@consultant.com>, Cutler James R writes:
On Nov 6, 2013, at 9:02 AM, Livingood, Jason <Jason_Livingood@cable.comcast.com> wrote:
Reverse DNS for (typical) residential customer IPv6 addresses is dead, people just haven't come to grips with it just yet.;-)
When publicly-reachable services in home networks are created that may be a different matter of course. But it is hard to imagine an ISP automatically or dynamically generating reverse records for all the IPv6 addresses handed out to your average residential users.
Jason
This discussion is currently NOT about ISP's generating PTR records for IPv6 reverse. It is about the automatic delegation of the DNS reverse namespace to to servers under customer control when the CPE device requests it as part of the Prefix Delegation request. This is about a adding KEY, DS and NS records at the delegation point in a secure manner. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
In message <5964ADA4-8FCF-4FCE-9E64-7474CCAE57F2@consultant.com>, Cutler James R writes:
Dynamic DNS providers will undoubtably endeavor to make money from AAAA and SRV entries for publicly-reachable services in SOHO and home networks. Dynamic DNS providers are normally not delegated authority to provide PTR records for ISP managed addresses, making provision of complementary AAAA and PTR records highly unlikely.
Because of the cost of scaling and delegation issues I agree with Jason and see no compelling business case for rDNS services for SOHO or residential users.
Did you BOTHER TO READ the draft before commenting as the comments imply that you haven't. Nothing in the draft is more difficult than is what is already being done inside enterprises networks today every single minute of the day. Enterprise DHCP servers construct DNS PTR records and add them to the DNS using TSIG signed UPDATE requests. They do it at one per machine. This is DHCP servers constucting a DNS KEY record and adding it to the DNS using TSIG signed UPDATE requests. The amount is ONE per customer. ISP's already support a PTR record per customer so your scale arguement is blown out of the water. This is draft addresses the delegation issue by automating it so that any CPE device from any manufacture can perform the delegation without humans being involved. Mark
It's dead, Jim
James R. Cutler james.cutler@consultant.com
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Wed, Oct 30, 2013 at 9:12 AM, Nolan Rollo <nrollo@kw-corp.com> wrote:
RFC draft-msullivan-dnsop-generic-naming-schemes-00.txt states:
I think you mean an "Expired RFC Draft from 2006 written by the people from SORBS states :" Which finally brings me to my questions:
It seems like the unspoken de facto that mail admins appreciate given the IP 203.0.113.15 is "203-0-113-15.[type].[static/dynamic].yourdomain.tld". This seems perfectly acceptable, it's short, detailed and to the point. Is there really anything bad about this?
No. Nothing at all, and as you've already discovered it's what is used by probably the majority of providers that include IP addresses in rDNS.
What, if any would you name a network, gateway, broadcast address? Should the PTR be empty?
I've never seen anyone put in rDNS for networks or broadcast addresses. (Naming networks was common many years ago, but it never made the jump to DNS from what I've seen). rDNS for gateways can be helpful for traceroute, and there are a few documents that provide examples of naming schemes for such hosts, but I can't seem to find them right now... Again, these are only samples - there's not such thing as a "right" answer. On Wed, Oct 30, 2013 at 9:24 AM, Nick Hilliard <nick@foobar.org> wrote:
the only thing that's important is that forward and reverse DNS matches. After that, there is no correct or incorrect, so you need to do something that makes sense for your deployment.
Well, yes and no... It's true that there's no "correct" answer, but there are "incorrect" answers - such as putting the term "dynamic" in the rDNS for an email server. It may not be incorrect enough to break an RFC, but it's still the wrong thing to do! Scott
I've never seen anyone put in rDNS for networks or broadcast addresses.
I've done this a fair bit, on both a personal and professional basis. I find it quite helpful when I forget what the subnet masks are (or fail to apply them properly) and try and Do Something with an address that can't be a host. Regards, Tim.
As for A records and PTR records matching, we've taken the approach that we'll auto-create a matching PTR where there's only a single A record with that IP. Otherwise, we'll add a PTR manually. Plenty of applications can handle multiple A records; I'm not so sure that the same holds true for PTR records. John
On Wed, Oct 30, 2013 at 12:12 PM, Nolan Rollo <nrollo@kw-corp.com> wrote:
RFC draft-msullivan-dnsop-generic-naming-schemes-00.txt states: When using IP addresses in host names, their numbers SHOULD be separated by '.'s (dots) rather than any meta character such as a '-' (dash) and expressed in decimal. Host names SHOULD NOT use the '_' (underscore) character, host names for hosts with any form of SMTP mail service MUST NOT use the '_' (underscore) character. It is preferable to use the IP address in reverse format in the same way the the IN-ADDR.ARPA. domain is defined.
Hi Nolan, Although no longer strictly required by the DNS RFCs, names which follow these conventions are more likely to work with everyone else's DNS servers. 1. Use only English alphabetic characters (a-z, A-Z), numeric characters (0-9), the hyphen and the period. 2. The periods separate non-null sections of the name. You can't start a name with a period or have two periods side by side. 3. Start each section of the name with a letter, not a number or hyphen. 4. Two hyphens can't be side by side, nor can a hyphen start or end a section of the name. Finally, the cardinal rule of reverse dns: whatever name the address resolves to must resolve back to the address. If you don't do that, you're basically asking for a whole bunch of servers on the Internet to reject your connections. So: 13.12.11.10.in-addr.arpa PTR bob.examplecompany.com. bob.examplecompany.com. A 10.11.12.15 is wrong (13!=15) and will cause your users problems! Also, if you omit the A record and simply have the PTR record, that too will cause your users problems. If you omit the A record, you should also omit the PTR record and let the address stand without DNS.
Actual Examples: cpe-67-XX-XX-XX.stny.res.rr.com - 67.XX.XX.XX d28-XX-XX-XX.dim.wideopenwest.com - 28.XX.XX.XX c-68-XX-XX-XX.hsd1.mi.comcast.net - 68.XX.XX.XX 24-XX-XX-XX.static.bycy.mi.charter.com - 24.XX.XX.XX
All of these examples are fine provided the forward DNS (A record) matches.
Which finally brings me to my questions: It seems like the unspoken de facto that mail admins appreciate given the IP 203.0.113.15 is "203-0-113-15.[type].[static/dynamic].yourdomain.tld". This seems perfectly acceptable, it's short, detailed and to the point. Is there really anything bad about this?
This is mainly for the benefit of the folks who run RBLs or other mail reputation services. They use this information when classifying the source and grouping sources into netblocks. If you take the time to distinguish your intended mail servers from your dialup address pool they'll try not to include your mail server when they ban mail directly from your dialup address pool. It's more a human factors question than supporting any automation. You're hoping that by explaining your network to the antispammers they'll cut you some slack when one of your doofus users gets pwned by a spam bot. Many will. Some won't.
What, if any would you name a network, gateway, broadcast address? Should the PTR be empty?
Pretty much whatever you want or nothing at all. If it doesn't originate packets then nobody out there cares what it's named. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Wed, Oct 30, 2013 at 03:22:55PM -0400, William Herrin wrote:
1. Use only English alphabetic characters (a-z, A-Z), numeric characters (0-9), the hyphen and the period.
This was never required by any DNS RFC. Also, they're not English characters, but ASCII ones. The full stop character is not actually part of the name. It's a separator. For presentation format (i.e. the one you see and manipulate) you need to use it, but be aware that it is not a part of the name as such. (This is why IDNA can't provide an "alternate" separator.) In my opinion, it's really better to think in terms of labels. Labels are separated by dots in presentation format, and by label length markers in wire format. In order to maximise interoperability, it is wise to stick to the LDH rule (which is roughly what William says above: ASCII letters either upper or lower case, digts, and the hyphen). But in principle, labels can be made of any octets you like. Note that, if you use IDNA (internationalized labels) in the most recent version (IDNA2008), the U-label form doesn't allow upper case. This yields the bizarre example that Fass is a label (LDG) and fass is a label (LDH) and faß is a label (U-label) but Faß is _not_ a valid label.
3. Start each section of the name with a letter, not a number or hyphen.
This isn't a requirement and hasn't been since the so-called "3com rule" change in RFC 1123. See RFC 1123 section 2.1. The topmost label, however, _cannot_ begin with a number. No label may begin with a hyphen.
4. Two hyphens can't be side by side, nor can a hyphen start or end a section of the name.
Two hyphens can be side be side, but if you plan to be compatible with IDNA they can't be side by side in the 3d and 4th positions. That is, foobar--baz is a perfectly good label. fo--obarbaz is not. This is so that strategies along the lines of "xn--", which is used for INDA, can be used again in the future for other issues.
Finally, the cardinal rule of reverse dns: whatever name the address resolves to must resolve back to the address.
This is a requirement for matching reverse. As I've already suggested in this thread more than once, it is by no means an uncontroversial claim. Best, A -- Andrew Sullivan Dyn, Inc. asullivan@dyn.com v: +1 603 663 0448
So in the four examples below, 3 of them preface the IP with an alpha character. Charter however, starts the rDNS off with a number. I'm not arguing with anyone but what potential problems could that cause with DNS? I'm also thinking of the famous www.1and1.com, where the number "1" starts off one of the sections. <snip> 3. Start each section of the name with a letter, not a number or hyphen. <snip>
Actual Examples: cpe-67-XX-XX-XX.stny.res.rr.com - 67.XX.XX.XX d28-XX-XX-XX.dim.wideopenwest.com - 28.XX.XX.XX c-68-XX-XX-XX.hsd1.mi.comcast.net - 68.XX.XX.XX 24-XX-XX-XX.static.bycy.mi.charter.com - 24.XX.XX.XX
On Oct 30, 2013, at 17:34, Nolan Rollo <nrollo@kw-corp.com> wrote:
So in the four examples below, 3 of them preface the IP with an alpha character. Charter however, starts the rDNS off with a number. I'm not arguing with anyone but what potential problems could that cause with DNS?
None.
I'm also thinking of the famous www.1and1.com, where the number "1" starts off one of the sections.
Which is fine. Joe
On Wed, Oct 30, 2013 at 2:33 PM, Nolan Rollo <nrollo@kw-corp.com> wrote:
So in the four examples below, 3 of them preface the IP with an alpha character. Charter however, starts the rDNS off with a number. I'm not arguing with anyone but what potential problems could that cause with DNS? I'm also thinking of the famous www.1and1.com, where the number "1" starts off one of the sections.
Using domain name parts that start with a number will likely cause issues for anyone running resolvers written in the 80's. Anyone running resolvers that are less than ~25 years will likely not have any issues. Scott
In message <CACnPsNUxTa3vYQSxuTE4x9NXFm_o+2Bp7HqMBApXcm5_G5Zr2Q@mail.gmail.com> , Scott Howard writes:
On Wed, Oct 30, 2013 at 2:33 PM, Nolan Rollo <nrollo@kw-corp.com> wrote:
So in the four examples below, 3 of them preface the IP with an alpha character. Charter however, starts the rDNS off with a number. I'm not arguing with anyone but what potential problems could that cause with DNS? I'm also thinking of the famous www.1and1.com, where the number "1" starts off one of the sections.
Using domain name parts that start with a number will likely cause issues for anyone running resolvers written in the 80's.
Anyone running resolvers that are less than ~25 years will likely not have any issues.
Scott
To be more precise it will cause no problems with the DNS. Some pre RFC 1123 gethostbyname implementations may reject the name but the DNS doesn't care. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Wed, Oct 30, 2013 at 5:33 PM, Nolan Rollo <nrollo@kw-corp.com> wrote:
So in the four examples below, 3 of them preface the IP with an alpha character. Charter however, starts the rDNS off with a number. I'm not arguing with anyone but what potential problems could that cause with DNS?
Once upon a time there were buggy software implementations which looked at the first character of the "name" to decide whether it was a host name or an IP address. How many of them still exist? Not many would be my guess.
3. Start each section of the name with a letter, not a number or hyphen.
The question I would ask myself is: will I recognize a gain from putting a digit first in the name instead of a letter? If yes, it's probably enough of an advantage to not worry about the old implementations. If no (and it surely seems to be "no" in Nolan's case) then keep to the conventions that work even with the ancient buggy crap. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Wed, 30 Oct 2013 21:33:38 -0000, Nolan Rollo said:
So in the four examples below, 3 of them preface the IP with an alpha character. Charter however, starts the rDNS off with a number. I'm not arguing with anyone but what potential problems could that cause with DNS?
Only if the system involved got on the net before 3com did (as RFC1123 specifically relaxed this requirement back in 1989). And at that point, Indiana Jones would say "It belongs in a *museum*".
On October 30, 2013 at 19:07 Valdis.Kletnieks@vt.edu (Valdis.Kletnieks@vt.edu) wrote:
On Wed, 30 Oct 2013 21:33:38 -0000, Nolan Rollo said:
So in the four examples below, 3 of them preface the IP with an alpha character. Charter however, starts the rDNS off with a number. I'm not arguing with anyone but what potential problems could that cause with DNS?
Only if the system involved got on the net before 3com did (as RFC1123 specifically relaxed this requirement back in 1989).
And at that point, Indiana Jones would say "It belongs in a *museum*".
Back when I put Boston University on the net, pre-DNS, an accidentally included host name with a leading digit submitted for the HOSTS.TXT file brought down probably over half the net, many many unix systems. There was a bug in the program which converted from the HOSTS.TXT format to the unix /etc/hosts format. It went into a loop filling the root partitions which in those days hung a unix system hard, and many sites used unix systems as their main or only internet connection, no fancy on-site routers back then. Typically sites loaded the new HOSTS.TXT file after (or exactly at) midnight automatically so not a lot of systems staff around to recover which made it all the more painful. So I heard a lot about this "no leading digits in host names rule" the next day though when everyone calmed down it was agreed that the conversion program shouldn't have behaved so poorly. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
On Wed, Oct 30, 2013 at 8:22 PM, William Herrin <bill@herrin.us> wrote:
Which finally brings me to my questions: It seems like the unspoken de facto that mail admins appreciate given the IP 203.0.113.15 is "203-0-113-15.[type].[static/dynamic].yourdomain.tld". This seems perfectly acceptable, it's short, detailed and to the point. Is there really anything bad about this?
reputation services. They use this information when classifying the source and grouping sources into netblocks. If you take the time to distinguish your intended mail servers from your dialup address pool they'll try not to include your mail server when they ban mail directly from your dialup address pool.
At dnswl.org, we identify new servers from looking at the rDNS in what we see is being queried through our logs. Names with "dynamic", "dialup" etc or that look like they have an embedded IPv4 address are discarded through that channel. -- Matthias
Nolan Rollo wrote:
RFC draft-msullivan-dnsop-generic-naming-schemes-00.txt states: When using IP addresses in host names, their numbers SHOULD be separated by '.'s (dots) rather than any meta character such as a '-' (dash) and expressed in decimal. Host names SHOULD NOT use the '_' (underscore) character, host names for hosts with any form of SMTP mail service MUST NOT use the '_' (underscore) character. It is preferable to use the IP address in reverse format in the same way the the IN-ADDR.ARPA. domain is defined.
That's not correct. Not all domain names are host names, which is why '_' is allowed for some domain names such as: _ldap._tcp.example.com [rfc2782] However, though rfc1034 specifies; For example, when naming a mail domain, the user should satisfy both the rules of this memo and those in RFC-822. When creating a new host name, the old rules for HOSTS.TXT should be followed. both of "should" in the rfc should, today, be interpreted as "MUST". Masataka Ohta
* Nolan Rollo <nrollo@kw-corp.com>:
It seems like the unspoken de facto that mail admins appreciate given the IP 203.0.113.15 is "203-0-113-15.[type].[static/dynamic].yourdomain.tld". This seems perfectly acceptable, it's short, detailed and to the point. Is there really anything bad about this?
Mail admins wanting matching forward/reverse DNS and hostnames that don't "look dynamically generated" is probably more of a human than an RFC thing: "We used to get a lot of spam from dialup IPs, or IPs without matching reverse DNS, so let's reject anything that comes from an IP without FcRDNS and greylist anything with more than X dashes and Y dots in it's hostname." Stefan
Mail admins wanting matching forward/reverse DNS and hostnames that don't "look dynamically generated" is probably more of a human than an RFC thing:
Right. Spam filtering depends on heuristics. Mail from hosts without matching forward/reverse DNS is overwhelmingly bot spam, so checking for it is a very effective heuristic. Mail from hosts with names that look dynamic is also quite spammy, but figuring out what looks dynamic is quite hard. I know someone who's been tuning his regexes for years. For most people, third party lists like the Spamhaus PBL are more reliable. R's, John
John Levine wrote:
Right. Spam filtering depends on heuristics. Mail from hosts without matching forward/reverse DNS is overwhelmingly bot spam, so checking for it is a very effective heuristic.
Leading digit is clearly in widespread use beyond 3com & 1and1. One of the most effective heuristics in my acl list is: \N^.*@\d{3,}\.(cn|com|net|org|us|asia) In the last few hours it has picked off multiple messages from each of these: Carol28@8447.com Jeff17@3550.com Ronald79@0785.com Kevin57@2691.com Deborah76@3585.com Kimberly34@5864.com Sarah94@0858.com zavfdv@131.com qgmklyysyn@163.com pjpeng@163.com fahuyrw@163.com Daniel57@4704.com Helen95@2620.com
In the last few hours it has picked off multiple messages from each of these: Carol28@8447.com Jeff17@3550.com Ronald79@0785.com Kevin57@2691.com Deborah76@3585.com Kimberly34@5864.com Sarah94@0858.com zavfdv@131.com qgmklyysyn@163.com pjpeng@163.com fahuyrw@163.com Daniel57@4704.com Helen95@2620.com
163.com is Netease, one of the larger ISPs in China. If you don't have any users who speak Chinese, you can probably block it, but if you do, you'll get complaints.
163.com (as well as 126.com which you don't have listed) is a bit of a special case. It's a Chinese site that offers free email address as well as a very popular portal site - think of it as the Chinese equivalent to Yahoo or Hotmail. Whilst it's certainly true that a lot of spam originates from there, simply classifying it as a spam site isn't (necessarily) correct, in the same way that classifying yahoo or hotmail as spam isn't correct. The company behind 163.com is actually listed on the NASDAQ... You did mention heuristics, so I'm guessing you're not actually just outright blacklisting it, just wanted to point out that all number-only domains aren't necessarily spam-only. Scott On Thu, Oct 31, 2013 at 3:49 PM, Tony Hain <alh-ietf@tndh.net> wrote:
John Levine wrote:
Right. Spam filtering depends on heuristics. Mail from hosts without matching forward/reverse DNS is overwhelmingly bot spam, so checking for it is a very effective heuristic.
Leading digit is clearly in widespread use beyond 3com & 1and1. One of the most effective heuristics in my acl list is: \N^.*@\d{3,}\.(cn|com|net|org|us|asia)
In the last few hours it has picked off multiple messages from each of these: Carol28@8447.com Jeff17@3550.com Ronald79@0785.com Kevin57@2691.com Deborah76@3585.com Kimberly34@5864.com Sarah94@0858.com zavfdv@131.com qgmklyysyn@163.com pjpeng@163.com fahuyrw@163.com Daniel57@4704.com Helen95@2620.com
participants (26)
-
Alex Rubenstein -
Andrew Sullivan -
Barry Shein -
Bjørn Mork -
Cutler James R -
Dave Crocker -
Jimmy Hess -
Joe Abley -
John Levine -
John Miller -
Lee Howard -
Leo Bicknell -
Livingood, Jason -
Mark Andrews -
Masataka Ohta -
Matthias Leisi -
Mikael Abrahamsson -
Nick Hilliard -
Nolan Rollo -
Sander Steffann -
Scott Howard -
Stefan Förster -
Tim Franklin -
Tony Hain -
Valdis.Kletnieks＠vt.edu -
William Herrin